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

[martins]

I've just uploaded a new beta (SVN r.14).

To get the beta, point your SVN client to

svn://orbiter-forum.com/orbiter

This includes some incremental fixes and improvements:

• a collection of bug fixes to the render engine
• a few fixed scenarios (lots more to do)
• retracted RSS for KLC39B (but still incomplete)
• revisions to built-in Shuttle launch autopilot
• some bug fixes to the Shuttle gimballing mechanism during launch
• revised Brighton Beach base
• support for vessel-specific MFD modes in VESSEL4 interface

The last point might be the most interesting for vessel addon developers. You define the MFD mode as usual via the MFD2 interface, but register it with VESSEL4::RegisterMFDMode instead of oapiRegisterMFDMode. The MFD mode can be defined directly in the vessel module. Have a look at the Atlantis launch autopilot for an example.

You need to download a modified MinorBodies.zip texture package from http://mirror.orbiter-radio.co.uk/orbiter/assets/orbiter_texturepacks.html for the new beta, which includes new textures for a few Saturn moons. All other external texture packages remain unchanged.

The D3D7 client code on sourceforge has been synced to this beta.

As usual, I have to apologize for the long intervals between betas. I am still working on Orbiter whenever time permits, but progress is painfully slow. I really would like to do a release before the end of the year, but I realize that there is still quite a lot to do. Maybe I'll have to aim for a halfway stable state and leave the smoothing of the rough edges to subsequent updates. Otherwise this may never happen ...

Please let me know about problems with the beta installation (missing files etc.) As usual, bug reports are most welcome (although I'm aware of various bits in need of fixing already).

Next, I'll try to find some time for updating documentation, scenarios and tutorials.

Have fun!

 

[Enjo]

Thanks Doc!
Here are my corresponding toys, updated to r.14:
http://enderspace.de/orbiter/addons-beta/

 

[dseagrav]

Is there is a bug tracker or something where stuff for the beta should go?

 

[jedidia]

Just as a heads up so it doesn't go under, this bug is still a thing.

 

[DaveS]

Is there is a bug tracker or something where stuff for the beta should go?

Here: http://www.orbiter-forum.com/project.php?projectid=1

 

[jedidia]

Huh, I always thought that was only for 2010 p1 and preceding versions...

Anyways, since updating I'm getting a worrying amount of random ctds while debugging. My code is certainly not without flaws, but it did run decently stable on the previous build.

I can't really make any rhyme out of the ctds since they happen pretty much anywhere in my code or in orbiter code (as I said, reeeeally random, rarely ever twice in the same location), but from the timing of their occurence I'd venture a guess that they have something to do with blitting textures or the panel redraw event in general (really not sure here, but it's the best I have).
Has anyone else expierienced a sudden peak in instability since the update when they were clicking around in a pannel, possibly while debugging?

 

[martins]

Just as a heads up so it doesn't go under, this bug is still a thing.

Thanks for the reminder. I have uploaded a new version (r.15) that should fix this problem. Can you let me know if it works as expected, in particular if clbkPostCreation is called at the expected position in the callback pipeline?

Not sure about the other problem with random CTDs. There wasn't that much change in the rendering engine since the previous build. Has anybody seen anything similar?

 

[N_Molson]

*heart attack*

 

[DaveS]

Martin: could you take a look at these two bugs? Having these fixed would help us in the SSU project immensely.

oapiVCSetAreaClickmode bug: http://www.orbiter-forum.com/project.php?issueid=1199
SetCameraDefaultDirection changes external camera direction: http://www.orbiter-forum.com/project.php?issueid=767

 

[kuddel]

D3D9Client for "R15"

Just to give something back: Here's D3D9Client linked against Orbiter BETA r15.
Thanks Doc.,
Kuddel

Not much changed in the library headers, so it should not make any difference whether one uses a D3D9Client linked against r13 or r15. Therefore no new upload to the codeplex site (having SVN troubles there again, anyway :/ ). But I thought: "many like the bleeding edge" :thumbup:

 

[jedidia]

Can you let me know if it works as expected, in particular if clbkPostCreation is called at the expected position in the callback pipeline?

Yup, done and gone! Thanks a bunch! :thumbup:

 

[martins]

Martin: could you take a look at these two bugs? Having these fixed would help us in the SSU project immensely.

oapiVCSetAreaClickmode bug: http://www.orbiter-forum.com/project.php?issueid=1199
SetCameraDefaultDirection changes external camera direction: http://www.orbiter-forum.com/project.php?issueid=767

Uploaded r.16 to address the first of these. Let me know if it works.

 

[GLS]

Uploaded r.16 to address the first of these. Let me know if it works.

Thank you thank you thank you!!! It seems to work well now. Thanks! :hail:

 

[DaveS]

Uploaded r.16 to address the first of these. Let me know if it works.

Thanks for taking a look at these. Two other things that need a bit of attention is higher MFD resolution in VC mode (currently seems to be 256x256) and this: http://www.orbiter-forum.com/project.php?issueid=601

 

[martins]

Martin: could you take a look at these two bugs? Having these fixed would help us in the SSU project immensely.

oapiVCSetAreaClickmode bug: http://www.orbiter-forum.com/project.php?issueid=1199
SetCameraDefaultDirection changes external camera direction: http://www.orbiter-forum.com/project.php?issueid=767

Uploaded r.17 to address the second issue. Again, please let me know if it works now.

 

[martins]

Thanks for taking a look at these. Two other things that need a bit of attention is higher MFD resolution in VC mode (currently seems to be 256x256) and this: http://www.orbiter-forum.com/project.php?issueid=601

Regarding the MFD resolution in VC mode: this might need a bit of thought. I could of course just increase the default resolution, but that might cause aliasing problems if the apparent size of the display is small (small render window or large viewing distance). So maybe a dynamic solution would be better. But this could also lead to strange visual effects, say if two side-by-side MFDs are rendered at different resolutions, just because of an arbitrary threshold.

What resolution did you have in mind?

 

[GLS]

Uploaded r.17 to address the second issue. Again, please let me know if it works now.

2 for 2!!! Thank you so much!

 

[DaveS]

Regarding the MFD resolution in VC mode: this might need a bit of thought. I could of course just increase the default resolution, but that might cause aliasing problems if the apparent size of the display is small (small render window or large viewing distance). So maybe a dynamic solution would be better. But this could also lead to strange visual effects, say if two side-by-side MFDs are rendered at different resolutions, just because of an arbitrary threshold.

What resolution did you have in mind?

Well, the shuttle MEDS MDUs render at 1024x1024 and those are mid-1990's equipment. We in the SSU project have discussed getting rid our reliance on the Orbiter MFDs due the small resolution of the MFDs. We really need the high resolution to fit everything.

 

[Urwumpe]

Well, the shuttle MEDS MDUs render at 1024x1024 and those are mid-1990's equipment. We in the SSU project have discussed getting rid our reliance on the Orbiter MFDs due the small resolution of the MFDs. We really need the high resolution to fit everything.

I would still disagree to render 1024 x 1024 px displays (even if the original did so), since we rarely use more than roughly 400x400 px when rendering in a 1080p display resolution.

512 x 512 px would IMHO be fine enough for the task, even a 4K display resolution would not need much more.

For showing the 1024 x 1024 px displays, we would need to use a full screen for a single MDU in most popular display resolutions (I am sure, many even still play SSU in 1024x768). If you really want 1024x1024, we should better implement some "remote display rendering protocol" into SSU, so rendering of the MDUs can be done on remote hardware.

 

[4throck]

For MFDs in VCs I think that 512x512 would be good for today's displays.

Thinking about two side by side MFDs + buttons on a 1920x1080 display.
Even zoomed in, the MFDs wouldn't be much larger than ~700 px.