Vessel Transorbital tug / Hauler

[jedidia]

I've set up a project and a repository:

GitHub - TheNewBob/OrbitalHauler

Contribute to TheNewBob/OrbitalHauler development by creating an account on GitHub.

github.com

Right now it's literally just a tin can with thrusters (using the standard orbiter module mesh) and a dock port. Technically that addresses the first story, since you can fly around between orbits and dock to stuff with it, but the main goal was really to set up the project and get some encapsulation started. More interesting things concerning the architecture will follow.
I had mostly forgotten all the ways you can shoot yourself in the foot with C++ and also Visual Studio, so this took a while. It's starting to come back to me...

I've put it under the MIT license, if anyone objects to that please speak up, it's just the default license I put into everything to have my peace. we can still change it.

 

[Urwumpe]

I've set up a project and a repository:

GitHub - TheNewBob/OrbitalHauler

Contribute to TheNewBob/OrbitalHauler development by creating an account on GitHub.

github.com

Right now it's literally just a tin can with thrusters (using the standard orbiter module mesh) and a dock port. Technically that addresses the first story, since you can fly around between orbits and dock to stuff with it, but the main goal was really to set up the project and get some encapsulation started. More interesting things concerning the architecture will follow.
I had mostly forgotten all the ways you can shoot yourself in the foot with C++ and also Visual Studio, so this took a while. It's starting to come back to me...

I've put it under the MIT license, if anyone objects to that please speak up, it's just the default license I put into everything to have my peace. we can still change it.

Good for a start. I started a small SysML model for doing the scaling and systems design based on my suggested configuration, but since I am in holidays with my family (as announced), things are progressing really slow.

As usual for modelling, I only plan to dive as deep into the model as really needed - the more abstract and coarse the ingame model can be, the less work has to be done there.

So - any way I can help you with getting started?

Can I suggest creating a dev branch for the actual development and reserving master for releases and hotfixes?

 

[jedidia]

Can I suggest creating a dev branch for the actual development and reserving master for releases and hotfixes?

Seemed a bit early for that, I usually branch that out with the first release, but sure.

So - any way I can help you with getting started?

I won't be having too much time either, so this will be slow going. Don't worry.
Right now I'm trying to rebuild my old Oparse library in visual studio 2019, and for some reason it's giving me hell... Built without issues in VS2017...
I have two kinds of errors, some of them related to generics, some to the orbiter headers. Trying to figure out the orbiter ones first, on the off-chance that the others will go away once that works right, but it's an issue.
I'm getting the error "instrument_User not found", something to do with the MFD api when including orbitersdk.h. I had this exact same problem when setting up the vessel project, where it went away as soon as I pulled in orbitersdk.lib correctly. But Oparse is a static lib itself, so I can't pull in other libs. I have no idea why it's only a problem for VS 2019, and how to get around it...

 

[Urwumpe]

I'll take a look, my children seem to be very tired today, after movie and a long walk around the lake.

Right now I try to figure out, what kind of project structure you intended. Looks like you want to have the project in ${OrbiterDir}/OrbiterSDK/OrbitalHauler

BTW - you can remove the x64 builds. Orbiter is x86 only.

 

[Urwumpe]

OK, looks like some configurations are terribly outdated in the DLL project. I get lots of linker errors, that shouldn't exist. Looks like some legacy configuration.

 

[jedidia]

Right now I try to figure out, what kind of project structure you intended. Looks like you want to have the project in ${OrbiterDir}/OrbiterSDK/OrbitalHauler

Yeah, that's documented in the readme.

OK, looks like some configurations are terribly outdated in the DLL project. I get lots of linker errors, that shouldn't exist. Looks like some legacy configuration.

That's weird... I created the project completely from scratch in VS 2019. All paths should be relative, so if you clone OrbitalHauler into Orbitersdk/OrbitalHauler and clone Olog into Orbitersdk/Olog everything should be found (Olog has been rebuilt with VS 2019, so that shouldn't be a problem either. The libs are included in the repo, so you shouldn't have to rebuild it).

BTW - you can remove the x64 builds. Orbiter is x86 only.

Yeah, they're not configured, either... I was just too lazy to kick them out for now.

 

[Urwumpe]

That's weird... I created the project completely from scratch in VS 2019. All paths should be relative, so if you clone OrbitalHauler into Orbitersdk/OrbitalHauler and clone Olog into Orbitersdk/Olog everything should be found (Olog has been rebuilt with VS 2019, so that shouldn't be a problem either. The libs are included in the repo, so you shouldn't have to rebuild it).

Yeah, it doesn't make sense. It also includes the right version of OLog, I even rebuild both with the same compiler to be sure. It shouldn't be related to OLog anyway, since it has no entry point and shouldn't include the runtime. Its somewhere in the Hauler project.

 

[Urwumpe]

For reference: This is the output:

Erstellen gestartet...
1>------ Erstellen gestartet: Projekt: OrbitalHauler, Konfiguration: Release Win32 ------
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(505,5): warning MSB8004: Das Output-Verzeichnis endet nicht mit einem nachstehenden Schrägstrich. Der Schrägstrich wird in dieser Buildinstanz hinzugefügt, da er für die ordnungsgemäße Auswertung des Output-Verzeichnisses erforderlich ist.
1>OrbitalHauler.cpp
1>DockPort.cpp
1>ReactionControlSystem.cpp
1>MainEngine.cpp
1>   Bibliothek "..\..\Modules\OrbitalHauler.lib" und Objekt "..\..\Modules\OrbitalHauler.exp" werden erstellt.
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol "___CxxFrameHandler3".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol "@__security_check_cookie@4".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol "___std_exception_destroy".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol "___std_exception_copy".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""void __cdecl operator delete(void *,unsigned int)" (??3@YAXPAXI@Z)".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__purecall".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol "___std_terminate".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""const type_info::`vftable'" (??_7type_info@@6B@)".
1>OrbitalHauler.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__imp___invalid_parameter_noinfo_noreturn".
1>LINK : error LNK2001: Nicht aufgelöstes externes Symbol "__DllMainCRTStartup@12".
1>Olog.lib(Olog.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp__tolower".
1>Olog.lib(Olog.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp____stdio_common_vsprintf_s".
1>Olog.lib(Olog.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp___strnicmp".
1>..\..\Modules\OrbitalHauler.dll : fatal error LNK1120: 14 nicht aufgelöste Externe
1>Die Erstellung des Projekts "OrbitalHauler.vcxproj" ist abgeschlossen -- FEHLER.
========== Erstellen: 0 erfolgreich, 1 fehlerhaft, 1 aktuell, 0 übersprungen ==========

 

[jedidia]

Huh, confirmed. I must admit, I hadn't even tested the release configuration. Can you build it in debug configuration?

 

[Urwumpe]

Huh, confirmed. I must admit, I hadn't even tested the release configuration. Can you build it in debug configuration?

Err. Sure. I actually rarely build in debug for Orbiter. Debug versions are error sources in my eyes, I use them only if really necessary. Was a lot of trouble some years ago, when we found out that a "production" build for x86 was a debug build in the past 15 years and broke when the Linux version on the Linux servers was updated, while the Sparc version ran fine since its compiler ignored the old gcc debug flags in the makefile...

No more errors. So its just an issue in the release configuration.

 

[Urwumpe]

About the main engine, shall I build a first iteration model for a LANTR? or should this choice be kept open for other configuration suggestions?

In this case, I could also provide a first model for Electric Power Subsystem and Thermal Control Subsystem.

 

[jedidia]

About the main engine, shall I build a first iteration model for a LANTR? or should this choice be kept open for other configuration suggestions?

So far noone has chimed in although there was time... And since in case of a LANTR all other systems kind of rely on the engine to provide power, and would therefore be difficult to design without knowing the engine, I'd say go ahead when you find the time.

Any objections from anybody else reading this? Any better/different ideas?

In the meantime I'll try to figure out what's wrong with the release configuration, as well as trying to figure out my other woes. Apparently something about template functions has changed since C++ 11, but I couldn't figure out what yet...

 

[Urwumpe]

In the meantime I'll try to figure out what's wrong with the release configuration, as well as trying to figure out my other woes. Apparently something about template functions has changed since C++ 11, but I couldn't figure out what yet...

At least, VC++ complains a lot, if you try to export template classes, that have implementation specific behaviour - for example the container classes, like vector.

We have git, we can throw the main engine implementation overboard anytime, of course with implications on the system design.

 

[Urwumpe]

Will you do the loading/saving code for the subsystems? Then I will ignore this for now.

 

[jedidia]

Will you do the loading/saving code for the subsystems? Then I will ignore this for now.

I'm planning to, when I can get that gorram library to build...

 

[Urwumpe]

I'm planning to, when I can get that gorram library to build...

OK, no hurry. I might have some heavy hauling to do today...

 

[jedidia]

Just wanted to add, when you start writing code, it will save some work if you make two structs (or classes, doesn't matter) for each system from the get-go, one containing the parameters you intend to load from the config, and one with the parameters you want to save to the scenario (Essentially, treat that second one as a model, i.e. read and write the states directly from/to it at runtime).

 

[Urwumpe]

Just wanted to add, when you start writing code, it will save some work if you make two structs (or classes, doesn't matter) for each system from the get-go, one containing the parameters you intend to load from the config, and one with the parameters you want to save to the scenario (Essentially, treat that second one as a model, i.e. read and write the states directly from/to it at runtime).

Can you be a bit more specific there?

 

[jedidia]

Well, just have the parameters be members of a separate struct or class, not of the class containing the logic. The struct containing parameters you want to load from config will be passed to the class on construction or init, and the class containing the state will be handed to the parser to be serialised to the scenario wholesale and deserialised from it on loading.
They can contain further subclasses, but again those shouldn't contain logic. Think "POJO", without the J, obviously...

 

[Urwumpe]

Well, just have the parameters be members of a separate struct or class, not of the class containing the logic. The struct containing parameters you want to load from config will be passed to the class on construction or init, and the class containing the state will be handed to the parser to be serialised to the scenario wholesale and deserialised from it on loading.
They can contain further subclasses, but again those shouldn't contain logic. Think "POJO", without the J, obviously...

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