What you want to see in the Next release of Orbiter

[Genius]

My only request is: Atmospheric Condition Effects on flying craft.

Good to see I am not the only South African around here.
What do you mean by Atmospheric Condition Effects?
Orbiter already have that. Just try to do a re entry with the DGIV, or the new XR2.

 

[Kaito]

Oooo, heres one:
Automatically update current ISS and Planet movement, and I think I have an idea on how to do it:
On a most basic level, the movement of ISS, the moon, the earth, and any mass, in a vacuum, can be defined by a mathematical equation. My idea is to find this equation, then cross reference it with the current time and date, using a "reference date" (I.E: The next orbiter release). This way, people who wanted to actually wait for the right launch window would have an opportunity to do so.

And, what more, this wouldn't effect scenarios like "Lunar Transfer", because the moon's position and plane is already defined.

Sound like a good idea?

 

[ar81]

How about support for a generic cockpit module in a vessel CFG?
How about limited visibility, useful in places like Venus.

 

[Kaito]

Couple of coding ideas:
-Maybe, when i switch vessels, the MFD's dont switch along with it (I'm in the DGIV, and i switch to ISS, which only has Glass cockpit mode. When i switch back to the DGIV, my MFD's all changed to what ISS's was...incluidng Glass Cockpit)
-When I switch vessels, have autopilots, etc, keep running (i was trying to watch a DGIV autopilot ascent from a vessel on the ground, and when i would switch, the autopilot would "turn off")
-Generic Minimizer? So I dont have to do Alt+tab? (this could be a simple add-on tho)

 

[yagni01]

Multiple joystick support, incl. brakes, nose wheel steering, rudder, engines other than main, user thruster groups, etc.
Independent rotation/linear RCS (to use with multiple joysticks)
Allow multiple windowed external views

I'm hoping the new graphics engine will do the last.

 

[Kaito]

Multiple joystick support, incl. brakes, nose wheel steering, rudder, engines other than main, user thruster groups, etc.
Independent rotation/linear RCS (to use with multiple joysticks)
Allow multiple windowed external views

I'm hoping the new graphics engine will do the last.

Nose Wheel: Elevon in the DGIV
Rudder: Atmospheric mode, twist your joystick, or use 1 and 3 on the numpad
Engines other then main: RCS Translate, and hover engines
User Thruster Groups: not sure what that means, but by your general trend, i'm assuming it means controlling one engine seperately then the other. That can be done, just use panel view.

 

[zerofay32]

Multiple joystick support, incl. brakes, nose wheel steering, rudder, engines other than main, user thruster groups, etc.
Independent rotation/linear RCS (to use with multiple joysticks)
.

All of this is possible with Fly By Wire.
[ame="http://www.orbithangar.com/searchid.php?ID=3223"]Fly-By-Wire 0.9 beta[/ame]

Zerofay32

 

[hypersonic]

I'd like to see 2 things.
1) Interstellar travel, by positioning all the stars in a 50 ly radius. So that experimentation with such can be acheived.

2) The modularisation of install packages, sceneries & ships, so that the install / uninstall of any addon, becomes self contained & does NOT interfere or break any previous addon or setup. So a little bit like how Flight Sim handles such things. - with even the ability to 'change' ship during the sim. Thus separating the object, & what the object is doing (orbital elements etc).

 

[yagni01]

Nose Wheel: Elevon in the DGIV
Rudder: Atmospheric mode, twist your joystick, or use 1 and 3 on the numpad
Engines other then main: RCS Translate, and hover engines
User Thruster Groups: not sure what that means, but by your general trend, i'm assuming it means controlling one engine seperately then the other. That can be done, just use panel view.

I think you misunderstood. Its the ability to do all that through additional joystick axes, as in rudder pedals, throttle quadrants, a separate joystick for RCS translation, etc. The user thruster group could be used to get the individual thrusters (i.e. left and right main engines) to control them separately, but primarily it is to allow access to SCRAMs on DG-S, DG-IV and XR-series vessels and pods on Shuttle-A, which are not directly supported by the API.


-----Posted Added-----

All of this is possible with Fly By Wire.
http://www.orbithangar.com/searchid.php?ID=3223

Zerofay32

Yes, much of this is possible with FBW (which I use), but there are limitations - mainly that RCS and flight controls are turned off in the Orbiter core in order for it not to override what the "foreign" joystick is trying to do. This affects panel controls, voice callouts, and other system constraints vessels have (i.e. APU must be running). At the same time, it prevents FBW from acting on, say, RCS inputs only when the RCS control is "on". Catch-22. If the core allowed a plugin to do such things without turning systems off, it wouldn't have to implement the whole thing.

 

[ar81]

I would like to see remote detaching.
For example, if you are onboard BSP and you want to detach the launcher, you might not want to switch vessels to detach.

Also, flight paths for detached vessels. You might like BSP launcher to return home.

 

[tl8]

I would like to see remote detaching.
For example, if you are onboard BSP and you want to detach the launcher, you might not want to switch vessels to detach.

Also, flight paths for detached vessels. You might like BSP launcher to return home.

No.1 Done! Release MFD
No.2 Can this be done with Lua Scripts? I am not sure.
Although If someone could make a basic autopilot that could read input off of a text file, that would be great!

 

[Kaito]

"Progressive saving":
What I like is how i always have a Current State scenario. What I would like is when I go like f4, i would like a save option, that would save a SEPARATE copy of that else ware.

 

[willy88]

I'd like to see full-blown weather. I'd really like to take off in an XR2 when it's dark and rainy, for some reason.

 

[tonykattvc]

I'd like to see 2 things.
1) Interstellar travel, by positioning all the stars in a 50 ly radius. So that experimentation with such can be acheived.

I belive an addon has been made to do this, i think it's called Multi Solar System Module, or something like that. The basic idea with it is when you point yourself at a star, when you get within a certain distance of it you automatically go to it. The way it works is when you get close to the star, the module creates a scenario, the dll then updates the scenario, like Orbiter upadates the Current State Scenario, and changes the Sol System that the scenario uses to the name of the star. Heres a link: [ame="http://www.orbithangar.com/searchid.php?ID=1078"]Msss MFD v4.0[/ame].

 

[RisingFury]

"Progressive saving":
What I like is how i always have a Current State scenario. What I would like is when I go like f4, i would like a save option, that would save a SEPARATE copy of that else ware.

Quick save button in F4 menu will save into the Quick save folder.
If you want a separate copy somewhere else you can exit your simulation and save it through the menu.

And if you don't wanna keep reloading the simulation all the time just rename your last quick save into the file you want and put it where you want it



I think OrbiterScript should be able to handle basic flight paths. I've seen it control Atlantis and launch it into a nice orbit. It can manipulate pitch, bank and thrust. It jettisons the external tank even though it's not empty and this would imply that you can do just about every action that has a key.

If you can obtain vessel's location through the script, you can use some simple vector math to get it to fly to a certain point that is in line with the runway and tell it to get it's orientation a certain way. That way you can align it with the runway and make it land.

This would allow the player to fly anywhere (well, within the fuel level) and the ship would still return back and land.

 

[penlu]

I've seen these two mentioned already, but just for emphasis...

COLLISION DETECTION
MULTIPLAYER

But the problem with multiplayer is... What about time acceleration!?

Anyhow, it would be great if you could be you. Like, a mesh called YOU would move around on a planet's surface (with a space suit, of course) or-especially this- be able to float through a craft, through the docking tunnel, and into a seat on the other craft. Just backing into the seat would sit you down in it. Check out ROBLOX (roblox.com) and you'll see what I mean. You get a player who walks around, and if you can script Lua you can create vehicles that you sit in to operate. There ARE seat objects that you touch to sit in. It's pretty interesting. Apply the concept to Orbiter... cool.

 

[chriswillb]

Well, the thing about orbiter is that the actual interface is a simulator so if that factor is kept and the "real" scenarios are then martin should feel free to do whatever he wants to orbiter to make it better with the support from the community. Oh and also he should build in sound and mars and moon realistic missons with better L. textures.

 

[garyw]

Textures are huge. Better off keeping them as separate download for those with the bandwidth.

 

[Stinger]

collision detection

I know this was discussed on page 2 of this tread already...

I may add, that I think it's not necessary to implement collision detection at high relative speeds. -Shooting down Satellites I rather leave to certain countries who consider it necessary to prove their power that way...

How often do you hit Vessels in Orbiter at high relative speeds? -Almost never I would say. Usually I launch to orbit to dock with ISS or any oher vessel, not to shoot it down. -Orbiter isn't a Space-Shooter but a Sim, right?

From my point of view collision detection would be nice for docking and for landings in mountainous regions (I'm from Austria ) or on buildings.
i.e. relative speeds below -say- ~300m/s

If you encounter ISS flying a east-west orbit, the flyby would happen so fast (~16km/s) that you couldn't recognize (visually) if it was a hit or a near miss... -So it wasn't important for the simulation to recognize a collision or not.
If you hit Mt. Everest at 8km/s and orbiter doesn't detect a collision with the mesh, you hit the 'real' sphere only one second later. -I could live with that. :thumbup:

 

[garyw]

So many years with 2006 alot of changes will be have to be made with some add-ons and on the other hand some improvements now could be made with some add-ons when it comes to the physics for example.
And for the record if there is one im with TS Penguin and TL8 no changes like that will needed to be made.

And the more changes that are made the more chances of unintended side effects, bugs and other problems.

Orbiter should do what it does best, focus on the the physics. Everything else (including collision detection) is best done by add ons.

Finally, the next version is at RC (Release Candidate) so it's a bit late for major changes.