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

[Ripley]

I'm sorry Mario.
Where did you create your Orbiter Beta folder?

 

[drgullen]

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.

Fair enough, but you could make the argument that since this is supposed to be a brand new version of Orbiter, why is the core client still based on technology that is actually 16 years old today? Shouldn't the core now be at least DX9 and the external be DX11?

Results using core client:

1. DG Docked to ISS scenario loaded fine.
2. Camera problem still happens.

 

[martins]

Fair enough, but you could make the argument that since this is supposed to be a brand new version of Orbiter, why is the core client still based on technology that is actually 16 years old today? Shouldn't the core now be at least DX9 and the external be DX11?

Well, what it should or shouldn't be tends to be decided by the people who do the actual work. You are very welcome to start working on a DX11 client, if the graphics on offer don't meet your demands (I think there was a DX11 project already at some stage, but I haven't heard anything about it for a while).

In fact, that was the reason why I opened the graphics interface in the first place - so that nobody is obliged to wait for me implementing features that are high on their wish list but low on mine. Graphics are not a particular concern of mine, and I am happy enough with the current DX7 graphics. But I realise that I am in a minority here, hence the support for external clients.

I don't expect to upgrade the internal client to a newer DX interface in the forseable future. More likely I'll end support for the inline client altogether, should DX7 finally become unusable.

Just one more general note regarding bug reports: Before reporting any issues, please always check if the problem is also present without any addons (including what you might consider essential plugins). I cannot debug other people's addons. Even if the sources were available, I have my hands full just straightening out the Orbiter core. If you fail to mention any addons the problem might be related to, I am assuming that it can be reproduced with a barebones Orbiter installation. If that turns out not to be the case, you send me on a wild goose chase, and waste time that could have been used to fix bugs within my scope. You also risk making me rather cross. :dry:

 

[mariostivala]

I'm sorry Mario.
Where did you create your Orbiter Beta folder?

Under D:\orbiter_beta\orbiter

 

[martins]

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!:

Firewall issue maybe? According to this, port 3690 should be open for svn protocol transfers.

 

[drgullen]

Definitely not trying to make you cross Martin and I meant no disrespect. For me, this version of Orbiter is all about the graphics. Just thinking about re-entering and landing on 3D terrain excites me, but for me at least, I would never do it with the inline client.

I did have add-ons installed, so I will delete everything, download r26 again this time with no external client and I will retest and report my findings.

Cheers,
Glen

---------- Post added at 01:17 PM ---------- Previous post was at 12:16 PM ----------

UPDATE:

Clean install of r26, no add-ons, no ext client -- results are the same. The docking scenario works fine and the camera still does not zoom in all the way.

Cheers,
Glen

 

[StevoPistolero]

White screen

I downloaded the source files and tried opening a few scenarios. I don't get a loading screen, or a crash, just a blank white screen. Not sure what to do about this, but I thought I would let you know. I am running Windows 10 with an NVIDIA GTX970.

 

[martins]

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.

Ok, I had finally some time to look into this. The behaviour you describe is indeed by design, and it is different to the 2010-P1 behaviour. In 2010-P1, the reference distance for the camera was zero (the origin of the target object). In the beta the reference distance is the mean radius of the object (as defined by the Size parameter in the config file or the module). In other words, you can move the camera up to the mean radius, but not further in.

The fact that switching from Brighton Beach to a DG as camera target shifts the camera distance from 500 to 10m is also expected. The camera distance is scaled by the mean radius of the target object, which happens to be 500m for Brighton Beach and 10m for the DG.

Here is the rationale for the new behaviour:

The main difference may be visible when using a planetary body, say Earth, as camera target. In the old version, you could drop the camera right through the surface. It was nearly impossible to move the camera close to the surface, because the movement was much too coarse at this distance from the reference point. In the beta, the reference is the (mean) surface itself, so this problem doesn't occur anymore. As the camera moves towards the surface, the control becomes correspondingly finer (both radially and laterally). Try it with both 2010-P1 and the beta, and you'll see the difference. I would argue that in 2010-P1 this camera mode was virtually useless for homing in to a surface location.

The same effect also applies to vessels and surface bases. You can move to the defined mean radius, but no further. I'd argue that certainly for vessels this makes sense. The external camera shouldn't be allowed to move inside the vessel, and seeing the vessel mesh clipped at the near plane of the camera frustum does rather interfere with immersion. Maybe for some debugging purposes it would be useful to move the camera through the vessel, but that's not what this mode is for.

For surface bases, the behaviour is slightly more controversial. I would however say that this camera mode is intended to see the base as a whole, rather to zoom in all the way to the (somewhat arbitrary) base origin. If you want to look at a particular part of the base in detail, you should instead use the ground observer mode.

If the camera movement towards a base really does seem too restricted, then maybe that is an indication that the Size parameter for the base is set too high.

What do other people think of the new camera behaviour?

 

[Abloheet]

Thanks sir, for explaining my point so clearly! :thumbup:

 

[mariostivala]

I've opened port 3690 on my firewall for both incoming and outcoming connections; the result is the same..

 

[jedidia]

From a recent report on IMS I gather that MFDs that are powered off are still drawing a black rectangle on the panel in the Beta. In 2010, powered off MFDs didn't draw anything at all, and could thus be made transparent. In the Beta, you can apply all the Alpha chanels in the world, the inactive MFDs will still draw a black rectangle.

 

[martins]

I've opened port 3690 on my firewall for both incoming and outcoming connections; the result is the same..

Sorry, that concludes my ideas. Do you get the same result for other repositories as well? (you could try the Orbiter graphics client code on sourceforge as a test)

svn checkout svn://svn.code.sf.net/p/orbitervis/code/

 

[kuddel]

Hey mariostivala,
I don't know but maybe you need some ssl-certificates (just a guess)
You can try the following:

1. svn checkout https://orbithangar.com/orbiter/ (note the "https"!). This might ask you to store some certificates, wich you should accept. The checkout will fail, but maybe these help in the next step...
2. svn checkout svn://orbithangar.com/orbiter/ Maybe now it works

Note, this is just a guess

 

[Felix24]

I would like to suggest a solution for adding controllable VC and exterior lighting to vessels without having to edit and recompile each vessel.

There is currently no way to manually control the VC lights in anything but the Deltaglider in the Beta, and the implementation in that case is model-specific. The graphics client is not aware of the status of the VC lights.

If we could add controllable lights to any vessel, whether or not they had any in the first place, that would allow other popular vessels like Atlantis, the DG, and the XR-2 to have VC floodlights and panel illumination, as well as custom exterior lighting. Every vessel could benefit from the added features.

There would be some keyboard shortcuts for different functions. They would be linked to vessel parameters that are read by the graphics client. The graphics client would then do the work of enabling and disabling the lightmap textures, if they are present.

 

[mariostivala]

Yes, unfortunately the response is the same...

---------- Post added at 05:11 PM ---------- Previous post was at 05:03 PM ----------

Thanks for the tip, but unfortunately it does not work!!

 

[Ripley]

Mario, did you try to uninstall Tortoise?
Maybe a reinstall "unblocks" it (from the firewall pov).

 

[martins]

Committed r.27

Change log:

1. DeltaGlider: implemented hover vertical speed hold autopilot
2. DeltaGlider: HUD controls now implemented as SubSystem
3. Frame loop logic: "paused" flag now set/reset before update phase (previously: between update and render phase). This should avoid the render block missing the last update before a pause.
4. Bug fix: D3D7 client: exhaust particle stream was shifted during pause (because of the point above)
5. Bug fix: elevation corrections for surface base objects
6. Bug fix: Exhaust particle shadow rendering now takes into account (approximate) surface elevation.
7. API: new function oapiSurfaceElevation
8. Ground observer camera: the altitude limit for terrain-following mode can now be selected in the Camera dialog.

New OVP commit to go with this beta: r.38 (implements Point 6 above in the D3D7 client).

Notes: Point 3 could potentially have side effects in addons. Until now, Orbiter set the pause/unpause status flag between the update phase and the render phase of a frame. However, this potentially meant that the renderer would miss the last update before a pause if checking for the pause flag. The new behaviour is to defer the pause/unpause flag until the beginning of the next update phase.

Point 1 should be fun for VTOL operations on Moon, Mars and similar. Soft touchdown guaranteed!

 

[Xyon]

I've opened port 3690 on my firewall for both incoming and outcoming connections; the result is the same..

Let's begin at the beginning. From the computer you're trying to check out on, open this link in Chrome and tell me what you see:

http://orbiter-forum.com:3690/orbiter

 

[JMW]

r.27
Buildings are sitting properly now, but runways/taxiways are still elevated.
Is this everyone's experience? (inline client :thumbup
https://www.dropbox.com/s/vynnqmrr67k0pi7/Screenshot 2015-09-25 18.21.37.png?dl=0

External client doesn't render the addon runway, but taxiways are "elevated" just the same.
https://www.dropbox.com/s/56wdry34h6prz6m/Screenshot 2015-09-25 18.40.55.png?dl=0

 

[Topper]

r. 27:
I noticed two new points:

1) When I took off from Brighton Beach and set verticle speed to +1m/s to test point 1 of r.27, the hover engine goes on off on off on off verry fast. It does not find a constant value for thrust level. Maybe the increment / decrement for changing the thrust level is to high???

2) It's only possible to set the verticle speed in the 3D Cockpit (not in 2D) but I think for this point it woks as designed for this beta release

Ah and one point I noticed even in the last version:
- "Impact point" of Map MFD does not takes evaluation level into account (Maybe this is more a feature than a bug and there are other priorities first)

One suggestion:
Can the method "OAPIFUNC void oapiGetBaseEquPos (OBJHANDLE hBase, double *lng, double *lat, double *rad=0)"
fill *rad with the value of the evaluation level of the base location?

However, great new release thank you Martin!

---------- Post added 26-09-15 at 04:22 ---------- Previous post was 25-09-15 at 21:27 ----------

I just tested the new api function "oapiSurfaceElevation" and

:hmm:
hmmm... that seems familiar to me to a very old game...