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

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
A few bugs in the D3D7Client code

Code:
bool Tile::InView (const MATRIX4 &transform)
{
	if (!lvl) return true; // no good check for this yet
	if (!mesh) return true; // DEBUG : TEMPORARY

	bool bx1, bx2, by1, by2, bz1;
	bx1 = bx2 = by1 = by2 = bz1 = false;
	int v;
	double hx, hy, hz;
	for (v = 0; v < 8; v++) {
		VECTOR4 vt = mul (mesh->Box[v], transform);
		hx = vt.x/vt.w, hy = vt.y/vt.w, hz = vt.z/vt.w;
		if (hz <= 1.0) hx = -hx, hy = -hy;
		if (hz >  0.0) bz1 = true;
		if (hx > -1.0) bx1 = true;
		if (hx <  1.0) bx2 = true;
		if (hy > -1.0) by1 = true;
		if (hy <  1.0) by2 = true;
		if (bx1 && bx2 && by1 && by2 && bz1) return true;
	}
	return false;
}


Code:
                // construct elevation grid by interpolating ancestor data
		ELEVHANDLE hElev = mgr->ElevMgr();
		if (hElev) {
			int plvl = lvl-1;
			int pilat = ilat >> 1;
			int pilng = ilng >> 1;
---->			INT16 *pelev = NULL;
			QuadTreeNode<SurfTile> *parent = node->Parent();
			for (; plvl >= 0; plvl--) { // find ancestor with elevation data
				if (parent && parent->Entry()->has_elevfile) {
					pelev = parent->Entry()->elev;
					break;
				}
				parent = parent->Parent();
				pilat >>= 1;
				pilng >>= 1;
			}

---->			if (!pelev) return false;  // There's a CTD on Enceladus without this
                                                         // when loading lvl 8 tiles. Lvls 0-7 are working fine
			elev = new INT16[ndat];
			// submit ancestor data to elevation manager for interpolation
			mgr->GetClient()->ElevationGrid (hElev, ilat, ilng, lvl, pilat, pilng, plvl, pelev, elev, &mean_elev);
		} else elev = 0;
 
Last edited:

n122vu

Addon Developer
Addon Developer
Donator
Joined
Nov 1, 2007
Messages
3,196
Reaction score
51
Points
73
Location
KDCY
Change log:
...
There has been a change to the user interface (point 4): The mouse wheel can now be used to control camera aperture in cockpit views, which is useful to quickly get a particular part of the VC into view (and is a fairly standard feature in other flight simulators, so should be reasonably intuitive.

For consistency, the mouse wheel now also controls aperture in external views (instead of radial distance to target). Radial distance is now instead controlled with right mouse button+mouse wheel. This might take some getting used to. Let me know what you think (of course, radial distance can still be controlled instead with PgUp/PgDn).

Excellent, thank you for this! One of the most-used features by many pilots in X-Plane when flying in a virtual cockpit. Glad to see it available in Orbiter now as well. Although, in X-Plane 10 for example, the mouse wheel controls zoom (or magnification if you will) instead of FOV, which is controlled separately either via the sim Rendering Options screen or via camera or aircraft plugin controls, just FYI.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Honestly saying, I am not satisfied with this change...
Me neither. In a poll I currently would vote against it
[*].

I would better use right mouse button + wheel for FOV changes, and just wheel - for distance (and height in ground camera mode). I use wheel a lot more, I do not change FOV so often.

A "partial" implementation might be a good compromise.
In cockpit (2D & 3D) view FOV change might be nice to have; outside I would still like the 'legacy' mode (whatever that was ;) )
Maybe a Launchpad option?
----------------

[*] that does not mean I'm against any changes; I just prefer the old behavior of that feature.:thumbup:
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
There appears to be some kind of D3D9Client conflict in stock Atlantis causing a CTD.

* \ng The non-graphics version of Orbiter returns always NULL, even if
* a graphics client is attached. To obtain a client-specific mesh handle,
* use \ref GetDevMesh .
* \sa GetMeshTemplate, GetMeshCount, GetDevMesh
*/
MESHHANDLE GetMesh (VISHANDLE vis, UINT idx) const;
 

Attachments

  • atlantis.png
    atlantis.png
    59.5 KB · Views: 37

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
I'm not sure if this is the place to post this but...
I was experimenting with the vessel specific MFD feature introduced in the New Atlantis but encountered the following errors when trying to compile the project.

I found a way to compile the Atlantis by manually editing a file "orbiterroot.vsprops" located in OrbiterSDK/resources/ to point to my Orbiter installation location. Not sure if it's a proper thing to do but it worked this time.
 

orb

New member
News Reporter
Joined
Oct 30, 2009
Messages
14,020
Reaction score
4
Points
0
Modifying OrbiterDir in orbiterroot property sheet is the proper way, but in the case of Atlantis, Orbiter needs to be in a path not using spaces. If there's 8.3 file names compatibility enabled for both the system and NTFS (in this case at the time the directory was created), it might be possible to work around the problem by using there the short file names for the directories.
 

Hlynkacg

Aspiring rocket scientist
Addon Developer
Tutorial Publisher
Donator
Joined
Dec 27, 2010
Messages
1,870
Reaction score
3
Points
0
Location
San Diego
I might have missed it somewhere in the 60+ pages of this and the previous BETA thread but is there a new function call to get altitude in AGL as opposed to MSL, or get the terrain elevation for specific point on the the planet?

I see references to "GetAltitude(AltitudeMode,int*)" but the function itself seems to be missing from OrbiterAPI.h.

On a related note would it be possible to have some sort of function that checks to see if a given vector intercepts the terrain mesh?
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
I might have missed it somewhere in the 60+ pages of this and the previous BETA thread but is there a new function call to get altitude in AGL as opposed to MSL, or get the terrain elevation for specific point on the the planet?

I see references to "GetAltitude(AltitudeMode,int*)" but the function itself seems to be missing from OrbiterAPI.h.
I think the 'elevation' API might provide the things you're looking for:
oapiElevationManager & oapiSurfaceElevation
Code:
// =============================================================================================
/// \defgroup ElevationSupport Elevation data-related functions
// =============================================================================================
//@{
/**
 * \brief Returns a handle for elevation queries for a specified planet
 * \param hPlanet planet object handle
 * \return elevation query handle (or 0 if planet doesn't support elevation data)
 */
OAPIFUNC ELEVHANDLE oapiElevationManager (OBJHANDLE hPlanet);

/**
 * \brief Returns the elevation of a point on a planet surface
 * \param hPlanet planet object handle
 * \param lng longitude [rad]
 * \param lat latitude [rad]
 * \return Surface elevation above planet mean radius
 * \note The OBJHANDLE passed to this function must be a handle for a planetary body
 * \note The return value may be negative if the specified point is below the mean planet radius.
 * \note If no elevation data are available for the specified body, the function returns 0.
 */
OAPIFUNC double oapiSurfaceElevation (OBJHANDLE hPlanet, double lng, double lat);
//@}

A simple Vessel::GetElevation() function combining the two calls might be handy, though - I have to agree
 

Matias Saibene

Development hell
Joined
Jul 7, 2012
Messages
1,055
Reaction score
642
Points
128
Location
Monte Hermoso - Argentina
Website
de-todo-un-poco-computacion-e-ideas.blogspot.com.ar
Missing PWR button on each MFD of DeltaGlider.
qxplo82t2yc6otg6g.jpg

I have also seen a small glitch in the CRS compass. Looks like a rendering problem because sometimes shown superimposed on the compass a painted gray area.
655pa1z8x9i6ppb6g.jpg
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
There appear to be some kind of problem causing a CTD in the Orbiter Beta r.43. It does not occur with the inline engine but it's pretty solid under D3D9Client. Frame rate seems to be one factor effecting ability to reproduce the CTD. Becomes difficult to reproduce if a frame rate is below 100.

1. Load Delta-Glider/BrightonBeach scenario
2. Hit F2
3. Zoom out
4. Max time acceleration
5. Wait a few secs
6. Reduce time Acc to 1000x
7. Zoom in
8. CTD

Note: May need to repeat steps 3-7 a few times.

Last call made for the Client by Orbiter:
Code:
[TRACE] .\D3D9Client.cpp Line:774 oapi::D3D9Client::clbkDisplayFrame
[TRACE] .\D3D9Client.cpp Line:821 oapi::D3D9Client::RenderWithPopupWindows
[TRACE] .\D3D9Client.cpp Line:1156 oapi::D3D9Client::RenderWndProc
[TRACE] .\D3D9Client.cpp Line:1156 oapi::D3D9Client::RenderWndProc
[TRACE] .\D3D9Client.cpp Line:1156 oapi::D3D9Client::RenderWndProc
[TRACE] .\D3D9Client.cpp Line:1156 oapi::D3D9Client::RenderWndProc
[TRACE] .\D3D9Client.cpp Line:1156 oapi::D3D9Client::RenderWndProc

Params:
Code:
[TRACE] HWND=0xB0DAE, uMsg=522, wParam=0x780002, lParam=0x18202D8
[TRACE] Done, returning...
[TRACE] HWND=0xB0DAE, uMsg=512, wParam=0x2, lParam=0x18302D8
[TRACE] Done, returning...
522 = WM_MOUSEWHEEL
512 = WM_MOUSEMOVE

EDIT: I tried running the Delta-Glider project under a debugger and it was not showing anything new.
 

Attachments

  • CTD.png
    CTD.png
    88.2 KB · Views: 24
Last edited:

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Committed r.44

Change log:
  1. Camera: mouse wheel in external view reverts to radial positioning
  2. Camera: separate tracking of aperture setting in external and internal views
  3. DeltaGlider: bug fix: panel element status undefined after visual destroyed/visual created cycle
  4. DeltaGlider: bug fix: z-tearing in VC HSI display
  5. DeltaGlider: added some missing indicators in VC and 2D panel
  6. Dragonfly: fixed CTD
  7. Dragonfly: updated project file
  8. Shuttle-A: some VC bug fixes (MFD displays not visible, some MFD buttons not working)
  9. API: oapiOpenFile: now accepts access mode "FILE_IN_ZEROONFAIL" [issue #1216]
On popular demand, the mousewheel reverts to the previous behaviour in external views. In addition, aperture is now adjusted separately in external and internal views, so that zooming in to the VC doesn't mess up the external view.

I fixed and recompiled the Dragonfly code to the point where Dragonfly scenarios shouldn't CTD anymore. I should mention that the Dragonfly code isn't mine. It has been contributed by a developer (Radu) a long time ago, and may need to be updated significantly at some point. I'm just pretty bad at editing other people's code ...

There is a new commit to the OVP (r.43) on sourceforge. This incorporates jarmonik's two bugfixes proposed recently. I have also made an additional edit to the Tile::InView method which potentially cuts down the number of rendered tiles and could have a performance impact.

There appear to be some kind of problem causing a CTD in the Orbiter Beta r.43.
I haven't specifically debugged this problem yet, but if this issue only appeared in r.43, it might be worth testing r.44, since I've reverted the mouse wheel behaviour in external views. This might have fixed the problem along the way. If it persists, I'll investigate further.

I have also seen a small glitch in the CRS compass. Looks like a rendering problem because sometimes shown superimposed on the compass a painted gray area.
This should be fixed now.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
At first, thanks for fixing the mouse wheel/zoom behavior and adding the FILE_IN_ZEROONFAIL. We made the same mistake with NULL check in every single place where ever we used oapiOpenFile() and I wasn't the only one. :lol:

I haven't specifically debugged this problem yet, but if this issue only appeared in r.43, it might be worth testing r.44, since I've reverted the mouse wheel behaviour in external views. This might have fixed the problem along the way. If it persists, I'll investigate further.

It was first discovered in r.43 but it has likely existed a long before that and it is still present in r.44. If the problem can be reproduced with a debug build of Orbiter then the addresses displayed in a screenshot would make more sense. Or is there a better way to catch it ?

EDIT: The stock Atlantis is still causing a CTD with D3D9.
 
Last edited:

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,875
Reaction score
2,129
Points
203
Location
between the planets
Camera: mouse wheel in external view reverts to radial positioning
Camera: separate tracking of aperture setting in external and internal views

Thanks for that!

I know how annoying it can be to have to sidetrack on control issues that you as a developer think are perfectly fine but has the users complain.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,434
Reaction score
689
Points
203
I fixed and recompiled the Dragonfly code to the point where Dragonfly scenarios shouldn't CTD anymore. I should mention that the Dragonfly code isn't mine. It has been contributed by a developer (Radu) a long time ago, and may need to be updated significantly at some point. I'm just pretty bad at editing other people's code ...
Your own unmodded Dragonfly code can still be found in the 021202 SDK available here: http://www.orbithangar.com/orbDownload.php?file=orbiter021202_sdk.zip

I guess that could be the starting point for a fresh Dragonfly implementation.
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
Martins, the elevation and texture data compress pretty nicely (~50%). Would you consider loading the data by decompressing them from zip files on the fly? I could give you some working code for doing this, if you like (Boost based).
 
Last edited:

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
2
Points
0
Location
404 ROAD NOT FOUND
Martins, the elevation and texture data compress pretty nicely (~50%). Would you consider loading the data by decompressing them from zip files on the fly? I could give you some working code for doing this, if you like (Boost based).

That would be awesome, because right now, the textures alone take 102 Gb of disk space - and Windows is yelling at me :lol:
 

fort

Active member
Joined
Mar 19, 2008
Messages
1,018
Reaction score
20
Points
38
error 404
 
Last edited:
Top