New Orbiter SVN commit (r.71, Oct 14 2017)

[Havner]

Is this only with the D3D9 client, or also with the latest D3D7 client?

Maybe the OVP change wasn't as uncritical as I thought ...

Happens for me as well (r54), but only with D3D9 (for r53). Windows shows a crash in D3D9 dll. D3D7 works fine.

 

[martins]

Does this happen with a recompiled D3D9 client, or are you using a version compiled for a previous beta? If it's the latter, then hopefully only a recompilation will be required.

 

[jarmonik]

Looks like there are some Sketchpad fonts created in GraphicsClient::clbkCreateRenderWindow(); but the D3D9Device is not yet initialized and the render windows doesn't exists, so, it is causing a crash in D3D9Client.dll. I suppose it should be possible to allocate the fonts as GDI only at that point and upgrade them to D3D9Fonts after the device is initialized.

 

[jarmonik]

Here's a new build that should work with r.54

 

[kuddel]

Thanks Jarmo,
that fixed it!
Was that change in Font-allocation unexpected? Or is that going to be the usual sequence? Just out of curiosity, cause I had some random Font- allocation / release issues some time ago which I couldn't reliably reproduce.

 

[jarmonik]

Thanks Jarmo,
that fixed it!
Was that change in Font-allocation unexpected? Or is that going to be the usual sequence? Just out of curiosity, cause I had some random Font- allocation / release issues some time ago which I couldn't reliably reproduce.

Yes, I wasn't expecting that. In D3D9 we have a graphics "sub-systems" initialized when clbkCreateRenderWindow returns. So, it's not exactly a good idea to create anything graphics related until that. Any font issues you might have had are unlikely related to this one.

 

[martins]

New Orbiter Beta Released (r.55, Apr 12 2016)

Change log:

1. Module class: added callback methods clbkProcessMouse, clbkProcessKeyboardImmediate, clbkProcessKeyboardBuffered for intercepting keyboard and mouse events. NOTE: requires recompile of all Module-based plugins (including graphics clients)
2. API: new version of oapiGetAltitude that allows to accommodate ground elevation
3. Lua API: new versions for oapi.get_altitude and vessel:get_altitude to accommodate ground elevation
4. DeltaGlider: bug fix: typo prevented atm. autopilot from executing
5. Graphics client: revert to previous splash screen font allocation
6. Camera: bug fix: ground elevation in ground observer mode could refer to wrong planet.

Re. point 5: after a report of resource leaks regarding Sketchpad resources, I had implemented an allocation counter to keep track of resource allocation, but inadvertently changed the allocation of the splash screen font, which seems to have caused problems. The allocation sequence should now have reverted to the original order.

Re. points 2 and 3: support for altitude queries in the presence of surface elevation has been extended in the C++ and Lua interface. This is in response to this request.

Re. point 1: Jarmo suggested callback functions that can intercept (and optionally block) keyboard and mouse events before they are processed by the standard Orbiter event handler. I've implemented these callbacks now in the Module class. This will allow more comprehensive keyboard and mouse customisation than possible so far.

The downside is that all Module-based plugins, including graphics clients, must be recompiled for this beta.

I don't know how many other addons are affected by this interface change. If this turns out to be a problem I can probably undo this modification. Since I want to get a release candidate out soon, it's maybe a bit naughty to come up with a feature addition so late in the day.

 

[Enjo]

The downside is that all Module-based plugins, including graphics clients, must be recompiled for this beta.

No problemo. Done.

I don't know how many other addons are affected by this interface change. If this turns out to be a problem I can probably undo this modification. Since I want to get a release candidate out soon, it's maybe a bit naughty to come up with a feature addition so late in the day.

Many addons will be affected, but we have to get with the times.

BTW, Martin, before making the final release, would you consider unzipping the textures and elevation data on the fly as proposed here?

 

[kuddel]

D3D9Client (Beta23.1) for BETA r55

...Module-based plugins, including graphics clients, must be recompiled for this beta.

Your wish is my command :thumbup:

 

[Havner]

[*]API: new version of oapiGetAltitude that allows to accommodate ground elevation

So while we're on API changes and close to release I'll allow myself to ask/report my finding. And hopefully cause it fixed before the release. I mentioned this in the OrbiterSDK subforum but I suppose you haven't read it.

I developed a small joystick plugin to allow me to support more then one device (plugin itself is irrelevant) and I found I'm unable to control nosewheel steering on the default deltaglider.

From reading the SDK this should be achieved by:
vessel->SetControlSurfaceLevel (AIRCTRL_RUDDER, newVal);

It doesn't work. It sets the rudder, not the NWS. Surprisingly it works for Dan's DGIV, but not for the included one. I have not found any other SDK function to achieve that. And the rudder in the included joystick implementation sets NWS.

The goal of my plugin was to completely mimmick the default Orbiter's joystick implementation (including ROT/LIN and Airfoil switch) and I achieved that, except that one detail.

So there is a bug either in the DG, or the SDK or there needs to be a separate SDK call for setting NWS value. I don't know which.

https://github.com/Havner/orbiter-joy-ext/blob/master/Controls.cpp - setRudder()

 

[martins]

BTW, Martin, before making the final release, would you consider unzipping the textures and elevation data on the fly as proposed here?

Yes, in fact the plan was (and is) to keep the entire tileset in a single zip file and extract individual tile files on the fly. This would avoid having to unpack and keep an enormous number of small files on the disk, which can cause various problems.

Doug Beachy has already kindly looked into that and also written and tested code for it. I just haven't yet gotten around incorporating it into Orbiter.

I also wanted to push the concept a bit further. Instead of unzipping a file every time is is requested, I want to keep the unzipped files as a cache. Orbiter would first check the cache if the required file is already present, and request the file from the zip archive if not in the cache.

I also want to keep the interface between Orbiter file requests and the zip file server module reasonably abstract, so that the zip server could eventually be replaced by a network server for remote tileset access, although that's a bit further down the line.

There are a few drawbacks with the zip archive approach, e.g. how to merge multiple zip archives for local tileset replacements (e.g. from base addons), or how to edit individual tiles inside the archive.

 

[Enjo]

That's great to hear!

Yes, in fact the plan was (and is) to keep the entire tileset in a single zip file and extract individual tile files on the fly. This would avoid having to unpack and keep an enormous number of small files on the disk, which can cause various problems.

If keeping the same number of compressed files on disk wouldn't be a problem (i.e. each tile would be a zip file), then the below problem wouldn't exist:

There are a few drawbacks with the zip archive approach, e.g. how to merge multiple zip archives for local tileset replacements (e.g. from base addons), or how to edit individual tiles inside the archive.

I understand that Doug has already written some working code, which is great already, but if you're able to abstract the Orbiter's "TileRequest(x, y, level)" call, then a contributed module could use the other option (read each tile from a separate zip file).


Also, don't get me wrong, but the caching functionality would probably need to be optional, since it kind of kills the purpose of zipping: Firstly, it would bloat the Orbiter installation, and secondly, it would increase the amount of work that the HDD had to do in the same time, when you need it for reading the zip file(s). I can imagine the HDD's head jumping from one sector to another in such scenario, thus slowing down the read process... unless the tile's source was indeed a network share.

[EDIT] One thing to keep in mind, is that in the spirit of the idea of unzipping is, that the unzipped tile should go straight into the memory, and not be placed on the disk.

 

[orb]

how to merge multiple zip archives for local tileset replacements (e.g. from base addons)

I guess it could be done with archive priority system and a map of the tiles wrt. the multiple archives (once their priority is determined). How to set priorities is TBD, but it could be by the file name, modification date, or alternatively set in a configuration file.

 

[Enjo]

Interesting ... but complicated ...

 

[Loru]

How about just storing default earth heightmap files inside the zip and for usser created bases or any modified part using uncompressed wrt files? Uncompressed should just be prioritized over compressed.

One of the advantages of this solution is, that you can delete any addon base and terrain returns to normal automatically.

 

[Eduard]

Bug: Having the "Remote Vessel Control" enabled causes CTD when launching Orbiter rev. 55.

 

[AssemblyLanguage]

Request: HSI Variable Approach Angle

Would it be possible to modify the HSI MFD to support a variable approach angle?

For example, the Shuttle Atlantis approach angle is 20 degrees. The PAPI at KSC is set at 20 degrees but the HSI shows a much lower angle.

Thanks.

 

[jarmonik]

I also want to keep the interface between Orbiter file requests and the zip file server module reasonably abstract, so that the zip server could eventually be replaced by a network server for remote tileset access, although that's a bit further down the line.

That sounds like a good idea. Also, in the current implementation it would be helpful if the path to a planetary textures could be specified. Users tend to have multiple installations of Orbiter, I got three right now. So, it would help a lot if an additional installations could fetch a planetary textures from the master installation.

 

[kuddel]

That sounds like a good idea. Also, in the current implementation it would be helpful if the path to a planetary textures could be specified. Users tend to have multiple installations of Orbiter, I got three right now. So, it would help a lot if an additional installations could fetch a planetary textures from the master installation.

That's what symbolic links are perfect for!
I have 15! Different Installations, 4 of which are Orbiter BETA based. Those 4 all have symbolic links at Textures folder for the Hi-Res Textures and Elevation maps...
This is the batch, that creates the links:

@echo off
setlocal EnableDelayedExpansion

set SRC=c:\Program Files (x86)\Orbiter\_Resources\Textures
set DST=.\Textures
set JUNCTION=c:\Program Files (x86)\Orbiter\_Resources\junction.exe

for /F "tokens=*" %%d in ('dir /b /a:d "%SRC%"') do (
  set NAME=%%d
  if "!NAME:~-4!" neq ".old" (
    echo.  %%d
    if exist "%DST%/%%d" rmdir /S /Q "%DST%/%%d"
    "%JUNCTION%" "%DST%\%%d" "%SRC%\%%d" > nul
  )
)
endlocal

In my example all the "shared" resources are located at "_Resources" Folder.
junction.exe is my favorite 'link-creator' btw. and is from SYSINTERNALS.
The extra check for paths "not ending in '.old' " just skips folders I like to keep, but should not be linked.

 

[fort]

http://blog.andrewbeacock.com/2010/01/how-to-use-junction-if-you-want.html

https://technet.microsoft.com/en-us/sysinternals/bb896768.aspx

:tiphat: