Project Orbiter Addon IDE - automatic C++ code generator

[Artlav]

Start small, eh?
How about an embedded text editor inside Orbiter?
You open an INI file in it, edit what you need, and have the genericvessel recompile the changes at once, without closing the simulation.

A dialog, like rcontrol module, called up by a hot key when in an SC3 vessel, with a text editor, and two buttons. Press recompile button, and your vessel gets updated.

Worth an evening to make?

 

[Face]

Start small, eh?
How about an embedded text editor inside Orbiter?
You open an INI file in it, edit what you need, and have the genericvessel recompile the changes at once, without closing the simulation.

A dialog, like rcontrol module, called up by a hot key when in an SC3 vessel, with a text editor, and two buttons. Press recompile button, and your vessel gets updated.

Worth an evening to make?

Yeah, that's exactly the idea. I would even go so far as saying that the embedded text editor is not needed at first. Just start with the reloading capability. You can test that already with notepad (or whatever) in parallel to Orbiter in window mode, and a dialog with a big, fat "RELOAD" button.

If that works out, go on to the first IDE-like functionality: a dialog as a kind of wizard to create a new "add-on". It could take a name plus a mesh-file and create a new genericvessel configuration from a simple template, and then create an instance. Then you can pop up another dialog with the embedded editor, that maybe auto-saves and fires a reload event everytime you change something and stop typing (with a delay of say 10 seconds). Of course the reload feature must be really stable and fault-tolerant, maybe with a feature to highlight wrong syntax in the editor.

As I see it, that would be so much win for SC3/genericvessel developers. And it would be also something you can build upon.

And I have no doubt that an experienced coder like you can really churn that out in an evening. Compared to the months of estimated development a dedicated editor would mean, that would be a great ROI .

 

[4throck]

Yes, an in Orbiter sc3 editor would help for placement of rcs thrusters, aminations, etc,etc. Much usefull. Even if it only generatef somo syntax for copy/paste by the user into the appropriate configs...

 

[dumbo2007]

ok, so looking at the generic vessel code , whats xves ?

oh no pascal again !!

So this GenericVessel class is the one to which stuff is added by the user ?

---------- Post added at 04:32 PM ---------- Previous post was at 04:27 PM ----------

Yeah, that's exactly the idea. I would even go so far as saying that the embedded text editor is not needed at first. Just start with the reloading capability. You can test that already with notepad (or whatever) in parallel to Orbiter in window mode, and a dialog with a big, fat "RELOAD" button.

If that works out, go on to the first IDE-like functionality: a dialog as a kind of wizard to create a new "add-on". It could take a name plus a mesh-file and create a new genericvessel configuration from a simple template, and then create an instance. Then you can pop up another dialog with the embedded editor, that maybe auto-saves and fires a reload event everytime you change something and stop typing (with a delay of say 10 seconds). Of course the reload feature must be really stable and fault-tolerant, maybe with a feature to highlight wrong syntax in the editor.

Ok now we are talking. Right I ll try that.

---------- Post added at 04:36 PM ---------- Previous post was at 04:32 PM ----------

So big fat reload button basically triggers a re-read of the ini file and sets the appropriate members in GenericVessel

 

[Face]

ok, so looking at the generic vessel code , whats xves ?

oh no pascal again !!

So this GenericVessel class is the one to which stuff is added by the user ?

There is nothing wrong with Pascal. Artlav just had this backend parser handy from his previous projects, and wants to keep it compatible with his other projects by sticking to the 2 layer architecture.

The xves parser just deserializes the INI file into a structure. The actual work is done in the genericvessel class. But there is nothing that a user should add there.

 

[Artlav]

Just start with the reloading capability.

Reloading is working now, but there are a few resource leaks.
No text editor yet.

Tried to commit, but got lost in your renames.
Here it is: http://orbides.1gb.ru/orbf/genericvessel-reload-130519.zip

Two problems - how to detect that the focused vessel is our class (dialog is global)?
And, resource deallocation is far from perfect - there are leaks, some of them with unknown plugability (meshes, drag elements and UMMU).

This is the kind of situation for which i insisted on keeping the separate layers for Orbiter vessel and data structure creation - with it, you can swap xves to a link to the editor, and have the same exact module perform there, while with your SC3Data puncture it all becomes impossible.

 

[Face]

Reloading is working now, but there are a few resource leaks.
No text editor yet.

Tried to commit, but got lost in your renames.
Here it is: http://orbides.1gb.ru/orbf/genericvessel-reload-130519.zip

Thanks! I'll try to merge it in. On what version did you base your changes?

Two problems - how to detect that the focused vessel is our class (dialog is global)?

One way could be to check the class configuration to contain a "[CONFIG]" section with a "MESHNAME" key. Of course that is not 100% perfect, but it should suffice for starters.
EDIT: or better yet - if we already have the class configuration file, anyway - reading the Module parameter to see if it is "genericvessel".

And, resource deallocation is far from perfect - there are leaks, some of them with unknown plugability (meshes, drag elements and UMMU).

That was to be expected and one of the reasons I suggested focusing on a stable reload first. All the problems encountered here would haunt you in every incarnation of an editor, anyway. Just now the side-effects can be minimized.

This is the kind of situation for which i insisted on keeping the separate layers for Orbiter vessel and data structure creation - with it, you can swap xves to a link to the editor, and have the same exact module perform there, while with your SC3Data puncture it all becomes impossible.

SC3Data per se is no puncture of it, just encapsulation. You just have to use a different function call in the Init function of it or load another xves.dll. What makes it break are the subsequent UMMU and Payload classes with their Init functions, because they assume an INI file as underlying data model.

In this case, though, I'd refrain from skipping the INI file data model for an internal memory model, like you seem to suggest with the xves exchange. The reason I say so is simple: crash resilience. If we always use the PrivateProfile API of Windows, we can make small, immediate changes to the resulting INI file while not having to worry about keeping the data persistent. If we use "just" another backend that deals with memory directly, we will have to make that rock-solid.

For the first run without embedded editor, it is irrelevant, anyway. There we'd have to reload the file with every press of the button. How we update/re-create the current vessel representation (and how we get it solid) is independent from the load method.

---------- Post added at 18:50 ---------- Previous post was at 14:16 ----------

OK, I've pushed your changes as a commit deriving from your master branch and named it Artlav\reload. Looks good :thumbup:. I've also started to merge it into my branch, and besides the missing reload feature in my classes (obviously), it works, too.

 

[florentin]

let me present myself : Florentin, 16 years old, i've been hired by chpeller to work on this project.
sorry for the bad english, i am french, feel free to correct my mistakes.
the devellopement already started, i focus first on the mesh loader. The wireframe view is ok :

but when i want to load textures, i get this :

the most important part of the texture is well positioned, but the other is anarchic. I think it's the "TEXWRAP" param in the mesh file, i don't understand the use of this param. Any idea ?