Project Orbiter MMU (oMMU) development thread

But for landed vessels. You need a location of the place the person hits the surface. Then that EVA vessel moves around. And if near the same spot they exited. They "enter" the vessel. They are destroyed. My ALPCA does that. If entered show a mesh of a guy inside. If exited then don't show the guy inside.

So really maybe a surface based movement guy vessel and the means of entereing/exiting. Transfer via docks. Now that you can have landed docked vessels in 2016. You may need to be able to transfer crew
 
100% agree with not bloating the core/api.

If you were to impliment something like an "astronaut" class it would need to be very abstract. Most of the functionality is already contained in the VESSEL class, except for the EVAing, and transferring.
 
jedidia said:
Hmph... Now that I think about it, considering there's by now a lot of vehicles, sibbling classes to the VESSEL interface for crew and vehicles might not be a bad idea...
Click to expand...
This is along the lines of what I was thinking. The way in which uMMU moved was very strange, and from what I have heard about making such addons, it is quite hack-y. A new class would allow different controls and possibly a more realistic movement. However, I also agree with keeping the core code tidy and not massively blowing it up
 
I think attachments might be a good basis for this. An 'astronaut' is basically a vessel that becomes invisible when attached and magically frees up the attachment port....
So some sort of attachment manager might be needed. The scenario editor already handles docking and fuel tanks. Ideally it could manage attachments.

As for dropping on to the surface and walking, I think that's related to generic landed vessel handling. Not 'astronaut' specific.
A starting point would be to integrate the improvements from "ParkingBrakeMFD".
Vessels already drive around, but some good core functions to handle that (WASD) would be great.
 
n72.75 said:
If you were to impliment something like an "astronaut" class it would need to be very abstract. Most of the functionality is already contained in the VESSEL class, except for the EVAing, and transferring.
Click to expand...
Very abstract for sure. My idea would be to unpack some functionality from the vessel class into some kind of "DynamicObject" class or somesuch, from which vehicles, vessels and astronauts would derive, so you can reuse the code they all share.

EDIT: Alternatively, I guess the whole VESSEL could be restructured as an ECS, so different behaviour can be switched out by composition... But that would pretty much break all backward compatibility. That would be more like a VesselV2 interface...
4throck said:
I think attachments might be a good basis for this. An 'astronaut' is basically a vessel that becomes invisible when attached and magically frees up the attachment port....
Click to expand...
I strongly disagree with such hacks. Anything that happens inside a vessel should stay inside that vessel. Leave it to vessel implementations what they do with astronauts on board. That is exactly the kind of thing I would keep out of the core like the pest. What the core would need to provide is a common interface for vessels to accept or spawn astronauts, and perhaps some minimally functional base class for the astronaut when it's outside any vehicle.
As soon as it's inside anywhere, it should really seize to exist for the core, or at least be removed from any calculations.
 
Last edited:
I agree - leave it to the vessel implementation. Same for the astronaut base class. This could also be done by a framework. Much more important would be a common definiton which astronaut vessel to spawn.

Also, from a roleplaying game fan perspective, any kind of standard, how to describe an astronaut to be exchanged, would be nice. In the worst case, its protocol buffers, XML or JSON and its still fine, as long as frameworks can support it.

An Orbiter Standard Framework library would be nice, but:

 
I agree with not utilizing attachments. That presents problems with larger vessels, and I may have been the only one to see them thus far when coding dll versions of the Cortez and Agamemnon., namely (and I'm going by memory from years ago) that anything attached to an attachment point farther than 999.99 m from the vessel's center of gravity seems to cause the vessel mesh to disappear. See this post in the Cortez development thread. It references UCD and UCGO's included limitations, but I found that when using good old-fashioned attachment points and defining them in the config any farther than this caused the core to bug out. If I pulled the number below this threshold, everything worked fine.
 
For non surface eva. creating the person and docking them seems to work. Docking at the hatch. That way they don't float away. For surface i guess a location needs to be stated.

For the shuttle 2016. I use attachment point. But that is so the guys can be moved,.....
 
Do you want to make this discussion about frameworks for implementing generic Astronaut entites its own thread so that @Woo482 can keep his thread about this specific project on-topic?
 
4throck said:
Aren't fuel tanks handled by Orbiter's API ?
Click to expand...
I assume they're handled by the VESSEL base class. And it's not always advantageous. I would sure have appreciated if propellant resources themselves were an overrideable base class, exactly because if you want to implement fuel mix, they keep getting in the way...
 
4throck said:
Aren't fuel tanks handled by Orbiter's API ? You don't need to add any custom code, unless you want implement fuel mix or something like that.
Click to expand...

The propellant tanks are also needed externally - for the mass of the spacecraft. If you need special behaviour beyond Newton, you need to write a wrapper around the propellant resources.
 
jedidia said:
I assume they're handled by the VESSEL base class. And it's not always advantageous. I would sure have appreciated if propellant resources themselves were an overrideable base class, exactly because if you want to implement fuel mix, they keep getting in the way...
Click to expand...
Yes, consumption is done in Vessel.cpp in the UpdateThrustForces function: https://github.com/orbitersim/orbit...5b6b06d8bc605802/Src/Orbiter/Vessel.cpp#L3852 . It is also initialized or reset in that class.
 
Xyon said:
Do you want to make this discussion about frameworks for implementing generic Astronaut entites its own thread so that @Woo482 can keep his thread about this specific project on-topic?
Click to expand...
Don't make me tap the sign.
 
Xyon said:
Don't make me tap the sign.
Click to expand...
I think those initially starting it read your statement as question. I wouldn't mind if you move or delete my post during a clean-up.
 
Face said:
I think those initially starting it read your statement as question. I wouldn't mind if you move or delete my post during a clean-up.
Click to expand...
I've been a parent too long, it's one of those questions where the answer is fine as long as it's "yes"
 
n72.75 said:
Ummu was fairly ubiquitous back in the O2006/O2010 days. I would gather that this was due, in no small part, to the number of compatible vessels it shipped with.
Click to expand...
All those addons will be obsolete in the x64 era, anyway.
 
Would @dbeachy1 be interested in releasing an oMMU xr fleet?

That would really motivate people to use it.
 
You must log in or register to reply here.

Similar threads

gattispilot
Programming Question Touchdown and eva
2
Replies
25
Views
3K
gattispilot
gattispilot
Matias Saibene
Update Multistage2026 - Development thread
5 6 7
Replies
137
Views
21K
gattispilot
gattispilot
Matias Saibene
Discussion TileEdit on Windows development thread
Replies
12
Views
3K
Matias Saibene
Matias Saibene
GLS
Discussion Space Shuttle Vessel - Payload Development Thread
6 7 8
Replies
143
Views
34K
Tiny_Bob
Tiny_Bob
nens86
  • Poll Poll
Gaming COSMORAMA Space Flight Simulator
Replies
9
Views
2K
nens86
nens86
Back
Top