UCGO compatible vessels

[computerex]

How do you determine if a given vessel is UCGO compatible at run-time? Also, I realize that the SetUcgoVisual() method is used to transform the mesh groups for the rotational offset of the cargo, so why doesn't this work?

Code: [Select]

VISHANDLE vis = oapiObjectVisualPtr(GetHandle());
if ( vis == NULL ) return;
hUcgo.SetUcgoVisual(vis); // crashes Orbiter

Is there a way for UCGO to work properly when you don't have access to clbkVisualCreated() ?



Post Edited ( 01-31-10 08:26 )

[DanSteph]

computerex a écrit:
Is there a way for UCGO to work properly when you don't have access to clbkVisualCreated() ?

If you have a vessel dll you have forcely access to clbkVisualCreated. It only miss the header and body declaration.

Hope this help ?

Dan

[computerex]

Well that is the thing, I don't have a vessel dll... Thus I don't have access to the clbkVisualCreated method of any
vessels. BTW, how do you at runtime determine if a given vessel is UCGO compatible?

[DanSteph]

computerex a écrit:
Well that is the thing, I don't have a vessel dll...

Ah you mean you want to code that from a mfd ? oapiObjectVisualPtr(GetHandle()); never worked for me if I remember well.

computerex a écrit:
how do you at runtime determine if a given vessel is UCGO compatible?

No need for that, vessels don't need to know if another one is compatible as you cannot transfer cargos.

Dan

[computerex]

If you take a look at the newest release of UMMUFA: http://orbithangar.com/searchid.php?ID=3509 It'll implement UMMU support for any vessel that has a docking port. The latest release takes out all fussing from the user point of view. If you have a docking port, you are UMMU compatible. No questions asked. Pressing TAB+LEFT brings up a user-friendly "add crew member" dialog box.

I want to add UCGO functionality in the UMMUFA module, so that any vessel with a docking port will be both UMMU compatible, as well as UCGO compatible. Furthermore, combining those two modules will allow me to do things like
oxygen management for all ships, waste management, etc. That will be really really cool! The majority of the vessels are spacecraftx.dll/cfg based, only a couple well known ones are dll-based ones. This effectively makes UMMU/UCGO
unavailable to the majority of the vessels in the simulator, thus completely destroying the vision of creating a widely used standard.

In order to do that, I need to know whether a given vessel is UMMU compatible and UCGO compatible. You have already told me how to find out if a vessel has UMMU coded in natively in another thread. But I don't know how to figure out if a given vessel is UCGO compatible on runtime. Otherwise the system will attempt to add UCGO functionality to a vessel like the DGIV. It is best if there is a way to figure this out on runtime. Otherwise I'll have to make a list of all the known UCGO compatible vessels. The list will have to be manually maintained.

I wonder why oapiObjectVisualPtr doesn't work with your SetUcgoVisual method. Perhaps this is an issue with the Orbiter core that needs to be reported? If I can't find a way to bypass that, this will just end up being a limitation for the system.



Post Edited ( 01-31-10 23:05 )

[DanSteph]

mhhh... at first I cannot find a way to detect UCGO vessel. UMmu vessel needed something characteristic because UMmu need to find airlock but this is not the case of UCGO.

My point:

UCGOFA & UMMUFA is great in one way because it allow anyone to add without any effort Crew & cargo to even a cube but in other way I'm sure it prevent some peoples to try making DLL and a serious job. So with all Spacecraft & "FA" application we end with many vessels for sure but they all have the same default and not well integrated systems, only the mesh change. So at the end we might exchange number vs quality but that's maybe another debat ?


Now I'm very happy that UMMUFA is mature. (Congrat ) Of course every vessel have a crew and if kids want to put 40 guy in a Shuttle at least they are virtual in vessel so it's not so serious.

BUT for UCGO adding cargo at any place without any check and a minimum consistancy is imho not great at all. There is no point to add 40 cargos floating in air near a ShuttlePB, this was not at all the point of UCGO and it would for sure prevent peoples to make DLL. Why bothering looking at C++ (which is not much than a big interactive script) or add UCGO to a dll when everyone can simply open a dialog ?

So I would personnaly leave UCGOFA to AT least the choice of authors: They need to write a simple "ucgofa" config file with slots position, max number of cargo, weight limit, release pos (on ground) grapple distance, visibility, crew number etc. etc. Limitation is that without "visual" they cannot give another rotation than flat but that's not a serious problem. (slot are cubic anyway)

This way you have consistency, better integration and no problem to detect "UCGO". What you think ?

As said for UMMUFA I don't care but if UCGOFA allow any users (not author) to glue cargo on Ariane's body I would be
personnaly worried. That's not serious, not a way to increase addons quality and not the main point of UCGO.

Dan



Message modifié ( 01-02-2010 00:12 )

[computerex]

The thing is, people are generally speaking scared of messing with cfg files...UMMUFA for example, the first release required the user to create the cfg file manually. There were examples included. But generally speaking, people thought it was hard to work with. So, in the next release, a GUI was included. To create the cfg describing the vessel's limitations and characteristics, you had to press TAB+D, and the GUI would have popped up. This too was considered too user-unfriendly. Until finally, I just said: "The heck with it". You couldn't have features like the crew dying when the landing was too rough, or the ship being disabled when there was no captain. You didn't have a seat limit. BUT, you had a UMMU compatible vessel if you had a docking port.

SO: The more customizable your add-on is = The more complex it is = The more head scratching there is :D
Unless of course you are excellent at making things user-friendly. I don't have any real life experience in software
engineering, so I don't know how to make things very user-friendly.

In any case, I think I will go with your suggestion. A cfg file defining all the characteristics of the vessel. This should
be interesting :D

ps. How much O2 does a mmu consume per second :D ? If I am going to do oxygen management I want to use existing values rather then create new ones.





Post Edited ( 02-01-10 01:15 )

[DanSteph]

computerex a écrit:
The thing is, people are generally speaking scared of messing with cfg files

Imho an addon worth only the time and effort that one have put into it. If we should exchange 7 addons well done against 50
mesh that all have the same unrelated behaviour I'd personnaly not hesitate.

I mean, Peoples that are scared about 15 parameters in a config or reading a 5 pages doc should NOT be allowed to post on O-H.

computerex a écrit:
In any case, I think I will go with your suggestion. A cfg file defining all the characteristics of the vessel. This should
be interesting :D

Great, if you need help or simply an advise I'm used to "user friendly" interface.

Imho the cfg must be self explanatory as cars's cfg

Code: [Select]

MAX_NBR_CARGO =                                         ;max cargo that a vessel can load
MAX_CARGO_WEIGHT=                                    ; max total cargo weight that a vessel can load
....
SLOT1_POSITION =                                          ;x,y,z position of cargo slot 1 in vessel local coordinate.

Even an idiot would be able to do such a cfg I bet you'll use the vessel's classname ?

ie: "config/vessels/UCGOFA/DeltaGlider.cfg"

ps. How much O2 does a mmu consume per second :D ? If I am going to do oxygen management I want to use existing values rather
then create new ones.

I think one should allow flexibility, real number doesn't mean anything, one just need to count in "breathable month/humain"

I've a code where you simply enter the number of breathable month given a 0%-100% tank level and number of pax aboard. The
guy would just need to enter a

Code: [Select]

NBR_MONT_O2 =                                         ; duration in month/man of oxygen reserve (min 0=unlimited max=100)

I've code ready for you if you want.

Also I think UCGOFA should allow to refuel o2, fuel (and maybe food) tanks with cargos.

Again I've code.

Best

Dan

[dziwigor]

WOW, good idea with that "days per man" value.
but still - shouldn't usage of O2 (and food! yeah! starving crew - cool) change ship's mass?
and if it does we should determine how much it changes?

or maybe these changes are to small to affect overall mass?

+++ edit +++

speaking of weight: UMMU has param. "weight" - where it comes from? I mean I cannot set it to specified value by any means... byt i guess that this 100kg per human range is to small to be considered... am I right?



Post Edited ( 02-01-10 12:31 )

[computerex]

When you consume a cargo, you have to manually update the mass of the vessel. The plan is to create a propellant
source for each cargo type (O2, food, etc). Then you can modify the propellant current mass to update the changes.

[DanSteph]

I personnaly don't bother with such complication (o2 weight is usually minor) that can lead to other problems.

Anyway if you do it remember to not update the weight every frame
that could seriously mess Orbiter's calculation.

Also each call of setweight should be followed by a ucgo setweight refresh
(see header of ucgo)

But seriously I never updated any weight for o2 and nobody never noticed (shhht)

Dan

[ar81]

computerex wrote:
When you consume a cargo, you have to manually update the mass of the vessel. The plan is to create a propellant
source for each cargo type (O2, food, etc). Then you can modify the propellant current mass to update the changes.

When you consume a consumable, there is no need to update vessel or UMMU mass or consider it as "propellant"
unless you jettison material to space.

O2 becomes CO2 when you breath.  And since both are in the same closed area, called spacecraft, mass remains the
same.  The same amount of atoms of different elements are only rearranged in different ways through chemical
reactions.  But mass remains the same.

Of course, if you want to track how much mass you have of each substance, you may need to refer to consumption
rates.  In the case of oxygen and food, it depends on the level of human activity.  A human that is resting consumes
less than one that is engaging in physical activity.