Project G42-200 StarLiner

With the afterburners on, you will accelerate much quicker and will be able to get off the ground before you run out of ruway easily.

With an empty bay, definitely, lighting the burners is more than sufficient to reach Vr. But with 6-7mt in the bay, the nose won't lift until a much faster groundspeed is achieved, which can't be obtained in the length of the runways at the Cape, burners lit or otherwise.

I think this is just a geometry issue at the moment. (Or a UCD thing. Anyone know how it accounts for mass and its affect on axial rotations? It may be adding the mass in the right place on the G42, but grossly overestimating the forces required to move that mass around using only the '42's control surfaces.) 6mt isn't much mass, but placed where it is so far forward of the center of lift, you can't get enough combined action between the elevators driving the tail down and the canards pushing the nose up until a much higher Vr speed.

At any rate, I admit mine is a flawed experiment, in that I don't know the designed estimates for maximum takeoff mass, or Moach's plans for the future. He could very well be planning for the addition of flaps, or afterburner nozzle vectoring to help drive the tail down, or a way to tie the aileron control in with the elevators to effectively double the surface area of the control surfaces for the take-off run. Personally, I'd love to see two "take-off assist rocket pods" mounted somewhere on the lower portion of the forward fuselage, angled at about 45 or so upwards and fired only when one pulls back on the stick to rotate the nose off the ground (probably not terribly practical ... but damn if it wouldn't look sweet!)

Anyhow, I'm just trying to get a jump on the orbital operations side of things, by experimenting with up-mass potential now rather than later. And the only real deterent thus far is getting the nose to want to come up. Once there is even a minimal positive AoA, she flies and climbs just fine.
 
Personally, I'd love to see two "take-off assist rocket pods" mounted somewhere on the lower portion of the forward fuselage, angled at about 45 or so upwards and fired only when one pulls back on the stick to rotate the nose off the ground (probably not terribly practical ... but damn if it wouldn't look sweet!)

Try attaching Jato packs from velcro rockets. Use the time delay, and decrease their burn time by removing fuel. that should do the trick just fine...
 
let's see... the torque generated by a mass stationed around the CoG grows in linear proportion with the distance from it...

as in trq = mass * distFromCoG....

it is possible then that those 6 tonnes are preventing the nose from going up as it should....

it is also possible that i've underestimated the control surfaces turning power, so that may very well be the cause of our problems here....

Jato packs really shouldn't be necessary for such a run-of-the-mill cargo mass... 6mt should me well within the typical operations envelope :hmm:

have you tried just using the atttach point in the bay, instead of UCD? - i don't know how that may be affecting things, so it's healthy to be as aseptic as possible when debugging stuff like this :focus:



as for the CoG shifter deal - i'd say about 5 taps to each side is the maximum it would go (i usually get some weird shameful feelings rising as i go with anything past that) :huh:


as for the max tonnage it can haul into orbit... yeah well, i really have no idea :blink: - so you tell me whenever you can figure it out :lol:

:cheers:
 
have you tried just using the atttach point in the bay, instead of UCD?
Crap, there's an attachment point in the bay??? Oops, I must of missed any references to it in the development thread! I'll give that a whirl and see what transpires, in relation to utilizing UCD at any rate.

I also want to play with the CoG shifting, see how that affects the flight characteristics and takeoff roll.

Based on the "feel" and fuel consumption of the '42 once I get her airborne, I'd say 6mT is a fairly minor cargo mass to be toting up to orbit. I'd estimate, at present, say 18-24mT as an upper limit. Let the experimentation begin!
 
An attachment point in the bay? Good to know.

Same with the CoG shifting. I will certainly be giving these two "features" a try when I get a chance. I also had in mind of using UCD to attach payloads into the bay.

I also planned on sticking a URMS in the bay as well.

One "bug" I found was loading up a scenario with the G42 in mid ascent into orbit. I had to cycle the fuel pump switches to get the RCS to work. And also loaded a quicksave where the G42 was still prior to T1 on the envelope and had no luck getting the ramcaster to ignite. I think it has to do with the scenario file.

The only issues I have come across so far with implemented features. Aside from the no brakes in D3D9 and Win XP x64.
 
How does one go about using this attachment point in the bay? Is it like velcro rockets, or something else entirely different?
 
Got add a line for the module:

ATTACHED #:#,G42-200

the first number I believe is the attachment point of the module, the second number is the attachment point on the big vessel, and the name after the "," is the name of the vehicle in the scenario file.

So for the G42-200, it could be ATTACHED 0:1,G42-200, but I am not sure how the attachment points are organized on the G42-200. Going to need confirmation on Moach or some trial and error to figure out which attachment point you need to use.
 
also, ive found that the canards give a stupid amount of pitch control, it makes it HARDER to fly final approach at subsonic speeds.
 
What's the attachment point in the bay numbered?
EDIT: I found them through Trial and Error: 0:0,G422 is the bay, 0:1,G422 is the arm location.
 
Last edited:
Latest on Re-entry:

CoG shift works a treat, - for Pitch-Up and = for Pitch Down (nose wise anyways), you should never need more than 6 notches

the re-entry itself was incredibly smooth, never made plasma and barely exceeded 1G (i think, its probably worth checking with an MFD or something), just use GlideslopeMFD after setting up a basesync re-entry with ANG 0.7 (ish) ALT 80 (Km) and ANT 40. just follow a little below the yellow line until the last minute, then you should find yourself 20km above your target. i managed to land without engines (although they were spooled just in case :P

nosewheel turning is still a little mad, needs tuning down by about 50% IMO and Canards make final approach too tricky (best to leave them in)

finally, the OMS burn for de-orbit is a little tricky, i suggest leaving some oxidiser and doing the burn on rockets (its only 80-90m/s, it hardly costs anything) and cleaning up your dV with RCS or OMS engines.

thats all i have for now, im off to bed

later dawgs
 
It's been a year or so since I seriously messed around with attachment points, and I seem to have forgotten some things. Figured out how to attach a cargo directly to the point in the bay, but it doesn't seem to add the mass to the spacecraft. Is this proper Orbiter behavior for attachment points?

Likewise, I can add a UCD to the same attachment point in the bay, but again, no mass is accounted for by the ship. (Which seems somewhat odd, as putting the UCD in the default CoG location DOES let the ship "acquire" the cargo mass.)

If I'm wrong on the first part, if adding a cargo directly to an attachment point does in fact tranfer its mass to the spacecraft, then I'm clearly not increasing the apparent mass of the loaded cargo on the ship as I though I was. Using a UCGO cargo (the fuel container, arbitrarily), I altered the mass in its config file, as well as in the scenario. Anything I'm missing? I'm fairly confident that this works, as the increased mass value is registered by UCD at least in its payload jettison view while in game.

Latest on Re-entry:

CoG shift works a treat
Couldn't agree with Grover more! CoG shifting really helped a lot towards the bottom end of reentry when the RCS alone can't maintain the 40 degree AoA any longer.

barely exceeded 1G (i think, its probably worth checking with an MFD or something),
Do we have an MFD that monitors g-loading or other forces acting on a spacecraft? Sounds like it could be a fun little toy...
 
on my next re-entry ill take a reading from the AccelerometerMFD, and look see about G-loads

but i definatley never made plasma, despite being lower and faster than the path suggested by glideslopeMFD throughout 85% of the re-entry course

i guess that this bird doesnt generate the same L/D ratio as the shuttle :P but anyways, re-entry is really easy if you understand what you're doing; theres plenty of warning before your mistakes, and plenty of room for error, even BEFORE you consider the crossrange you have when using your turbofan/turbojet engines and RAMCASTERS

but still, my FPS goes from 55 to 8 when i enter the VC (85% decrease in performance)
 
performance hits on VC are often caused by MFD's... the surface and MAP MFD's particularly seem to have some weirdness going on that cause a FPS drop after a while...


it seems to get better if you toggle them off and back on again (the ancient tech-support ritual) :hmm:


anyways, how is it that you got attach point 0:1 to do anything? - there's only one point in the bay, and that's zero :blink:

could the other one be the docking port? i don't remember ever adding an arm-attach :rolleyes:

weird...


anyways, i'll check that nosewheel again (my x52 setup may be too precise to get a good feel of how it works for everyone else, it makes everything seem "easy") - i'll also check those canards.... they may be a bit overpowered when the ship is unladen


there is quite a handful of trouble caused by this, you know... the largest part of the '42s takeoff mass is fuel and oxidizer.... when it comes back without that, it handles so differently a lot of things become problematic :huh:


i may have to add some sort of "control relief mode", for when the usual ACS response would make it to jumpy to bear with

same goes for the engines.... i think there may have to be some "hi/lo idle" selector, to cut down the power for landing and taxi-back :rolleyes:
 
I don't think the turbojet engines need a LO setting, because you can set the throttle precisely with either a joystick or keyboard. As for canards, ill just leave them in, because they ARE needed for takeoff.
 
...anyways, how is it that you got attach point 0:1 to do anything? - there's only one point in the bay, and that's zero :blink:

could the other one be the docking port? i don't remember ever adding an arm-attach :rolleyes:

weird...

I had a CTD when attaching Kulch's URMS, as it wanted to attach itself to 0:2. I switched it to 0:1, but have not tried docking it yet, so if it's the Docking port, we've got problems... If you want, I'll post the .scn for the G42 with URMS at KSC 15.
 
but still, my FPS goes from 55 to 8 when i enter the VC (85% decrease in performance)

Grover, have you considered giving the d3d9 client a spin? I just recently (read, yesterday) decided to give it a go, and man, it was a huge improvement on framerate. With the d7 inline graphics, I got around 60 fps with the G42 most of the time, with localized drops to somewhere in the 30s every now and again. But with the d9 client, my framerate in the G soared to around 800 fps! Even after ratcheting up the MFD refresh rate and a few other visuals, my framerate still shows a consistent 3-400 fps. Just a thought.
 
D3D9 is the way to go. It does not work with DGIV or Shuttle Fleet, and has an issue with UMMU (can't get rid of the gold visor), but it makes the visuals better, and the performance boost is massive.
 
well performance boost is questionable. now i get a consistent 30 FPS, even inside the G42-200, but it is definatley better looking, and as long as it works with the XRs and ISS v3.2, ill make do :P
 
Back
Top