General Question Spacecraft3.dll in Orbiter 2010

[Face]

Sure. I hope staging and overall logic of the file doesn't need further explanation.

Thanks, it is now here: http://bitbucket.org/face/genericvessel/wiki/Specifications

 

[Pipcard]

I also would like a guidance file that involves altitude instead of time.
(I don't know if LaunchMFD works with multistage2)

 

[BruceJohnJennerLawso]

I also would like a guidance file that involves altitude instead of time.
(I don't know if LaunchMFD works with multistage2)

Velcro rockets uses an autopilot similar to that.

 

[Pipcard]

Velcro rockets uses an autopilot similar to that.

That's an autopilot that works on its own, without a guidance file (unless that's a feature I've never read about). It's mostly nice (see the Velcro EELVs add-on), but it isn't very precise when it comes to what the pitch should be. When I was developing my Negi-1 rocket, I made mock-up stages in Velcro rockets. However, the autopilot failed to put it into orbit.

Also, you can define custom exhaust textures and particles in multistage2. Both Velcro and multistage2 have their pros and cons.

 

[BruceJohnJennerLawso]

That's just an autopilot that works on its own, without a guidance file. It's mostly nice, but it isn't very precise when it comes to what the pitch should be. When I was developing my Negi-1 rocket, I made mock-up stages in Velcro rockets. However, the autopilot failed to put it into orbit.

Also, you can define custom exhaust textures and particles in multistage2. Both Velcro and multistage2 have their pros and cons.

Interesting. There are a few options that can help avoid guidance issues with a velcro rocket, but I always fly to orbit myself anyways. If I remember the pdf correctly, the autopilot uses orbital energy, & potential energy versus altitude.

 

[fausto]

I think that the main goal should be an OrbiterNexGen compatible Sc3 and Ms2 version. Once achieved that, we can improve the modules without change the main structure.. i was thinking about a new dll integration in order to add some missing structures, like virtual cockpit in multistage2 vessels, and alternative autopilot concept.. I don't like the idea to change all ini files in FOI vinka modules based addon :huh:

 

[Face]

I think that the main goal should be an OrbiterNexGen compatible Sc3 and Ms2 version. Once achieved that, we can improve the modules without change the main structure.. i was thinking about a new dll integration in order to add some missing structures, like virtual cockpit in multistage2 vessels, and alternative autopilot concept.. I don't like the idea to change all ini files in FOI vinka modules based addon :huh:

That's what my idea is already:

My idea - that I will outline as code in my repository - is to first produce a module that works as replacement for both SC3 and MS2. If there is sufficient "we" (aka. enough community interest and input) with a specification that is agreed upon, I will also try my hands on developing the replacement into that direction.
If there is not, at least the code for the framework that is used by so many quality add-ons is not lost, as I'll make the replacement framework code GPL.

 

[Artlav]

Seeing where this thread is going, i can add that my SC3->DLL converter can be turned into a spacecraft3.dll replacement in a few lines of code - just skip the DLL generation and loading stage, and import the ini file into the osh vessel class directly.

Maybe such a variant would fare better than a little-used converter?

---------- Post added at 16:15 ---------- Previous post was at 15:23 ----------

Here you go:
http://orbides.1gb.ru/etc/oshdll-sc3-dropin-130207.zip (obsolete)
WARNING: Replaces your spacecraft3.cfg

This is a drop-in replacement for sc3 with the OSH generic module (AKA SC3->DLL converter).
The SC3 vessels should work just as if it was spacecraft3.dll
Compatibility is the same as with the converter.

Current limitations (proof-of-concept slapped together and tested in 10 minutes, tested on Swift1 [ame="http://www.orbithangar.com/searchid.php?ID=2877"]Swift1[/ame] only):
-Only one vessel per scenario guaranteed to work
-Only the "S11:spacecraft\spacecraft3" style of defining SC3 vessels is guaranteed to work.
-Only spacecraft3, not 2 or 1 are defined in cfg.

If this works, and there is a point to improve it, then the limitations and bugs would go away quickly.

 

[Face]

Seeing where this thread is going, i can add that my SC3->DLL converter can be turned into a spacecraft3.dll replacement in a few lines of code - just skip the DLL generation and loading stage, and import the ini file into the osh vessel class directly.

Is it open source? If not, I'm afraid that it is just replacing one closed framework with another. If it is, contributions are of course welcome.

 

[Artlav]

Fixed bugs, removed all limitations:
http://orbides.1gb.ru/orbf/oshdll-sc3-dropin-130207-1.zip (obsolete)
SSBB40's big Earth station now loads nicely.

At this point i would appreciate any bugs/issues found.
Known incompatibilities are described here:
http://www.orbiter-forum.com/showthread.php?t=21727

Is it open source? If not, I'm afraid that it is just replacing one closed framework with another. If it is, contributions are of course welcome.

Making it open source is not a problem - the DLL is the sum of code the converter generate, the converter itself is nothing terribly secret.

Contributing is another matter entirely - as usual, i have my own approaches and frameworks, so my code would likely be perpendicular to any existing code.

---------- Post added at 17:19 ---------- Previous post was at 17:12 ----------

My system's structure is two modules:

oshdll.dll is a parametric vessel class.
This class gets a data block describing the vessel, and unfolds into a corresponding Orbiter vessel.

xves.dll is the converter. It parses the SC3 ini file and produces the data block the oshdll can use. oshdll calls xves on each vessel's creation.

Both modules are independent and interchangeable, so each can be tweaked on it's own.
You can replace the xves with your own parser, some vessel generator (station shipyard used that), or output from an editor (orbiter shipyard used that).

So, the ini file format is decoupled from the Orbiter version and Orbiter vessel - you only need to update the vessel's simple code to restore compatibility.

 

[Face]

Making it open source is not a problem - the DLL is the sum of code the converter generate, the converter itself is nothing terribly secret.

Contributing is another matter entirely - as usual, i have my own approaches and frameworks, so my code would likely be perpendicular to any existing code.

If you mean that you use another language than C++ together with another tool-chain, that wouldn't be too much of a problem for me, as the existing code is rather minimalistic . I have experience in Delphi and other forms of Turbo-Pascal based languages, if this is what you are hinting at.

But of course you address a problem: if it is different to what people are used to work with for Orbiter development, it is probably not a good idea to start with it. And I think this project should thrive to be "open" for as much input as possible. Something like Turbo-Pascal as developing language might be less of a problem for me as it would be to the majority of hobby coders in the Orbiter community.

Still, I could be very wrong with this view, so nothing stops you from making it open source and open for contributors to change the code base, if they are interested. This way at least your effort is not lost for the community, should you one day decide to leave it for other things in life.

BTW: my virus scanner goes ballistic on your xves.dll . It constantly tells me about a FRAX trojan. Do you do interesting things with the PE headers, maybe?

 

[Artlav]

Here is the oshdll's code, C++:
http://orbides.1gb.ru/orbf/oshdll_standalone-130207.zip
Expects to sit 2 levels from the root, i.e. in Orbiter/sources/oshdll.

The xves code is in my own flavour of Pascal, that FPC and Delphi digests mostly nicely.
I'll post it close to the evening.

It's not that similar to OGLAClient's structure - there is no Orbiter interface being exported to pascal side, just a DLL with one call that would locate and parse an ini file.

The only part in pascal is the ini parsing and interpreting - no intersections with existing Orbiter developing experience one way or another.
I find C's and C++'s string stuff extremely clumsy, so i'd prefer a higher level language for that type of task.

No idea about antiviruses flagging the file - i never use them.
The DLL is nothing special - what Delphi's compiler produced, no changes.

---------- Post added at 20:51 ---------- Previous post was at 17:39 ----------

The xves sources:
http://orbides.1gb.ru/orbf/xves_standalone_src-130207.zip
And a synced up compiled version of it all:
http://orbides.1gb.ru/orbf/oshdll-sc3-dropin-130207-2.zip

The xves should be compiled with Delphi (7, anything newer from Borland is dead body twitches), or Free Pascal.

I've cleaned up that code from any dependencies on frameworks, so it should be clean and straightforward.
The INI file is being interpreted and a data structure is being composed.
The structure is then sent back to the oshdll.

xves should be largely Orbiter-version-independent, so any compatibility breakages should be fixable by changing the community-friendly oshdll.



How does that look?
I kind of butted in, it seems.
If we are going my way, then system-wide, i suppose the goal is to get the compatibility sorted out, then ensure (and tweak if needed) the compatibility with D3D9Client or any others.
Some bugs and limitations of the SC3 are already overcome - no vessel or object count limits, etc.

After that - follow the Loru's specifications?
oshdll already contains support for UMMU and Kulch's PayloadManager.
Later might be removed due to obsolescence.

OrbiterSound support can be added easily, but i have zero experience working with it.

One downside is multistage2, which is a whole new unopened can of worms for me - no idea how hard would it be to add support for it.

 

[Face]

Here is the oshdll's code, C++:
http://orbides.1gb.ru/orbf/oshdll_standalone-130207.zip
Expects to sit 2 levels from the root, i.e. in Orbiter/sources/oshdll.

<snip>

The xves sources:
http://orbides.1gb.ru/orbf/xves_standalone_src-130207.zip
And a synced up compiled version of it all:
http://orbides.1gb.ru/orbf/oshdll-sc3-dropin-130207-2.zip

The xves should be compiled with Delphi (7, anything newer from Borland is dead body twitches), or Free Pascal.

I've cleaned up that code from any dependencies on frameworks, so it should be clean and straightforward.
The INI file is being interpreted and a data structure is being composed.
The structure is then sent back to the oshdll.

xves should be largely Orbiter-version-independent, so any compatibility breakages should be fixable by changing the community-friendly oshdll.

So if I understand this right, xves.dll is "just" the parser back-end. I don't see a problem in using the Pascal code at first, if it quickly gets us to a working replacement. I think it would make sense to eventually port it to C++, but this can certainly wait.

I only have a licensed Delphi 5 copy, so I guess I can't immediately compile it now. Have you tried to compile it with a freely available tool-chain, and if so, where can I download it?

That said, I'd like to check-in your code-base into my repository here. As I said before, I will make it open source under GPL v2+ . This would mean that your code will be under this license, too - of course credited to you as author. I will not do it if you are not happy with this. So what do you say?

How does that look?
I kind of butted in, it seems.
If we are going my way, then system-wide, i suppose the goal is to get the compatibility sorted out, then ensure (and tweak if needed) the compatibility with D3D9Client or any others.
Some bugs and limitations of the SC3 are already overcome - no vessel or object count limits, etc.

"Butted in"? Why do you feel that way? I think the ultimate goal is to get a future-proof SC3 replacement first, and to get it in a way that it can't be "lost" anymore. Your work certainly helps to reach this goal.

After that - follow the Loru's specifications?
oshdll already contains support for UMMU and Kulch's PayloadManager.
Later might be removed due to obsolescence.

OrbiterSound support can be added easily, but i have zero experience working with it.

One downside is multistage2, which is a whole new unopened can of worms for me - no idea how hard would it be to add support for it.

As depicted in the (very crude) roadmap here, I think this is the way to go, yes. MS2 should of course be implemented BEFORE there are additional features added. The Wiki is open for Bitbucket users, so if you have suggestions, please edit as you see fit.

No idea about antiviruses flagging the file - i never use them.
The DLL is nothing special - what Delphi's compiler produced, no changes.

Your latest compile package is not having the issue, BTW.

 

[Donamy]

One downside is multistage2, which is a whole new unopened can of worms for me - no idea how hard would it be to add support for it.

IMHO, your UAP is better than MS2, it just needs more control.


One major item needed would be to be able to push the buttons for the 2 MFDs in the virtual cockpit, without the need for the glass-cockpit addon.

 

[Artlav]

That said, I'd like to check-in your code-base into my repository here. As I said before, I will make it open source under GPL v2+ . This would mean that your code will be under this license, too - of course credited to you as author. I will not do it if you are not happy with this. So what do you say?

Better make them more digestible then.

Here are the to-the-commit version of the code, with comments and clean variable names:
http://orbides.1gb.ru/orbf/oshdll_standalone_src-130207-1.zip
http://orbides.1gb.ru/orbf/xves_standalone_src-130207-1.zip

No problems about turning it GPL, that i know of.
There are tiny bit of code from the DG.

So if I understand this right, xves.dll is "just" the parser back-end.

As i described in #110, there are two parts - the INI parser and the Orbiter vessel module.

The module passes it's vessel name to the parser, the parser locates the ini file and produces a data block to pass back (or blank vessel if no ini found), the vessel receives the data block and unfolds into a vessel class according to it.

The advantage is that the in-the-flux Orbiter part is decoupled from relatively-static INI parsing part. Both can be worked on independently, be made in languages to fit the task, etc.

Orbiter vessel part is a simple C++ module that can be updated (or fixed) independently of the more complex parser, by anyone familiar with Orbiter add-on development.

That's the architectural outline of the system.

I only have a licensed Delphi 5 copy, so I guess I can't immediately compile it now. Have you tried to compile it with a freely available tool-chain, and if so, where can I download it?

Have you tried the Delphi 5? It might work, as there is little system dependent or object-oriented code.
Failing that, Free Pascal ( http://www.freepascal.org ) should work fine.
I've even included a build script for it.

"Butted in"? Why do you feel that way?

Well, you were doing things on your own, starting a project, laying out a framework, then i go in and give you my own 3/4-done working solution to replace all that.
I've met people who would consider that rude.

Your latest compile package is not having the issue, BTW.

I've removed most of the unused framework parts, including some SSE-assembly-optimized memory copy functions. Maybe these were flagging it off?
I've had these problems with FASM - antiviruses flagging up programs left and right.

IMHO, your UAP is better than MS2, it just needs more control.

Hm?
UAP does not define staging like Velcro or MS2.
It only flies a rocket.

One major item needed would be to be able to push the buttons for the 2 MFDs in the virtual cockpit, without the need for the glass-cockpit addon.

The problem there is perpendicular to SC3 - most of it's add-ons, even good ones with detailed VCs, simply don't have the buttons in question routed in the VC mesh:

Give me a mesh with places for buttons, and the buttons would be implemented with insignificant effort - there is nothing terribly difficult about them if you have the right mesh.

 

[Donamy]

Here's what I need.

 

[Artlav]

Here's what I need.

I don't get it. Any clarifications?

 

[Donamy]

That is my VC mesh with the buttons and switches.

 

[Artlav]

And?
I don't see buttons for MFDs routed in there.
Or do you want to assign some random buttons from the panel as them?

 

[Face]

Better make them more digestible then.

Here are the to-the-commit version of the code, with comments and clean variable names:
http://orbides.1gb.ru/orbf/oshdll_standalone_src-130207-1.zip
http://orbides.1gb.ru/orbf/xves_standalone_src-130207-1.zip

No problems about turning it GPL, that i know of.
There are tiny bit of code from the DG.

Ok, thanks. I will commit your sources under your name. Normally I use the forum handles for that, but if you like, I can use a standard template in the form of "Full Name <[email protected]>". If you prefer the later, just drop me a note.

Have you tried the Delphi 5? It might work, as there is little system dependent or object-oriented code.
Failing that, Free Pascal ( http://www.freepascal.org ) should work fine.
I've even included a build script for it.

No, I did not try Delphi 5, as I think it will choke on Win7, anyway. That said, I could try one of my VMs with XP, of course, but... meh. I'll rather use the free compiler, so I know that it works if other developers want to change something there.

Well, you were doing things on your own, starting a project, laying out a framework, then i go in and give you my own 3/4-done working solution to replace all that.
I've met people who would consider that rude.

I do not consider it rude, especially not for the polite way you did it. I just had the feeling that folks around here complained about the status quo without even thinking about solving the problem. That's why I proposed to start a project to get where we want it to be. And here you are, contributing 75% to previously 1% .

Interesting enough this is the second time now that someone just had to say "let's do it" to get the community moving. D3D11Client had the same strange "block" to overcome, and there my actual contribution was rather minimal, too. So please don't fear to hurt my ego, even my wife says it is much too big to be hurt like this .

On this note, I think it is now high time to start a dedicated thread for the development of "genericvessel". I'm going to post it as soon as I've got your work up and running there.

regards,
Face