# VesselTransorbital tug / Hauler

#### jedidia

##### shoemaker without legs
Can you already tell me in a short way how to publish events?
It's already kind of described in the code, and there's a description of the concepts in EventBroker.h. The short of it is, you add a topic to the EVENTTOPIC enum, you add an event identifier to EVENTTYPES (if you need a new topic and a new event, that is). A class that wants to publish events should retain a reference or a pointer to the vessels EventBroker, then all they have to do is eventBroker.publish() (there's an example event published at the end of clbkSetClassCaps currently).
If it's a simple event in the style of "this happened, no further information required", you can use a SimpleEvent with the identifier, if the event needs to transfer more complex data you should make a new class for it that inherits Event_Base.

Can I also use this API for pumping data to a MFD or is this better suited for commands?
That depends a bit on what you mean by MFD. If you mean just some display we integrate into the cockpit, sure. If you mean an actual orbiter-style MFD, it gets a bit more complicated because that runs in a different module. As a rule of thumb, anything that needs to receive events needs to get a hold of a reference to the vessels EventBroker instance at some point before being able to do so (well, actually that's not quite true... it can also be subscribed to the broker by a third party that knows the broker and the subscriber). As long as you can facilitate that, there's no boundaries to who can receive events. Just be aware that if there's multiple vessel instances in a session, things can get rather tricky if you start passing events beyond module boundaries...

#### Urwumpe

##### Not funny anymore
Donator
That depends a bit on what you mean by MFD. If you mean just some display we integrate into the cockpit, sure. If you mean an actual orbiter-style MFD, it gets a bit more complicated because that runs in a different module. As a rule of thumb, anything that needs to receive events needs to get a hold of a reference to the vessels EventBroker instance at some point before being able to do so (well, actually that's not quite true... it can also be subscribed to the broker by a third party that knows the broker and the subscriber). As long as you can facilitate that, there's no boundaries to who can receive events. Just be aware that if there's multiple vessel instances in a session, things can get rather tricky if you start passing events beyond module boundaries...

I mean a vessel specific MFD, that is part of our VESSEL module. I wanted to use this for providing some first test diagnostics for the transport equations.

#### jedidia

##### shoemaker without legs
I mean a vessel specific MFD, that is part of our VESSEL module. I wanted to use this for providing some first test diagnostics for the transport equations.
Yeah, that's no problem at all.

#### jedidia

##### shoemaker without legs
@Urwumpe Say, is there anything I should best proceed with?

#### Urwumpe

##### Not funny anymore
Donator
@Urwumpe Say, is there anything I should best proceed with?

As long as you are staying away from the main engine files right now, so I have less conflicts, you have all the choices you want. Loading and Saving the scenario is still open, payload handling would be a point we really need.

I want to first finish the main engine model to use this for scaling the rest of the spacecraft subsystems. This is literally the heart of the spacecraft, since electrical power and some of the thermal control subsystems depend on it. Right now, I model it like professional nuclear simulations (because I have some scientific papers about this), but look for ways to simplify things and harden the functions for high timewarps. Since the reactor will be really small, I can reduce the math to a single finite cylindrical cell containing everything, with the control drums controlling the boundaries of the cell. The fuel elements are modelled as one solid uniform foamy (coolant channels) block inside a uniform cloud of neutrons of varying energies. I think I will use a similar design as for the Topaz reactors for the control drum, adding 3 quickly reacting safety drums (on/off) and a 3*n drums that move slower but allow fine control of the chain reaction.

I hope the primary math will be stable enough itself in high timewarps (similar space nuclear reactors needed 10 minutes in computer simulations to meltdown in failure situations), but if it won't work out, I would stabilize the reactor simulation by brute force. My worst fear are amplifying 2D oscilations between thermal state and nuclear power output.

Right now, my enemy is the neutron transport equation - how many cohorts of neutron energies will I support (at least two are needed: prompt and thermal). Radioactive decay would be fairly simple then, thermal transport functions would become a bit more complicated. If the plan works out, I could even, with minimal extra code, allow to simulate aging neutron absorbers on the control drums (limiting the maximum lifetime of them to 4-12 years).

Once I have coarsely scaled everything, I could either keep on coding (what I would prefer) or produce a first mesh (which I am really bad at)

If I go on with coding, I think the two kinds of RCS would make sense next:
• External modules around the crew section, that can be replaced by refueled modules quickly and without danger of propellant leaks. Mostly needed when the reactor is shut down or during docking maneuvers, thus can be really weak.
• Hot hydrogen thrusters around the reactor machinery, using hot GH2 from the reactor. Could have fairly high thrust when augmenting them with oxygen, or be really fine controllable when using only hot H2.
• Option to use Arcjet technology to further heat the H2 would be possible, but performance gains by injecting O2 could be reduced then.

What I am not too sure yet:

• Crew size: 2, 3 or even 4 needed?
• Since we use a nuclear reactor for energy production, should a nuclear engineer be mandatory for the crew?
• How many functions can the player/captain handle without it becoming obsessive?
• Would an AI crew add value to the simulation?
• Interior design: Do we want to follow modern visual conventions? I think for gamification and simplicity, some older science fiction references could be smarter, like 2001 or Moonbase Alpha
• If the visual design for the interiour is selected, we could need a MFD framework to define a common UI visual language, so all MFDs and other displays in the spacecraft are uniform.
• With a 2001 like design, adding a murderous AI to the spacecraft would be no bug, it would be a feature.
• Even if we will likely start out with a 2D panel, this would still depend on the visual design choices
• Right now I planned without artificial gravity, keeping the time in space of the crew limited to about 3 months, is that OK?
• Main engine customization: I have found quite many material choices and places where customizing would be possible, and my (likely overcomplicated) mathematical model could support many of them. Would we later allow "Pimp Your Rocket?"
• Other vehicles, bases, buildings in the world - they would make sense, but I haven't really thought about them yet.
• OMmu support? It is far from ready for production right now, but its open source.
• Skin support - I think it would be mandatory if we go fishing in the XR waters, but I have no idea yet how to implement it.

#### jedidia

##### shoemaker without legs
Oh wow, that is a lot more detailed than I expected!

Once I have coarsely scaled everything, I could either keep on coding (what I would prefer) or produce a first mesh (which I am really bad at)
By all means, keep on coding. We can make do with the tin can for a while, and if we have something cool, maybe somebody more talented at modelling than either of us gets interested in taking it off our hands...

External modules around the crew section, that can be replaced by refueled modules quickly and without danger of propellant leaks
Interesting concept. I'd say it's probably best to not have them be actually detachable in a first iteration.

Do we want to follow modern visual conventions? I think for gamification and simplicity, some older science fiction references could be smarter, like 2001 or Moonbase Alpha
Yeah, something more recognisable might be a better choice, I agree.

If the visual design for the interiour is selected, we could need a MFD framework to define a common UI visual language, so all MFDs and other displays in the spacecraft are uniform.
Hmmmyeah, I'm certainly the wrong person to discuss visual language with... somebody might be interested in making some drafts. Codewise I guess we should try to go for something that can visually be easily changed.
Again, if we're going with touchscreen interfaces, my UI-framework might serve well. It's externally themeable and layoutable, and can even switch themes at runtime (not layouts, though). The customisation options aren't that varied, but some things can be done. I guess I could start ripping it out of IMS2 and putting it into the hauler for a quick proof of concept, though it's a bit iffy without much to control yet. I guess I could start implementing actual orbiter MFD support, because that's still missing.
Oh, and it's easier to work with for prototyping than a raw panel (though not as easy as I'd like), so if we decide to tear it all out later it's not such a great loss either. In any case, even if we want physical switches, it should still serve well for any text displays in the panel (graphs not so much, though a sketchpad element would be easy enough to add...).

Right now I planned without artificial gravity, keeping the time in space of the crew limited to about 3 months, is that OK?
3 Months is plenty. I'd kind of expect such a vessel to be necessary if there's already some serious orbital activity, and probably some places that have artificial gravity to recuperate. Or the crew can just tkae a shuttle down to the moon for shore leave...

Other vehicles, bases, buildings in the world - they would make sense, but I haven't really thought about them yet.
Yeah, let's not think about that just yet....
OMmu support? It is far from ready for production right now, but its open source.
I was thinking about it these days, and it would certainly be somewhere on the horizon, but I wouldn't give it much priority until we have most of the vessel functional and presentable. I've worked with UMMU, if OMMU works in a similar way it shouldn't be a problem to add it later.
Skin support - I think it would be mandatory if we go fishing in the XR waters, but I have no idea yet how to implement it.
I do. Not that much to it, just load in a texture manually and associate it with the mesh behind the scenes. No big deal, can be added whenever we have a mesh and more than one texture.

So, let's see...
Loading and Saving the scenario is still open, payload handling would be a point we really need.
Scenario saving is simple enough with Oparse in there as long as the data that goes into the scenario is neatly encapsulated. I guess I could make some example.
But payload... huh. There's a discussion to be had about how we want to handle payloads first of all. The natural choice are attachment points, they're basically made for that. But: Scenario editor does not allow to control attachment points, which means it's quite a pain to actually attach payloads without also implementing some payload manager. Sure, you can grab a dragonfly and dock them all there manually, or do so with an RMS, but most people are not so much into that (especially since the dragonfly doesn't quite work in Orbiter2016). Being able to relatively quickly attach a payload and get going is crucial I think.

So either we use dockports to attach payloads, or we have additional work to make the thing usable. I'd suggest going for dockports first, and then maybe changing that in a later iteration if we don't like it. Dockports and Attachment points have a very similar API, so it wouldn't be too hard to switch.
That would still leave the question open of how payloads are handled simulation-wise. I assume IRL you'd position the payload and then close some latching or grabbing mechanism to secure them, otherwise they fly off when there's more than a certain acceleration...

Last edited:

#### Urwumpe

##### Not funny anymore
Donator
I think attachments would still be better for the sake of one aspect: They don't have any effect on the parent vessel.

If we go with docking ports, we would need to control the CoG, so things like pumping around fuel or engine trim would become mandatory.

Maybe we can go with some cheat MFD there, to simply attach suitable payloads directly, without positioning.

About the UI - in a 2D panel, anything is like a touchscreen anyway - since it more or less is it on the host computer.

I still think, something with lots of pushbuttons and switches would have more character. What do you think about doing a Dark Star like cockpit?

Its small, cramped and pretty minimalist (what you can get for a \$60000 movie budget), but conveys a sense of business - nothing extra, not a m³ wasted, the satanic ergonomy of a minuteman missile bunker. Pretty much what you would expect for a spacecraft designed to cost.

I think such displays could also work fine in Orbiter, they are not too fictional.

Last edited:

#### jedidia

##### shoemaker without legs
Maybe we can go with some cheat MFD there, to simply attach suitable payloads directly, without positioning.
Oh, I wouldn't have anything else in mind. I'm certainly not going replicate universal cargo deck, more something along the lines of the XR-5 payload manager, but that in itself is already a bit of a hassle so early on in the project. But it's true what you say about the CoG issue. I have some code lying around that rebalances the RCS on a CoG change by adjusting each thrusters power, but it's a pretty expensive operation that needs its own thread and comes with a couple unfortunate side effects for stock autopilots, so I'd rather not use it.

I still think, something with lots of pushbuttons and switches would have more character. What do you think about doing a Dark Star like cockpit?
Yeah, that's what I think too. I would love a more retro, "brutalish" approach to the controls, to be honest.
Now, the UI can still handle custom bitmaps for buttons, so at least in a panel you could display handcrafted buttons and switches and the likes, but in a VC you'd expect those to be part of the mesh, so that aspect would translate very poorly. I'm starting to think that it might be best to ditch the panel and instead implement some easily modifiable VC architecture so we can still iterate over the whole thing without too much hassle. After all, if we do a panel, everybody (including ourselves) would wish we had a VC, while vice-versa isn't very likely. And anything you do for panels just translates awfully to a VC in terms of reusability, except for displays.
Trouble is, I have no experience whatsoever with VCs. Coming up with something useful is going to take a while...

#### Urwumpe

##### Not funny anymore
Donator
Trouble is, I have no experience whatsoever with VCs. Coming up with something useful is going to take a while...

Well, I have the experience with VCs, but making the meshes would be beyond my competence. What I did not yet try was using FreeCAD for drawing it and then export the meshes on OBJ format to be converted into Orbiter meshes. Could be quite polygon heavy.

For implementation, I would recommend using a separation between the internal simulation model and the visual representation to the user (maybe a bit like MVC)

This way, we could always have a button existing, even if we don't yet show it, even if only keyboard inputs, MFDs or AI Crew interact with it.

For the VC, we could then separate animation code and definitions into their own classes (maybe even reuse similar animation classes for different objects) without the interal simulation needing to know about it or VC code bloating the files for internal model or 2D panel representation.

We could even allow plugging an interface for a SimPit there, using a similar interface between internal model and representation. Or a debug class that only reads such communication and logs it for testing.

#### jedidia

##### shoemaker without legs
For implementation, I would recommend using a separation between the internal simulation model and the visual representation to the user (maybe a bit like MVC)
Well, that much is kind of a given... wouldn't want the interface to be strongly coupled to the logic. What I'm very unclear about is how the VC is composed. Do all the movable parts have to be incorporated into the main mesh? or can they be sub-meshes that you can prop on top of it? I guess one could still achieve the later with some mesh manipulation, but it would be a lot more comfortable if orbiter already supported such a thing...

#### Urwumpe

##### Not funny anymore
Donator
Well, that much is kind of a given... wouldn't want the interface to be strongly coupled to the logic. What I'm very unclear about is how the VC is composed. Do all the movable parts have to be incorporated into the main mesh? or can they be sub-meshes that you can prop on top of it? I guess one could still achieve the later with some mesh manipulation, but it would be a lot more comfortable if orbiter already supported such a thing...

You can make one or more separate specialized meshes for the VC, that will only be displayed in VC mode. (Using SetMeshVisibilityMode(MESHVIS_VC)). Otherwise, its pretty much similar to a normal mesh in terms of animation - what you can do there, also works in a VC.

For gathering mouseclicks, you can define quads and spheres. Both areas can handle multiple elements since you are provided with the coordinates of the mouseclick on that area. A rectangular region works best there. So, for a VC, its smart to let the inputs first get handled by a panel definition that distributes the event to the correct VC representation of a simulation model, and then let it decide, how the internal behaviour should change.

Last edited:

#### jedidia

##### shoemaker without legs
Pulled in the shuttleA VC mesh for a bit of experimentation, and took a good look at the ShuttleA code to see how stuff works. So yeah... anything 2dimensional works pretty much like on a panel, everything 3-dimensional is expected to be part of the mesh. And of course everything that changes in the mesh needs to be its own mesh group. That's gonna be painful to abstract... Though I guess one could compose the VC out of several meshes, just like the vessel? No idea, haven't tried that yet, but it would already help a bit...

How did you guys solve this in space shuttle ultra? Are really all of those gazillion switches part of the VC mesh?

#### Urwumpe

##### Not funny anymore
Donator
How did you guys solve this in space shuttle ultra? Are really all of those gazillion switches part of the VC mesh?

Yes.

No procedural generation.

I am not really happy with the result, it was a constant pain. But it was also the first VC code I had written in my life, so yeah, shoot me. ?

#### Urwumpe

##### Not funny anymore
Donator
About freeing the events - could it make sense to use a flyweight pattern for better performance? We have no garbage collection, so freeing the events would result in the heap getting fragmented and memory getting scarce despite lots of free space.

#### jedidia

##### shoemaker without legs
About freeing the events - could it make sense to use a flyweight pattern for better performance? We have no garbage collection, so freeing the events would result in the heap getting fragmented and memory getting scarce despite lots of free space.
Yeah, I'm not... uhm... that technical, to put it mildly? I'm pretty bad at algorithms . And in C++, I'm just glad if I remember to clean everything up after myself, never mind keeping the heap orderly. I'm really mostly an encapsulation and structure kind of guy, that's what I'm good at...

#### Urwumpe

##### Not funny anymore
Donator
Yeah, I'm not... uhm... that technical, to put it mildly? I'm pretty bad at algorithms . And in C++, I'm just glad if I remember to clean everything up after myself, never mind keeping the heap orderly. I'm really mostly an encapsulation and structure kind of guy, that's what I'm good at...

No deal. I had been developing Java And C99 software in parallel for some years, so caring for the different runtime behaviours was quickly part of the job.

If you want, I can take a look there later. Right now, I think it would be better to accumulate a fixed pool with event structures and pick a free event from the pool in the factor method.

#### jedidia

##### shoemaker without legs
I think it would be better to accumulate a fixed pool with event structures and pick a free event from the pool in the factor method.
Ugh! And here I was thinking that the only advantage of an environment without a garbage collector was that you didn't have to hassle around with object reuse because there's no garbage collector freezing your process when you don't want it...
I'll take it on the todo list, but probably won't do immediately.

#### Urwumpe

##### Not funny anymore
Donator
Ugh! And here I was thinking that the only advantage of an environment without a garbage collector was that you didn't have to hassle around with object reuse because there's no garbage collector freezing your process when you don't want it...
I'll take it on the todo list, but probably won't do immediately.

No deal. I have no idea how long we would have to play the game until new returns a null pointer or exception, because the heap is full of many too small holes... Generally, that is a problem that you only have if you program at low level. Most VMs with garbage collection are also able to move structures in the heap to compact it.

#### jedidia

##### shoemaker without legs
Had a bit of time to experiment around a bit with VC. Composing one out of several meshes works without issues, actually. So it wouldn't be impossible to write a small framework to dynamically define panels with switches and stuff, where the meshes of the switches can just be exchanged later on. It's a bit of work, but might be worth it... Would certainly make prototyping a lot more simple. We wouldn't even need an actual cockpit mesh until we know how it looks, the panels can just be hung into the empty vacuum for prototyping (Must be some further develpment on the "Siemens Lufthaken"...), and arrangement of switches could also be easily changed without touching a mesh...

#### Urwumpe

##### Not funny anymore
Donator
Doing boring table work... I first thought about moving this into an external file, but I feel like it won't be worth the effort, since the set of reactions to be implemented will have implications for the rest of the simulation. It is just easier to define such reactions in tables for finding errors.

C++:
const NeutronReaction NEUTRON_REACTIONS[NUMBER_OF_NEUTRON_REACTIONS] = {
{ISOTOPE_U235, 10.0, 0.0, ISOTOPE_U235, 0.0},    //Scattering of thermal neutrons at U235
{ISOTOPE_U235, 99.0, 0.0, ISOTOPE_U236, 0.0},    //Absorption of thermal neutrons at U235
{ISOTOPE_U235, 583.0, 0.0, ISOTOPE_U236F, 0.0},    //Fission of U235 by thermal neutrons
{ISOTOPE_U235, 4.0, 0.0, ISOTOPE_U235, 0.0}, //Scattering of fast neutrons by U235
{ISOTOPE_U235, 0.09, 0.0, ISOTOPE_U236, 0.0},
{ISOTOPE_U235, 1.0, 0.0, ISOTOPE_U236F, 0.0},
{ISOTOPE_U238, 9.0, 0.0, ISOTOPE_U238, 0.0},
{ISOTOPE_U238, 2.0, 0.0, ISOTOPE_U239, 0.0},
{ISOTOPE_U238, 0.00002, 0.0, ISOTOPE_U239F, 0.0}
};

Replies
18
Views
777
Replies
31
Views
1K
Replies
137
Views
4K
Replies
2
Views
256
Replies
61
Views
3K