XR2 Public Release Candidate Testing

[Messierhunter]

However, in the XR2 and the upcoming new versions of the XR1 and XR5 you will be able to bail out and each astronaut's chute will auto-deploy.

I seem to be the only one who thinks this (dev team aside), but if given the choice I prefer a "bailout" option to an unrealistic ejection option. The DG4 won't even allow regular bailouts except at impossibly low speeds, so I actually prefer the XR implementation of bailout, despite having to manually toggle the chute auto-deploy.

We are considering adding a turbopack "access panel" to the exterior of the ship, but that may or may not be implemented: the panel would probably not be reachable from the ground anyway, plus it's basically just eye candy over having the turbopack just deploy next to the ship.

If nothing else it'd be nice to just have a spot on the texture designating the presence of an access panel even if it doesn't open or do anything functionally.

 

[dbeachy1]

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

Don't forget that as of the XR2 (and the next XR1 and XR5 releases) the chutes will auto-deploy when you bail out, so it should be easier now.

Regarding a turbopack hatch, Steve and I still hope to be able to add a real hatch that will open when the pilot flips a switch on the lower panel. Steve and I are looking into it.

Tonight I'll also work on using Steve's new custom-fit turbopack mesh for the turbopacks (normally used by Lee and Kara), although you will also be able to deploy a normal turbopack if you select that via a switch on the lower panel.

 

[Karpador]

got another bug. This happened in a clean install in the mars scenario. I hit the main engines and the wheels on the landing gear rotaated on the wrong axis.

 

[Coolhand]

which part & what axis? helps if you're as descriptive as possible when you report bugs.

however, if you're talking about the wheels, i think you're probably just seeing a common effect caused by rotating things syncing up with framerates.

this is an excellent real world example of this effect:
[ame="http://www.youtube.com/watch?v=Dyisg9-Mwjw"]YouTube - Amazing Flying Helicopter - Defying The Laws Of Physics[/ame]

 

[dbeachy1]

Yes, Steve is correct. Karpador, what you are seeing is simply the effect of the "snapshot" rendered at each frame. Depending on the speed the wheel is rotating vs. the number of frames-per-second you are getting, the wheels may appear not to move or even rotate backwards a little bit. For example, if you are getting 60 frames per second and the wheels are rotating at 60 (or any multiple of 60) RPM, the wheels will appear to not be rotating at all because at the instant each frame is rendered the wheel is in exactly the same point in its rotation. This effect is commonly seen on video footage.

Also, to reiterate what Steve said, for any future bug reports please provide as much information as possible when describing the problem. Thanks.

 

[willy88]

For the turbopack hatches, I'll propose this:

The above image is the turbopack hatch closed.

The below image shows the turbopack hatch open.

As you can see, the doors on the turbopack hatches could retract into the XR2 body, kind of like the lens covers on many digital cameras. I guess the main advantage of this design would be the fact it looks really cool.

 

[dbeachy1]

I'm fine with that, assuming there is room to make it work. However, the hatch design is really up to Steve since he'll be modeling it, although I'll be animating it.

Note, however, that the hatch will "snap open" like the fuel and LOX hatches do now, so the type of animation is likely moot.

 

[Coolhand]

it'll be a single peice flap like the fuel hatch. no need to make things more complicated than necessary.

 

[willy88]

Aww.

 

[Coolhand]

lol. sorry.

 

[orwellkid]

yeah there does seem to be something wierd going on with the hud, the bars and other tracking information, docking overlays and so on seem to be stretched out on the vertical axis for some reason. so if for example you're looking at the ISS and 'locked on' in docking mode the lockon box will be centred on the station if you put it in the middle of the hud, if you change pitch so it's in the upper or lower part then the box will actually be further up or down than it should be, like it's being offset somehow and the offset increases the further it is away from centre.

I can confirm this. It appears to be moving against rotation in a logarythmic (I believe) pattern. The farther -Z the nose gets, the farther +Z the box goes with respect to the ISS. +/- X seems to be ok though.

 

[dbeachy1]

I have been testing that here and the exact same effect occurs with the default DeltaGlider, albeit to a lesser extent. This is similar to the effect that occurs when you use ALT-UP or ALT-DOWN to change your viewpoint. It's just the way that the Orbiter core renders the HUD.

 

[Coolhand]

I think its fine if it wanders a wee bit, but it's quite a big offset in the xr2 - the bounding box isn't even on the target at all for example when it's off axis. I did a comparison in the XR1 earlier and i didn't notice it in that vc.

So, what is the difference between the two craft that causes this effect?

 

[dbeachy1]

I can't be 100% certain without having access to the core Orbiter code that actually renders the HUD, but since the effect also occurs in the default DG it is very likely related to the position or distance of the HUD glass in relation to either the pilot's eyes (the HUD is farther from the pilot in the XR2), or the ship's center of mass (much farther in the XR2). Or it could be related to the distance of the HUD and pilot above the ship's centerline (+Y axis, much higher in the XR2 as well).

In any case, from a code standpoint here is all a ship does to enable a VC HUD:

static VCHUDSPEC huds = {0, PILOT_HUD_MESHGRP, {-0.414, 1.946, 8.011}, 0.127};
oapiVCRegisterHUD(&huds);

That's all there is to it. Except for custom HUD text like "Airbrake Deployed", everything else is rendered by the Orbiter core.

 

[Coolhand]

Anything that needs to be changed to improve the HUD, i think we should look into. If it needs moving somehow in relation to the camera, then fine, i'll make the changes... perhaps it can be cheated or tweaked somehow by changing those coordinates?

 

[dbeachy1]

I will post a question about this in the Oribter Beta forum since this appears to be an Orbiter core issue. I will report back if and when I know something.

 

[yagni01]

Doug,

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?

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.

Just thoughts.

 

[Coolhand]

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?

 

[computerex]

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

 

[Coolhand]

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.