Vessel Transorbital tug / Hauler

[jedidia]

Ah, like that. I thought you meant some kind of inheritance.

No, the less inheritance the better (for the data structures). The library has a way to handle polymorphism, but it can get very confusing very quickly, so unless you have structs that have quite a lot of duplicated members, it's more readable if they don't inherit from anybody.

 

[Urwumpe]

No, the less inheritance the better (for the data structures). The library has a way to handle polymorphism, but it can get very confusing very quickly, so unless you have structs that have quite a lot of duplicated members, it's more readable if they don't inherit from anybody.

No problem, that is why I asked first and complain later.

(Maybe better write this into a code style guide for the open source project)

 

[jedidia]

StackOverflow to the rescue:

Function template won't compile in VS2019 express

I have a project with quite a lot of function templates that I wrote back in Visual Studio 2017, and it always worked fine. Now I have to build it in VS2019, because I need to include the lib in an...

stackoverflow.com

Now I'll eternally wonder how that project was ever able to compile, dammit!

 

[Urwumpe]

StackOverflow to the rescue:

Function template won't compile in VS2019 express

I have a project with quite a lot of function templates that I wrote back in Visual Studio 2017, and it always worked fine. Now I have to build it in VS2019, because I need to include the lib in an...

stackoverflow.com

Now I'll eternally wonder how that project was ever able to compile, dammit!

Welcome to the forth stage of debugging: "How did this ever work?"

 

[jedidia]

Welcome to the forth stage of debugging: "How did this ever work?"

It's not my first time, obviously, but I must say that it happens a lot less when working with Intelij and Kotlin...

Fixed and pushed the release configuration. Turns out one should only exclude MSVCRT from a debug build, but not from a release build. It probably makes perfect sense if you know what the silly thing actually does...

 

[jedidia]

Finally got around to including Oparse in the project and got some config loading going. The current ThrusterConfig should be strictly regarded as an example, I didn't really intend anything with it. Scenario state will follow, but first I need a state to save.

That means that we got one more dependency. if you just do git clone https://github.com/TheNewBob/Oparse.git in your Orbitersdk folder, it should work.
Also, I noticed that when running the DebugD3D9 configuration, the debugger doesn't attach for some reason. No idea why yet, and not giving it too high a priority.

EDIT: Forgot to mention, you'll have to copy the config from the repo to the orbiter config folder.

 

[Urwumpe]

EDIT: Forgot to mention, you'll have to copy the config from the repo to the orbiter config folder.

Mind if I want to do that automatically by post-build step?

 

[jedidia]

Oh, I don't mind at all, quite the contrary. Would've done it myself if this was gradle, but I was too lazy to figure out how to do it in VS.

 

[Urwumpe]

Oh, I don't mind at all, quite the contrary. Would've done it myself if this was gradle, but I was too lazy to figure out how to do it in VS.

Its a bit weirder there, and we are also not operating on CMake here.

BTW: Was it strictly single engine or was dual engine permitted? If dual is permitted, there would be some redundancy (not putting all eggs into one basked), if not, there would be more fun after an failure (emergency power supply)

 

[jedidia]

BTW: Was it strictly single engine or was dual engine permitted?

I don't really have an opinion on that. I assume a dual-engine LANTR means two reactors, which seems like it would weigh a whole lot, but I don't really know much about the matter. Do what you think is best/most fun for you.

 

[Urwumpe]

I don't really have an opinion on that. I assume a dual-engine LANTR means two reactors, which seems like it would weigh a whole lot, but I don't really know much about the matter. Do what you think is best/most fun for you.

OK - then I might not decide this at all yet. Maybe we can do both configurations in one DLL or reuse the dual reactor option for a heavier version of this one.

 

[jedidia]

If you implement it smartly, we might get away with just instantiating the engine twice to make it dual-engine...

 

[jedidia]

Hmph... I'm taking alook at my event engine, and a lot of time has passed since then. I didn't really know how event messengers worked at the time, and for that it's pretty decent, but after working with them for a couple of years now I have to say that what I built is overly complex and cumbersome to use, because I made the darn thing decentralised. A central message broker with subscribers would be a lot simpler to use and offer a lot less opportunity to shoot yourself in the foot, so I'm seriously thinking about rewriting the whole thing. Much of the code should be reusable...

 

[Urwumpe]

If you implement it smartly, we might get away with just instantiating the engine twice to make it dual-engine...

That was the plan. Of course, it isn't just that simple, because there is also a spacecraft around it, we need cockpits, etc.

But for the very basic stuff inside a nuclear rocket engine, we could share all the code for two instances of the engine. I just need a framework for loading and saving the state, that can handle it.

 

[jedidia]

I just need a framework for loading and saving the state, that can handle it.

Not a problem. IMS2 could have an arbitrary number of the same system instantiated and saved and loaded them all individually. That's what Oparse was developed for.

 

[jedidia]

Ripped the event engine appart and put it back together again, being able to discard at least half of it while keeping all capabilities but one that I don't think we'll need, at a much easier usage. Why is it that discardning code feels so much better than writing it? ?‍
Event broker and handlers are instantiated and hooked up in the current project for the purpose of example. Documentation for how the thing works can be found in EventBroker.h.

 

[Urwumpe]

OK, now after a lot of conflict resolving and some hammering, I managed to get this into my LANTR fork for further working on it.

Primarily, I went away from the ThrusterConfig and switched to a LANTRConfig, since thrust and ISP shall depend on the reactor performance. The config also defines some first pressure thresholds for mode switching.

Right now I define 6+1 propellant resources for LH2, which makes it easier to isolate tanks from being used and allow individual single-point refueling.

Maybe I can reduce this two just two (usable propellant + isolated propellant) with a more complex tank model.

Each LANTR engine will have two thrusters: The NTR thruster will provide thrust as by pure H flowing through the throat. The LANTR thruster will define the thrust by adding hot O2 to the exhaust - This way, I can change the appearance of the exhaust during the simulation. The thrust and specific impulse of both will be calculated in prestep based on reactor temperature (assuming no big difference between H2 and reactor fuel pellets right now) and reactor pressure / mass flow.

 

[jedidia]

OK, now after a lot of conflict resolving and some hammering, I managed to get this into my LANTR fork for further working on it.

Maybe you could do a pull request every now and then so we don't diverge that much.

Primarily, I went away from the ThrusterConfig and switched to a LANTRConfig, since thrust and ISP shall depend on the reactor performance.

Sure, that was never really meant to last anyways.

 

[Urwumpe]

Maybe you could do a pull request every now and then so we don't diverge that much.

That was the plan - what I did not include is that we have the same "business hours" today. ?

 

[Urwumpe]

Can you already tell me in a short way how to publish events? Can I also use this API for pumping data to a MFD or is this better suited for commands?