Standards

[Zatnikitelman]

First rule of asking for help. Be specific which addon it is; AKA: please link to "Nikita's Soyuz" and Mustard's Launchers (though I know where the latter is).
Though I am in agreement with the other forum members in this topic, I'm curious what your exact problem is.

 

[reinaldojr]

Well, David, i very sorry i sounded like that, but thats not what i meant. Don't you think i want somebody to show up and say "hey stupid, here's a fix to your problem"? But everything i heard so far involves getting a bigger bucket to take more water from the sinking ship. What i was about to propose is not anything like it. Is to fix the problem once and for all. And donamy, who the hell am i to tell someone how to make their addons? In which point i sounded like that?

The problem is, everybody is familiarized with Orbiter the way it is, with 8 different orbiter instalations and everything else that the idea of change is completely out of question.

I'm not, i repeat, i'm not, listening only to my own voice. The thing is, I just won't settle down, until a problem its solved. And getting a bigger bucket isnt a solution. I want to fix the hole.

But as you beautifully said, you are entitled to do whatever you want. I can't argue with that.

I just feel very sorry that i can't express myself the way i wanted and create all this situation.

 

[Donamy]

The usual way to get a "problem" fixed is by either persuading the addon maker him/her self to change it (which is not uncommon), or become familiar with making Orbiter addons yourself (which is most common).

 

[Andy44]

David413 is right. Different installs in different folders.

If you are upset because two addons don't play nice with each other, you need to understand that making addons is something developers do for their own enjoyment, and posting them online for others to download is not a requirement, so you get what you get. It's all free.

The best you can do is ask nice, and some developers might make changes to help you out, if they want to take the time. If you want to launch a Soyuz on a particular rocket, there may be ways to help you.

Or you can learn to make your own addons, which is a lot of work but it's very fulfilling. In my case, the only way to get what I wanted was to do it myself.

Orbiter is free, both money-wise and in the sense of freedom to do as you please. Developers share their craftwork with other users for free as well, and in such an environment enacting a new set of rules is almost impossible and enforcing it even more so.

Listen to what David413 and others say, and enjoy the world of Orbiter, bask in its glory, and welcome to the community!

 

[reinaldojr]

Andy, what do i have to learn to make or modify addons?

 

[Andy44]

Andy, what do i have to learn to make or modify addons?

Somewhere around here is a thread or two for addon newbies, I don't see it stickied but I didn't do a thorough search.

Addon development is a very steep learning curve, so I would suggest starting with something simple and getting more complex as you feel comfortable. I have been doing it for a couple of years and I am still a rank amateur at it, while others jump in and built something amazing within months of finding Orbiter.

If you want to modify someone else's add-on, remember it's not for redistribution without the creator's permission, of course. And modifying a particular add-on can be easy or difficult depending on how it was made.

If it has a custom DLL, you're probably out of luck. But if it uses the generic Spacecraft3.dll, it's a lot easier.

But baby steps...

 

[reinaldojr]

Well, thankyou very much Andy, i'll try to find these threads. That was not my original idea, but as you said, "the only way to get what I wanted was to do it myself".

Thankyou very much again.

 

[tblaxland]

who the hell am i to tell someone how to make their addons?

You could develop and publish a detailed specification of how you think other developers should make their addons (packaging, interfaces, etc) - there is nothing wrong with that. I believe the point Donamy was trying to make was that complying with such a specification would require significant effort on the part of other developers. Since this is a purely volunteer and hobby community, you cannot rightfully expect people to comply with it.

To produce such a document (including some programming libraries, I guess) would require significant knowledge of addon making, so start simple first. See the section titled "Tutorials for Addon Developers" on this page: http://www.orbiter-forum.com/tutorials.php

BTW, in addition to COI that I mentioned earlier, CVEL is another attempt at solving a different subset of the problems you have mentioned.

 

[Andy44]

You could develop and publish a detailed specification of how you think other developers should make their addons (packaging, interfaces, etc) - there is nothing wrong with that.

That's an interesting idea. The Model Railroading Association formed decades ago and adopted a set of standards which, of course, are voluntary for model railroads, but which most hobbyists try to conform to. Manufacturers sometimes do and sometimes don't, as it's all voluntary, but those that do can generally claim better quality.

To do this in Orbiter you would form a "club" of developers who agree to try to abide by a set of standards, which would be published for others to follow or not as they please.

I would probably not...but anyone's free to do what they'd like. CVEL is a good example. In fact I would follow that if I knew what I was doing.

 

[Tommy]

When i downloaded Kukanotas' KSC i was completely impressed by it. For the good and for the bad. The good part was that before, KSC was a sad place with blurred shapes and strange edges, but after, it became completely realistic with rivers, ponds, grass, roads and everything else. The bad part was when i loaded a basic scenario like, Shuttle Satelite Launch, the ship was completely out of place. Not only this, but every single scenario that had a ship landed in KSC was out of place.

Actually, that's not Kukanotas' fault. The stock Cape Canaveral is incorrectly located. Hi-Rez surface tiles based on satelite imagages have to "move" everything into it's geographically correct location for it to match the tiles. Pretty much every Hi-Rez Canaveral and Florida tileset has this issue.

I believe the locations for the stock Canaveral are corrected in the beta.

 

[sunshine135]

I don't know. Out of this entire thread I think a utility to check for updated versions of the add-ons might be cool, but it would also need to update your scenario files. That might be a pretty neat little project.

True enough though, Orbiter is not a single structured program. Some people may use it for its basic functionality to teach, others may want to simulate specific historical missions (Apollo, Gemini, Shuttle Fleet, Shuttle Ultra). Still others want future ships or future scenery. Also, an important point- no simulator is free of conflicts. I've used FS2004 and had to be very careful with some conflicting scenery especially.

And if you really want something to gripe about, I highly recommend complaining about why we don't have a version of Orbiter that will run on Linux!!!

That was meant for levity...It is getting too angry in here

Peace to all,

 

[n72.75]

Rather then trying to force an unreasonable list of standards on addon deveolpers(which will never happen), we could draft a book of standards and any addon that complied with these standards would receve an endorcement.

Not all, or even most, addons would have to follow the standards.
However, it would create a groop of addons that would be guarenteed to preform on a certian way.

Do you see where i'm going here? it would make, use of addons easer for the casual user, while the advanced user would still have the freedom to, both use and create addons that don't conform to the standards(in my oppinion the better ones).

just a thought, of course someone would have to wright the document od standards...

 

[reinaldojr]

well, as I see some of the people are already getting the idea. I tried last night to express myself in the best of the ways but i feel i sounded completely stupid sometimes and i regret that. there's nothing for me to win picking fights with people here, when my original idea was to unite rather than divide.

I agree completely with Andy, Sunshine and N72. The idea behind the standards is not to force a new rule, but to create different option that an user can choose how complicated he wants to experience orbiter.

Today we have an ordely caothic system that works 90% of the time, but on the other side, those 10% left will never work, no matter how hard you try, unless you build from ground it yourself.

The addon system today depends on the exclusive view of thousands of addon makers and most of the time, they do their job is done magnificent. Specially when you know that this is a hobby and their do it for free. As I said before, i bow to you people.

But in my view, i think after a while, these 90% working solutions will start to drop, cause the addons are becomig more and more advanced and becoming themselves so self contained that more and more orbiter installation will be needed to avoid conflicts, each one for an independent addon.

My proposal of a solution is based on a Shuttle Fleet Scenario Generator i found some time ago. It simply created scenarios for the shuttle fleet using the ships, the cargo and everything else as modules that could be moved and added and rearrange the way the user liked. It created customized scenarios that worked perfectly without the user having to mess with a single programing file in the scenario file.

continues...

---------- Post added at 01:41 PM ---------- Previous post was at 01:30 PM ----------

My idea is to create a Main Scenario Generator. And use everything inside Orbiter as modules to create specific scenarios that works with everything installed inside.

It would work in a tree like options chooser, with the basic and large scaled stuff in the beguinning and endind with the more advanced customized stuff.

For example: the first screen would ask the size of the playable "universe". LEO, Earth and Moon, Inner planets, Outer Planets, Asteroids, and etc. This options would be used by the program, to choose an stardard Sol System and add to the beguining of this temporary scneario file.

After that, the user could choose what ship or ships they would want in that scenario. Where would they be and etc. More or less like the Scenario Editor that comes with Orbiter works today.

This is the basic idea. All textures, surface bases and everything would work like modules that a user can turn on or off. But since they would work over a standard installation, you could roll back anytime you want cause the changes would work only for that specific scenario you created.

continues...

---------- Post added at 01:48 PM ---------- Previous post was at 01:41 PM ----------

For that to work, unfortunatelly, would have to count with the help from the addon developers. The idea is to modularize the addon, pack it to be installed as a separated folder inside for exemple, a Ships folder and everything related to the addon would be gathered inside that folder. All the textures, all meshes, all cfgs, all its modules, dlls, and etc. This would avoid overwrites and make it easier to uninstall such addon.

So for example, if a user wants to create an scenario with the earth and the moon, everything hi-res, and play with a sigle DGIV in a space trip to that Luna space station. The main generator would invoke only the files and the textures needed for that scenario.

More option could be added with the development of a more advanced generator. Soundpacks, Terraformed planets, different solar systems, different textures for the same ship.

continues....

---------- Post added at 01:54 PM ---------- Previous post was at 01:48 PM ----------

The standards would be based around somethings that we already have, such as Orbiter Sound, Shuttle Fleet, high resolution planets and etc. This would come bundled with orbiter, since 99% of the people download and installs those things even before opening their first simulation.

The standard plataform would grow, and with these addon serving as standards more things could be added based on them, upgrading, offering new options, but never overwriting permanently.

continues...

---------- Post added at 02:02 PM ---------- Previous post was at 01:54 PM ----------

Other addons would elect themselves to become standards also. This would be voted here, by the people who uses them everyday and know if they conflict or not and how independent they are. They would come bundled with the next version of orbiter which would be delivered every 6 months, exactly as the Ubuntu Linux Distribution does.

Every new version would come with revised and upgraded standards, which would serve as a solid base for developing new stuff.

So in the end, Orbiter would become a single installation program, with everything you need inside it, but nothing else conflicting with one another, exactly the same way the base orbiter instalation pack works.

---------- Post added at 02:04 PM ---------- Previous post was at 02:02 PM ----------

I don't even know if its possible to do, but i just wanted to share the idea, for the more enlightened people in the ways of addon making to discuss it.

 

[computerex]

So you want me to settle down knowing i can never, ever, ride Nikita's Soyuz atop Mustard's Soyuz Series launcher on that funny little train that comes with it because that's the way life is? Keep watching.

Actually I am 90% sure you can. You will find that for Orbiter many of the things you require are already present, and many can be made in a short period of time. For instance, this add-on allows you to easily attach payloads to any vessel: http://orbithangar.com/searchid.php?ID=3262

What you have to understand is that not everyone shares the same beliefs. For instance, while the AMSO add-on and the NASSP add-on both aim to provide a realistic simulation of the Apollo missions, AMSO focuses on making the missions realistic and simple whereas NASSP aims to provide the most realistic simulation.

This is one of the key things that I like about Orbiter. You are not limited to one solution. It's always nice to have alternatives in my opinion. Imagine if there was only one computer program present to do something.

 

[Face]

Well, since COI was mentioned here:

I really believe that every system "above" Orbiter will fail if it depends on the community to agree to a certain packaging or developing standard.

Almost naturally everyone gets the best solution to deal with Orbiter's many addon diversities: multiple installations.
Multiple installations is what got me thinking about developing COI... just a system to "overlay" all those multiple installations together in a single directory. And a way to choose one of them as the active one. A version control system is the best tool for this IMHO.

Especially when it comes to deploying an addon to the users, having a way to ship the development environment to the user is the key part in making robust "installation". In the end the user wants nothing else but the content of the directory the developer had while creating and testing the addon. At least for trying it out, that is, merging and compiling a selection of addons into one "running" Orbiter installation will always be work to be done (solving conflicts).

Regarding vessel interaction standards... Besides Dan's OS and UMMU I am not aware of a standard (for Orbiter addons) worth its name to date.

regards,
Face

 

[4throck]

Just my opinion, what could help would be to keep an updated list of incompatible / specific addons and possible fixes, and release the fixes on OH. A single addon developer doesn't have to time to fix compatibility with this or that specific addon so the community must help.
Some of the integration problems might be solved by having generic spacecraft3 versions of spacecraft instead of custom .dll . Why not make them? It's only a matter of creating text files in notepad.

Don't forget that Orbiter grows because it has a community willing to share it's creations with others. Take active part in solving the problems you find and share the solution. That's the way to progress.

 

[Hielor]

Some of the integration problems might be solved by having generic spacecraft3 versions of spacecraft instead of custom .dll . Why not make them? It's only a matter of creating text files in notepad.

Because for those of us capable of making custom .dlls, we don't want our ships to be constrained by the severe limitations of spacecraft3?

 

[Urwumpe]

Because for those of us capable of making custom .dlls, we don't want our ships to be constrained by the severe limitations of spacecraft3?

When spacecraft3 can do all things I can do in C++ and be less verbose as it is today (currently it is more the COBOL of add-on making), I would have no problems using it.

But I think before that happens, somebody will have written a good C++ or C# framework for making advanced vessels...

 

[David413]

(currently it is more the COBOL of add-on making)

OMG, "COBOL"...besides being a "blast from the past" for me, this may well be the single best post ever in these forums! Thanks for making my day, and in fact my entire (holiday) weekend! :rofl:

 

[Ark]

I agree with the fact that addon conflicts are a huge annoyance in Orbiter. However, I don't think the solution lies in actually messing with how Orbiter works, but in getting addon developers to stop bulldozing everyone else. Users shouldn't be made to sacrifice addons in favor of others, it's not that hard to avoid incompatibilities with other popular addons. Make sure your ship configs have unique names that won't overwrite anything, and include decent instructions on how to modify files instead of replacing them. It's not difficult.