Project XR2 Ravenstar - Mk II

[Xyon]

Coolhand, that looks absolutely beautiful. As always, I sit in awe at your work.

 

[Bloodworth]

Absolutely awesome.
Forgive me if this question has been asked and answered, I didn't have time (or the connection) to sift through 85 pages of posts... Is the VC going to be functional? Please say yes.

 

[dbeachy1]

Absolutely awesome.
Forgive me if this question has been asked and answered, I didn't have time (or the connection) to sift through 85 pages of posts... Is the VC going to be functional? Please say yes.

Answer on the previous page.

 

[halcyon]

Halcyon, cheers, the VC is the whole reason i started the project a couple of years ago. With the upgrade now it should also have some of the nicest detail of any mesh in the game... nearly everything has been improved in some way.

I can already say it's nicer then some payware aircraft I've had the misfortune of buying in the past for FS9.
And I'm glad it was your centerpiece, as well it should be.

Will you guys be announcing beta testing signup here or on your own site?

 

[dbeachy1]

Will you guys be announcing beta testing signup here or on your own site?

Like previous XR betas, the XR2 Mk II's beta team will be by invitation-only. In any case, we are still quite a ways away from beta test.

 

[Spike Spiegel]

Not to rain on your parade or anything, but baking the reflections into the glass texture might not be a good idea, at least if you consider moving the camera position around the cockpit. The reflections wouldn't move and my guess is it would look unnatural. (Actually, given your skill level, you've probably considered this already.) Little scratches and dust wouldn't be a problem though.

Someday, some future version of Orbiter will handle real-time reflections though, and then it's all good.

 

[Coolhand]

Given that we've already done this once before its all been considered already. I think it would probably work, even if you're moving your head around a little... it would be fairly faint, so you can still see outside. maybe it would annoy some, maybe others would prefer it to no reflection. But there's probably only a small percentage of orbinauts who have 6dof track ir, or have built their own setup, so i don't see why thats a reason to deny it to everyone. And if you didn't like it, just replace the texture with a blank.

However, there may have been a technical reason why we didn't do it in the end, it may have caused some graphical glitch with orulex and some other objects.

 

[Cairan]

Quick question: Does the XR2 disables the reentry failure modes when it is docked? I am asking as when it is docked inside a vessel like the Arrow, it should be protected from reentry damage. Have not tested the behaviour yet, but if this has not been put into this revision, it might not be too late...

 

[Keatah]

small question, are the panel lights gonna be reflected in the windows in game? it looks awsome!

I'm not so sure I'd like to see reflections, they would need to very accurate and would also need to shift position as your point of view changes. They would also need to reflect the panel as it changes and updates. Like if you have mfd's on or warning indicators blinking.

To see a panel light flash and its reflection on the window not flash that would just cheapen the look, not to mention be disorienting. Surely the tech today exists to make anti-glare coatings work here..! Ahh perhaps we could have a glaredimmer switch, like the boeing 787 does - actually it has a glass that can darken and change polarization or something like that.

I say we don't bake any texture details into the glass. Or perhaps make it an option in the .cfg file to satisfy everyone.

Oft-times special effects get added to a game just because they can be. I hope that orbiter does not go the way of the multi-million dollar gaming productions of today - using special effects just to use them,. The 'art direction' in a lot of modern games seem to mandate effects are used, whether or not they are appropriate. Just add more bling! It will sell better!! *NOT*.

The most common culprits are:
Making the whole scene brown.
Adding excessive blooming/lighting.
Increasing contrast.
Too much vignetting.
Excessive ground reflections
Glass surfaces being polished too much.
Intense lens reflections.
Fake motion blur.
HDR and oversaturated color.


See here for other discussion.
http://www.atariage.com/forums/topic/160260-modern-games-too-real/
and
http://en.wikipedia.org/wiki/Uncanny_valley
I think the uncanny valley applies to this even though we are not dealing with robotics.


Also, come to think of it, no multi-million dollar company would ever buy-out Orbiter or any of the add-ons. Why me thinks that way? Orbiter is not dumbed-down enough. You have to actually think about what you are doing. Installing add-ons is way way too complex. Many game companies mandate that the user do nothing more than click on a link or icon to install something. All this unpacking and copying directories is deemed, by 'big money' corporations, far far too complex to release to the general public. It isn't turnkey-stupid enough!!

They would also insist that the development process be closed off, there would be no direct and immediate interaction between users like ourselves and the add-on makers, base builders and ship builders.. It it precisely this discussion that will make the XR-2 (and any other add-on) a better deal.

Well hell!! This is kind of like test piloting and engineering discussion. The pilots go fly the planes and report back to the designers, the engineers make changes and then the cycle repeats. For those of you that have worked in aerospace, you'll be kind and forgive my overly simplistic description, it suffices here.

 

[Mandella]

Yes, the Mk II will have a fully-functional "glass panel" virtual cockpit. i.e., it will have flat glass panels with displays and touch controls on them.

Wooooot!!!

I'm going to be spending days in this craft.

:thumbup:

 

[Bloodworth]

Lol, is that a roswell grey floating outside the window?

 

[dbeachy1]

Quick question: Does the XR2 disables the reentry failure modes when it is docked? I am asking as when it is docked inside a vessel like the Arrow, it should be protected from reentry damage. Have not tested the behaviour yet, but if this has not been put into this revision, it might not be too late...

Currently the XRs do not take docking status into account when computing damage. The (slightly) tricky part is that if I disable damage while docked, the user can simply dock two XRs together and then reenter at crazy velocities (i.e., "cheat"). You do raise a good point, however, that when docked inside a larger vessel the XR would be protected from damage. As a compromise, I'll add a new config parameter named 'EnableDamageWhileDocked' which defaults to 'on'. That will prevent "cheating" by default, but still allow users to disable damage while docked if they want to.

 

[mc_]

What about "hold IAS by pitch" autopilot? It can be useful during ascent.

 

[River Crab]

What about "hold IAS by pitch" autopilot? It can be useful during ascent.

I second this. Not too dumb like the DGIV's ascent/atmo flight autopilots. Anyway, the XR2 is much more of an aircraft than any Deltaglider. :yes:

 

[markl316]

One quick suggestion to this amazing craft. Sometimes, I like to manually do a vertical landing on the moon or other celestial body without an atmosphere (using attitude hold autopilot to hold it at 0 degrees bank and zero degrees pitch). Of course, the use of translation is necessary to do this. However, the keyboard shortcut to switch between hold pitch and hold AOA mode is numpad 9, so whenever I need to translate back a bit, I hit numpad 9, and suddenly the attitude hold autopilot switches to hold at -60 degrees or so, and bad things happen...

Would it be possible to make this hotkey perhaps CTRL+ALT+NUMPAD 9 (or something along those lines) to allow backwards translation while using the attitude hold autopilot? That would be great. Same for numpad 6 (which is translate forward and bank right, maybe make it something like CTRL+ALT+NUMPAD 6?).

Thanks for such an awesome ship.

 

[TSPenguin]

Currently the XRs do not take docking status into account when computing damage. The (slightly) tricky part is that if I disable damage while docked, the user can simply dock two XRs together and then reenter at crazy velocities (i.e., "cheat"). You do raise a good point, however, that when docked inside a larger vessel the XR would be protected from damage. As a compromise, I'll add a new config parameter named 'EnableDamageWhileDocked' which defaults to 'on'. That will prevent "cheating" by default, but still allow users to disable damage while docked if they want to.

How much work would it be to enhance the feature by adding config options like these:

ProtectiveDockVesselList = "Arrow01, DeepStar04, Excelsius"​

Which would allow the pilot to choose a list of vessels he can reenter with safely while docked. Or a variant I'd prefer:

ProtectiveDockVesselPrefix = "foo"​

So you can safely dock to any ship which name starts with foo. Much more coding would be required to allow wildcards etc.
Well, a suffix would be nice too.

Is it just me, or can anyone else feel Dougs coding sense tingling?

 

[dbeachy1]

Would it be possible to make this hotkey perhaps CTRL+ALT+NUMPAD 9 (or something along those lines) to allow backwards translation while using the attitude hold autopilot? That would be great. Same for numpad 6 (which is translate forward and bank right, maybe make it something like CTRL+ALT+NUMPAD 6?).

Thanks for such an awesome ship.

Hmm...well, the issue is that NUMPAD6 is the pseudo-standard key for banking right using Attitude Hold (the DGIV uses that key as well), and it is used quite often during reentry (at least by me), so IMO it doesn't make sense to change it to a CTRL-ALT key: everyone would have to re-learn that, and IMO it would be cumbersome to have to hit CTRL-ALT while making a simple bank change.

Like you, I also like to use the ship's autopilot to hold the vessel level while landing. However, that is exactly what the Descent Hold autopilot is designed for: just switch on Descent Hold and then translate left/right/aft/forward using the normal keys. However, if I understand you correctly the difference is that you like to control your descent manually without having Descent Hold take over the hover engines, correct? Since I really can't change the NUMPAD6 for Attitude Hold, what you can do instead is just remap the keys that Orbiter uses for translation (NUMPAD6/NUMPAD9) to some other keys by editing your $ORBITER_HOME\keymap.cfg file.

 

[markl316]

However, if I understand you correctly the difference is that you like to control your descent manually without having Descent Hold take over the hover engines, correct? $ORBITER_HOME\keymap.cfg file.

Yeah, that's what I meant, I'll just remap in my orbiter keymap. Thanks for the suggestion. Also, quick question, like when I use the attitude hold autopilots, they can sometimes be off by half a degree or so, is this meant to be? Again, not a big deal at all, just wondering.

Mark

 

[Keatah]

Yeah, that's what I meant, I'll just remap in my orbiter keymap. Thanks for the suggestion. Also, quick question, like when I use the attitude hold autopilots, they can sometimes be off by half a degree or so, is this meant to be? Again, not a big deal at all, just wondering.

Mark

http://www.orbiter-forum.com/showthread.php?t=13257#post142929

 

[dbeachy1]

Also, quick question, like when I use the attitude hold autopilots, they can sometimes be off by half a degree or so, is this meant to be? Again, not a big deal at all, just wondering.

Mark

Yes, what you are seeing is normal. I'll try to explain exactly why here. Tuning an autopilot is a compromise between 1) Efficiency (how much RCS fuel does it burn?), 2) Stability (how stable and smooth is the ship under time acceleration [low effective frame rates]?), and 3) Tolerance (how tightly does it try to hold a given setting?). It is relatively simple to make an autopilot that is very good at any one of those three criteria. It is much more work, however, to build one that is pretty good at all three.

For example, it's easy to tune an autopilot for very tight tolerances (i.e., hold within 0.1 degree) if you crank up the RCS power it uses at every timestep. When you do that, however, two things happen: 1) efficiency goes way down because the autopilot is much more prone to "overshooting" and then correcting with almost the same force in the opposite direction due to the framerate varying and/or just being too low, and 2) stability would be terrible under time acceleration (i.e., low effective frame rates) because of the "overshooting" that would constantly occur as the hold targets/air density/framerate constantly varied. So the trick is to tweak the autopilot code to be efficient and stable even under low frame rates while still holding a good degree of accuracy. During testing and tuning I found that holding within 0.5 degree still allowed very good efficiency and stability, even under time acceleration. For example, if you're getting 40 fps or more you should be able to reenter using Attitude Hold even at 10x time acceleration, which is an effective framerate of only 4 frames per second. In other words, the XR's autopilot is only able to update thruster levels four times per second of simulation time while having to cope with constantly changing air resistance, hold targets, and framerate.

So it's really just a matter of design goals: in the XRs' case I wanted to be able to reenter at 10x time acceleration or more while Attitude Hold remained stable, so that's why I had to loosen the tolerance a little more than I would have liked. But the payoff was very good stability and efficiency.