XR2 Public Release Candidate Testing

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,220
Reaction score
1,568
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
From my initial testing here ESS Station works for me as well.

Now, regarding the wheel animation problem, it is proving quite frustrating. Here is how to reproduce it:

1. Load up a landed scenario and switch to external view.
2. Switch vessels with F3 and then switch back to the XR2.
3. Now the wheels appear offset from the axles. If you blip the throttles to rotate the wheels they rotate around the wrong coordinates.

The key is when Orbiter destroys the XR2 visual and recreates it: it looks like the Orbiter core is applying the transformations to the mesh in a different order or something when recreating the mesh vs. just creating it for the first time. Testing has shown it is related to gear compression: if the gear is fully uncompressed the vessel switch is fine. It may be due to the fact that that the gear is up in the XR2's initial mesh vs. down like with the Vanguard, but I haven't figured it out yet. So far I haven't found a workaround, but I'll work on it some more tonight.
 

Chas

New member
Joined
Jan 5, 2008
Messages
16
Reaction score
0
Points
0
Location
Mitcham,Surrey
XR / ESS

I have just looked at my "ESS_station.Zip" down load file and can confirm that the ESS.CFG file is in the wrong place. It should go into the Config\Vessels folder but actually unzips directly into the Config folder.

I had relocated the ESS.cfg file to its correct place (Config\Vessels) and re-zipped the "ESS_station.zip". It was this corrected version that I have installed into clean Orbiter installs. Sorry about the confusion.

The ESS station does appear to function OK when this modification is performed.
 

Russ_H

Addon Developer
Addon Developer
Joined
Apr 15, 2008
Messages
118
Reaction score
0
Points
0
Location
louisville, Ky
Hi, Chas

I am going to try ESS station one more time. I know this is only an issues that I have but it seems that the more add-on's I have installed the less stable orbiter is.

Thanks for the info
Russ
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,220
Reaction score
1,568
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
I have just looked at my "ESS_station.Zip" down load file and can confirm that the ESS.CFG file is in the wrong place. It should go into the Config\Vessels folder but actually unzips directly into the Config folder.

I had relocated the ESS.cfg file to its correct place (Config\Vessels) and re-zipped the "ESS_station.zip". It was this corrected version that I have installed into clean Orbiter installs. Sorry about the confusion.

The ESS station does appear to function OK when this modification is performed.

That is correct; more details on that in this thread: http://orbiter-forum.com/showthread.php?t=2743
 

Chas

New member
Joined
Jan 5, 2008
Messages
16
Reaction score
0
Points
0
Location
Mitcham,Surrey
XR2 Beta 1B flight testing continues. See screenshot 1 & 2.

A test flight from Brighton to the Cape was set up with just 2 crew on board. I too have grown fond of the pointy bits on my co-pilot Kara.

The objectives were simple. Test out IMFD for the trip home from the Moon, and then AeroBrake in Earth's upper atmosphere using AeroBrakeMFD. As suggested by Travis Reed I had used the Shift-S option to create the ships lift and drag parameter files over several flights within Earth's atmosphere. This is called "XR2Ravenstar.ld" and is written to the Orbiter "Modules\Plugin" directory by AeroBrakeMFD.

The flight was pleasantly uneventful. Take off to Orbit was swift and effortless and I was soon in a stable circular orbit.

IMFD set to "Course/Planet Approach" with Source Moon, Ref Earth and a PeA of 61k...Was this a bit low ? IMFD "orbit eject" page slaved to "Course" and set to off axis. IMFD did its magic and a Lunar orbit eject Autoburn was performed flawlessly. I was heading home with some 61% fuel left in the XR2.

IMFD5.1m is very accurate and as I left the Moon's SOI and reset the IMFD source to Self the map page showed my PeA to be around 80k.. Pretty close!
I used the RCS linear thrusters to tweak this down to about 61k.
On entering Earth's SOI I tweaked again to get the Pea to 61k and prepared for my encounter with the Earth's atmosphere.

I had flown this flight in the XR1 and XR5, and know from experience that the first aerobraking encounter slows you down enough to be captured into Earth's orbit. Subsequent Aerobraking manoeuvres can then bring the ApA right down.

I made sure that the XR2 configuration was cleaned up for the fiery encounter, and was a bit alarmed at the near vertical spike displayed on AeroBrakeMFD's temp page. Still it also said I would experience no more than 1.8g.

With the lowest point of 61km approaching, and at an AoA of around 42deg I watched as the heat built up on the nosecone to about 1800c and my path curved around Earth and finally captured into orbit. AeroBrakeMFD had been accurate. The heat build up had been very quick, as predicted and displayed, but well within operating tolerances.

I looped back out into space to an ApA of around 12000km (I think) and at ApA I tweaked the PeA down to 59.5k for the second Aeroraking manoeuvre. The AeroBrake display showed the same near vertical spike, and the G prediction was again around 1.8. I sat back as my altitude fell and the hull temperature rose rapidly. I could hear the roar outside and switched to the external view to see my hull glowing an eerie orange at around 1900c.
See screenshot3.

The temp rose for some 90 seconds, 2000,2100, er..I was getting worried.2200,2300. This was uncomfortable as the heat spike on Aerobrake's display showed that I had not reached the moment of peak temperature. 2400, 2500. I was squirming anxiously. 2600, 2700, 2800 ! I had never seen such temperatures in the XR1 or XR5 and survived!

I sat there white knuckled, helpless and horrified, even Kara looked worried!
I swear that for a few seconds the nosecone read 2900c. The Nose and leading edges were glowing white hot. See screenshot4

The Ravenstar pulled through, and soon the temp fell as I looped back out to a greatly reduced ApA. I still have to stabilise the orbit and align for re-entry and landing at the Cape, but will probably use the engines to do this as I am going to have to dump fuel before re-entry anyway.

The XR1 and XR5 manuals state that the max temp for the nose cone is 2840c, and assuming that the XR2 has similar tolerances, I feel this test flight was very lucky not to have ended tragically, and that the survival of the crew was solely down to the sturdiness and reliability of the XR2 design.

Once again Altea aerospace delivers a winner!
 

Attachments

  • XR2-01.jpg
    XR2-01.jpg
    281.4 KB · Views: 80
  • XR2-02.jpg
    XR2-02.jpg
    697.4 KB · Views: 74
  • XR2-03.jpg
    XR2-03.jpg
    255.7 KB · Views: 63
  • XR2-04.jpg
    XR2-04.jpg
    260.6 KB · Views: 80

C3PO

Addon Developer
Addon Developer
Donator
Joined
Feb 11, 2008
Messages
2,605
Reaction score
17
Points
53
Oh! I almost forgot.
The heateffect.dds in Beta 1b is only in 128 colours. Is that intentional?
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,220
Reaction score
1,568
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
The nosecone absolute temperature limit is indeed 2840 C on the Raventar as well -- I'd say you were pretty lucky to have made it! :)

Seriously, though, do you guys think the new heating rate is about right, or does it heat up too fast? The heating algorithm was tweaked in the last Beta. The new algorithm will also be in the next XR1 and XR5 versions.
 

markl316

XR2 Ravenstar Commander
Addon Developer
Tutorial Publisher
Joined
Mar 30, 2008
Messages
450
Reaction score
1
Points
18
Seriously, though, do you guys think the new heating rate is about right, or does it heat up too fast? The heating algorithm was tweaked in the last Beta. The new algorithm will also be in the next XR1 and XR5 versions.

I never exceed 1200 degrees on the XR1 or XR5, so however you tweaked it, it's probably fine. Actually, I'd rather it heat up faster for a more challenging reentry. :cheers:
 

Arrowstar

Probenaut
Addon Developer
Joined
May 23, 2008
Messages
1,785
Reaction score
0
Points
36
I can't believe you survived at those temperatures? The hull temp C/W must have been going off like mad. Nice piloting work!

Thanks for the screenies, too. It makes those of us who have to watch the Beta from the sidelines look forward that much more! :)
 

Karpador

New member
Joined
Jul 29, 2008
Messages
7
Reaction score
0
Points
0
This is exactly happened to me on mars when we determined it was syncing frame rates.
 

Arrowstar

Probenaut
Addon Developer
Joined
May 23, 2008
Messages
1,785
Reaction score
0
Points
36
The nosecone absolute temperature limit is indeed 2840 C on the Raventar as well -- I'd say you were pretty lucky to have made it!

I assume the fuzzy logic that I recall being part of the code base for this aspect of flight has been implemented in the XR2? If so, out of curiosity... what was the probability that the XR2 should have blown up at that point? :p
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,220
Reaction score
1,568
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
Yes, there is fuzzy logic. The probability depends on several factors; here is an explanation from page 42 of the Vanguard Flight Manual:

If you exceed the maximum safe temperature on one or more of your hull surfaces the hull begins to weaken and will fail, on average, within about eight seconds if hull temperatures are not reduced below maximum. Note that the higher you are overtemp the faster the hull will (on average) fail, and overheating more than one surface will increase the chances of hull failure proportionally.

Note: It is theoretically possible to breach the hull anytime you are over-temp -- there is no hard-coded "minimum time" or “maximum time.” Typically you will have about eight seconds if you are right on the threshold and only have one surface that is over-temp; however, the average time-to-breach will be lower if you are significantly over-temp (percentage-wise) for a given surface. Also, the more surfaces you have over-temp the more likely that one of them will breach. For example, if you have four surfaces over-temp instead of just one your odds of a breach will be four times higher than if only one surface is over-temp (assuming each surface is percentage-wise equally over-temp). Furthermore, 200 degrees C over-temp on the wings is only 8.4% over maximum, but 200 degrees C over-temp on the cockpit is 13.4% over maximum. The more you are over-temp on a surface, the higher your odds of a hull breach on that surface: being just slightly over-temp is
less likely to cause a hull breach, but it is still possible at any time when you are over-temp.
 

to be

Member
Joined
Mar 15, 2008
Messages
156
Reaction score
0
Points
16
For example, if you have four surfaces over-temp instead of just one your odds of a breach will be four times higher than if only one surface is over-temp (assuming each surface is percentage-wise equally over-temp).
I am going to have to disagree with that, because that would mean that if there were a 30% chance of a hull breach on each surface, and 4 surfaces were over-temp, you would have a 120% chance of hull breach. :blink: Really you have a 70% of there being no hull breach on each surface, and logically every surface must not breach, so that is .7^4, or 0.24: 24%. That means in that situation instead of a 120% chance, really you would have a 76% chance of hull breach.
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,220
Reaction score
1,568
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
I am going to have to disagree with that, because that would mean that if there were a 30% chance of a hull breach on each surface, and 4 surfaces were over-temp, you would have a 120% chance of hull breach. :blink: Really you have a 70% of there being no hull breach on each surface, and logically every surface must not breach, so that is .7^4, or 0.24: 24%. That means in that situation instead of a 120% chance, really you would have a 76% chance of hull breach.

Maybe we're talking about semantics here -- let me explain with an example: the odds of a hull breach are not "added together" in the code: each surface is computed individually and they have nothing to do with each other. For the sake of an easy example, let's say each surface has a 33.3% (1 in 3, or 2 in 6) chance of breaching in this timestep (say, one second). Now take a standard six-sided die and roll it: if you roll a 1 or 2, that surface breaches; otherwise, the surface is OK until the next timestep. Now repeat that for each surface that is over-temp. The odds go up with each over-temp surface, but each individual surface only has a 33.3% chance of breaching regardless of how many dice you roll. However, the more dice you roll the higher the odds that at least one die will be a 1 or a 2, but just because you roll four dice does not guarantee that at least one will be a 1 or 2. Also, the longer you keep rolling the dice (i.e., the longer you are over-temp) the higher the odds that at least one die will be a 1 or 2. But there is still no hard guarantee that "after X number of tries rolling Y number of dice a 1 or 2 will come up."

Maybe I should phrase it, "...you will have four times as many chances to hull breach as if only one surface was over-temp..."

----

Now, on to other matters: Guys, Beta-1c is a go! Changes include:

* Added Steve's new exhaust textures (replaced main/hover/RCS textures).

* Added code to manually play Steve's new main/retro/hover/RCS engine sounds. These may be enabled/disabled via the config file:
Code:
#--------------------------------------------------------------------------
# Enable or disable custom main, hover, and RCS sounds.  
#
# Note: 'EnableCustomMainEngineSound' includes retro engine sound as well.
#
#   0 = custom sound disabled (Orbiter default sound will play instead)
#   1 = custom sound enabled (default)
#--------------------------------------------------------------------------
EnableCustomMainEngineSound=1
EnableCustomHoverEngineSound=1
EnableCustomRCSSound=1
* Added 12 new skins from Steve; there are scenarios for each optional skin in the "XR2 Ravenstar\Skin Demos" subdirectory. Skins included:
Code:
Angel
Blue
BlueRaven
Gold
GoldRaven
Prototype
RedRaven
SilverRaven
Stealth
White
YellowRaven

* Added Steve's new Altea Aerospace logo to 2D panels.

* Added MAIN/RCS/SCRAM/LOX dump exhaust stream animation. [Steve's request]

* Added keyboard shortcuts for engine gimbaling: [Steve's request]
Code:
ALT-P  = gimbal up   (nose up)
ALT-L = gimbal right (nose left)
ALT-; = gimbal down  (nose down)
ALT=' = gimbal left  (nose right)
ALT-0 = recenter

* Increased aileron response by another 20%. [Steve's request]

* Added code to prevent docking when nosecone is closed. [Thanks to Tschachim for the idea on how to work around the Orbiter core problem.]

* Fixed/moved airbrake and wheel brake status messages on VC HUDs.

* Added code to automatically vary the Vr and V1 takeoff callouts based on ship and payload mass.

* Tweaked the contrail emissions to work better with Steve's new exhaust textures.

* Integrated Steve's new XR2 turbopack meshes.

* Added turbopack support to the ship (minus an animated hatch -- that may be in the Mk II later). To deploy or stow a turbopack, use the new Turbopack screen on the lower panel. Note that both the nosecone and outer airlock door must be open to deploy or stow a turbopack.

* Added coded to make the external pressure lines decrease gradually (but rapidly) when lines disconnect vs. just dropping to zero instantly. [Yagni01's request] Note that the green pressure light goes out instantly when the line disconnects; this is by design, since the light only shows green when fuel/LOX can actually flow.

* Fixed LOX comment block in the config file. [Chas]

* Fixed small animation glitch on the upper port elevon surface. [Steve]

* Added code to delete an elevon's mesh if it is ripped off during flight.

* Unfortunately I had to defer gear compression until the Mk II when Steve will rebuild the gear due to an animation problem that only appears when switching vessels while landed. [Thanks to Chas for finding this.] In summary, the gear will have to be changed in the mesh in order for compression to work properly 100% of the time. More details about this were posted earlier in this thread.

* Added code to prevent the APU from engaging auto-shutdown when the pilot switches vessels if the APU is currently engaged by (i.e., required by) the autopilot.

-------------

XR2 Beta Team: please check your inboxes for the download link. The first thing you will want to do is check out the new scenarios demoing Steve's new skins in the XR2 Ravenstar\Skin Demos scenario directory. :speakcool:

Thanks, and have fun!
 
Last edited:

James.Denholm

Addon ponderer
Joined
Feb 8, 2008
Messages
811
Reaction score
0
Points
0
Location
Victoria, Australia
Whoa...

*Is blown backwards by awesomeness*

* Added keyboard shortcuts for engine gimbaling: [Steve's request]
Code:
ALT-P  = gimbal up   (nose up)
ALT-L = gimbal right (nose left)
ALT-; = gimbal down  (nose down)
ALT=' = gimbal left  (nose right)
ALT-0 = recenter

* Added code to prevent docking when nosecone is closed. [Thanks to Tschachim for the idea on how to work around the Orbiter core problem.]

* Added code to automatically vary the Vr and V1 takeoff callouts based on ship and payload mass.

* Added coded to make the external pressure lines decrease gradually (but rapidly) when lines disconnect vs. just dropping to zero instantly. [Yagni01's request] Note that the green pressure light goes out instantly when the line disconnects; this is by design, since the light only shows green when fuel/LOX can actually flow.

* Added code to prevent the APU from engaging auto-shutdown when the pilot switches vessels if the APU is currently engaged by (i.e., required by) the autopilot.

Just curious, will these be added to the XR1 and XR5 in a future update?
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,220
Reaction score
1,568
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
Yes, all the new features you mentioned are also in the XR1 and XR5 -- they all share a common base class, so adding it to the other two ships was "free."

In addition, turbopack support is also now in the XR1 and XR5.
 

Travis Reed

Unstable
Joined
Aug 8, 2008
Messages
68
Reaction score
0
Points
0
Sigh...gonna be a long road to Beta 3 and then public release...

Wish I could go into hibernation until then...

And where's an emoticon for drooling?
 

orwellkid

Addon Developer
Addon Developer
Joined
Apr 10, 2008
Messages
66
Reaction score
0
Points
0
Seriously, though, do you guys think the new heating rate is about right, or does it heat up too fast? The heating algorithm was tweaked in the last Beta. The new algorithm will also be in the next XR1 and XR5 versions.

The heating algorithm seems to be pretty spot on to me. I think you've done an outstanding job.

Can't wait to test out the new Beta... w00t!

_O.K._
 
Top