Orbiter 2016

[martins]

In my opinion, the only thing that 2016 has got wrong is not to flatten terrain along runways.
Of course, Orbiter only comes with a few bases and those are usable.
But the concept of rollercoaster runways following the terrain is odd. It should be the other way around.

Do we need an SVN repository for Elev_mod tiles? Any budding landscape architect could register as a contributor, and if they feel aggravated by the bump in the middle of their runway they could flatten it and submit it to the repository so that everybody else would also get the benefit. In the end I just scoop up all the contributions and bundle them in the next texture update.

 

[turtle91]

Anyone notice that your Delta Glider's fuel mass will not decrease and remain constant when you play with DG-S in the scenario "DG-S waiting for take-off on the runway" that comes with the default Orbiter 2016 folder under the Delta Glider folder heading?

Could it be a 2D-glass-cockpit only issue ?
So the (2D) fuel-display shows the contents of both, the SCRAM and the RCS/MAIN tank-level(in percent ?) ?

 

[gattispilot]

ok. On my LER. I started to make it 2016 capable. I added the the new touchdown points. But then the vessels starts to rotate along the z axis.

static const int ntdvtx = 8;
static TOUCHDOWNVTX tdvtx[ntdvtx] = {
	{ _V(-2, -2.166, 1.5), 1e6, 1e5, 1.6, 0.1 },
	{ _V(-2, -2.166, -2.6), 1e6, 1e5, 1.6, 0.1 },
	{ _V(2, -2.166, -2.6), 1e6, 1e5, 1.6, 0.1 },
	{ _V(2, -2.166, 1.5), 1e6, 1e5, 1.6, 0.1 },
	{ _V(-2, 2.166, 1.5), 1e7, 1e5, 3.0 },
	{ _V(-2, 2.166, -2.6), 1e7, 1e5, 3.0 },
	{ _V(2, 2.166, -2.6), 1e7, 1e5, 3.0 },
	{ _V(2, 2.166, 1.5), 1e7, 1e5, 3.0 },
};

I also noticed ShuttleA on Brighton pad 1 is above the pad.

 

[Zach121k]

Will there be updates to 2016 Via the Tortoise client

Also why does Atlantis ascend to heaven on the Demo

Another thing, the camera going from space to a base camera messes up heavily.

 

[GLS]

AMSO, when separating the stages and these are far too low rather than being behind.

View attachment 14789 View attachment 14790 View attachment 14792

I have found the same behaviour (spent stage apears far below the vessel) when trying the SLS for the Orion MPCV.
- 1st guess: Better create the vessel in PreStep(), not PostStep().
- 2nd guess: When creating a new vessel the coordinate system references to the altitude above terrain, instead to altitude above mean planetary radius. This would explain why this effect only appears in low and medium altitude, not when high in orbit.

SSU had a similar problem when separating from a vessel, or creating a new one, that required its position to be set. We followed Martin's advice and now we only play with the SetState functions in the PreStep and it all works as it should.
About the 2nd guess: for staging events I think using the current vessel position and adding an offset is enough to correctly place the new vessel (the spent stage), so the 3D terrain shouldn't make a difference in this case.

---------- Post added at 12:40 AM ---------- Previous post was at 12:30 AM ----------

ok. On my LER. I started to make it 2016 capable. I added the the new touchdown points. But then the vessels starts to rotate along the z axis.

static const int ntdvtx = 8;
static TOUCHDOWNVTX tdvtx[ntdvtx] = {
	{ _V(-2, -2.166, 1.5), 1e6, 1e5, 1.6, 0.1 },
	{ _V(-2, -2.166, -2.6), 1e6, 1e5, 1.6, 0.1 },
	{ _V(2, -2.166, -2.6), 1e6, 1e5, 1.6, 0.1 },
	{ _V(2, -2.166, 1.5), 1e6, 1e5, 1.6, 0.1 },
	{ _V(-2, 2.166, 1.5), 1e7, 1e5, 3.0 },
	{ _V(-2, 2.166, -2.6), 1e7, 1e5, 3.0 },
	{ _V(2, 2.166, -2.6), 1e7, 1e5, 3.0 },
	{ _V(2, 2.166, 1.5), 1e7, 1e5, 3.0 },
};

While playing with the drag chute in SSU I noticed that c.g. had to be +/- in the center of the touchdown points being used (or the touchdown points +/- equidistant from the c.g.), or the vessel would start rotating slowly. No such problems with the orbiter vessel, so I guess it could be related to vessel mass.

 

[4throck]

.. if they feel aggravated by the bump in the middle of their runway ...

But it's not a case of bumps, it's a case of unusable runways (ex: Vandenberg). I guess the terrain data at high resolution is dominated by noise or something...
Since we still have bases and we still have runways, it's expectable for them to work as such with no need for extra terrain tweaks.

Anyway, it's more of a philosophical question, not a problem. I can always liftoff from flatter ground :thumbup:

 

[gattispilot]

Thank. I modeled the touchdown points off a Shuttle A. The mass is 4000. It starts out fine then starts to dive into the surface.

On Earth it finally calms down but is upside down. When I show the force. There is a yellow arrow (gravity) and light blue force that appears. No thrust applied

 

[turtle91]

...and light blue force that appears. No thrust applied

I have this forces with all vessels, and this causes me some problems to have a full "wheel-stop/landed-idle" after landing, esp on the moon. No idea from where this forces are coming from. There are no such forces on a landed vessel in Orbiter-2010.

 

[gattispilot]

Well it seems it has to do with ground contact. Look at the DG those arrows are coming from the gear.

Not sure why the ler is upside down on Earth.. I have another vessel with no thrust that is fine.

 

[Face]

Do we need an SVN repository for Elev_mod tiles? Any budding landscape architect could register as a contributor, and if they feel aggravated by the bump in the middle of their runway they could flatten it and submit it to the repository so that everybody else would also get the benefit.

And how to hand out SVN commit permissions? On request? What if somebody overwrites files, or by accident reverts them?

I think that if you really want to go with a versioned controlled approach here, it should be decentralized in order to circumvent problems like commit-race and permission-scaling. A pull-request workflow for something of this scale will be more reliable IMHO.

 

[Nicholas Kang]

I can't reproduce this. You did check the "Limited fuel" option, right?

Could it be a 2D-glass-cockpit only issue ?
So the (2D) fuel-display shows the contents of both, the SCRAM and the RCS/MAIN tank-level(in percent ?) ?

To both Doctor Martin and turtle91,

I already checked that I wasn't wrong. I checked the "limited fuel" option every time I started experimenting with the scenario. It is clear that this happens only in 2D display window. So, you need to hit F8 after getting into DG as the default window in the scenario is the new cockpit view with all buttons available. Hit F8 on your keyboard and you will switch to the 2D view that is the general 2-MFD view that is available on all spacecrafts. Then, I flew DG-S many times and the fuel value always remain at 2.49k (kg). To prove that, I shall now upload my screenshot.

Just in case the picture size is too small, I also uploaded it as an attachment. Notice that flying at hundreds of m/s for more than 390 seconds, the fuel value stays at 2.49k as stated early. I don't cheat anyone. The picture proves it.

For your information, this computer is running Windows xp, AMD althon processor (old computer) Orbiter 20160828 with d3d9 enabled. I tried running the scenario without d3d9 client and the fuel value stays constant.

Nicholas.

 

[gattispilot]

I tried the DG 3 points. SDK says minimal 3 points.

static const int ntdvtx = 3;
static TOUCHDOWNVTX tdvtx[ntdvtx] = {
	{ _V(0, -2.166, 10), 1e6, 1e5, 1.6, 0.1 },
	{ _V(-3.5, -2.166, -1), 1e6, 1e5, 3.0, 0.2 },
	{ _V(3.5, -2.166, -1), 1e6, 1e5, 3.0, 0.2 }
};

And I get this:

But when I start forward on the earth I hit a bump and away I go and end upside down.

 

[JMW]

Fuel metering issue (in glass cockpit only)

Fuel indicator not reducing in glass cockpit for me either.
Other views operating fine.

 

[Babbo]

Video problem solved, old scenarios and thanks.

Strange problem solved and post no.1 here: Hello all!

Running Win 7 Enterprise, x64, SP.1, I installed, i.e. copied the zip-content of Orbiter 2016 (downloaded yesterday) to my system partition as c:\Orbiter 2016. Didn’t try the client (Orbiter_ng), but orbiter.exe, which instantly crashed (no launchpad) without any remarkable notification. The solution was: copy the whole directory to my storage partition (HDD), start it there and change the video settings (had a wrong 3D device entry), exit, copy everything back to my faster system partition (SSD) and – it worked! (It goes without saying that the copy-all approach probably was somewhat exaggerated.) Maybe, this can solve someone else’s problem.

Allow a fast question please: may I successfully use old 2010-scenario saves in this new release? (Tried it without crash, but I feel totally unsure …)

Strolling around here for a couple of years, I also believe this to be a convenient occasion to send you all my honest thanks for that great piece of software, naturally including Mr. Schweiger’s work and that nice community here!

 

[boogabooga]

To both Doctor Martin and turtle91,

I already checked that I wasn't wrong. I checked the "limited fuel" option every time I started experimenting with the scenario. It is clear that this happens only in 2D display window. So, you need to hit F8 after getting into DG as the default window in the scenario is the new cockpit view with all buttons available. Hit F8 on your keyboard and you will switch to the 2D view that is the general 2-MFD view that is available on all spacecrafts. Then, I flew DG-S many times and the fuel value always remain at 2.49k (kg). To prove that, I shall now upload my screenshot.

Just in case the picture size is too small, I also uploaded it as an attachment. Notice that flying at hundreds of m/s for more than 390 seconds, the fuel value stays at 2.49k as stated early. I don't cheat anyone. The picture proves it.

For your information, this computer is running Windows xp, AMD althon processor (old computer) Orbiter 20160828 with d3d9 enabled. I tried running the scenario without d3d9 client and the fuel value stays constant.

Nicholas.

Ohh. I see.

The glass cockpit is referencing the SCRAM fuel. Not the main fuel. If you turn on your scam engines, the fuel level will decrease as normal. It's not a bug, just different than before.

Just use the 2D or 3D cockpit view to see the status of all three fuel tanks (main, RCD, scram). But fuel is physically draining as it should.

 

[jarmonik]

And how to hand out SVN commit permissions? On request? What if somebody overwrites files, or by accident reverts them?

Isn't the Orbiter-Forum and OrbitHangar Mods already using the same user IDs ? Could this user ID sharing be extended to a tile repository or a community projects repository in general. For a public tile repository, every community member with 50+ post would get a write access by default. (Maybe to his own personal branch from where the contributions could be merged into a public distribution.)

I can't really see any solutions to a race-conditions where two different contributors are making changes to the same area other than co-operation between the contributors.

 

[4throck]

If there's gone be a community based project, I think it should be focused on adding real world data. So the criteria can be amount of detail, realism, area covered, usage of allowed image sources, etc.
Beyond bases there are other resources that might benefit from a community approach such as markers.

If the goal is to release official updates for Orbiter and Martin is behind it, I'm all for it.

 

[Face]

Isn't the Orbiter-Forum and OrbitHangar Mods already using the same user IDs ? Could this user ID sharing be extended to a tile repository or a community projects repository in general. For a public tile repository, every community member with 50+ post would get a write access by default. (Maybe to his own personal branch from where the contributions could be merged into a public distribution.)

The ID match with O-F is a good idea. The post count thing is a bit arbitrary, perhaps a request system like with social groups would make more sense.

I can't really see any solutions to a race-conditions where two different contributors are making changes to the same area other than co-operation between the contributors.

The commit-race I've mentioned is like so: user A edits tile /Elev/04/000000/000000.elev to integrates his changes, user B does the same in the same branch at the same time, but edits just another pixel. User A commits first. User B wants to commit, but can't, because he is not up-to-date. User B has to update and merge his work with the changes user A did. In the meantime, User C also edits that tile and integrates his changes. He is also faster and commits his changes before B can do it. B again has to merge, and so on.

This is a very common problem with push-based workflows, and it gets worse with more people concurrently working on the same branch. The point here is, that user B can't checkpoint his work at all. He will end up doing ZIP-backups to save his snapshots.

Now with separate branches for each user, this would of course not be a problem, but it would make the life of the integrator (presumably Martin) harder, because he would be the one to merge like 100 different branches into the trunk, each one of them triggering like 10 merge collisions. And we do not have an elevation and/or texture merging tool yet. In addition, each developer would have to keep his branch merged from trunk, so his working area is not too far behind the trunk.

In a pull-request workflow, you can always choose to branch off from the current trunk, commit and publish your own changes, then tell the integrator that he can review the changes. If those trigger merge collisions, the integrator can hand back the task of merging to the users. If the integrator has no time, the user can point people to his own published results in the meantime.

Based on my experience in this matter, I can only strongly advice to NOT use a centralized version control system for this kind of usage. If it absolutely has to be a version control system at all, use a decentralized one, preferably Git.

I'd even propose to ditch the VCS aspect, because there is not really much of versioning going on. In essence it is a database, so why not model it like so? SQL server, relational tables, web interface to get/update tiles. Give people permissions to certain tables, log their access, do frequent database backups.

my :2cents:

 

[kuddel]

I'd even propose to ditch the VCS aspect, because there is not really much of versioning going on. In essence it is a database, so why not model it like so? SQL server, relational tables, web interface to get/update tiles. Give people permissions to certain tables, log their access, do frequent database backups.

Nice idea! I also think that traditional "merging" of the (binary-like) files would not be doable at all (neither SVN nor git nor any other would be good in that until they knew the internal structure!)
The database approach seems to be a workable way, but only if the web-interface spits out the "current"/"new" elv files immediately, so the person trying to fix an issue can check if that really did the trick...

 

[Face]

Nice idea! I also think that traditional "merging" of the (binary-like) files would not be doable at all (neither SVN nor git nor any other would be good in that until they knew the internal structure!)

Well, it would be possible to write a dedicated merge-tool for the file-types involved, but TBH it feels like a VCS is the wrong tool for this job.