New Orbiter Beta Released (r.13, Mar 7, 2015)

Orbiter Beta SVN commit #8

This one is a bit of a self-indulgent detour from the current main topic of terrain support (sorry about that ;)

I felt the need to upgrade the DG virtual cockpit a bit so here you go. It's not complete yet, so a few more things to come in the next beta (plus, some of the 2D panel controls are currently out of order as well.)

Note that for the cockpit lights to work (the two switches on the right side panel) you need to enable local light sources in the Launchpad dialog.

Also try Ctrl-H and be amazed :lol:

This may be of general interest for addon developers because it adds a few API features:

  • support for local light sources inside virtual cockpits
  • VESSEL::GetAnimation method for retrieving an animation state
  • oapiGetMeshGroup function for retrieving a deep copy of a DEVMESHHANDLE group
  • oapiEditMeshGroup: now allows to add to vertex components (in addition to replacing)
 
Ok.
Is it me again or has everybody got this?
On trying to load Deltaglider in Revision 8
 
Last edited:
Ctrl-H is a cool feature :thumbup:. However, it is only animated in the cockpit view, not in the outside view. Not sure if that was intended, though.
 
I'll be without pc until tomorrow.
Please explain to us poor men what this CTRL-H does...
 
I tried to upgrade the D3D9Client to support rev. #8 but something odd is going on. It would appear that oapiCameraProxyGbody() returns a NULL.
 
Ok.
Is it me again or has everybody got this?
On trying to load Deltaglider in Revision 8
If you didn't go through the installation app, you may have to manually copy install/orbiter.bin to ./orbiter.exe.
Let me know if there are any files missing though, there is always a possibility that I missed to add new files to SVN.
Ctrl-H is a cool feature :thumbup:. However, it is only animated in the cockpit view, not in the outside view. Not sure if that was intended, though.
Yes I know. The external view uses a simplified cockpit mesh, and I haven't got around to updating that yet. The VC is painful enough for me, since I am rather 3D-modelling impaired. I've created the entire VC mesh via Matlab script, triangle by triangle ...
I'll be without pc until tomorrow.
Please explain to us poor men what this CTRL-H does...
It turns the DG from a no-nonsense workhorse into an executive toy :thumbup:
 
I tried to upgrade the D3D9Client to support rev. #8 but something odd is going on. It would appear that oapiCameraProxyGbody() returns a NULL.

OK, I'll look into that. It's a bit strange, since I don't think I touched anything close to that function. Did it work ok in rev #7?
 
OK, I'll look into that. It's a bit strange, since I don't think I touched anything close to that function. Did it work ok in rev #7?

Yes, It did work in rev #7. The client is loading a scenario just fine until it reaches that function. Could it be a mismatch between *.dll and *.lib ? I don't recall seeing anything like that before.

---------- Post added at 15:19 ---------- Previous post was at 14:58 ----------

I think I may have found the problem. Something has changed a bit and now the function is called too early while the scenario is still loading. Looks like the problem is on our side, false alarm, sorry.

---------- Post added at 16:03 ---------- Previous post was at 15:19 ----------

Not sure if this is an other problem on our side. But the hSurf parameter of "void D3D9Client::clbkRender2DPanel (SURFHANDLE *hSurf, MESHHANDLE hMesh, MATRIX3 *T, bool additive)" is NULL when in a panel view in a DG. The virtual and glass cockpits are working properly. Also Shuttle-A is working properly in all cockpit modes.
 
Ran Install app.
Still got the problem.
Just to clarify, Deltaglider.dll not loading (according to orbiter log),
so no visible vessel, though F9 displays name.
Error message as in my previous post now only intermittently displaying.??

Not sure what Doc means when says "Let me know if there are any files missing though,....."
Where do I look to know if any are missing?:shifty::shifty:
 
Since nobody else is reporting this problem, I am more inclined to think that this is a problem with your installation rather than an inconsistency in the repository. Can you try a fresh checkout, just to be on the safe side?

If that still doesn't work, you could use the DependencyWalker to check if your orbiter.exe actually exports the oapiGetMeshGroup symbol. If not, you've got an old version of the executable.
 
If using TortoiseSVN, right-click orbiter.exe, find revert and do that, then run it again. Orbiter.exe doesn't get replaced when you update.
 
Orbiter.exe doesn't get replaced when you update.
That's why I don't play directly on the SVN working copy of Orbiter, but in a separate directory with symbolic links to each of the files that won't get modified during runtime, and otherwise copies of the files that are modified by me or Orbiter when I use it or build sources. This makes the SVN directory clean of add-ons, hi-res textures, changed configuration and my testing modifications, too.
 
jangofett, you got it! :thumbup::tiphat:

Thanks to everyone, and congratulations to the good Doctor for more strides forward on the realism trail.

If I could understand what Orb said, I'd do it.
What's "symbolic links"?
Found this http://www.orbiter-forum.com/showthread.php?t=32376&highlight=symbolic+link
Is this only applying to d3d9, or any files you need to link?

Any advice on quick fixes for my hud changes? I've started labouring my way through altering all the x,y references but there's dozens of 'em! :beathead:
 
Last edited:
That's why I don't play directly on the SVN working copy of Orbiter, but in a separate directory with symbolic links to each of the files that won't get modified during runtime, and otherwise copies of the files that are modified by me or Orbiter when I use it or build sources. This makes the SVN directory clean of add-ons, hi-res textures, changed configuration and my testing modifications, too.
Nice trick using the symbolic links! What I do is locally branch to "local" or something, then go back to "master" before updating. Then I can merge everything if lazy enough to not reinstall everything. (But all I'm using is D3D9 so nothing really complex.
 
I get this "can't find entry point..." error upon launching orbiter.exe

PZKGUpB.png


BTW, it still says "Orbiter 2010", but it is Orbiter 2014 Beta.
 
Just do what jangofett said;
If using TortoiseSVN, right-click orbiter.exe, find revert and do that, then run it again. Orbiter.exe doesn't get replaced when you update.
 
Found some duff data in the cloud map (it's there in the original E. Hemisphere Blue Marble Clouds). A bit of amateur photo-shopping (well GIMPing):-
picture.php


A couple of other minor bugs I noticed with the 140602 beta:

DG ALT-SPACE menu for animations/lights has no 'close' 'x'
Selecting HUD button from VC MFDs e.g. surface/docking doesn't update the relevant VC button.
Also, the HUD in VC view seems to enhance (brighten) the celestial background (observed whilst messing with the cool Alt-H feature ;-)

I know these are very minor things - the beta looks absolutely awesome.
 
I get "unspecified error" when unpacking the hi-res moon textures in 7-zip. Should I just download the files again? I downloaded them by torrent, so they should be ok...

---------- Post added at 08:00 PM ---------- Previous post was at 05:45 PM ----------

Hmmm... it seems the error occured because I installed the hi-res textures after installing the low-res. Once I deleted the old texture folder, it worked. Might be a useful piece of information.
 
I just noticed that non-spherical gravity seems to switch-off at time-warp > x2000.
With the non-spherical gravity box checked in the parameters tab, I was targeting the ISS and as soon as I time-warped from x1000 to x10000 the LAN, ApA and PeA remained fixed. I brought up the "Orbiter: Time acceleration" tab and I noticed that the equatorial LAN precession and ApA and PeA oscilation were working up to time-warp of ~x1900, but at x2000 and above they remained fixed.

Can anyone else confirm this?
 
Back
Top