OHM StackEditor

[OrbitHangar]

Author: meson800

Co-Created with jedidia

StackEditor is both a standalone and in-Orbiter addon that allows for
click and drag construction of larger ships/space stations, IMS-style, out of smaller
Orbiter vessels.  StackEditor can also import and export these constructions
to and from Orbiter.

 

Requires the VS 2013 redistributable here. (If that direct link doesn't work, use this link and select the x86 redistributable)

 

The default toolbox sets require an IMS install, but you can create your own toolboxes with any Orbiter vessel.  To use all IMS toolboxes, go into StackEditor/StackEditor.cfg and change the default toolbox set from Default to IMS.



DOWNLOAD

 

[boogabooga]

Kerbalification of Orbiter? :thumbup:

 

[meson800]

Kerbalification of Orbiter? :thumbup:

There may have been some KSP influence on the idea :lol:

 

[Donamy]

Can it use SC3 vessels ?

 

[meson800]

Can it use SC3 vessels ?

Technically they can be loaded if one adds the SE_MeshName and SE_DOCKLIST parameters as described in the readme.

However, they might not import/export to Orbiter correctly.

---------- Post added at 12:22 PM ---------- Previous post was at 11:40 AM ----------

Tested, SC3 vessels do not work. This is because SE only looks in the Config/Vessels folder.

I'll see if I can make a patch to let SC3 work.

 

[jedidia]

There is another, bigger problem here: As far as I remember, it takes medium-tier hacking skills to have more than one SC3 vessel of a kind in a scenario at once. This would reduce the usefulness of StackEditor extremely (not to mention that it would make it fairly crash-prone...). However, I think GenericVessel finally fixes that circumstance, and it might be complete enough by now to make an extension to it worth thinking about.

It's still a bit of work, since it basically requires another set of parsers... Could somebody more knowledgable in the matter advise us a bit on the loading scheme of SC3/GenericVessel? I know they use .ini files, but how is the loading handled? do they come with additional config files that reference the dll and trigger the loading of the .ini? in that case they could be made compatible by a few additions to their config file without any stackeditor side support requirements.

 

[marcellino4]

Hi folks. This aplication looks fine, but is there any option how put great ISS into this program? Thanks for any advice

 

[jedidia]

The same way as the delta glider or any other vessel not immediately compatible (see readme). Of course, you'll have to find out where the docking ports are on the ISS.

 

[4throck]

Good idea and it works fine.
Copy/paste is a great feature, along with undo.


Constructive criticism :
Interaction is not that great. Undock / detach parts is hit and miss, and camera pan/move/rotate is also a bit confusing.

I'd suggest adding front,side and top down views, and a more direct undock or delete module option. Why not simply select the module with "tab" and allow it do be deleted with "del" ?

 

[jedidia]

Undock / detach parts is hit and miss

Undocking is hit and miss? :blink:

I would have understood it if you said docking, but undocking baffles me a bit... click on a vessel, hit tab, click on node, done... could you explain a bit better how it behaves unexpectedly?

 

[Face]

Could somebody more knowledgable in the matter advise us a bit on the loading scheme of SC3/GenericVessel? I know they use .ini files, but how is the loading handled? do they come with additional config files that reference the dll and trigger the loading of the .ini? in that case they could be made compatible by a few additions to their config file without any stackeditor side support requirements.

My last version of genericvessel uses a layered approach to determine where to load the definitions from. The code can be inspected here: https://bitbucket.org/face/genericv...icVessel.cpp?at=default#GenericVessel.cpp-117

Basically, it first tries the SC3 scheme (INI file from vessel name), then it tries to find an INI file with the class name. If this fails, it loads the standard Orbiter configuration for that class and expects INI tags in it. This way, genericvessel authors can create vessels with configurations inside the /Config/Vessels folder and have them ScnEditor-created as well.

The release comes with an example for that: Donamy's excellent EVA puppet (multi-arm!) can be spawned from ScnEditor.

 

[meson800]

Good idea and it works fine.
Copy/paste is a great feature, along with undo.

Thanks

camera pan/move/rotate is also a bit confusing.

Yeah, it's not the most intuitive right now...what would make it better?

I'd suggest adding front,side and top down views, and a more direct undock or delete module option.

Why not simply select the module with "tab" and allow it do be deleted with "del" ?

Do you mean combining undocking with deletion? Currently "del" deletes the currently selected stack. Would the ability to delete a single module, splitting any connected modules into separate stacks, be better?

 

[Face]

Forgot to mention: authors don't have to actually supply the INI tags in the standard Orbiter config at all. Due to the fallback scheme, you can create a class INI and add a skeleton config in the Config/Vessels folder, that just points to the module "genericvessel". This is actually what the example demonstrates.

 

[jedidia]

So in other words, any genericvessel that supplies a config with declarations for either Orbiter or StackEditor mesh and dockports will work. That sounds good.

 

[4throck]

Thanks
Would the ability to delete a single module, splitting any connected modules into separate stacks, be better?

To me yes. Simpler and more flexible I think.

_____________________


Just to add that I successfully exported a large "Freedom dual keel" type station to Orbiter, and all went well!
Quite good performance. Finally got to grips with undocking elements and rotating the camera... ;-)

The root vessel created does not correspond to an IMS command module. On my case the command module got named Freedom_7.
IMS then fails, only attaching two docked vessels, and integration just makes them disappear.
Surely an IMS problem, or simply a too complex stack to integrate, I don't know.
Tried to rename elements to shorter names, but got the same result.

Will try with a simpler station design

 

[4throck]

Ok, tried to load the stack on another Orbiter install and IMS integration went better.
So it's an IMS/Orbiter install problem, not StackEditor.

 

[jedidia]

The naming depends on the node you select the stack with, since StackEditor has no concept of command or whatever modules. So if you want to export an IMS vessel, it's usually a good idea to grab the stack at the command module for export.

 

[boogabooga]

WOW. This has made IMS WAY more practical. Thank you!

Issue:
I you rotate a part to certain orientation and then attach, the part snaps back to whatever orientation it feels like.

 

[jedidia]

I you rotate a part to certain orientation and then attach, the part snaps back to whatever orientation it feels like.

Not to whatever orientation it feels like. It snaps to the orientation of the docking port. Which is neccessary, or you will have a nasty surprise when you export to orbiter, as orbiter does not support rotating dockports natively. We could rotate them, but then they would default back to their original rotation once you reload the scenario.
Making the rules for docking in SE the same as in Orbiter is the only practical way to ensure that what you build is what you'll actually get when you export to orbiter.

Let me note that replicating this orbiter feature reliably has given us some headache, so it definitely is a feature, not a bug

 

[meson800]

Let me note that replicating this orbiter feature reliably has given us some headache, so it definitely is a feature, not a bug

So much matrix math to wrap our heads around :lol: