XR2 Public Release Candidate Testing

[dbeachy1]

When you open the consumables hatches, it takes a couple seconds to connect and pressurize the lines after the hatch opens. When you close them, everything is immediate. How about adding a reverse process where when you close the hatches, the pressure bleeds down, there's a short wait, then the the hatch closes?

That would be possible to implement, but it would require a fair amount of work due to how the fuel and LOX hatches work. The reason they "snap" open and closed is because when the pilot moves the ship via the engines with refueling lines engaged they have to instantly disconnect and the hatches snap shut. If the resupply hatches would open and close slowly I would have to add two more damage subsystems and warning lights, add warning callouts for them, and add door motion indicators like the door indicators on the upper panel.

I suppose I could take a short cut and just not implement a damage subsystem/warning light/warning callout for the hatches and then force the hatches to close normally when the pilot moves the ship. However, I would still have to add a door indicator for each hatch and that would require reshuffling the lower panel components to make room. So while it would be possible to do, it would be a lot of work for what is basically a minor eye candy feature. The first two XR vessels did not have visible resupply hatches, and that's why support for that was not added in the beginning. However, I will add a note to revisit this for the XR2 Mk II release -- I don't want to hold the Mk I any more than I have to.

Steve, Any way to have more detailed textures of the payload bay? It would be nice to have a more RL wall texture when viewed through the bay camera.

Man, you guys are a tough group. I think the Ravenstar textures, including the bay textures, are some of the best I've ever seen -- they look RL to me.

 

[Travis Reed]

Can we please see an in simulation screenie? I have been dying for the release of this one....

There's plenty of in game shots in other thread, and one or two more in here.

if i've the time i'll try and make a small gallery later.

I may be mistaken, but I think he may be requesting more up to date screenshots, and possibly those we haven't seen (such as for the 2D panel).

A gallery would be nice though.

 

[yagni01]

That would be possible to implement, but it would require a fair amount of work due to how the fuel and LOX hatches work. The reason they "snap" open and closed is because when the pilot moves the ship via the engines with refueling lines engaged they have to instantly disconnect and the hatches snap shut. If the resupply hatches would open and close slowly I would have to add two more damage subsystems and warning lights, add warning callouts for them, and add door motion indicators like the door indicators on the upper panel.

Sorry, I guess I didn't use the right terms. Its not the door animation or a motion indicator I was describing, but the operation of 'the system' when the switches are pressed. When pressing the switch to open the (lets say) fuel hatch, the following occurs (minus the door graphic):
Hatch annunciator illuminates
After a couple seconds delay (presumably for supply line connection), the line pressures begin to rise
The pressure annunciators illuminate when there is sufficient pressure to transfer fuel.
Pilot can then open the appropriate drain/fill valve and transfer occurs.

But, when the pilot presses the switch to close the hatch, all annunciators/gauges immediately go to zero/closed/off. Boom. Done.

What I was wondering is if there could be a similar 'system presentation' for closing as there is for opening. For example, when the pilot closes the fuel hatch. . .
Fill valve closes (if open)
Pressure bleeds off, turning off the pressure annunciator when it goes lower than the 'ready to transfer' pressure. This would occur more quickly as if a QD occurs, just not be intantaneous.
A delay as lines are stowed (or whatever the initial 5sec delay is for when opening)
Hatch annunciator goes out (and hatch is closed)

EDIT: deleted undocking scenario.

I other words, making the shutdown (via switch) of the transfer system appear (from inside the cockpit) as complex as its initiation. That was the thought.


-----Posted Added-----

mate, those are rl textures.. they're snagged from some shuttle bay photos. i'm not quite done with them, but they'll do for now... they're plenty detailed aren't they? only way to make them more detailed would be to increase the texture res, is that what you mean?

Correct. I know they're from photos, but you set the bar pretty high, mate. I think they look fuzzier than the rest of the ship, but if its a choice between that and the VC, its just fine

 

[dbeachy1]

In other words, making the shutdown of the transfer system appear as complex as its initiation. That was the thought.

I agree it's a worthwhile enhancement. The reason the hatch "snaps shut" is because there is currently no warning light/damage modeling/warning callouts for the resupplly hatches, so I either have to close them automatically as happens now or make them fully damageable subsystems. So I still need to have an "instant disconnect/hatch close" for the Mk I release, but what I can do for now is make the pressure decrease rapidly when the lines disconnect rather than returning to zero instantly. That way the disconnect pressure sequence it will be similar to the line connection pressure sequence, but I won't have to write a lot of additional code for the Mk I release. This enhancement will be in the upcoming Beta-1c.

Right now I am hard at work on adding turbopack support to the lower instrument panel, and once that is done I'll add the disconnect pressure enhancement and then release Beta-1c to the XR2 team. Barring anything unexpected Beta-1c should be ready in a few days.

 

[yagni01]

I agree it's a worthwhile enhancement. The reason the hatch "snaps shut" is because there is currently no warning light/damage modeling/warning callouts for the resupplly hatches, so I either have to close them automatically as happens now or make them fully damageable subsystems. So I still need to have an "instant disconnect/hatch close" for the Mk I release, but what I can do for now is make the pressure decrease rapidly when the lines disconnect rather than returning to zero instantly. That way the disconnect pressure sequence it will be similar to the line connection pressure sequence, but I won't have to write a lot of additional code for the Mk I release. This enhancement will be in the upcoming Beta-1c.

Right. It was the pressure sequence and delay before the hatch annunciator goes out that I meant. Cool.

 

[James.Denholm]

so I actually prefer the XR implementation of bailout, despite having to manually toggle the chute auto-deploy.

Wait... there's a bail out feature? :huh:

 

[SlyCoopersButt]

Not exactly a feature. Just a thing you do.

You'll probably be able to bail out of the XR2 much like you would the XR5. All you need to do is dump all fuel in lower altitude and lower speed and set trim to maximum and open the docking port and EVA everyone out the door. That's how I'd escape the shuttle in real life if I were in that situation when landing isn't possible.

 

[dbeachy1]

To clarify, to "bail out" you simply EVA while in flight in an atmosphere and each each astronaut's parachute will auto-deploy. This enhancement is in the Ravenstar and will be in the next XR1 and XR5 versions as well since they share common code.

 

[C3PO]

If you tick the 'Play radio sound and attitude mode change also in external view' the aircond.wav doesn't fade with distance.
Try zooming way out in external view, and you will hear aircond.wav at constant amplitude. The default DG doesn't play this sound in external view.

 

[James.Denholm]

To clarify, to "bail out" you simply EVA while in flight in an atmosphere and each each astronaut's parachute will auto-deploy. This enhancement is in the Ravenstar and will be in the next XR1 and XR5 versions as well since they share common code.

Oh. Ok then! Thanks.

 

[dbeachy1]

If you tick the 'Play radio sound and attitude mode change also in external view' the aircond.wav doesn't fade with distance.
Try zooming way out in external view, and you will hear aircond.wav at constant amplitude. The default DG doesn't play this sound in external view.

Hmm...that is odd, because XR vessels do not play or manage the air conditioning sound -- it is all handled by OrbiterSound. It may be a bug in OrbiterSound that only occurs when new sounds are loaded into sound slots, which is something that most vessels don't do.

 

[Chas]

XR2 beta 1B Visual error?

This visual mixup has now happened 3 times in the past 3 or 4 days of intensive testing. See attachment "Screenshot1".
The tyres appear to roll upwards into the hull whilst the wheel struts remain in place. This has happened only during landing (at touch down), on Mars and the Moon.
Alt-F4 to launchpad and reloading the "(Current state).scn" seems to clear it. See the second screenshot. It seems a bit like the inverted nose cone graphics problem on Dan Stephs DGIII sometime ago.

It is hard to replicate using a clean Orbiter install, or any installation of Orbiter, as it is quite a rare occurence. I finally grabbed the screenshots because I believe a similar problem may have been reported here earlier.
It does seem a purely visual problem as the XR2 still functions OK with the tyres misplaced. I took off and flew around with them as such. Retracting and then re-extending gear did not clear it. I even landed on the struts with the wheels up in the hull.

What gets me is that I have landed dozens of times without this occuring, and then suddenly it will just happen. i hope someone else can confirm this from the screenshots.

Also on a menial and petty level...

In the included XR2 scenarios Mir is not set up correctly and does not show up with the F3 switch vessel menu, or the scenario editor.The following is from the "Docked at ISS" scenario

Mir
STATUS Orbiting Earth
RPOS -396621.04 -407208.67 -6643320.57
RVEL 7718.419 66.383 -453.100
AROT 179.61 -76.53 -72.43
VROT -0.08 -0.01 -0.00
IDS 0:540 100 1:542 100 2:544 100
XPDR 482
END

And finally, in the XR2RavenstarPrefs.cfg file the LOX loadout section refers to a "full crew" of 5 not 14.

I apologise if I appear petty in bringing some of these matters to notice, and would like to add that in every other respect the XR2 Beta 1B has gone thru some punishing testing and has proved itself superbly.

 

[Coolhand]

I can confirm the nosewheel problem actually, only seen it once and it was also a lunar scenario.

 

[adamb193]

I can confirm the nosewheel problem actually, only seen it once and it was also a lunar scenario.

AHHH!!! see not even an advanced craft like this can land on the moon, let's see how NASA explains this!

 

[dbeachy1]

This visual mixup has now happened 3 times in the past 3 or 4 days of intensive testing. See attachment "Screenshot1".
The tyres appear to roll upwards into the hull whilst the wheel struts remain in place. This has happened only during landing (at touch down), on Mars and the Moon.
Alt-F4 to launchpad and reloading the "(Current state).scn" seems to clear it. See the second screenshot. It seems a bit like the inverted nose cone graphics problem on Dan Stephs DGIII sometime ago.

That's really odd. I have never seen "intermittent" animation problems before -- animation should either "work" or "not work." Have you ever duplicated it in a clean installation? I have seen buggy third-party add-ons cause odd visual glitches when they corrupt Orbiter's memory heap. Do you have any other add-ons installed? Are you and Coolhand running Orulex?

In the included XR2 scenarios Mir is not set up correctly and does not show up with the F3 switch vessel menu, or the scenario editor.

Actually, Mir does not appear in the F3 vessel menu for any other scenarios either, even in a completely clean Orbiter installation. The reason is that Mir's configuration file contains this line:

EnableFocus = FALSE

That prevents Mir from appearing in the F3 vessel switch menu. Since that config file is included with Orbiter's core package, it's a bug in Mir's config file.

And finally, in the XR2RavenstarPrefs.cfg file the LOX loadout section refers to a "full crew" of 5 not 14.

That's a great catch! The LOX loadout comments are also incorrect; this will be fixed for the next Beta.

I apologise if I appear petty in bringing some of these matters to notice, and would like to add that in every other respect the XR2 Beta 1B has gone thru some punishing testing and has proved itself superbly.

No worries, I want the ship to be as polished as we can make it.

 

[James.Denholm]

...it's a bug in Mir's config file.

A bug, or is it really a feature? Surely it's in there on purpose.

 

[Chas]

XR2 gear graphics

I can confirm the nosewheel problem actually, only seen it once and it was also a lunar scenario.

Snapped it again. See screenshot.
The rear wheels are affected too. The nose wheel strut is also just visible to the far left on the image.
The scenario running had only the XR2 and two Ummu crewmembers EVA'ing on the lunar surface. I had Level 9 moon textures installed.

I have not had it happen in a completely clean Orbiter install, but the version I am testing is virtually clean. Orulex is not installed.

I use the ESS_station by Sirius Fett for orbital rendezvous and Ummu testing but this was not present in the scenario that produced the screenshot.
Apart from AeroBrake, IMFD 5.1 and Launch MFD, all installed, but not activated, this is just about a clear install of Orbiter.

I will try some further testing with a completely clean installation. It is the elusiveness of this problem that makes it both frustrating and yet compelling to try to isolate!

 

[Russ_H]

I use the ESS_station by Sirius Fett for orbital rendezvous and Ummu testing but this was not present in the scenario that produced the screenshot.
Apart from AeroBrake, IMFD 5.1 and Launch MFD, all installed, but not activated, this is just about a clear install of Orbiter.

I have found that this add-on "ESS_station" causes issues with the XR code.

ESS_station is a fantastic add-on I wish it would work with the XR code.
I have landed on the moon at least 50 times with the XR2 and have had no issues with the gear.

Russ

 

[dbeachy1]

Chas, when that occurs and you taxi the ship do the wheels still rotate normally? Also, did it occur exactly on touchdown or were the wheels off-center when you first lowered the gear? The only thing that should cause what you're seeing is if the attachment point of the wheels changes, which the code does not do.

Also, just for testing purposes, can you please fly for a day or two with just a clean install (with no other modules loaded) and see if you can reproduce the problem? That would let us eliminate other add-ons as being involved with the problem. Also, the more details you can give about what the ship is doing when the problem first occurs, the better. I don't have much to go on at this point.

This is a weird one!

EDIT: Good news here, guys -- I was able to reproduce the bug! I am working on it now. Stay tuned...

 

[Chas]

EDIT: Good news here, guys -- I was able to reproduce the bug! I am working on it now. Stay tuned...

Thank you Doug! I was begining to wonder whether this was a figment of my imagination!.

I would not swear on it but I believe that the wheel displacement happens at the moment of touchdown as the strut compression animation happens. I have been so taken back and anxious to grab a screen shot that I have not yet tried taxiing, though I did take off, fly around and land again at one point.

To fill in the details, the XR2 tests involved a flight between two lunar ground bases. Brighton Beach (Default) and a small southern hemisphere lunar base that I have made. It is simply a landing pad (Scale 0,with no landing aids) and a set of beacon arrays forming a square shape. These are in the background of the screenshots.The base has a VOR beacon on 117.35.

The scenario had 2 ummu crewmen on EVA at the second base with about 40% (50minutes) of Oxygen. Mission objective to fly from Brighton to Southern base, pick up the stranded crewmembers, and fly back. I usually get to them with around 7minutes O2 left.

I have flown this mission many times in the XR1 and XR5, and use is as a benchmark test for speed, acceleration, braking and fuel usage. I don't know if it is relevant but during the landing approach I switched focus (F3/Ctrl-F3) from the XR2 to the EVA Ummus repeatedly to check on their status (O2 levels running low)

No Orbiter modules were activated other than Scenario editor and OrbiterSound3.5. ESS_Station was NOT included in the scenario.

I had been using the ESS for some time now in my extensive operations with the XR1 and XR5, having tweaked the .cfg file (MaxFuel = 640000) to add 640tonnes of fuel. I had used it as a crew station and for refuelling around Earth, Moon and Mars.
I was surprised to find a problem with ESS reported (Russ_H) as I had never encountered anything out of the ordinairy with it when used with the XR craft or CTV-ATV 2.1 by Well and No matter (wnm-ctv-atv2.1.zip).
Whilst I will exclude the ESS from all further XR2 testing, I do not feel that I have enough evidence to warrant its removal from my main XR fleet operations. The only other alternative is the UMMU ISS, and I suffer fairly poor framerates during docking manoeuvres when using it.