General Question Spacecraft3.dll in Orbiter 2010

[BruceJohnJennerLawso]

The community has also seemingly been to willing to kick developers to the curb too.

The community and Orbiter should hold the developers in a high regard. Without them Orbiter is a fraction of its potential. And they do this for nothing more than the love of the sim. It is not too much to ask that SC3 compatibility be maintained in the future.

I agree with that for sure. My feelingt is that it may soon be time to begin discussion on SC4, and make sure the source is open this time. Besides, if SC4 can happen, think of all of the new features we could add

 

[Ripley]

...As Ripley said, there is already a Spacecraft -> compiled DLL converter.

It was not me who said that, it was N_Molson.

...Regarding giving the sources to the community, any SC3 add-on IS the sources...

What does this exactly mean? What is "\Modules\spacecraft3.dll" then?
I've never developed with SC3. I'm now reading its doc and I see there's a whole lot of possible parameters.

 

[Arthur Dent]

For inexperienced programmers, Spacecraft3.dll and multistage2.dll is the only way to make Orbiter vessels. With a few parameters in a text file, you can create a fully functioning Orbiter vessel. This is way easier and faster (for the inexperienced) than coding and compiling in C++.

The only thing better would be, if spacecraft3.dll and multistage3.dll could get unified. Sitting in a capsule on top of a multistage rocket and only being able to use and see the VC when you're separated from all multistage parts is a bummer.

 

[Izack]

Never understood why some people only like add-ons made with certain tools or languages.
I guess that it might have something to do with preventing others from improving or studying from their work. Another possibility is trying to force a dependence on add-on X or Y for certain special features.
In short, fan-boy or childish behavior.Whatever...

Oof. I (and I think I speak for a few here) prefer to use compiled libraries because they are infinitely more versatile than spacecraft3 vessels, and less restricted (for instance, the classname-vesselname issue) and there is no way around that. I respect Spacecraft3 and the remarkable things that have been done with it, but it is, ultimately, a blunted tool compared to the 'intended' method of writing addons in C++. It's MSPaint vs. Photoshop. One can get crazy-good with Paint, but no one can deny who the superior software is.

I agree somewhat on the point of source-releasing (on that note, any of my meager code is available on request.) For the community's sake I urge any developer to make public their code, so it can be maintained and expanded beyond its original capacity, especially if the developer abandons the project. But at the same time, we have some professional programmers here and some remarkably complex projects, and I understand if anyone wants to protect their craft, because some people will steal work if they can. Zealously sitting on your project and refusing to update or release it, when so many are wanting it (not saying the name I want to) is childish and pathetic, though.

To finish, I'd like to point out that there's something called Lua scripting included in orbiter. As far as I know, it can do amazing stuff and replace SC3. It also works out of config/text files, just like sc3. Nevertheless it is very undocumented and there are no good examples of it, as far as I know... :hmm:

100% agree here. It requires some programming knowledge, but not like C++. Good documentation + tutorials would forge it IMO into one of the greatest tools for general addon-making.

 

[4throck]

From the coments on this thread, the main point seems to be sc3 add-ons are "limited" and "crude" by some standard.

Well, for a simulator the only standard is realism. As far as I can tell, sc3 and multistage generate by the book performance, if you input the correct parameters...

All else is just talk. You cannot judge a tool/method by what it CAN do.
You must consider what it DOES in reality.

SC3 does simple ships with basic systems in an accurate way. And a lot of ships are really like that in reality. Others are not and of course shouldn't even be tried, unless the goal is only partial simulation (let's say simulate only docking)

I feel the comparison with Paint as very negative.
It distracts from the RESULTS and puts the focus on methods.
It mixes the notion of professional tools with amateur FOR FREE work.


As far as I'm concerned, making an add-on is not a programing contest, or a display of knowledge.
It's all about research and creativity. And of course, wanting to share that with others.

 

[PhantomCruiser]

There are plenty of Spacecraft3 "haters" to be found...

But, take a look at Don's Jason, or some of Cizurator's work (the Gorizont spacecraft, or the Caravelle aircraft for instance). Greg Burch really pushed the capabilities of sc3 in some of his add-on's as well. So there's proof that sc3 works wonders when "done right". There are plenty of examples of done wrong too, but, well, what can you do...

Despite some pretty good tutorials available to help me learn to code, I'm very slow at it. And I've got stuff (read... life) going on that doesn't let me dedicate a lot of time to learning it (won't keep me from trying though). I hope sc3 is usable for a long time. I'd look forward to learning to do a craft with lua as well.

 

[Arthur Dent]

I would even go further with the Paint vs Photoshop comparison:

Coding C++ is like paint - you can do everything, but it takes time and skill. Coding in SC3 script is like Photoshop-Light. You can do a lot of things faster, and it if you're inexperienced, you can achieve more, than you would be ever able to do if you code directly in C++. But you are limited in your options.

So an even better toolbox would be needed to make developing for Orbiter faster, more comfortable.


Coding/Scripting in SC3 and Multistage2 is relatively simple and easy (compared to coding C++). In my opinion both tools (SC3 and Multistage) should be unified and expanded and modernised. Not as a "washed down" approach into orbiter coding, but with a few extras. This unified "super.dll"-kit could become the real thing. Programming by scripting would allow less experienced programmers to release higher quality add-ons.

Alternatively, Artlav's fantastic SC3 to DLL converted could be expanded to take more parameters into account, than just the SC3 parameters, so it would compile more advanced add-ons. I can't stress enough, that including multistage2.dll and new parameters would make this the über-tool.

 

[4throck]

Agree. The beauty of scripts is that sc3 / stage. dlls are just interpreters.
The files that compose the add-on itself are readable directly by any other dll. So a replacement or unified version is possible at any time.

This also means of course that our sc3 addons can run outside orbiter if needed, and straight out of the box.
Because the mesh + parameters are in txt format.

 

[Loru]

Few thoughts on topic by c++ ignorant.

I generally don't like spacecraft/multistage add-ons or to be more specific manual creating scenario entry for multistage vessels, name limit for sc3 vessels and some minor other flaws

however

I cannot imagine developing something without multistage, spacecraft3 and velcro. Those are excellent prototyping tools for me. Without coding skills I can test basic concepts, flight characteristics, animations and visual effects (smoke, flames or even guns ). Of course some more advanced features need coder but he has much easier job when all parameters, animations, and other stuff are in 1 file.

So I may not like them as orbiter user but I love them as add-on developer.

 

[Izack]

There are plenty of Spacecraft3 "haters" to be found...

I don't hate it, it's just, well, limited. Attitude thrusters must be placed 1m from the centre and have unrealistic, enormous thrust values for significantly-sized vessels. The thrusters are all guaranteed to be perfectly placed, so there is no ability to make orbital manoeuvres more complex. The vessel must be named exactly what its classname is. Animations require odd keypresses (shift+numpad, etc.) and are finicky, relying on high framerate to properly complete (try closing that door at 10x acceleration. It'll stick part-opened.) No useable cockpit. No custom HUD. No moving thrusters. No changing landing gear. No ability to support other developer tools like Payload Manager or UMMU without more hacks. No features at all beyond the basics. It's excellent for some purposes, yes, but not all. It's all too easy to learn Spacecraft 3, and then never progress any farther.

Oh well, no one was ever convinced of anything over the Internet, anyway.

 

[N_Molson]

For inexperienced programmers, Spacecraft3.dll and multistage2.dll is the only way to make Orbiter vessels.

Don't forget sputnik's Velcro Rockets, that allows to create excellent stuff, with a built-in customizable autopilot. That one has not been used enough, IMHO.

For inexperienced programmers, Spacecraft3.dll and multistage2.dll is the only way to make Orbiter vessels.

I'm not an "SC3 hater", but it worries me that people think it is the only way to make addons. There are actually several options (also count LUA in...). Staying flexible and open-minded to new methods is the good attitude, IMHO again.

(sc3, ms2, velcro) ...Those are excellent prototyping tools

I completely agree with that. I haven't released a lot of stuff (my ongoing projects will come to life one day, be patient), but each time I wanted to test a concept, I first used Velcro as an experimental tool to see "if that rocket could work in theory".

The community and Orbiter should hold the developers in a high regard. Without them Orbiter is a fraction of its potential. And they do this for nothing more than the love of the sim.

Those 3 statements are essential and should be written in marble, to many people forget this.


In general, I find discussions like this one around add-on developping in general very interesting, because developpers tend to work individually, and sharing some general thoughts is invaluable.

 

[4throck]

.. each time I wanted to test a concept, I first used Velcro as an experimental tool to see "if that rocket could work in theory"....

That's how I see it and how it can work.
Script based add-ons are like a wiki (and could in fact be loaded from a wiki...). One can improve and add things up to a point. When "critical mass" is achieved, them someone can take it another step and add specific function through custom code.

I'm involved in such a project with the Brazilian rockets. I have a working version of the VS-40 rocket using multistage and sc3 but of course that way it can only launch straight up and doesn't do a slow roll like it should.
Even with those limitations, I and others got the performance right (payload ascends to the correct altitude at the correct time).

But in reality that rocket launches at an angle and does that roll. This is where custom code starts. Since the rocket was already correct, the custom code only added the launch angle parameter, aerodinamics and some basic telemetry. It was simple and rather quick, but it would never have gone that far without the initial development!


So instead of saying that "VCs don't work in sc3" or "It doens't EVA", the people complaining should take those add-ons and custom code what's missing, if it is really that important! If it isn't that important then all is well! :thumbup:

 

[Face]

Well, if Martin decides to move on with Orbiter in a way that breaks the legacy SC3 code or OVP devs don't care about it anymore AND vinka left the community without looking back or caring about his work ...
then my suggestion would be to write a similar framework from scratch, preferably open sourced this time to make it a living community effort.

IMHO there is not much sense in ranting about why and how a member is not supporting his add-ons anymore. Every contributor is doing it in his free time and is not obliged to support or even care about the work he gave us for free.

Granted, in this case of a framework for easy add-on development it is a kind of dilemma, but if you want to blame anyone at all, then please think twice the next time you hop on a closed-source framework for your valuable work. Because chances are - as you see here - that your work is lost because the provider of the framework just doesn't care anymore, and you have zero chance of easily getting your work to move on.

So, anyone of the SC3 fans up to writing a specification for a replacement framework? And no, "the same as SC3" doesn't cut it, because that would mean all the bugs, all the short-comings... and all the incompatibility, too.

my :2cents:

 

[garyw]

IMHO there is not much sense in ranting about why and how a member is not supporting his add-ons anymore. Every contributer is doing it in his free time and is not obliged to support or even care about the work he gave us for free.

Very well said. If Vinka isn't supporting his addons then there can be many reasons for it. I just hope that vinka isn't suffering from ill health.

What people need to remember is that Vinka, like the vast majority of developers gave the community something wonderful and useful. In fact, it's so useful that we wind up right here with people complaining that he isn't supporting it. In many ways this is a mark of how popular it is.

It's also the wrong approach because other developers may well be discouraged to develop something if the community comes down hard on them when they get bored, decide to do something else or fall ill.

So, anyone of the SC3 fans up to writing a specification for a replace framework? And no, "the same as SC3" doesn't cut it, because that would mean all the bugs, all the short-comings... and all the incompatibility, too.

Now that is a great idea. With all the new features available in orbiter maybe it's time for a new take on SC3. Maybe SC2013 should be in the planning?

 

[Cras]

Well.........

I think Vinka's contribution to the forum to be pretty darn significant. Right up there on that second level behind UMMU and Orbiter Sound.

So I am not gonna go and join in hoping that that guy is suffering from bad health.

 

[Face]

So I am not gonna go and join in hoping that that guy is suffering from bad health.

Nobody here is hoping that Vinka is suffering. Why should somebody do that, anyway?

Edit: Oh, I see... you mean Gary's comment there. Well, while it is maybe not grammatically correct, I'm sure everybody got what he wanted to say.

 

[Aeadar]

Oh well, no one was ever convinced of anything over the Internet, anyway.

I'm not entirely convinced of that.

 

[garyw]

Nobody here is hoping that Vinka is suffering. Why should somebody do that, anyway?

Edit: Oh, I see... you mean Gary's comment there. Well, while it is maybe not grammatically correct, I'm sure everybody got what he wanted to say.

Bad edit on my part. I've now corrected it. Thanks for pointing it out Cras.

To summerise, We've all had things in life drag us away from Orbiter. I have a job, wife and a cat to take care of. The last time I fired up orbiter was a month ago so I can understand why developers will often start something with all the best intentions only to have life side swipe them.

With Vinka's work I hope it's because he has found something more interesting/exciting to occupy his time rather than something like ill health.

 

[4throck]

A solution will appear if needed. No drama. The most immediate option is keep using the Orbiter version that supports what you need :lol: !

I think that we are still discussing about persons, methods and tools, and little about the add-ons themselves.


I propose that on OH the uploaders should be separated from the author(s).
We need the option to be able to indicate multiple authors per add-on. Also, another option to explicitly indicate something like "Orbiter free license", meaning free usage/modification within the "Orbiter ecosystem". This would make development a little more cooperative (as it happens informally on the forums).

Also we could use the Orbiter Wiki a little more. Sure, the information and feedback is here on the forum, but the Wiki is the right place to collect the most useful informations.

 

[Face]

A solution will appear if needed. No drama. The most immediate option is keep using the Orbiter version that supports what you need :lol: !

I disagree. The solution will certainly not appear out of nowhere if needed. Somebody has to do the work. And if nobody does the work, a kind of drama will emerge for sure ("why, oh, why, does Orbiter 2014 not support my SC3 add-on!", "Vinka left without a trace, help!", etc.) - similar to this thread, but a bit more drastic due to immediate consequences looming ahead. While your solution of simply using the appropriate Orbiter version is certainly valid, it will not satisfy the masses IMHO.

This is why I suggested creating a replacement framework.

I propose that on OH the uploaders should be separated from the author(s).
We need the option to be able to indicate multiple authors per add-on. Also, another option to explicitly indicate something like "Orbiter free license", meaning free usage/modification within the "Orbiter ecosystem". This would make development a little more cooperative (as it happens informally on the forums).

Also we could use the Orbiter Wiki a little more. Sure, the information and feedback is here on the forum, but the Wiki is the right place to collect the most useful informations.

Good ideas. Is there an immediate connection to the topic at hand, though? Do you mean this is necessary to better deal with SC3 add-ons? Or is it just a general comment on making the "Orbiter ecosystem" (nice term, BTW :lol: ) better?