Next orbiter release???

[BruceJohnJennerLawso]

Why a final solution for it? Are you overburdened having the choice?

You can choose what you want, and if you don't like Velcro or Multistage, you are free to make your own. Who says that there can be only two?

Though I must say, it is hard finding something simpler than Velcro.

Me? :leaving:

Its a fair bit out of my depth as a developer right now, but I would be happy to contribute to it. My point is that in an ideal world, an intermediate user should be able to create & fly any rocket (say a Saturn V) if they have the meshes for each stage, and data on the rockets performance (stage weight, thrust, propellant, isp, exhaust type & location... not an extremely difficult task.). Multistage2 suffers from the problems listed above, but the issue with Velcro rockets has been that end users cant see it visually, and for some reason few developers have used it. I just think its important for orbiter to have a connection to whats really happening in space exploration, as well as just learning orbital mechanics on the DG training wheels :lol:.

Side note: the Orbiterwiki page on Mayfly.dll should list you as its author correct?

 

[Loru]

I know some would consider this to be a job for the addon devs, but I personally think that the next orbiter release should have a final multistage vehicle solution. For orbiter to really progress as a tool to understand modern spaceflight, we need to make launching a Saturn V, SLS, Soyuz, Falcon Heavy, one of the first things a new user tries after flying the DG for the first time, but for any of these things, you need either:

Multistage
+very common, popular lots of choice
+simple to use
-buggy, boosters dissapear without certain patches, payloads never have any fuel, & cant have a UMMU crew unless hardcoded in the DLL
-Unless Im mistaken, Multistage3 is never coming. If a new orbiter release is incompatible with Multistage2, were going to have a lot of quality addons become useless

or

Velcro Rockets
+very flexible, hard to imagine anything you cant do with it
+usually seems very stable
-very difficult to use. Unless someone does eventually create that visual interface for building them, velcro rockets arent very easy to adjust or create

What we really need is a Dlled vessel class that can be built through the scenario editor or some other program to create a config file which loads the desired launch vehicle, can add payloads in the scenario editor, and can have its guidance set by the user while on the pad (more or less this http://www.orbithangar.com/searchid.php?ID=5442)
in a general format. I dont think it will be easy to create this, but either through martins or the addon devs, were going to need some sort of better solution for mutistage vehicles.

Default Atlantis is multistage vehicle.

And with all due respect: Orbiter isn't "click and go" game for 1 afternoon. It is simulatior. There were many attempts to achieve multistage by means of cfg or ini files. However:

1.) Is Deltaglider configurable via cfg file? All those complex systems had to be hardcoded. Same with multistage vessels. COG shifting, proper separation sequences, etc etc.

2.) If you have multistage properly installed and add-on is properly developed there is no disapearing meshes, or similar issues. Any payload may be attached via universal carego deck and it retains its full functionality (UMMU, oxygen etc).

3.) If such add-on exists then may be more in future. Feel free to request one. If someone can create it then excellent.

4.) It is up to Martin what he plans to include in next orbiter as well as the date he releases it. Remember that it is his hobby NOT A JOB. Same with add-on devs. Most of add-ons were made for a pleasure/satisfaction of their respective authors. They do us a big favour to share their creations with community. And they're not getting money from it.

I know it may sound harsh but if you're not satisfied with current Orbiter state go and write your own space simulator.

 

[Mr Martian]

Martin should stop giving the Orbiter versions names by the release year... Its too easy to increment.

I suggest giving Orbiter versions female first names, so that not only natural disasters are named after women.

so true!!! i never thought about it, but most disasters are named after chicks! like cyclone tracy and catrina!!! i never thought about it really but its true!! :thumbup: funny how people notice things that u never thought about before.

---------- Post added at 12:14 AM ---------- Previous post was at 12:12 AM ----------

My attitude is, Rome wasn't built on a day, and certainly not on 640K. I'm happy with whatever is out there.

nice thinking

 

[orbitingpluto]

I think BruceJohnJennerLawso is somewhere near the right path, but isn't there yet. Part of the problem with Multistage and Velcro is that it is rocket science at heart. One needs to have to have some idea of the math behind it to figure it out. For people who have problems figuring out the maths of a rocket, dealing with the coding of Multistage and Velcro is like another barrier to entry. After tinkering for a while and learning the hard way about vectors and normalization on this very forum(from the ShuttleFleet's Dave and Donamy) I know how getting ones feet wet is quite a hurdle, because it isn't the type thinking I'm used to.

The problem is that there isn't a good reference guide to what things like "normalizing the vectors" means. Maybe someone should make something like that on the OrbiterWiki. Hint Hint.

 

[Cras]

Velcro rockets is a beautiful add on. A wonderful tool for making things in Orbiter. Multistage, I am not nearly as fond of, though I do appreciate the possibilities it creates.

 

[N_Molson]

I share Cras point of view. Mainly because multistage is getting old, IMHO. "Multistage3" and "Spacecraft4" would be a good thing (even under a different name ). So currently Velcro beats it. But I also like the idea that all the stages and vessels "exist" from the launch as separate entities. It adds a lot of flexibility.

My concern about Orbiter is the compatibility of the DX7 inline client with the newest OS/hardware. While graphic clients like D3D9 are excellent, it is a problem when you want to run Orbiter through a compiler in debug mode.

 

[Urwumpe]

Side note: the Orbiterwiki page on Mayfly.dll should list you as its author correct?

If it is the same tiny hack that I created some felt centuries ago, yes.

 

[jedidia]

Oh, it's time for these threads again :lol:

I suggest giving Orbiter versions female first names

I actually like the idea!

i never thought about it, but most disasters are named after chicks! like cyclone tracy and catrina!!!

Hell hath no fury as a woman scorned!

 

[BruceJohnJennerLawso]

I think BruceJohnJennerLawso is somewhere near the right path, but isn't there yet. Part of the problem with Multistage and Velcro is that it is rocket science at heart. One needs to have to have some idea of the math behind it to figure it out. For people who have problems figuring out the maths of a rocket, dealing with the coding of Multistage and Velcro is like another barrier to entry. After tinkering for a while and learning the hard way about vectors and normalization on this very forum(from the ShuttleFleet's Dave and Donamy) I know how getting ones feet wet is quite a hurdle, because it isn't the type thinking I'm used to.

The problem is that there isn't a good reference guide to what things like "normalizing the vectors" means. Maybe someone should make something like that on the OrbiterWiki. Hint Hint.

Thanks. Just to be clear Im not looking to bash Martins for what he does/doesnt develop, Id just say that a proper multistage solution would be nice to have distributed across the board just like TransX is. Maybe it can be done as a project in a year or 2 but, I think it would be best to drop the topic for now.:tiphat:

 

[Urwumpe]

FYI... I don't use TransX, I prefer InterplanetaryMFD.

 

[asmi]

The problem with "want a feature in Orbiter - write an addon" attitude is that there are certain features that are impossible to implement anywhere without support inside the Core. And as graphics client developer, I'm facing this problem almost on a daily basis, that's why current development progress much slower than it was half-year ago - we simply run out of things that can be implemented without nasty hacks/workarounds that tries to circumvent/amend some of Orbiter's core systems. 3D terrain is a perfect example - Glider and myself had invested countless hours trying to come up with collision detection/response implementation that would be stable at high time acceleration, and we both had failed. Now it turned out that it's impossible per se even for the flat surface without some case-specific things inside Orbiter's core (take a look at latest beta and Martin's explanations regarding collision meshes), so to me it sounds like a principal design flaw that can not be easily fixed.
To be fair to Martin it's not his fault that we want much more out of today's Orbiter that he ever thought of back in the day - it's actually the other way around - because Orbiter is such powerful, flexible and successful we've got hopes and aspirations for more. Every system however flexible it is has limits of its' flexibility, and we've reached them now.
I'm actually more and more often thinking of developing similar project that would be similar to Orbiter, but with these shortcomings fixed, but there will always be "something else" that author didn't think of...

 

[orb]

Just a random comment about "next orbiter release": 2 new public beta versions were released just recently.

 

[asmi]

Just a random comment about "next orbiter release": 2 new public beta versions were released just recently.

There is 121023 that doesn't seem to be stable enough yet (judging by comments in the topic), and what's the second one?

 

[orb]

what's the second one?

121021

A link to it was removed, but the file is still available on the server.

 

[asmi]

121021

A link to it was removed, but the file is still available on the server.

I see. Well - such quick re-release likely means that there was something VERY wrong with a first one

 

[orb]

Rather quick fixes of some bugs Martin found by himself, before people stared reporting other bugs.

Otherwise it worked just like 121023.

 

[asmi]

Rather quick fixes of some bugs Martin found by himself, before people stared reporting other bugs.

I see - well that happens to me all the time - a second _after_ you release something, you find some issues there before anyone even have a chance to look at that yet

 

[BruceJohnJennerLawso]

The problem with "want a feature in Orbiter - write an addon" attitude is that there are certain features that are impossible to implement anywhere without support inside the Core. And as graphics client developer, I'm facing this problem almost on a daily basis, that's why current development progress much slower than it was half-year ago - we simply run out of things that can be implemented without nasty hacks/workarounds that tries to circumvent/amend some of Orbiter's core systems. 3D terrain is a perfect example - Glider and myself had invested countless hours trying to come up with collision detection/response implementation that would be stable at high time acceleration, and we both had failed. Now it turned out that it's impossible per se even for the flat surface without some case-specific things inside Orbiter's core (take a look at latest beta and Martin's explanations regarding collision meshes), so to me it sounds like a principal design flaw that can not be easily fixed.
To be fair to Martin it's not his fault that we want much more out of today's Orbiter that he ever thought of back in the day - it's actually the other way around - because Orbiter is such powerful, flexible and successful we've got hopes and aspirations for more. Every system however flexible it is has limits of its' flexibility, and we've reached them now.
I'm actually more and more often thinking of developing similar project that would be similar to Orbiter, but with these shortcomings fixed, but there will always be "something else" that author didn't think of...

If I might be so bold as to comment on the collsion detection debate:

I do agree with those who want their 3d terrain, and I personally would rather see that than the collision meshes and upside down landing, but part of the problem could be the complexity of the solutions that people want. If we can just have vessels landed on Orulex terrain or similar terrain, just staying at the appropriate elevation (no tilting, no upside down, no crashes sideways into terrain), and that could be stable enough to save & load from SCN files, I think that would be good enough. Its basically all that UMMU/UCGO collisions does, and its all I think we really need.

I mean, stop and think about why people want collisions and terrain: They want to fly to a planet/asteroid, land on it at a realistic height, then run around up and down the terrain in UMMUs, and Rovers. If Martins can create a function returned by ng_exe whenever a graphics client requests it, setting a vessels state as landed when the terrain elevation is reached, that lander doesnt need to go anywhere!. So, all we really need is a new vessel class for wheeled rovers, and proper support for UMMUs to travel on the terrain. If we limit collision detection to only what we need, I think we can have it working in the next beta. If not it may be years or never.

 

[asmi]

If I might be so bold as to comment on the collsion detection debate:

I do agree with those who want their 3d terrain, and I personally would rather see that than the collision meshes and upside down landing, but part of the problem could be the complexity of the solutions that people want. If we can just have vessels landed on Orulex terrain or similar terrain, just staying at the appropriate elevation (no tilting, no upside down, no crashes sideways into terrain), and that could be stable enough to save & load from SCN files, I think that would be good enough. Its basically all that UMMU/UCGO collisions does, and its all I think we really need.

I mean, stop and think about why people want collisions and terrain: They want to fly to a planet/asteroid, land on it at a realistic height, then run around up and down the terrain in UMMUs, and Rovers. If Martins can create a function returned by ng_exe whenever a graphics client requests it, setting a vessels state as landed when the terrain elevation is reached, that lander doesnt need to go anywhere!. So, all we really need is a new vessel class for wheeled rovers, and proper support for UMMUs to travel on the terrain. If we limit collision detection to only what we need, I think we can have it working in the next beta. If not it may be years or never.

I hope Martin would never settle for that - remember Orbiter is a simulator, not an arcade game. And simulator has to respect laws of physics. So if vessel needs to be tilted when it's stopped in uneven terrain - that's the way it should be!
There is a thing that you don't seem to understand - collision detection/response is NOT complicated at all - in fact there is even hardware-accelerated implementation (PhysX), and NVIDIA gives it (plus software-based fallback in case there are non-NVIDIA video card(s) in the system) for free - all you need to get your hands on it is simple registration form with less than 10 fields in it ( http://developer.nvidia.com/ ). So the biggest problem with adding it to Orbiter is not an implementation itself, but compatibility with existing addons.
Current problems are not just impossibility to "suspend" vessel at terrain - for example it's impossible to fly at altitudes below average planetary radius which is considered to be "sea-level" now - think about what word "average" means.
Overall I've invested a lot of my time in studying this problem, and I think I understand the domain quite well, but in this topic it is an off-topic. If you want to know more - create a separate thread and let's discuss that in details.