Project G42-200 StarLiner

A table is easier to check than an equation.
 
Power-cycling the MFDs produces graphical garbage on the button labels. I think that might have something to do with a lockup I get later, where the sky suddenly goes dark and the machine locks up so hard I have to use the 5 second salute.
 
Power-cycling the MFDs produces graphical garbage on the button labels. I think that might have something to do with a lockup I get later, where the sky suddenly goes dark and the machine locks up so hard I have to use the 5 second salute.

wait what??
AFAIK, no user-mode (not driver) windows software has the hability to cause such a freeze-up that requires the "5 second salute" ( <- great name for it! :lol: )

are you sure ctrl+alt+del doesn't kill it? if not, there might be something more wrong going on with that rig of yours than i'm qualified to guess a fix for :uhh:


remember, if you see the blue screen, hardware has gone kaput :rolleyes:


windows NT and up shouldn't allow "regular" programs such as Orbiter and whatever DLL it loads (such as the '42) to halt the system in a way that can't be resolved without hard-booting... the multithreading rig should always have higher authority

unless you have set orbiter's thread priority to "realtime" - which is not madness, it is Sparta! :blink: :cheers:
 
BSOD's don't always mean hardware failure. I have had 3 BSOD's, all in Orbiter, all in XR2's, all shortly after takeoff at about 5 km altitude. The last one happened about half a year ago, and I have not had one since. My machine has been running fine. (Also worth noting, the computer was brand new at the time.)

All this sounds great, Moach! (Except the part with the blue screens. :rofl:)

I'll download it when I get home. I can't wait! :cheers:
 
Last edited:
BSOD's don't always mean hardware failure. (...)

true, well noted - the infamous BSOD is windows' way of telling you that a kernel-mode software (system driver) has gone south - fortunately, not always this means the hardware associated with that driver is gone with it :hmm:


either way, orbiter should not have enough system authority to cause one of those... perhaps if video memory corruption occurs... but that's more likely an engine-side fault which unfortunately, i have little to no control over :shrug:

if a reference outside the G42's lookup-table bounds were accessed, and that led to an invalid/illegal operation, you'd get a CTD, and windows would say it's "trying to fix the problem" (as if...)

but usually, that wouldn't even cause an error by itself... native C++ works very much in a "i hope you know what you're doing" fashion, and fetching data from unadvisable places usually only brings about the random result of interpreting that data in the form you would do with the correct stuff :P

luckily, the lookup tables are read-only... if i were to actually write stuff into some "here be dragons" memory address, we'd be in for a world of trouble :lol:
 
Last edited:
HI,Moach clicking on the rendering window a couple of times only worked once,and then it wouldn't switch between the pilot,and engineer for the rest of the flight up.I also am experiencing the Ramcaster IGN bug.
 
We are the beta testers. We always get the problems, and when damage is simulated, we are the first to die. :lol:
Cheers to Moach and his wonderful machine so far! :cheers:
 
g42-200_seatbelts.png
 
ok, dummies... ehrm... "brave test-pilots", more progress newz! :salute:


i think i'm done rearranging the cockpit... i've added two new panels on the sides (engineer side for ECS controls, pilot side for flight computer / recorder switchboards)...

the engineer-side panel where the ECS used to be is now reassigned for the airframe temperature (deice/cooling) stuff

where that used to be (in the front panel, left of the MFDs) now is a more advanced external fuel supply control set...


the feed-pump switches are now together with the OMS/RCS stby ignition and oxy-feed pump controls...

the ramcaster switches are now located where the ext-fuel-tanks thingies were before... but since they take up less space, i've managed to scoot the APU controls forward, and added a "MPCS OVERRIDE" (Malfuntion Prevention and Correction System) panel with a nice little flip-up cap that must be lifted before one can access the almighty do-whatever-you-want override knob :lol


it makes a lot more sense now - and the most commonly used switches are now in much easier reach for the pilot


i have yet to fix the VC-Switch retrieval setup (the thing that's not working and causes the keyboard to not flip the respective switch as it should)... not sure what's screwed up with that, but something definitely is :rolleyes:

then i shall proceed into coding a proper EICAS redraw routine...


not sure how long that'll be, since i have undemermined-cause problems ahead of me, but once i get that, the ACS animations and the RCS thrusters all set up (and perhaps some texturing on that ext model), i will pack up for WIP-2

it should feature seatbelts too :hmm: - we don't wanna end up like that guy on the pic, isn't that? :cheers:
 
all i can suggest is to make sure that there is an airbrake in WIP-2, because trying to keep the speed down on final descent is kinda tricky, youve gotta nail the descent so you aim short, then slow down as you level out into an almost-airliner-descent-angle well before you pass the threshold, unless you fire up the engines (but if you've got no fuel left, you're screwed)

re-entry cant be practiced anymore, because its gonna change hugely; 1/10 trim effectiveness will render the G42 unable to hold even 30* AoA, even with full RCS. and on that topic, if you have to close the RCS doors for re-entry, you wont be able to use them to hold AoA, so we're only left with the weakened trim and the non-existent CoG shift

the only alternative i can think of is to use a shuttle-style RCS system, where you can keep the RCS useable even in descent, but you cant put any thrusters IN the heatshield itself (for obvious reasons), check the RCS on the stock atlantis to get some idea.

either way, i think the CoG shift should be powerful enough to allow the G42 to hold 40* AoA without full trim, that way its easier to quickly increase it as you fol over, to prevent huge leaps in your trajectory as you roll (in the past ive gone from ~40m/s downwards to ~300m/s upwards as i rolled over to start the next S-Bend

so, two things:

get a speedbrake in WIP-2, it makes landing approach WAY easier

rethink RCS, we sorta need them for re-entry

thanks Moach!
 
After flying some manual reentries in the Shuttle Fleet, I think a similar system might be good for the G42:
by pressing a button, the Orbiter stabilizes on a 39° AOA, letting the pilot control roll, which is perfect. At first it uses only RCS, but it automatically switches on control surfaces and RCS off reaching about 85km of altitude. Yaw RCS remains active a little longer.

Otherwise, this ship looks great, looking forward to flying it!
 
try glideslope MFD, it basically does that, though needs some manual input midway through to help it reach the AoA it wants.

it also tells you everything you need to know to co-ordinate your S-bends, and even tells you where your speed and altitude should be! awesome with the G42 because you can have 3 instances of this, and the surfaceMFD all at once, everything you need!
 
It seems really really light on its feet, so I looked and the PMI are down around DG values. Shipedit's initial cut for the starliner mesh said 245, 295, 65; running with those numbers gets that big-bird feel for me.
 
I know its been mentioned just a few times ... but, man! Is this a great ship to fly or what?!

I've been having an inordinately insane amount of fun putting the 42 through her pacing in the lower atmosphere, just to see how much abuse she can take and still remain flying. Turns out, she can take a lot! Loops are totally possible, even negative loops, if you don't mind losing 10,000m in altitude doing it. Barrel rolls are also possible with a heavy amount of stick to keep the VV on the horizon. I haven't quite managed a Hammerhead turn due to the relative ineffectiveness of the small rudder. But with the wings in low-lift reentry profile, you can even do a low-and-slow high AoA runway buzz at about 100 m with just under 50m/s forward velocity and about a 40* AoA, using the throttle to keep the sink rate nil. Hard as hell to keep the nose up for any length of time though.

About the only thing I can't get her to do is give me a good stall. At altitude at low speeds, she rolls on her axes so slowly I just can't force it. Best I can do is pull like hell on the stick with mid-throttle to get the nose up, then kill throttle and watch the AoA increase. Eventually, though, the nose just drops, and she recovers smoothly pretty much no matter how much I try to torque her around. Of course, these stall characteristics are GREAT for what is essentially an airliner. Still, good to know now that if she stalls she's not going to immediately roll inverted or something crazy, rather than, say, when you're too slow on final trying to pull up for a flare.

It'll definitiely be interesting in WIP2, if Moach gets an airbrake installed by then. Love to have some flaps too, but that wouldn't be very conducive to surviving reentry I suppose, lol. I'm also eagerly curious to see how an aerodynamically effective canard affects the low atmospherical flight characteristics, especially if we can't yet add a payload to balance the weight just yet.

Anyhow, great ship dude! She's been so much fun, and has cut into so many hours of sleep so far that there she needs to come with warning labels! Cheers! :cheers:
 
I've done aerobatics in an XR2, but I never thought of doing some in a G42-200...:hmm:
thanks for the idea cymrych, :cheers:, though without CoG shift, I aint going to be pulling a cobra.
 
CoG shifting will be essential to do more in the 42. She's just way too stable and solid otherwise, and slow to rotate on her axes. And I'm sure most of what I've attempted would rip her wings off at the root in Real Life, but fun to try all the same!:thumbup:

And I'm bound and determined to get a full-on stall. Just haven't quite gotten there yet. May have to wait for some CoG shift ability there tho. Or maybe gimbaled burner nozzles? (Wink wink, nudge nudge :shifty:)
 
(...)

About the only thing I can't get her to do is give me a good stall. At altitude at low speeds, she rolls on her axes so slowly I just can't force it. Best I can do is pull like hell on the stick with mid-throttle to get the nose up, then kill throttle and watch the AoA increase. Eventually, though, the nose just drops, and she recovers smoothly pretty much no matter how much I try to torque her around. Of course, these stall characteristics are GREAT for what is essentially an airliner. Still, good to know now that if she stalls she's not going to immediately roll inverted or something crazy, rather than, say, when you're too slow on final trying to pull up for a flare.

It'll definitiely be interesting in WIP2, if Moach gets an airbrake installed by then. Love to have some flaps too, but that wouldn't be very conducive to surviving reentry I suppose, lol. I'm also eagerly curious to see how an aerodynamically effective canard affects the low atmospherical flight characteristics, especially if we can't yet add a payload to balance the weight just yet.

Anyhow, great ship dude! She's been so much fun, and has cut into so many hours of sleep so far that there she needs to come with warning labels! Cheers! :cheers:




alright, thanks for the enthusiasm! - all of you, really! :thumbup:


anyways, just thought i'd point out that while airbrakes are by now a must-have for WIP-2, flaps really don't suit delta-wings like the big '42 (Concorde has no flaps)...

and it is expected that she shouldn't stall in a "classical" manner - kudos, for putting it through the test :salute:

the G42 doesn't undergo "stalls" for two reasons - first, it's a delta-wing, and those are known to take up heavy AoA without actually coming to stalled conditions...
second, it's conceptually equipped with a state-of-the-art fly-by-wire system, which would prevent such events from taking place in case of pilot error (or "let's see what you got" type testing) :hmm:



jthill gets a million internets for so cleverly pointing out the PMI values for a "heavier" feel... in the end, i opted for a middle-ground solution, but it definitely feels more airliner-like now :thumbup:


the canards should go a long way in making it more pitch-stable... once i get that coded in :rolleyes:



anyways - in the very very little able time i was able to scrounge in this saturday before mother's day, i somehow managed to get code in place for a proper CoG shifter system... it's not done yet, but i goes as far as to show that only a few tens of centimeters worth of shift are enough to make for a very stable and controlled reentry :cheers:


more when i have more :hailprobe:
 
When WIP-2 comes out, can I have an extra set of landing gear? I broke mine. I think the repair job will hold until then.

(added by edit:)

Hey, a thought, could you add a 'trim slew rate' hi/lo? There's so much range to the trim that each step adds like 0.5m/s^2 VAcc. That or just reduce the trim authority and use gimbals and CoG shifting for the larger-scale attitude frobbing.

Put it on the overhead, there's room up there for that and the trim setting indicator. A fancy tenth-of-a-degree readout would look impressive, no?
 
Last edited:
When WIP-2 comes out, can I have an extra set of landing gear? I broke mine. I think the repair job will hold until then.

roger that! i'll include some spare parts to go along with those seatbelts :lol:


(...)There's so much range to the trim that each step adds like 0.5m/s^2 VAcc. (...)

yeah, that's actually fixed now :thumbup: - i've recalibrated the trim so it is no more powerful than the elevator itself (WIP-1 has it all messed up)



something that i found about that CoG-shift thing.... orbiter has a way of making things very complicated when dealing with CG changes... mostly because it's built in a way that it is expected that the CoG would be always located at the vessel's "local zero"

while this makes perfect sense, simulation-wise (and by no means i'm criticizing martins work), there are a few caveats which can be quite inconvenient....

and by inconvenient, i mean all the VC click areas will migrate along with the CG, as will the center-of-lift, which must be manually reset....


then i realized, the CoG-shift is only relevant on winged flight.... with FBW controls, the '42 would correct all RCS output in order to eliminate parasitic spin and travel....
so this allows a few redundant corners to be cut, and the CoG-shift can be simulated "backwards" by simply altering the center-of-lift instead :rolleyes:


i have to test this out, and make sure it's not a stupid idea :hmm: - but i expect it should go well, and in that case, life gets a lot easier :cheers:
 
Back
Top