Project Orbiter StackEditor

meson800

Addon Developer
Addon Developer
Donator
Joined
Aug 6, 2011
Messages
405
Reaction score
3
Points
18
Version 1.0.1 released!

Co-created with jedidia

Orbiter StackEditor is a external vessel docking editor. It is designed to make a (semi KSP-like) external interface that can dock several Orbiter vessels together. It will allow users to easily assemble space stations (from the wonderful SSBB), or create IMS ships, then import them into Orbiter.

StackEditor.PNG


Orbiter Shipyard is built on the Irrlicht 3D engine, and the development version is available through Github here.

You can get version 1.0.1 from OrbitHangar [ame="http://www.orbithangar.com/searchid.php?ID=6810"]here[/ame]. Just unzip into the main Orbiter folder and run shipyard.exe

Keymap
Left click - Selects/deselects a stack
Shift-left click - Quick-adds the last created node
Right-click held - rotate Camera
Niddle mouse button or Control-mouse move - Camera move
Middle-mouse wheel - Camera zoom
Tab - Switches to undocking view with selected stack
ASDWQE - Rotation keys for the selected stack
Control-o - Exports the currently selected stack to Orbiter (if in linked mode)
Control-i - Imports the current Orbiter focus vessel and all connected vessels (if in linked mode)
Control-c - Creates a copy of the currently selected stack
Delete - Deletes the currently selected stack
Control-z - Undo
Control-y - Redo

What isn't it?
StackEditor is not Orbiter Shipyard or IMS, which create one Orbiter vessel out of
other sub-vessels. StackEditor can certainly help by exporting all of the vessels
docked together in Orbiter, but does not have any integration features like IMS.

Configuration
StackEditor is configured with its own config file located at:
ORBITER_ROOT/StackEditor/StackEditor.cfg

The config file contains documentation on how to set settings.

You can change screen resolution, default toolbox set, and log level in the config file.

StackEditor comes with two toolbox sets, Default, which contains a small amount of IMS toolboxes,
and IMS, a more full-featured toolbox set.


How do I use it?
To use in standalone mode, run StackEditor_standalone.exe from the root Orbiter
folder. The only restriction in standalone mode is that you cannot import/export to Orbiter.

To use in linked mode inside Orbiter, go F4->Custom->StackEditor.

When StackEditor loads, you will see four main sections of the GUI.
Most of the window will be taken up by the main screen. This is where you manipulate all nodes in the session.

In the upper left is the toolbox list. StackEditor comes with a default set of IMS toolboxes
to get you started.

Below the toolbox list is the session manipulation buttons. Save/save as saves the current session,
load loads the current session.

In the lower portion is the currently selected toolbox. Double click an item to add it into
your current session.

Left-click selects a stack (a node and all nodes docked to it). If you hover the cursor over a docking
port (blue sphere) of another stack/vessel, their docking ports will snap together.
Clicking again will dock the two stacks.

Pressing tab with a stack selected allows you to undock a stack. Tab will show currently docked ports on the
selected vessel. Simply click a docking port to undock that, splitting the stack.

When using StackEditor in linked mode, you can export your current stack to Orbiter by selecting it,
pressing ctrl-o and entering a name for the stack. Pay attention to deactivate the OrbiterSound module before doing this.
The resulting dock message spam typical for larger stacks will most probably crash Orbiter.

You can also import a stack that exists inside Orbiter into StackEditor. Make sure a vessel from the stack
is currently the focus vessel in Orbiter, and press ctr-i. If you make changes to an existing stack and
re-export it, StackEditor will modify the actual stack in Orbiter, instead of just spawning it anew.
Only vessels that were not previously in the stack will be newly created. Vessels that were removed from the stack,
however, will not be deleted in Orbiter. They'll just float off into space.
These rules also apply if you re-export a previously exported stack, provided the scenario is still the same.

Toolboxes
You can add or delete nodes from each toolbox, or add and delete toolboxes.

To add a toolbox, right-click in the toolbox item area(lower part) and select "Create new toolbox"

To delete a toolbox, right-click in the toolbox item area and select "Delete toolbox".
You cannot delete the last toolbox (there must always be one).
If you really must delete the last toolbox, create an empty toolbox before deleting the other one.

To add a vessel to a toolbox, right click in the toolbox area and select "Add vessel" and select
the configuration file of the vessel you want to add.

To delete a vessel, right click in the toolbox area and select "Delete vessel"

How to make the Deltaglider compatible with Stack Editor

Stack Editor has only access to config files of vessels. But some vessels, like for example the Deltaglider,
declare their dockports and mehses exclusively in code. Both properties are obviously vital
for Stack Editor to work with a vessel.

But you cannot just go to the config file and declare the meshname and the DOCKPORT_LIST,
because then the vessel will have a duplicate mesh and dockport when created in Orbiter.
It will not check whether the mesh or the dockport was already loaded.

For this reason, Stack Editor provides alternate names for these two properties.
You can put them in a vessels config file, and Stack Editor will recognise them, while Orbiter itself will not,
thus avoiding the above described calamities.

These parameter names are:

Code:
SE_MeshName = meshname
BEGIN_SE_DOCKLIST
END_SE_DOCKLIST

The dockport and meshname declarations otherwise work exactly the same as they would for a normal Orbiter parameter.
So let's say you want to use the Deltaglider in Stack Editor, you declare its mesh name and its docking port
in the deltaglider.cfg as follows:

Code:
SE_MeshName = DG/deltaglider

BEGIN_SE_DOCKLIST
0 -0.49	10.076		0 0 1		0 1 0
END_SE_DOCKLIST

Voila, you can now add it to a Toolbox in Stack Editor.
Technically, this would also work with a DG4 or an XR-whatever. The problem with these vessels, however,
is that they have their dockports retracted on spawning, and also have sophisticated damage models:
They will spawn docked, but with closed nosecones, and will pretty much self-destruct as a result of that.
Sorry, but there's no way we can circumvent that.

Conclusion
I look forward to your thoughts and suggestions! :cheers:
 
Last edited:
What do you know, I only just started something exactly like this (even using irrlicht), and for a change someone beats me to it! :thumbup:

The name has to change, or there'll be confusion (for example, it was pure luck I took a look at this thread because I thought it was just some necro-post on Artlav's shipyard). My project currently is called "StackEditor", but since my project won't be needed (because you are much further along, but I'll still be able to salvage the GUI code it seems... it really isn't much yet) you can call it that if you want to.

I have a pretty detailed plan for the GUI, so I can help with that. Also, I'll be aiming for running this thing inside orbiter, though real time editting of existing stacks will be somewhat of a different challenge.

All in all, it's really cool you have all the 3-d interface stuff figured out... No need for me to write it all up again.

Just the GUI for this is simple enough: Have a listbox with toolboxes. Have a toolbox GUI element (custom GUI element, lying around totally unfinished on my laptop because IMS release got priority just now). It's displayed at the lower screen, displaying the pictures that would be displayed by the scenario editor, of all vessels contained in the selected toolbox. Add to the stack on screen by simple drag and drop. Switch toolboxes with the listbox. Provide context menu to allow the user to add or remove cfg's to and from toolboxes, save toolboxes, GUI solved.

Once that stands, the logical next step is to enable the user to work on multiple stacks simultaniously. Another listbox to select the current stack should also be enough to handle that. Then a few buttons for quick editing (for example, copy the current stack x times), also no big deal.

Once we get to real time editing inside Orbiter things get more complicated architecture wise... but we'll cross that bridge when we get there.

My mesh importer requires that Meshname be a parameter in the config file. This is not true of some vessels like the Deltaglider.

Almost impossible to solve otherwise. What you could do is check the config for another parameter, like "ShipYardMesh" or somesuch, where people can note the mesh in the config file if the orbiter parameter isn't declared, without confusing orbiter. And otherwise, just spawn a dummy mesh.

IMS modules have accurate meshes look really, really bad for some reason.

I'll take a look at it. Anyways, you can count me in on this. I was planning on doing the whole work myself anyways. I'll just have to see when I get the time for it (for now, releasing IMS and calling it bygones has priority). But since you're already on Git, I'll be able to chime in any time.

---------- Post added at 11:49 AM ---------- Previous post was at 10:13 AM ----------

Uhm, the binary is asking for MSVCP120.dll. You should note that the project requires other VS runtimes than orbiter. And preferably build it against the same, so people don't have to install additional dependencies.
 
Last edited:
Nice!
And surprisingly simple as well.

Better pick another name, however - there will be confusion aplenty if you reuse mine.
Also, add a note somewhere that MSVC2013 redistributables are necessary ( http://www.microsoft.com/en-us/download/details.aspx?id=40784 )

Suggestions on the interface - you should take a look at Station Shipyard ( [ame="http://www.orbithangar.com/searchid.php?ID=4075"]Station Shipyard 090701[/ame] ), which does essentially the same, only with custom part set.
Might get some interface ideas.
KSP have a largely similar interface.
Specifically, instead of file select make a visual list of all vessels you can load, and let people select from that.

Also, be aware that few people read manuals or problemsolve - a gray, hintless window is not enough.
And you might want to use Orbiter's version of MSVC to avoid the need for another redistributable.

Disadvantage of doing it in a separate program is that all but simplest vessels will have a DLL or SC3 definition, making it impossible to determine docking port locations or proper mesh.
For DLL it's unsolvable, but for SC3 you can use GenericVessel's parser to read the docking/mesh definitions (or just make your own - it's a Windows-compatible INI file, and you'll only need a few easy to find parameters without bothering with supporting the entire monstrosity).

On the program itself - it just does not seem to work at all.
When i launch it, i get a gray oversized window (on top of everything, filling the screen, but not full-screen), with no controls.
Any click results in a crash.
Can't seen any log files.
Pressing Control-O does open a file select dialog, but selecting any file either results in a crash the moment ok is pressed, or nothing happening.

Windows 7 64bit, O2010P1 clean install.
 
Can't even run it now that VC2013 redist is installed... Did you per chance put a debug build up?
 
No, that was a release build, I'm not sure why it doesn't work.
What platform version is orbiter compiled against? Right now, it's compiling against v120(the vc2013 version)

I think I know the reason behind the crash on click, when you click on something that isn't a vessel. I will be unavailable for the weekend, but I should be able to fix the above and add some info text and logging sometime next week.

Sent from my SAMSUNG-SGH-I747 using Tapatalk
 
What would be awesome is to have a "construction plan" with a "launch schedule" which tells you what module to launch next and where to put it. And the ultimate idea would be to even create the series of scenarios using the launcher you want.

But, that's just an idea that I just had ...
 
just what i needed thanks! am i correct in thinking this will allow me to make vessels out of any standard orbiter modules and them 'bounce' them down to a single vessel? i've just downloaded it so i'll go try it out, it might be a while but i'm looking forward to seeing if you guys make an in game version. it'll add renewed purpose to making modules!
 
am i correct in thinking this will allow me to make vessels out of any standard orbiter modules and them 'bounce' them down to a single vessel?

No, that's not the purpose at all. The purpose is to provide a good interface to create large stacks of docked together vessels, because that's a pain to do in scenario editor.

The closest thing to what your looking for is IMS, which would profit greatly from such an interface, which is why I'm interested in it. The two are still completely distinct projects, though.

What platform version is orbiter compiled against?

Orbiter 2010 is built against VS 2008 if I'm not mistaken (might be even 2005?), which is why I'm mostly using that.

Anyways, I figured out my mistake. I thought the redistributables were platform dependant, not build dependent. I.e. I installed the 64-bit redistributables because I have a 64-bit system, not realising that this was only the redist needed to run stuff compiled on 64 bit, and that you need to install the x86 redist to run stuff that was compiled in 32 bit. As such, a direct link to the dependancy would have avoided the problem, but I learned something new, so no harm done...

But, as reported by Artlav, the program currently hangs itself up when trying to load pretty much any cfg. No theories on why, I'll have to get the code and plug it into a debugger first...
 
Last edited:
Orbiter 2010 is built against VS 2008 if I'm not mistaken
Orbiter 2010/P1 is VS 2005 SP1 with ATL security updates (4053). Betas from year 2011 are also VS 2005 SP1, but additionally with MFC security updates (6195). Only the newest public betas from the end of 2012 and beginning of 2013 are VS 2008.
 
Awww, it's using some VC 11 calls... meaning I can't even build it before downloading an additional 1 Gig.

What I am worried about is, can I even build an orbiter module with VS2013? if not, it would be better to start replacing those calls immediately...

Also meson800, I would recommend casting implicit conversions with data loss to avoid all those warnings that clutter up the build log.

Oh never mind, just found the answer in another thread. Time to update my visual studio, I guess...

*sigh* I'm getting old and conservative, it seems...
 
Last edited:
I fixed the largest bug at the moment, and the latest build in the description is now updated. I will move on to actual logging, help text, etc when I have time later this week.

Any click results in a crash.
Fixed the crash on a non-vessel click in the latest build, build 7de603b, please test.

A click in an empty area would select the root scene node, which passed the bit-mask test to see if the selected node was a vessel. Then, the root scene node would be incorrectly casted into a VesselSceneNode*, causing the crash.

But, as reported by Artlav, the program currently hangs itself up when trying to load pretty much any cfg. No theories on why, I'll have to get the code and plug it into a debugger first...
I could not reproduce, even with the release build, run without a debugger. I tried loading several built-in Orbiter cfg's and several IMS module cfg's, and did not encounter any crashes. What addons/cfgs specifically cause the crash? I'm wondering if this crash was somehow related to the above bug.

Also note, that I have not added camera-recentering logic, so you do have move the camera to the left (right click and drag to the right) to see the modules sometimes.

Awww, it's using some VC 11 calls... meaning I can't even build it before downloading an additional 1 Gig.
What calls is it using? I downgraded the platform version to v100 (Visual Studio 2010), and it built fine :shrug:

A general question: does it matter if I compile the module versus the 2010 or 2013 binaries? I have both versions installed, and the current code appears to build on v100(vs2010) and v120(vs2013) without any modifications. Is either version preferred over the other? I realize it would change the redistributable version that end-users would need to install, but they will have to install one anyway because I cannot build against vs2005, like Orbiter.
 
What calls is it using? I downgraded the platform version to v100 (Visual Studio 2010), and it built fine

VS 2010 uses VC++11. It's really annoying with the naming...

Specifically, std::vector doesn't have the "data" member, and stdint was also introduced with C++11. But I already installed VS 2013, so I'll be able to build shortly. Have not installed Git yet, only checked out the code as a zip currently.
Anyways, since VS2013 seems to make no problems with Orbiter, I guess it's ok to use it... many people will have to install the runtimes (same as for VS 2010), but they're not large...

Is either version preferred over the other?

I prefer 2013, because I installed it just yesterday (bye bye to another 6 gigs of harddrive space) and because if I have to upgrade, I might as well go all the way :lol:

I'd assume that more people have the 2010 runtimes installed than the 2013 ones, though.

What addons/cfgs specifically cause the crash?

I didn't find a single one that didn't. Including the default ISS. But I'll get behind the reasons shortly.

---------- Post added at 07:58 PM ---------- Previous post was at 07:27 PM ----------

Ok built it and ran it. The crash happens because of vector subscript out of range at line 231 in OrbiterMesh.cpp, function setupMesh. The reason for the the subscript being out of range seems to be simply that the vector meshGroup has a size of zero, so something obviously went wrong when loading the mesh. I'll have to see why that is.
 
Regional settings?
Like, somewhere the decimal point is . and other places it's ,
A very common problem when parsing data with default functions.
 
Ok, that was easy :lol:

VesselSceneNode.cpp, line 42 (constructor):

You have an absolute path in there! ;)


Ergo, the question clearly is: "Where is the bug?" It even makes sense in some creepy kind of way :rofl:

And to think deep thought had to construct an entire planet only that humble me some million years into the algorithm would check someone elses code... :lol:

Now for figuring out Git to actually start working on this. Say, do you mind if I replace the eventhandler? I have one ready to go that is already adapted to be plugged into orbiter later on. (MastEventReceiver-derived, of course... I'm surprised you're not using that, actually).
 
Last edited:
Ok, there were actually two different absolute paths. :facepalm:

Latest revision 0f4eb14, is updated without absolute paths.
 
I now had the time to actually run and test it a bit. I like what's there of the handling. A few things:

An alternative to middle mouse button will be needed. A lot of laptops don't have one. I'll do this when I plug in the new event handler.

While the ability to rotate stuff the way you want it when docked, keep in mind that it is not possible in orbiter: The docking ports have a fixed alignement, and short of having the module save rotated port indices and new alignements in the scenario and apply them at loadup, the vessels will not appear as they are visible in the StackEditor. Such an approach would however conflict with any add-ons that rotate docking ports by themselves (like for example IMS).

I think it would be best to only allow docking to the actual orbiter docking port alignements to keep it as generally applicable as possible.

And yeah, something's fishy with that meshloader, it seems. Or the texture loader, rather.

Anyways, I managed to check out the develop branch, I'll start easy by plugging in a new eventhandler and see if I get that stuff with the commits... :shifty:
 
Last edited:
An alternative to middle mouse button will be needed. A lot of laptops don't have one. I'll do this when I plug in the new event handler.
Thanks, I didn't think of that.

While the ability to rotate stuff the way you want it when docked, keep in mind that it is not possible in orbiter: The docking ports have a fixed alignment, and short of having the module save rotated port indices and new alignments in the scenario and apply them at loadup, the vessels will not appear as they are visible in the StackEditor. Such an approach would however conflict with any add-ons that rotate docking ports by themselves (like for example IMS).

I think it would be best to only allow docking to the actual orbiter docking port alignements to keep it as generally applicable as possible.
That's because the modules don't actually dock when they snap together at the moment...:shifty:

Inside the VesselSceneNode::snap code, I only have the first quaternion snap, which aligns it. I need to add the second quaternion which rotates the reference directions like they are in Orbiter.

Also, the rotation you see in the program occurs because the "docked" flag actually isn't set, I haven't gotten around to actually competing that section of the code. When they do "dock" together, a click on any of the stack vessels will move the entire stack. When I get time, I'll prioritize the above so it works more like it is supposed to.

Anyways, I managed to check out the develop branch, I'll start easy by plugging in a new eventhandler and see if I get that stuff with the commits... :shifty:
You might want to work off a topic branch off of develop. Just remember to push that branch to the server if you do do the topic branch.

Pushing a local branch to a remote branch (only do this once to create the branch on Github)
Code:
git push -u origin your_branch
On the crappy-looking IMS textures, do any of the modules include transparent textures? I think I might have to set a flag in Irrlicht to get it to render transparent.
 
I doubt there are any transparent textures. I'm not even sure vanilla orbiter supports them. But greg wasn't really adept at using textures, doing most detail work in polies, so i would be very surprised if he used transparency.

On the topic of reworking the vesselscenenode: i'll have to make some major changes to the overall architecture to ensure an efficient workflow with the gui.

In explicit, i'll have to preload stuff (meshes and configs) before creation of vesselscenenode.
I'll make a mesh manager to ensure that every mesh is only loaded once, and the config data will be stored in a new vessel data class, from which later, when the user creates a vessel, the vesselscenenode will be created. This won't change too much in the present code (vesselscenenode will get a new constructor, that's about all), but there is one thing that has to change: the dockport and mesh data in vesselscenenode has to be switched to use pointers. I can do that when I get to it, but it would probably be best to do it sooner if there's a lot of code to be added to the class.

Also, take into account that at one point the program will need not only to know about the individual nodes, but also about the stack they are docked in. You should write the docking code with that in mind.
 
In explicit, i'll have to preload stuff (meshes and configs) before creation of vesselscenenode.
I'll make a mesh manager to ensure that every mesh is only loaded once, and the config data will be stored in a new vessel data class, from which later, when the user creates a vessel, the vesselscenenode will be created. This won't change too much in the present code (vesselscenenode will get a new constructor, that's about all), but there is one thing that has to change: the dockport and mesh data in vesselscenenode has to be switched to use pointers. I can do that when I get to it, but it would probably be best to do it sooner if there's a lot of code to be added to the class.

Also, take into account that at one point the program will need not only to know about the individual nodes, but also about the stack they are docked in. You should write the docking code with that in mind.
Preloading the meshes and config files is a good idea which I was moving towards, but it might be better if you wrote it to fit with your GUI idea.

I however do not see the advantage of storing pointers to the OrbiterDockingPorts. If each individual vesselscenenode has it's own OrbiterDockingPorts, it can directly store information (pointers to parent/docked node) about the vesselscenenodes it's attached to.

As to the stacks. I could easily add a vector<VesselSceneNode*> to store each stack. Do you think this will really help overall performance? When I initially envisioned this, I imagined stack information would be generated mostly on-the-fly.
In the current system, the plan was to, when a node was selected in the event receiver code, to recurse through the docking ports, adding each new vesselscenenode to a vector called something like SelectedStack. Then, any movement/rotations/copy&paste operations would just act on all of the VesselSceneNodes inside SelectedStack. This should work with the current system, and is not that bad efficiency-wise because the recursive function is only called once, when the user clicks on a node. Any subsequent operations just use the generated stack info.

In my envisioned system, docking would occur as follows, using a "dock" function inside VesselSceneNode:
  • Snap our docking port to the other node's docking port, just in case
  • Set the docked bool in our docking port and the other docking port
  • Set our docking port's "dockedTo" pointer to the other docking port's parent, and vice versa
Then, when stack information is re-generated when one of the nodes in the stack is selected, it automatically includes the new docked node.

Undocking is simply handled as setting each docked bool to false, and nulling the dockedTo pointers.

What was your idea regarding stacks? It seems more complicated than it's worth to store global stacks. In that case, one vesselscenenode could not simply dock itself to another, docking would be a more complicated procedure, involving the docking sequence above, but then pointers to VesselSceneNodes would have to be bumped around the various stacks.

I'm not sure when I'll be able to get back to programming, it might be a few days, but I'll focus on docking.
 
but it might be better if you wrote it to fit with your GUI idea.

And I will. As I said, about the only change to vesselscenenode would a new constructor, which I'll implement once I need it, and switching the mesh to use a pointer. If the code you're going to add involves references to the mesh, it might be smarter to make that switch now, before a lot of new code is added that will have to be changed later on. If the switch to pointers will only affect the current code, then it doesn't matter.

I however do not see the advantage of storing pointers to the OrbiterDockingPorts.

Sorry, I was unclear. I was merely refering to the data from which the ports are created, which is currently stored as a member of each vesselscenenode individually.

I imagined stack information would be generated mostly on-the-fly.

That should work too, I guess. Just as long as we have the possibility of docking stack to stack. The advantage of having the stacks registered would be that they are easily selectable from a list, but I guess it would be more trouble than the feature is worth...
 
Back
Top