Project Universal Car for Orbiter (UCO)

[Dman1410]

inside that box of rations you could even find another box of rations or the almighty Probe :rofl:

 

[Ghostrider]

There is always at least one ration of chicken inside it.

As long as there is no long pig...

 

[Messierhunter]

Aaah I think I get it, you mean that ISOTAP spawn something else when landed ? Like Spirit for example ?

Yup.

That's left to author of the "module" spawned by cargo, in other word ISOTAP will not do it but one can rewrite my code or make another code that do such thing.

So in other words, all the user would really have to do is add a UCGO config file for ISOTAP to get it to spawn something else, or would it require us to rewrite the dll module for ISOTAP?

One neat idea for "active cargo" would be nuke missiles but only for a precise purpose: destroying incoming and dangerous Asteroids. Packed the nuke would look like unassembled, UMmu would be required to unpack him (construct) and also activate him. (countdown ? target etc?)
Such addon would require to be released with exploding asteroids as target and somes good "hurry" scenarios to go with.

Unfortunately such scenario is realistic but it might be fun for Orbiter (I think this exist already maybe for a previous version of Orbiter?)

Dan

That would be a whole lot of fun!

 

[dansteph]

Yup.
So in other words, all the user would really have to do is add a UCGO config file for ISOTAP to get it to spawn something else

Yep, just create a new cargo config file with "spawn line" into it. Isotap is the final module just a demo to show that cargo can spawn modules. I'ts not really part of the "SDK". (appart that I give the source if asked)

Say you want a cargo that transform in ShuttleA just create a config file with for example this name:

"UCGO_CargoShuttleA.cfg"

And inside it would look like this:

; === Configuration file for UCGO cargo ===
ucForceName    = cSHUTL        ; Force object name when cargo is released max 6 char.
Module         = UCGODynamicCargo    ; if this cargo is active (chute,unpack, module etc)
Mass         = 3560            ; mass of content in kg
MeshName     = MyShuttleABox        ; Box mesh name (packed cargo)
UcDescription     = Auto unpack ShuttleA    ; description
ucSpawnModule    = ShuttleA          ; name of vessel config to spawn once cargo released.
ucSpawnDelay    = 15            ; delay in seconds of module spawning after cargo release (max 600)
ucSpawnCondition= 2            ; 0=Landed 1=Not landed 2=Always 3=unpack by UMmu

Now if you want a cargo that transform in universal car you can do it also, here a cargo that would spawn the Azure rover once unpacked by UMmu:

; === Configuration file for UCGO cargo ===
ucForceName    = cAZUR            ; Force object name when cargo is released max 6 char.
Module         = UCGODynamicCargo    ; if this cargo is active (chute,unpack, module etc)
Mass         = 4000            ; mass of content in kg
MeshName     = MyAzureBoxMesh    ; Box mesh name (packed cargo)
UcDescription     = Azure rover Cargo    ; description
ucSpawnModule    = UCGOCarAzure          ; name of vessel config to spawn once cargo released.
ucSpawnDelay    = 0            ; delay in seconds of module spawning after cargo release (max 600)
ucSpawnCondition= 3            ; 0=Landed 1=Not landed 2=Always 3=unpack by UMmu

I'm not sure if all the differents possibilities of UCGO cars and cargo SDK are clear for everyone ? But anyway I'm thinking about the doc since a long time. There will be a clear and comprehensive html doc that will expose with images link all what can be done with the requirment for each things. (C++ Yes/No Config yes/No, Meshes etc) and help authors to choose and navigate to the correct information. Once selected it might open a pdf or other ressources (example model of the cargo box, rough car shape to see orientation, size, C++ SDK doc etc)


Dan

 

[garyw]

Very neat Dan. I think even I can handle editing config files! :thumbup: This makes UCGO very flexible. Really looking forward to this. Great stuff.

 

[dansteph]

Say hello to Ludmila the pretty UMmu technician.
She say "sorry to look so dirty" but she just worked on Arrow's engine.

"May I help you working on this engine ???"

Let not hide the sh... detailled faces does not support very well
the 12 o' clock light. (Say hello to vampirella, the pretty monster)

Dan

 

[Lucy]

More awesome! MOAR!

 

[Urwumpe]

On a side note, can you remove the debug string interface (the numerical commands) for the MKSAT payload in UMMU and maybe implement it as some sort of virtual PDA or HUD mode?

 

[dansteph]

On a side note, can you remove the debug string interface (the numerical commands) for the MKSAT payload in UMMU and maybe implement it as some sort of virtual PDA or HUD mode?

That and the Prelude base to adapt for breathing base etc etc... There would be easy 1 month of work on the DGIV if I want to do things correctly.

So, no promise, also the MTKS sat is obsolet imho, everyone played with him during two years ? The ISOTAP might be a better toy for the DGIV ?

Dan

 

[the.punk]

Nice.
How many different UMMU people do you have now?

 

[Ghostrider]

Say hello to vampirella, the pretty monster

OK, now we'll have to EVA her into the sunlight to see if she sparkles.:thumbup:

 

[dansteph]

Nice.
How many different UMMU people do you have now?

Can't check yet put it still miss me 2 or 3. (3 if I want to redo the "gorilla doc")

I'm doing yet the VIP then I'll do the simple Crew (white spacesuit) and I'll see about Mr monkey.

Dan

 

[Urwumpe]

So, no promise, also the MTKS sat is obsolet imho, everyone played with him during two years ? The ISOTAP might be a better toy for the DGIV ?

Well, I played with it, it actually just more about the interaction between payload and UMMU astronaut...but I could maybe do a really dirty replacement for the functionality as Plug-in for orbiter.

 

[Dig Gil]

I'm doing yet the VIP (...)

Is this the reference picture?

:tiphat:

or this one?

 

[dansteph]

he he, thanks but I started already.

Dan

 

[Urwumpe]

dansteph: Do you plan to make custom name tags for the UMMUs?

 

[dansteph]

Tricky question... I think about this since a long time. Here are my thought.

EDIT:

[.... long and complicated post removed...]
I just had an evil idea about ID.... would allow for anyone to add their own or modify existing ID and for addons to install their custom id with link to existing or custom mesh without requiring cfg edit from users.

Now follow the idea:

in config/UMmuIDConfig there would be several empty config files on wich filename would set name of mesh to use, name and ID.

Example:

UMmuVIP-Very important person-Vip.cfg
UMmuP-Captain-Capt.cfg
UMmuSCI-Biologist-Bio.cfg
UMmuSCI-Scientific-Sci.cfg
... etc etc

Now this has several advantage over a unique config file:

• Addons that would add their own ID and/or mesh would simply add a new file in the zip without requiring users to modify a unique config file or worse overwritting the default config.

• Default config file could be modified by users but not changed by addons (as a different filename could not overwrite the existing file)
• The list is nor more internal to the sdk, doc could list the defaut ID but add a note to look into this folder for complete list.
• Last as meshname is at start of filename a "order file by name" would immediately show all ID that use "Sci" meshe for example.

I think this is the solution I searched since a long time: flexibility performance (only the first Ummu grab the list) and security.

What y a think ?

Dan

 

[jinglesassy]

whats so hard about writing a few lines of a .cfg file?

 

[Arrowstar]

whats so hard about writing a few lines of a .cfg file?

Just one more installation step. It's also significantly easier to just unpack a bunch of files into the Orbiter directory than it is to make the user go modify a file. Besides, you know there are newer users out there that will get it wrong...

 

[dansteph]

whats so hard about writing a few lines of a .cfg file?

You are an addon author you want to add/modify your own mesh/id and distributes it.

• 1-You overwrite the config file, thanks for other addons that have done that already, for the default installation and/or for the user that maybe didn't expected his UMmu's/modifications replaced so roughly (either default, either addons) (Not all authors are stricts with docs and work, that's not a critic, only the reality: all "aces" where "noobs" one time included me)

• 2-You ask in a readme to your users to modify this config file.

1-Is horrible any addon a bit .. well.. "weak" may completely mess your UMMU installation (and maybe other addon install if they provided own id/meshe)

2-Is not better, I personnaly expect to buy a fully fonctional car and not rework the engines before using it or read the full manual before trying. Also too many users don't read or want to put hand in the dirt or don't know how and this is not my view of a quality addon wich should work right out of the box and resist to bad manipulation/install.

With the system above you have the better without the worse: authors can add things without any risk (to mess or be messed later) and users are not asked to install addon by hand.

Make sense ?

Dan