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

[Anroalh12]

I've installed d3d9beta17f for orbiter 2016 but when I select D3D9 in modules tab nothing happens. I can't see the video tab

 

[Ripley]

Why don't you try the latest?
http://www.orbiter-forum.com/showthread.php?p=531002&postcount=175

 

[Anroalh12]

Why don't you try the latest?
http://www.orbiter-forum.com/showthread.php?p=531002&postcount=175

Thank you very much!!

 

[indy91]

I have a question about Orbiter 2016 and I hope this is the appropriate place to ask it.

Does Orbiter 2016 accurately model the Earth as an oblate spheroid and if yes, is the atmosphere modeled to fit the spheroid? I am asking about the shape here, not the gravitational model.

While working on the Virtual AGC for NASSP we have noticed that multiple programs have trouble with the spherical Earth in Orbiter 2010. For example, the program 22 of the AGC is used to track a landmark on Earth. As an input the program wants geocentric latitude, longitude and altitude above the Fischer ellipsoid. The AGC then calculates the position vector of the landmark from these inputs. For a landmark on the Earth, we kind of have to trick the AGC to make it work. The longitude is fine, but latitude and altitude have to be adjusted so the AGC finds the correct position of the landmark on the spherical Earth. In NASSP we have set the radius of the spherical Earth to the radius at Cape Canaveral.

Similarly the entry interface is defined as 400k ft altitude above the Earth. Again, the spherical vs. ellipsoid Earth is relevant in some calculations the AGC does. The AGC actually has a program to calculate midcourse corrections itself. For low latitudes at entry interface, where the radius difference is more pronounced, the maneuvers the AGC is calculating become increasingly inaccurate.

I have set a Delta Glider at different points on the Earth on oceans and the radius always seemed to be identical. So if despite the awesome terrain models in Orbiter 2016 the average shape of the Earth is still not an oblate spheroid, consider this a feature request. :thumbup:

 

[SolarLiner]

I notice there are camera animations in the new welcome scenario, how was that done? I tried opening the playback editor but have been unable to find any new event type.
Also, if you stop the playback halfway through, those camera animations keep playing anyway.

 

[Weirdo Earthtorch]

I notice there are camera animations in the new welcome scenario, how was that done? I tried opening the playback editor but have been unable to find any new event type.
Also, if you stop the playback halfway through, those camera animations keep playing anyway.

http://orbiter-forum.com/showthread.php?p=528731&postcount=100

 

[T1234]

Is it possible to have just the highest earth res texture with the low res elev,if so, what download is it and is the EarthLo level 11?

 

[vinny5000]

Hi, guys!

I have the orbiter beta which is released on February 16th I believe, I read the textures pack installation instructions but I don't see textures>planets in the orbiter beta directory. Any suggestions? Thanks!

Cheers,
Vincent

 

[jroly]

Should be like...
D:\orbiter_beta\Textures\Earth
D:\orbiter_beta\Textures\Mars
...etc

 

[vinny5000]

Hi, Jroly!

The textures are working now! Thanks!

Cheers,
Vincent

 

[JMW]

Not Recognizing Pad Occupied

"SOLVED"
Well not diagnosed but....
Scenario from r.54 works in r.55, but scenario in r.55 doesn't work in r.54....
Be interested to see what result you have with scenario attached and where.
BUT DON'T WASTE ANY TIME ON IT DOC. PLEASE

Beta rev55.
Why does the "pad occupied" flag not come up?
The craft is definitely Inactive (Landed) according to Scenario Editor, but nothing shows against pad in Info tab - Object = Base......
Code that worked pre Beta to detect occupation does not function either (understandably) which is annoying.

Scenario attached is at Cape Canaveral base.
Someone please try it on their set-up to see if you get the same result.

Please Doc, if this could be solved pre release it would be great!

 

[GLS]

I'm not sure if this is a bug report or a "request" so I'm just going to put it here.
If a scenario starts with the distance to the vessel under whatever minimum value the new Orbiter now imposes, one cannot move the view back, i.e. the camera gets stuck at the current distance.

---------- Post added at 01:36 AM ---------- Previous post was at 01:20 AM ----------

And another thing, looks like the MAKEGROUPARRAY points for attachments aren't being updated in the first time step. This is reproducible with Atlantis by grappling something, exiting, and on a new run the attached object will be in the position it would be if the arm was stowed (and the arm is correctly in the saved position). (Starting the sim paused shows the issue better.)

 

[jarmonik]

If a scenario starts with the distance to the vessel under whatever minimum value the new Orbiter now imposes, one cannot move the view back, i.e. the camera gets stuck at the current distance.

Yes, I have noticed that too. Also, some vessels seems to have a problem not being able to move the camera close to a vessel. It's likely intended that the camera can't be moved inside a vessel's "radius".

---------- Post added at 04:32 ---------- Previous post was at 04:25 ----------

[/COLOR]And another thing, looks like the MAKEGROUPARRAY points for attachments aren't being updated in the first time step. This is reproducible with Atlantis by grappling something, exiting, and on a new run the attached object will be in the position it would be if the arm was stowed (and the arm is correctly in the saved position). (Starting the sim paused shows the issue better.)

I was investigating that problem a while ago and noticed that Atlantis implementation is very sensitive about the calling sequence of some callbacks. If clbkUpdate() is called twice before a visual is created it wont work anymore. Must be called only once, no less, no more, due to a tricky use of booleans that controls the initialization.

 

[GLS]

It's likely intended that the camera can't be moved inside a vessel's "radius".

Yes, but if the scenario file has a value under that, the camera gets stuck.

I was investigating that problem a while ago and noticed that Atlantis implementation is very sensitive about the calling sequence of some callbacks. If clbkUpdate() is called twice before a visual is created it wont work anymore. Must be called only once, no less, no more, due to a tricky use of booleans that controls the initialization.

When you say "clbkUpdate()" do you mean the SetAnimation() function?

 

[jarmonik]

When you say "clbkUpdate()" do you mean the SetAnimation() function?

Sorry, I mean the clbkPreStep(). I think the problem is related to this code section.

if (arm_moved) {
	SetAttachmentParams (rms_attach, arm_tip[0], arm_tip[1]-arm_tip[0], arm_tip[2]-arm_tip[0]);
	arm_moved = false;
}
if (arm_scheduled) {
	arm_scheduled = false;
	arm_moved = true;
}

which makes the operation call sequence critical.

EDIT: When "Start Paused" is checked it's likely that clbkPreStep is never called until un-paused.

 

[GLS]

Sorry, I mean the clbkPreStep(). I think the problem is related to this code section.

if (arm_moved) {
	SetAttachmentParams (rms_attach, arm_tip[0], arm_tip[1]-arm_tip[0], arm_tip[2]-arm_tip[0]);
	arm_moved = false;
}
if (arm_scheduled) {
	arm_scheduled = false;
	arm_moved = true;
}

which makes the operation call sequence critical.

EDIT: When "Start Paused" is checked it's likely that clbkPreStep is never called until un-paused.

In SSU (and I'm sure all other vessels), both the clbkPreStep() and the clbkPostStep() are called once before the first frame shows up.
Currently (2010 edition), in one of several such "animation/attachment systems", a call is done to SetAnimation() from clbkPostCreation() right after the animations are created, already using the scenario file state values. Then clbkPreStep() runs, and nothing is done in there as the points haven't been updated yet. Between that and clbkPostStep() the update is done, and is there that in the first run we put a SetAttachmentParams() call to set the attachment to the updated points. Then the first frame shows up.
In Orbiter 2016 the points aren't updated between the first clbkPreStep() and clbkPostStep() functions, so when the first frame shows up the attachment is still in the default coordinates. Only between the first and second frames is the update made.

 

[jarmonik]

Without start paused calling sequence is:

000000.000: Atlantis::clbkPostCreation
000000.000: Finished initialising panels
000000.000: Atlantis::clbkPreStep
000000.010: Atlantis::clbkVisualCreated
000000.010: Atlantis::clbkPreStep
000000.020: Atlantis::clbkPreStep
000000.030: Atlantis::clbkPreStep

With start paused enable calling sequence is:

000000.000: Atlantis::clbkPostCreation
000000.000: Finished initialising panels
000000.000: Atlantis::clbkPreStep
000000.010: Atlantis::clbkVisualCreated
- End of Log -

Also, the grapple target displacement problem seems to occur with both 2010-P1 and latest Beta when start paused is selected due to missing 2nd call to clbkPreStep() that initializes the grapple target.

Calling:

SetAttachmentParams (rms_attach, arm_tip[0], arm_tip[1]-arm_tip[0], arm_tip[2]-arm_tip[0]);

from clbkVisualCreated() seems to fix the issue.

 

[GLS]

Yeah, I can confirm that the points are updated between clbkPostStep() and clbkVisualCreated(), but I'd still like to hear from the man himself about this change from the 2010 version, is it intended or a bug?
About this problem occurring in the default Atlantis in 2010 I can't comment as I didn't check there.

 

[Nicholas Kang]

Hello Ladies and Gentlemen,

I am wanted to play Orbiter Beta just now but after downloading the required low-resolution texture files and files from SVN. I found out that the SLF runway is missing while running my simulator. Also, my GL-NT front wheel appears to be missing when landed at the Brighton Beach base. That is not important to me, though, after I chenge my view angle, it reappears. The most critical part is the missing SLF and also the area around it that looks too blur compared with the VAB. Perhaps I downloaded the low-resolution textures.

That doesn't bother me. But without a runway, how can I land my vessels?

Maybe you need to look at this:

**** Orbiter.log
000000.000: Build Apr 12 2016 [v.160412]
000000.000: Timer precision: 6.98413e-008 sec
000000.000: Found 0 joystick(s)
000000.000: Devices enumerated: 6
000000.000: Devices accepted: 5
000000.000: [ ] RGB Emulation (SW)
000000.000: [ ] Direct3D HAL (HW)
000000.000: [x] Direct3D T&L HAL (HW)
000000.000: [ ] Direct3D HAL (AMD Radeon HD 6520G) (HW)
000000.000: [x] Direct3D T&L HAL (AMD Radeon HD 6520G) (HW)
000000.000: Module AtlantisConfig.dll .... [Build 150906, API 150906]
000000.000: Module AtmConfig.dll ......... [Build 150906, API 150906]
000000.000: Module DGConfigurator.dll .... [Build 150906, API 150906]
000000.000:
000000.000: **** Creating simulation session
000000.000: DirectDraw interface OK
000000.000: Direct3D interface OK
000000.000: Graphics: Viewport: Fullscreen 1366 x 768 x 32
000000.000: Graphics: Hardware T&L capability: Yes
000000.000: Graphics: Z-buffer depth: 32 bit
000000.000: Graphics: Active lights supported: 8
000000.000: Loading 15382 records from star database
000000.000: Module Sun.dll ............... [Build 150906, API 150906]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
000000.000: Module Mercury.dll ........... [Build 150906, API 150906]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
000000.000: Module Venus.dll ............. [Build 150906, API 150906]
000000.000: Module VenusAtm2006.dll ...... [Build 150906, API 150906]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
000000.000: Module Earth.dll ............. [Build 150906, API 150906]
000000.000: Module EarthAtmJ71G.dll ...... [Build 150906, API 150906]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
000000.000: Module Moon.dll .............. [Build 150906, API 150906]
ELP82: Precision 1e-005, Terms 116/829
000000.000: Module Mars.dll .............. [Build 150906, API 150906]
000000.000: Module MarsAtm2006.dll ....... [Build 150906, API 150906]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
000000.000: Module Phobos.dll ............ [Build ******, API 060425]
000000.000: Module Deimos.dll ............ [Build ******, API 060425]
000000.000: Module Galsat.dll ............ [Build 150906, API 150906]
000000.000: Module Jupiter.dll ........... [Build 150906, API 150906]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
000000.000: Module Io.dll ................ [Build 150906, API 150906]
000000.000: Module Europa.dll ............ [Build 150906, API 150906]
000000.000: Module Ganymede.dll .......... [Build 150906, API 150906]
000000.000: Module Callisto.dll .......... [Build 150906, API 150906]
000000.000: Module Satsat.dll ............ [Build 150906, API 150906]
000000.000: Module Saturn.dll ............ [Build 150906, API 150906]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
000000.000: Module Mimas.dll ............. [Build 150906, API 150906]
SATSAT Mimas: Terms 113
000000.000: Module Enceladus.dll ......... [Build 150906, API 150906]
SATSAT Enceladus: Terms 33
000000.000: Module Tethys.dll ............ [Build 150906, API 150906]
SATSAT Tethys: Terms 101
000000.000: Module Dione.dll ............. [Build 150906, API 150906]
SATSAT Dione: Terms 59
000000.000: Module Rhea.dll .............. [Build 150906, API 150906]
SATSAT Rhea: Terms 68
000000.000: Module Titan.dll ............. [Build 150906, API 150906]
SATSAT Titan: Terms 100
000000.000: Module Iapetus.dll ........... [Build 150906, API 150906]
SATSAT Iapetus: Terms 605
000000.000: Module Uranus.dll ............ [Build 150906, API 150906]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
000000.000: Module Miranda.dll ........... [Build ******, API 060425]
000000.000: Module Ariel.dll ............. [Build ******, API 060425]
000000.000: Module Umbriel.dll ........... [Build ******, API 060425]
000000.000: Module Titania.dll ........... [Build ******, API 060425]
000000.000: Module Oberon.dll ............ [Build ******, API 060425]
000000.000: Module Neptune.dll ........... [Build 150906, API 150906]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
000000.000: Finished initialising world
000000.000: Module ShuttlePB.dll ......... [Build 160412, API 160412]
000000.000: Module DeltaGlider.dll ....... [Build 160412, API 160412]
000000.000: Module LuaInline.dll ......... [Build 160412, API 160412]
000000.000: Module ShuttleA.dll .......... [Build 160412, API 160412]
000000.000: Finished initialising status
000000.000: Finished initialising camera
000000.000: Finished setting up render state
000000.000: Finished initialising panels
000177.585: ---------------------------------------------------------------
000177.585: >>> WARNING: Obsolete API function used: oapiTriggerRedrawArea
000177.585: Replaced by VESSEL::TriggerRedrawArea
000177.585: ---------------------------------------------------------------
000303.699: **** Closing simulation session

I think the problem is with the warning part. I checked my downloaded SVN "texture" folder and I can still find the runway texture in the Runway1 and Runway2 files. Why couldn't the SLF be displayed properly then?

Thanks for helping.

Regards,

Nicholas.

 

[jedidia]

Also, my GL-NT front wheel appears to be missing when landed at the Brighton Beach base.

Yeah, there's some clipping problems with the terrain still, I noticed that on several occasions.