Project Orbiter Addon IDE - automatic C++ code generator

[chpeller]

I had a look on the Orbiter Shipyard project, it is exactly the idea. The render is very good. I think it is a good proof of concept i never dreamt that it will be possible to have something working right now.
Is the code reusable ?
Obviously the mind is a bit different than my own vision, you supposed it was already an existing .ini file, and you generate an improvement of that .ini file and not C++ code. But the basics of my user oriented objectives are the same.
I invite all the potentials contributors to test your project to have an idea of the project goals.

Why did you stoped this project ?

 

[Artlav]

I like your combined approach for the editor, is it so hard to make ?

Not sure, really.
It might not be much harder than to make the full one.

Would you like to help me to initiate this project ? with your experience you could be a major wining contributor.

I tend to be highly unpredictable in terms of hobby projects, and i enjoy hardware more than software these days, so don't count on me as a core contributor if you want to do things in a reasonable time.

regarding your writing about custom tools, the problem is that we need to work with a team of contributors and i think it is much better if they, (i am not developper unfortunatly), use the same tools for the same job.
How do you think we could do this ?

Exactly, and the common denominator is C++ and Visual Studio 20**, not Java and Eclipse.

And have you an idea about the graphical framework for the interface ?

No.
I always made my own, so i'm not too familiar with the selection.

---------- Post added at 18:18 ---------- Previous post was at 18:12 ----------

Is the code reusable ?

Genericvessel and Station Shipyard use the derived backplane, the graphics are OGLAClient, the GUI is a library, but everything else is gone.

Obviously the mind is a bit different than my own vision, you supposed it was already an existing .ini file, and you generate an improvement of that .ini file and not C++ code. But the basics of my user oriented objectives are the same.

English parsing error.
Please rephrase the statement.

Why did you stoped this project ?

Too much details to attend to. Too much work to get it to perfection.

 

[Urwumpe]

Too much details to attend to. Too much work to get it to perfection.

Which is why his idea of having multiple developers for that is not wrong.

But who would stop his own projects for this?

 

[dumbo2007]

3. Start without big UI, but make it interactive. I.e. don't do fancy dialogs and snap-in features right from start, concentrate on the ability to create content fast.
4. Add dialogs to get away from text-based definitions.

Number 3 could be achieved by means of a reload function to SC3, i.e. the possibility to edit the INI while running the simulation, then reload the configuration to see what it changes.

Which .ini files exactly are these ? Something related to Orbiter core or SC3 ?

Is it possible to change the contents of the simulation by reloading a ini ? Like say load an alternate star system

 

[Face]

Which .ini files exactly are these ? Something related to Orbiter core or SC3 ?

In the scenario I described I had SC3 INIs in mind. AFAIK, Orbiter doesn't use INIs itself, just key/value pair configuration files and dedicated block syntax.

Is it possible to change the contents of the simulation by reloading a ini ? Like say load an alternate star system

I'm not sure I understand what you mean. With a SC3 INI, you certainly can't change the whole simulation, as it is meant as vessel configuration.

 

[dumbo2007]

Ah ok. Just wishful thinking on my part

 

[chpeller]

The SAMOSS (Simple Addons Maker for Orbiter Space Simulator), project as just been created on SourceForge.
Feel free to contact us if you want to contribute.

 

[Artlav]

The SAMOSS (Simple Addons Maker for Orbiter Space Simulator), project as just been created on SourceForge.

Um.
http://www.youtube.com/watch?v=Jb0WAo5qOpc#t=00m52s

Also, Sourceforge search returns no results for SAMOSS or Simple Addons Maker, so you better link it directly.

Which is why his idea of having multiple developers for that is not wrong.

But who would stop his own projects for this?

Huh? He asked why i stopped, not why he could.

 

[Urwumpe]

Huh? He asked why i stopped, not why he could.

I didn't refer to his question there. It simply means a lot of work to even get started, you can't just contribute to it 5 minutes per month to make it go ahead. Some developer will have to join and work focussed only on that. Maybe two.

 

[BruceJohnJennerLawso]

Just my 0.2€

A visual companion to SC3 / multistage is the way to go. It can be done in almost any language, the only "problem" being mesh display.
Integration into Orbiter is nice, but what would happen when the next version comes out? Better use a standalone solution.

Nevertheless, to be really useful, it would need to be integrated with some sort of data repository. I remember a discussion about a rocket engine database sometime ago.
I'm thinking about something where you could choose something like Rocket » Atlas; Payload » Mercury and get that assembled into some sort of workflow that you could manipulate.

What I don't see working is making this work with individual meshes, unless they are uploaded to the "system" with some data associated (mass, internal camera position, animations, etc). So we are talking free meshes and data here (or at least Orbiter licenced ;-) )

I would much prefer having a Velcro/Multistage editor all combined in one program. It's been asked for for such a long time, & AFAIK, SC3 is pretty much fine to use without a visual editor, since there aren't that many things needed position wise to develop a SC3 config, but working with multiple meshes and vessels in Multistage/Velcro makes a visual interface more necessary.

I think the best solution to the problem is just to use Meshwizard, gives more flexibility with making mesh changes at the same time as finding coordinates for various things.

Which .ini files exactly are these ? Something related to Orbiter core or SC3 ?

Is it possible to change the contents of the simulation by reloading a ini ? Like say load an alternate star system

Loading an alternate star system, like in Orbiter Galaxy doesn't change configs themselves. The orbiter process terminates, while the Orbiter Galaxy program keeps running, then respawns the Orbiter process with the new scenario file added.

 

[chpeller]

Um.
http://www.youtube.com/watch?v=Jb0WAo5qOpc#t=00m52s

Also, Sourceforge search returns no results for SAMOSS or Simple Addons Maker, so you better link it directly.

It works now ...

 

[dumbo2007]

Doing the editing from inside the Orbiter proper is ripe for problems, from GUI and camera controls to resource allocation exhaustion and OVP compatibility. I was at one time thinking of making a KSP-like editor for Velcro rockets from inside Orbiter, and there were too many problems even to get to a proof-of-concept.

Is the memory restrictions due to the 4GB memory limit of Orbiter as its a 32 bit process. So if the user loads a large texture or many such textures(to try them out on say a planet) then this "editor+orbiter" combine could run out of memory ?

In that case a way out maybe to have a separate process that provides the editor. When the user wants to try out something, then it launches Orbiter with the proper files copied in to the correct directories inside the Orbiter installation. I think there is a way to skip the Launchpad too.

Many games seem to take this approach where the editor is separate, so if the game crashes, the changes made in the editor are not lost.
Of course the editor has to maintain its own Orbiter installation in a pristine state at all times. So any changes made for previewing must be reverted once the user has viewed his/her changes.

 

[Face]

Is the memory restrictions due to the 4GB memory limit of Orbiter as its a 32 bit process. So if the user loads a large texture or many such textures(to try them out on say a planet) then this "editor+orbiter" combine could run out of memory ?

In that case a way out maybe to have a separate process that provides the editor. When the user wants to try out something, then it launches Orbiter with the proper files copied in to the correct directories inside the Orbiter installation. I think there is a way to skip the Launchpad too.

Way too much premature optimization IMHO. I think you will go a very long way before you hit any memory restrictions if you use an Orbiter session for "normal" add-on development. After all, every memory restriction you hit with an add-on will be a problem in Orbiter anyway, so such an add-on would be close too useless for normal Orbiter users.

Many games seem to take this approach where the editor is separate, so if the game crashes, the changes made in the editor are not lost.

This is a valid point, of course. OTOH, the same is true for any separate editor you make. Just because you code a 3D renderer from scratch doesn't mean it will be more stable than Orbiter itself. And it is not only about the 3d rendering, it is particle simulation, part animation, flight characteristics, and so on.

Do you really want to reproduce all these aspects of an add-on in your editor? If so, I bet the first few versions will be less stable than Orbiter is now.

Please scratch that separate editor approach. It will lead you nowhere but vaporware. Artlav tried it and ended up with a practically stalled project, and that man is a genius.

While it is certainly possible that you can come up with a similar project after some endless hours of work, it will not be used by people at first, because it is alpha/beta/not-yet-done/WIP/not-WYSIWYG-yet . And that is the crucial thing here IMHO: early usage by the target audience.

You need an approach that includes your users right from start of the project. That means early functionality, incremental progress. I know that this will discourage big-design-up-front, but I think a project like this on a free basis - initiated by non-coders for other non-coders - should not focus on a waterfall process, anyway.

just my :2cents:

 

[dumbo2007]

Yeah true, the best editor is of course the one which is inline so the changes are visible immediately. While editing, Orbiter could be stalled by setting the time step to 0 perhaps and each time the user wants to try something, the current time can be set to a fixed MJD and the simulation can be started.

The current set of panels used by Orbiter based on Windows native controls can be extended I guess. Mouse dragging and clicking/picking inside the Orbiter window will have to be supported by the graphics client though.

 

[Face]

Mouse dragging and clicking/picking inside the Orbiter window will have to be supported by the graphics client though.

Why? Just define the editor to only work in inline client at first. If you want a dedicated editor for a specific graphics client, just create a new version that makes special efforts to e.g. define normal-maps, reflection definitions and whatnot.

You see, it will be so much work to come up with a decent dialog/menu/interaction pattern, anyway, why complicating it with requirements that have a very low probability of importance? YAGNI.

 

[Urwumpe]

You see, it will be so much work to come up with a decent dialog/menu/interaction pattern, anyway, why complicating it with requirements that have a very low probability of importance? YAGNI.

Also, you could create line drawings of a mesh in a dialog for having something clickable. it must not be in the Orbiter Window, actually too much 3D can also be annoying. If you want to be precise, you also need to be able to manually edit data and maybe as secondary objective, have reference planes and lines for assisting you. Being able to see how much force and torque a thruster group produces might also be of interest.

And you could also try Artlavs suggestion and simply "hijack" a graphics client for rendering the vessel like Orbiter would.

 

[Face]

And you could also try Artlavs suggestion and simply "hijack" a graphics client for rendering the vessel like Orbiter would.

Still I think controlling a graphics client is too much work to invest at first. Even if a client is error-free and stable enough, you still have to create the right framework and the right callback calls in the proper order.

 

[Urwumpe]

Still I think controlling a graphics client is too much work to invest at first. Even if a client is error-free and stable enough, you still have to create the right framework and the right callback calls in the proper order.

Well, the biggest problem would be finding out, on what an user clicked in the 3D view. Would be easier with other graphics engines, for example IrrLicht has a good interface for that. But then, the rendering would not be like Orbiter.

 

[Artlav]

The Velcro Rocket Editor i planned was a vessel, sitting on a placeholder base near Habana.
The interface was drawn using the vessel's 2D panel feature.
The ship to be assembled was standing in the middle, and the cockpit's camera was able to rotate around it like is it was a regular vessel, with a certain trick.

The "resource allocation exhaustion" problems were about things being created and destroyed constantly (meshes, engines, animations, etc), which caused some random crashes. It might be my fault, or something in the older Orbiter.
Then, one of the updates screwed up the camera trick i used, and i never found a way to fix it, which got it over the give up point.

Never got around to 3D click detection, but i guess it should be manageable - either with VC controls of some sort, or by doing the matrix math in reverse.
Orbiter have a fixed projection, so the last option should not be very hard to do in sketch.

I guess, that if these problems are overcame, then the embedded editor is the way of least resistance and most power.

No need to restart Orbiter or anything - vessel being built can be simply passed to a newly-created xves instance, to be test-flown immediately.

simply "hijack" a graphics client for rendering the vessel like Orbiter would.

And write an Orbiter facsimile to drive it?
That too goes nowhere fast - http://spaceway.1gb.ru
Even the Orbiter Shipyard's editor was pretty simplistic - the animations and mesh logic are OGLAClient's domain, but everything else was simply not there.

 

[Face]

Well, the biggest problem would be finding out, on what an user clicked in the 3D view. Would be easier with other graphics engines, for example IrrLicht has a good interface for that. But then, the rendering would not be like Orbiter.

I'm not even talking about that stage. Just loading the mesh, textures and scenario definitions and then calling the right functions of the rendering pipeline - defined by Orbiter's gfx client interface - would be an overhead I wouldn't want to invest in such a project for a first step.

It is about defining an addon, not about creating/editing a mesh currently, isn't it? For mesh creation, there are much better solutions ATM, but there is none for putting it together for an add-on visually. And only for mesh creation you really need a fancy CAD-like point&click view/plane/object-snap interface.

For positioning meshes and thruster origins, an interactive spin box like ScnEditor's would already greatly enhance development of a SC3-like INI description. Even an edit-box - where you simply type in the numbers - would make it easier at our current state-of-affairs.

This is what I meant in my earlier suggestion: start small, but with already huge win over the standard notepad->Orbiter->notepad->Orbiter approach for DSL-driven development, and you'll get to your audience for feedback. Small improvements, like visually placing e.g. thruster origins by clicking planes of the mesh can be added incrementally.