Project Universal Car for Orbiter (UCO)

Back in topic: first test show that concept of "UMMU action" seem to work. (see above) Maybe only doug and me would use it !? but hey... :)

Dan
 
Back in topic: first test show that concept of "UMMU action" seem to work. (see above) Maybe only doug and me would use it !? but hey... :)

Count me in as well, the Black Dart is maybe not yet scheduled for release, but since it uses UMMU and has already a lot of "surface" for EVA, it would be a "must-have" feature to add - I already have two access doors, and I want more. :thumbup:

Also, together with the hangar, it would then be easier to install a new payload, during the turn-around, if you can direct actions from UMMU.

I just don't know, if I can make use of the cargo feature there, since the Black Dart has no cargo hold of it's own (you would have to bolt a cargo carrier into the payload bay) and stores its small cargo in drawers, similar to the MPLM.

Now that the Ares I-X is done and DaveS still busy with the launch complex, I want to get the Black Dart forward, so I can aim for a release, but I doubt I will finish it before you are done.

It is a bit sad that there are only very few people making such add-ons, but I'll keep on doing missionary work. :cheers:
 
Count me in as well,

Great, I'll test the concept on you then :)

Let me explain:

Using UMMU SDK you can declare "active" area around your vessel in local coordinate with radius. You give the ID you want to this area, the type of action "repair" "open" etc OR a wav filename. At run time you can edit those area, delete them, change them, set them on or off.

Something like This: (pseudo code)

Code:
DeclareUMMUActionArea(ID,LocalPos,Radius,ON,"DontTouchMyBeer.wav");
In clbkPostStep you have a function that will return if a UMMU pressed the "action" button giving you the ID of the area:

Code:
Returned=GetUMMUActivatedActionArea();
if(Returned==ID)
{
     // the bad guy drank my beer, launch a missile on him
}
And in UMMU the wav will play when the guy press the button. (given you provided the sound)

Now as you can edit the area you may do something like that for example for a door:

Code:
Returned=GetUMMUActivatedActionArea();
if(Returned==ID&&DOOR_OPEN)
{
     EditUMMUActionArea(ID,NULL,NULL,NULL,"DoorIsClosing.wav");
}
else if(Returned==ID&&DOOR_CLOSED)
{
     EditUMMUActionArea(ID,NULL,NULL,NULL,"DoorIsOpening.wav");
}
With such system you can define complex action for example for repair:

Code:
if(Returned==ID&&RepairStep=1)
 {
      EditUMMUActionArea(ID,NULL,NULL,NULL,"OkNowGoToRedPanel.wav");
    RepairStep=2;
 }
else if(Returned==ID&&RepairStep=2)
{
     EditUMMUActionArea(ID,NULL,NULL,NULL,"OkNowReturnToEngine.wav");
    RepairStep=3;
}
else if(Returned==ID&&RepairStep=3)
 {
      EditUMMUActionArea(ID,NULL,NULL,NULL,"GreatEngineArOkNow.wav");
    RepairStep=4;
 }
else if(Returned==ID&&RepairStep=4)
  {
       EditUMMUActionArea(ID,NULL,NULL,OFF);
}
Now I can also define a second declare function with another parameter instead of sound that could define somes defaut feedack sound:

eg:
Code:
DeclareUMMUActionArea(ID,LocalPos,Radius,ON,DOOR_ACTION);
When the UMMU press the action key it will hear "Door activated" and the function will return the activated ID as with the previous function.

Code:
 Returned=GetUMMUActivatedActionArea();
Does it sound enough simple ? understandable ? practicall ?

Dan
 
Last edited:
Okay , here's an image of the SDK header with how it could look:
Does this sound good ? (appart typo of course ;) )

UcgoPreviewtruck9.jpg
 
Last edited:
Thought I might get in on the act, ;)

Would something like this interest you Dan ?
 

Attachments

  • lift_truck.jpg
    lift_truck.jpg
    32.2 KB · Views: 35
Okay , here's an image of the SDK header with how it could look:
Does this sound good ? (appart typo of course ;) )

UcgoPreviewtruck9.jpg


Looks good to me;
 
Ah yes, the joyous smell of scope creep in the morning. I love it! Great work Dan, UCGO, UMMU, and the DGIV just keep getting better and better! :D
 
Dan, it seems as if you anticipated my future needs with this action feature. :thumbup:

One question I have: It seems that pretty much everything will be editable on runtime. That's great for debugging, but it might make it a bit too liable for "cheating". Do you plan to implement a possibility to deactivate runtime editing?
 
Dan, it seems as if you anticipated my future needs with this action feature. :thumbup:

One question I have: It seems that pretty much everything will be editable on runtime. That's great for debugging, but it might make it a bit too liable for "cheating". Do you plan to implement a possibility to deactivate runtime editing?

Self restraint?
 
The only point of criticism I see, is that the audio file parameter is mandatory, it would be nicer if it could be omitted by having a default parameter, or by editing the sound files into the action area. Polling the actions is OK, is the list of ids per vessel or global?

There should not be too much detail in the interface itself, especially not artificial limitations... leave it to the add-on developer, he knows best how to ruin his add-on.
 
One question I have: It seems that pretty much everything will be editable on runtime. That's great for debugging, but it might make it a bit too liable for "cheating". Do you plan to implement a possibility to deactivate runtime editing?

Sorry maybe I didn't get your point but this SDK is for author, once compiled into their addon there is no possibility of "editing"

The only point of criticism I see, is that the audio file parameter is mandatory, it would be nicer if it could be omitted by having a default parameter, or by editing the sound files into the action area. Polling the actions is OK, is the list of ids per vessel or global?
For audio the author might enter NULL instead of a filename, I'll add that in the doc. In this case the UMMU will have no feedback sound, that's not very user-friendly.

The id list is per vessel and doesn't matter at all for UMMU you enter what is most convenient for your zone, 198765 as well as 1,2,3. This is the number that will be returned to you if the area is activated.

About details, does it look good as it is now do you see something missing or not clear ? Is 10 area per vessel to limited ? (as you can edit in in real time it seem it's largely sufficient)

I'll add also a defaut "action_click.wav"

Dan
 
Last edited:
Hmm... ten would be a bit limited, I already get 17 action regions just by quickly going over the existing places for interaction:


  1. Opening/closing the outer hatch
  2. extending/retracting ladder
  3. manually opening/closing ventral payload bay doors
  4. remove/install port wing payload
  5. remove/install starboard wing payload
  6. extend/retract port wing pylon
  7. extend/retract starboard wing pylon
  8. remove/install centerline payload
  9. remove/install port door payload
  10. remove/install starboard door payload
  11. remove/install bay payload A
  12. remove/install bay payload B
  13. remove/install bay payload C
  14. remove/install port wingtip payload
  15. remove/install starboard wingtip payload
  16. open/close port MPS access door
  17. open/close starboard MPS access door
And I could easily see more places for it - like a red rapid power button on the front landing gear or more access doors for in-flight repairs. The editing of action areas would make sense for repairs, which are forcing the player to be done in the desired order.

I am sure, other add-on devs would get into similar magnitudes quickly. and the next thing I see: Once you have such a feature, add-on devs will sure find more good ideas for such actions, approaching the maximum rapidly unless you make the interface so hard and complex to use, that it hurts.

Currently, I planned to allow accessing such features over a custom function dialog in Orbiter, your action regions would be less of a work around. while the larger payloads could also be handled by a dialog inside the Black Dart, I wanted to have a lot of small stuff that can be carried by a UMMU.

Maybe 32-40 would be a better initial limit, also you should maybe ask anemazoso about his personal estimates...he wants to make Overton a UMMU compatible vessel, and could likely need more than 10 action areas over the whole area of the base.

Could you maybe allow some S.C.U.M.M (the scripting engine behind games like Monkey Island or Day of the Tentacle) like verbs to be connected to a action? Like "OPEN", "CLOSE", "REMOVE", "INSTALL", etc. A single enumeration parameter with the verb would be enough, the add-on vessel itself could decide if this works or not.

While I see the audio feedback argument, let me, in a weak attempt, add a counter argument: I don't want to torture people with my voice, when I do the voice acting myself.
 
Last edited:
Okay, not a problem anyway, I'll increase the limit to 40-50

About voice the problem is that you don't have access to UMMU from your vessel, so the best you can do to give feedback is oapiDebugString wich is not very great.

mmmmhh...now maybe I can allow also to pass a text that could be displayed inside UMMU VC.

You'll have the choice of text and/or voice or nothing.
Yes, it sound good, I'l add that possibility in DeclareActionArea and a SetText...

The interface will be exactly the same then now, so it's not very complicated and cover almost all the cases possible. A good middle point beetween too complicated (script multicase action) and "brute" (return you only the pos of UMMU that clicked around you, charge for you to do all the work: play sound, display text etc)

Dan

---------- Post added at 01:35 PM ---------- Previous post was at 01:01 PM ----------

Now, what key inside UMMU for "action key" !?? :)

CTL+A ?
 
Last edited:
About voice the problem is that you don't have access to UMMU from your vessel, so the best you can do to give feedback is oapiDebugString wich is not very great.

mmmmhh...now maybe I can allow also to pass a text that could be displayed inside UMMU VC.

Most of the stuff I have on my list would also be visible by animations and maybe spawning vessels. Also possible feedback paths are light-beacons and other visual manipulations (for example emissive surfaces)

The interface will be exactly the same then now, so it's not very complicated and cover almost all the cases possible. A good middle point beetween too complicated (script multicase action) and "brute" (return you only the pos of UMMU that clicked around you, charge for you to do all the work: play sound, display text etc)

OK.

Now, what key inside UMMU for "action key" !?? :)

CTL+A ?

Why not RETURN? It is the second-biggest and least used key on all keyboards. ;)
 
Why not RETURN? It is the second-biggest and least used key on all keyboards. ;)

Sold !

Dan

---------- Post added at 02:37 PM ---------- Previous post was at 02:24 PM ----------

For test purpose I'll implement open/close lift in Arrow freighter.
So just stay below or close to Azure or crew lift and press "ENTER" to stow or deploy it.

This new feature open again a new set of possibilities: bases lights, doors, failures etc..

PURE FUN !!! :)

Dan
 
Back
Top