New Orbiter Beta Released (r.44, Dec 5 2015)

[JMW]

Here's my temporary solution to having a proper base...I moved Jarvis to where Vancouver International Airport would be.

I thought airports, like Heathrow in London would have runways that wouldn't be roller-coasters, but I guess there is some discrepancy between the coordinates.

This site gives all the detail we need to position the runways etc.
http://ivao.co.uk/atc/quickview/lllookup.pdf

Problem is, how can that be done in Orbiter using these coordinates ?
And would that result in flat runways, or are the "elv" files not that accurate?

 

[DaveS]

I thought airports, like Heathrow in London would have runways that wouldn't be roller-coasters, but I guess there is some discrepancy between the coordinates.

This site gives all the detail we need to position the runways etc.
http://ivao.co.uk/atc/quickview/lllookup.pdf

Problem is, how can that be done in Orbiter using these coordinates ?
And would that result in flat runways, or are the "elv" files not that accurate?

I believe the elevation data is from the Shuttle Radar Topography Mission (SRTM/STS-99) which so far has the best resolution (30 m). This is excellent for general topography but not small stuff like runways.

 

[JMW]

So we do need some sort of "smoothing tool" to kinda plough runway locations flat.....
Is it do-able?

 

[jroly]

If you use the beta version of the XR2 found on this forum, it works for the most part.

I would like to use the XR2 beta, where on the forum is it located?

 

[dbeachy1]

I would like to use the XR2 beta, where on the forum is it located?

Check out the links in this post.

 

[drgullen]

Thanks Doug, you beat me to it by a few minutes!

Just out of curiosity, were you aware of the XR5 issue and is there a fix by chance or is that a WIP?

 

[PeterRoss]

Since the XR5 is the only one of the bunch with CoG shifting, that sounds like a very probable explanation...

I'm pretty sure XR2 has CoG shift as well.

 

[fort]

Bonjour Docteur,

Thank you for your work on Orbiter;

Would it be possible, as in past versions of ortbiter, to to have (by adding a line?), in the current state and quicksave's scn, the line
Help Default \ Checklists \ .... useful when a specific chm comes with an addon (Kulch addons ans some others).

For example:

BEGIN_ENVIRONMENT
System.....................
Date MJD ...............
Help CurrentState_img
Help Default\Checklists\mychm,mychm
END_ENVIRONMENT

I'm finishing an utility giving the possibility via different menus to view videos, images, text files,htm files, pdf, in two separate windows, and timers, starting from a chm parsing an external html file.


swf'pdf and timer

video flv and pic ( not very presentable but I do not want to multiply images here )

pdf


Good day.

 

[drgullen]

Here's a couple of bugs that I've noticed that are present in r25 (forgive me if these have been mentioned previously and are already being worked on):

1. Orbiter will CTD upon exit and also during startup if the current ship (i.e. the one in focus in the scenario) is docked somewhere. If you edit the scenario file and take out the docking info, there is no CTD. There is also no CTD if you start Orbiter focused on an undocked ship and then switch focus to the docked ship. I noticed this using the XR2 and a space station using spacecraft3.dll so perhaps neither of those are supported yet.

2. There is some weirdness with the camera. Start a scenario focused on a vessel and then switch the camera to target a base, like Brighton Beach for example. You will not be able to zoom in all the way like you could in 2010 P1. It's as if the camera still thinks it's actually looking at the vessel you were previously observing.

 

[JMW]

SetMaxWheelbrakeForce and SetWheelbrakeLevel.

Forgive me if I'm way behind here but what's happened to SetMaxWheelbrakeForce and SetWheelbrakeLevel.

They don't seem to have any effect anymore....

since when I don't know - just noticed it (don't do a lot of flying on the ground :lol

Is it now hard-coded?........

 

[Abloheet]

1. Orbiter will CTD upon exit and also during startup if the current ship (i.e. the one in focus in the scenario) is docked somewhere. If you edit the scenario file and take out the docking info, there is no CTD. There is also no CTD if you start Orbiter focused on an undocked ship and then switch focus to the docked ship. I noticed this using the XR2 and a space station using spacecraft3.dll so perhaps neither of those are supported yet.

This problem is because of orbitersound. if you disable it, works fine. When enabled, works sometimes.

 

[NextBigLeap]

I'v been busy lately, so I haven't been able to report that since r17 any external graphics client will not work.

 

[Abloheet]

If you want to use d3d9 client with the latest r25 beta, get its compatible r23 client by reading a few earlier posts in this thread. The post shouldn't be too old. The client devs have uploaded it there. Not in the client website


http://www.orbiter-forum.com/showthread.php?p=514923&postcount=75


Here is your post. If you want the latest version(i.e., for r25, try pm ing the devs. This works fine for r25)

 

[kuddel]

D3D9Client for Orbiter BETA r25

Codeplex still having problems with their SVN bridge (seems like they don't pay *any* attention to it ...)
So for everybody who likes to be "linked against the latest Orbiter BETA":
Here you are.
D3D9Client linked against Orbiter BETA r25

 

[martins]

Committed r.26

Change log:

• Bug fix: Surface bases: mean base elevation was not correctly computed
• Bug fix: Shadows for railway-type base objects was not projected onto true surface elevation
• Bug fix: Camera: ground mode and track mode for surface bases was not referenced to true altitude
• DeltaGlider: Gimbal controls now implemented as SubSystem

Mainly fixing some problems with ground-relative camera positioning in the presence of terrain elevation. The camera in free ground mode now keeps true altitude, i.e. it follows the terrain. Camera focussed on a surface base should now center the base correctly.

Here's a couple of bugs that I've noticed that are present in r25 (forgive me if these have been mentioned previously and are already being worked on):

1. Orbiter will CTD upon exit and also during startup if the current ship (i.e. the one in focus in the scenario) is docked somewhere. If you edit the scenario file and take out the docking info, there is no CTD. There is also no CTD if you start Orbiter focused on an undocked ship and then switch focus to the docked ship. I noticed this using the XR2 and a space station using spacecraft3.dll so perhaps neither of those are supported yet.

I can't reproduce this. Can you provide a scenario (including only stock vessels)?

2. There is some weirdness with the camera. Start a scenario focused on a vessel and then switch the camera to target a base, like Brighton Beach for example. You will not be able to zoom in all the way like you could in 2010 P1. It's as if the camera still thinks it's actually looking at the vessel you were previously observing.

Has this been fixed with r.26?

 

[drgullen]

Martin,

I have updated to r26, but one thing I now find a bit confusing is which D3D9 client should I be testing with? I don't know if this is possible, but I think it would be helpful if the client that you consider to be the proper match for each release was included when we do an SVN update. That way, if it has changed, it is updated automatically. Just a thought.

Anyway, with Beta r26 and D3D9 client r23, my results are:

1. The stock DG docked at ISS scenario gives me a CTD every time. One thing I noticed about that scenario though is the camera target says SH-02 even though there is no SH-02 defined. If I change the BEGIN_CAMERA from SH-02 to GL-02 (the ship that is docked), I still get a CTD. However, If I change the BEGIN_FOCUS from GL-02 to GL-01 (the ship landed at Habana Base), the scenario loads. So the bug seems to be when the scenario is started with the BEGIN_FOCUS ship value equal to a docked ship.

2. The camera bug is still present. Start the DG in orbit scenario and then F1 to go outside. The distance says 40.00. Now, use the camera and switch the target to be Brighton Beach. The distance says 2.000k. Now, start zooming in using the mouse wheel. The closest you will be able to zoom in is 500 meters. Now, use the camera and target the DG again. The distance here now is 10.00. I don't know if that is by design, but that seems off to me and isn't the same as it was in 2010-P1. In the same scenario there, I can zoom all the way in to 0.00 on both the ship and Brighton Beach.

I should note that I am on Windows 10. I don't know if that matters or not in this, but I wanted to mention it in case it does.

Let me know if you'd like me to test with a different D3D9 client.

Cheers,
Glen

 

[Ripley]

Drgullen, I think you should test the beta with the default client, i.e. orbiter.exe (not orbiter_ng.exe).

This way Martin can investigate your/our bug reports and possibly get rid of them.
After that he can publish a new revision with the updated D3D7 default client, which D3D9 is derived from.

Edit: I don't intend to speak for Martin or D3D9 team, but that's how I see it. A betatest should involve as much default content as possible.
I'm no programmer, so I hope I didn't say anything too wrong.

 

[martins]

Indeed. In fact, I hadn't realised that these issues were tested only on the external client. I would ask anybody reporting an issue to also test with the inline client, even if you usually run the beta in conjunction with an external graphics client, and to report back your findings. This will give me some chance of deciding if the problem is caused by the orbiter core, or has a graphics-interface related cause.

As to which version of the D3D9 client to use, I can't really comment. The developers of the client are in a better position to answer.

Edit: If you find that a problem occurs when using the D3D9 client, but not the inline client, you should also test with the external D3D7 client. This will allow to further determine if the problem is a general graphics client issue, or related specifically to D3D9. In the latter case, it would be a good idea to also raise the issue with the D3D9 client developers, to make sure they are aware of it.

 

[Abloheet]

The docked vessel scenario load crash is really a bug of orbitersound 4.0 with orbiter beta.
Many times, when loading the dg mk4 in orbit scenario, you can get to hear 'gear up' just as the scenario loads.
When scenario loads docked to a space station, mayb orbiter sound tries to play some sound related to docking, but fails in the latest beta. If you disabls orbiter sound for these docking scenarios, orbiter wont crash. Otherwise, orbiter sound doesnot cause any other problems.
Tested for both latest d3d9 as well as inline client.

In the latest betas, you cant zoom in anymore all the way till the centre of your viewpoint. For vessels and bases, u can zoom in till a specific distance, after which zoom speed becomes very slow very quickly. This wasn't there in 2010, and one could even zoom inside the vessel and 'see its insides'!

D3d9 client devs maintain a seperate d3d9 beta client for beta revisions as they come out.
I think d3d9 client for 2010 development has stopped, or finished..
Generally, there isnt much need to update the client everytime a new revision comes out, but i remember getting an error trying to use d3d9 for r16 with r23.
Thanks for the d3d9 r25!

 

[mariostivala]

This is the response after command SVN checkout (I've read your link!!):
Command: Checkout from svn://orbithangar.com/orbiter, revision HEAD, Fully recursive, Externals included
Error: Unable to connect to a repository at URL 'svn://orbithangar.com/orbiter'
Error: Can't connect to host 'orbithangar.com': Impossibile stabilire la connessione.
Error: Risposta non corretta della parte connessa dopo l'intervallo di tempo oppure
Error: mancata risposta dall'host collegato.
Completed!: