Discussion Frameworks for implementing generic Astronaut entites

Sbb1413

Well-known member
Joined
Aug 14, 2018
Messages
948
Reaction score
373
Points
78
Location
India
Preferred Pronouns
he/his/him
According to the comment by @Xyon at Orbiter MMU (oMMU) development thread:
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?
So I decided to open this thread to continue the discussion about frameworks for implementing generic Astronaut entites. I'm interested in this discussion.
 
Last edited:

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,261
Reaction score
3,238
Points
203
Location
Toulouse
What do you mean by "framework" ? To me it seems like software-architecture related stuff.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,632
Reaction score
763
Points
128
Some kind of custom visual interface would be useful. As an example launch pad structures should be visuals in a same way as a vessels are, without physics of course but maybe with animations. Currently light and shadow interaction between vessels and launchpads is difficult due to being rendered separately from eachother.
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,261
Reaction score
3,238
Points
203
Location
Toulouse
Which is what a framework is all about

Yeah, that's pretty much what I had in mind. But the term is rather generic, so it doesn't hurt to be specific. (y)

Some kind of custom visual interface would be useful. As an example launch pad structures should be visuals in a same way as a vessels are, without physics of course but maybe with animations. Currently light and shadow interaction between vessels and launchpads is difficult due to being rendered separately from eachother.

That's a thought I had during all those years, but for rocket assembly purposes. Something like a Virtual Cockpit in fact, surfaces rendered in 3D you can click on. In theory we could make any kind of GUI that way. In theory. As you say light/shadow is currently a limit (but could be good enough for a simple interface ?).

OR maybe it can be done through implementing interfaces more advanced (and lets be honest, visually attractive) than Win 98 dialog boxes, now that Orbiter's code is Open Source. Probably less jury-rigged than the other option.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,835
Reaction score
2,098
Points
203
Location
between the planets
Some kind of custom visual interface would be useful. As an example launch pad structures should be visuals in a same way as a vessels are, without physics of course but maybe with animations. Currently light and shadow interaction between vessels and launchpads is difficult due to being rendered separately from eachother.
You're quite a bit off-topic, but I fully agree none the less!
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,672
Reaction score
1,329
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
So other then the features the Vessel class provides, what features does an "Astronaut" need. To me it it sounds like it's mostly the same, other than the ability to be "in" and go "between" vessels. And that sounds like more of an extension to the Vessel class: some kind of "payload".

How is that different from just docking/attachments?
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,835
Reaction score
2,098
Points
203
Location
between the planets
So other then the features the Vessel class provides, what features does an "Astronaut" need.
Well, there's the issue of walking...

How is that different from just docking/attachments?
It is very different in that there is no interface for it. If the core were to provide an API that vessels can implement, there would be no issues with sharing crew among vessels that might be written with different libraries.
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,672
Reaction score
1,329
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Okay, that's good info.

I do think that surface behavior, and the ability to be transferred between vessels represents core functionality.

How would "Astronauts" be updated (pre and post step) when they are "in" a vessel?

It sounds like, this is more of a change to the vessel interface, than simply the addition of an astronaut class derived from vessel.

Fully support the idea btw, but let's get it right.
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,261
Reaction score
3,238
Points
203
Location
Toulouse
Just an idea : it would be nice to have a simple timer when you transfer crews, in uMMu you could teleport crew members all across a Star Destroyer, it worked but wasn't super-immersive.

The vessel addon dev would only have to input time values between the vessel "center" (actually the ability to define several "nodes" for large vessels would be better) and the docking ports.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,835
Reaction score
2,098
Points
203
Location
between the planets
How would "Astronauts" be updated (pre and post step) when they are "in" a vessel?
I really hope they wouldn't be. In my opinion, when an astronaut enters a vessel, the job of the core is done. What would you want to update anyways? You can't put things like eating or breathing into the core, because that would mean you'd have to provide interfaces for vessels to provide consumables to an astronaut like propellant to a thruster, and things for the vessel developer can quickly get very, very tedious.

My suggestion would be to invoke a callback on the vessel that hands off a data structure that can be used to instantiate the astronaut again outside, and have the callback return true or false. If true, the core assumes the vessel has accommodated the astronaut and destroys the simulation representation, if false it assumes that it was prevented from entering for whatever reason and leaves it as is.
What exactly happens with the astronaut inside the vessel is the vessels concern. A library could be written for that too, of course, but there's no reason for that to go into the core.

Just an idea : it would be nice to have a simple timer when you transfer crews, in uMMu you could teleport crew members all across a Star Destroyer, it worked but wasn't super-immersive.
Again, not a concern of the core, in my opinion. There's nothing preventing a vessel from implementing an internal layout and have its astronauts wuzzing about inside it Sims style (except it's an awful amount of work). If you start implementing such basic mechanics in the core, you loose that flexibility on the vessel side. Again, a generic crew library that implements layout patterns and behaviours can be written and can be pulled in by each vessel as they see fit, no need to dictate it from the core.

I think the thing many people here are unclear about is: The core is THE LAW! Whatever behaviour the core defines, requires hacks and workarounds when you want to change that behaviour. Again I will mention thrusters and propellant sources: Everybody that wants to implement fuel mixtures basically has to hack that pattern by substituting a dummy propellant source and then feeding that from their own structures somehow. In other words, the core provides convenient functionality that can save you a lot of work if you're just doing what the core intended, but it it also limits your freedom if you need things differently.
Therefore, behaviour that can be generalised and abstracted away from the core, should be done there. That way, you retain convenience and flexibility, because everybody can decide for themselves whether they want that functionality implemented this way or not. If it's in the core, you're just stuck with it.
 

Owenmck

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
I agree with @Urwumpe, that responsibility should be handed over to the vessel when they are inside. This allows developers to implement features like breathing, eating stress etc. however they want.

Also, petition to call these Astronauts...
Orbinauts
(Credit to @Boxx for that one)
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,564
Reaction score
2,298
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
I am not even sure, how much functionality of the core is really required. For example: For transfering crew or cargo just as pure set of data, we need no special core API function. Having one in the API would be better for standardization, but not mandatory.

But what would be needed for for example transfering astronauts between different add-ons or frameworks, would be a common understanding, which attributes an astronaut has.

In UMMU, this is name, space suit type and pulse rate, AFAIR.

Is that enough? If we want more - how could we extend this? Do we define astronauts as a ECS, with the entity of an astronaut having multiple simple components with attributes and every framework can decide, which components it can handle? Like a framework, that does not know about illnesses or injuries would simply ignore those components in its simulation. A framework, that knows no piloting skill, would simply not calculate anything with it. In this case, we could leave the high-level decisions to the market: components, that are important, will be supported by any framework, and I am sure, we could expect the add-on developers to find a good way of interoperability. (Defining the components together, having a common core component and move extensions into a different component, etc). This wouldn't be exactly fast or use little memory, but it would be interoperable.

The same communication protocol should also work fine with cargo, data and liquids then.
 

n122vu

Addon Developer
Addon Developer
Donator
Joined
Nov 1, 2007
Messages
3,196
Reaction score
51
Points
73
Location
KDCY
Urwumpe said:
Is that enough? If we want more - how could we extend this?

I'd envision this as some sort of configuration menu, or a separate program such as the DGIV or OrbiterSound utilize. A way to add attributes, and define what they do, within a set of abilities defined in the core (ex: Does this attribute define a resource consumption, a resource quantity, an identity of some sort, a "health" attribute, etc).
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,564
Reaction score
2,298
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
I'd envision this as some sort of configuration menu, or a separate program such as the DGIV or OrbiterSound utilize. A way to add attributes, and define what they do, within a set of abilities defined in the core (ex: Does this attribute define a resource consumption, a resource quantity, an identity of some sort, a "health" attribute, etc).

What about an approach like many ECS (Entity-Component-Systems) use, with a definition what a "component" is and "component systems" that operate using those components.

In this case, add-ons could provide their own component definitions, while the vessels still have the authority which components they invoke and how. Ideally, there should be a "baseline" group of component systems, that can be invoked by any add-on with a single call in PreStep and which are extended by the plugins that the player uses, so only those components, that are more vessel specific would require handling.

And we could then use the Plugin architecture of Orbiter for this, without needing to change the UI already.

For example, you activate a plugin, that adds a fiscal system to Orbiter and a MFD to display the information. At the same time, the plugin could install components and systems to the baseline for all astronauts in the simulation, that all vessels that support this "third party framework" would use automatically...

(Yes, I know, the use cases still have many many gaps and "something magical happens here." But it could be described with an algorithm, right?)
 
Top