Project G42-200 StarLiner

[Grover]

it was right after i came out of re-entry, so it was INT oxy supply, throttle was zeroed, i opened the RAM doors, ignited the engine, and as i throttled up, it froze.

so, perhaps there is a dependancy on the main engine running before the RAMCASTER can be ignited, so far i think most people would have done that during ascent to avoid a brief period of zero thrust

 

[Hlynkacg]

this is strange, i managed to run both at the same time recently.

could it possibly be something to do with re-entry? did you make your tests after leaving the atmosphere or without leaving it at all?

I'm doing my tests in sub-orbital flight, my quicksave starts me at Mach 15, Altitude 71k. All prior manuevers/switch throwing were performed IAW Moach's launch checklist in the readme.

---------- Post added at 07:25 PM ---------- Previous post was at 07:22 PM ----------

it was right after i came out of re-entry, so it was INT oxy supply, throttle was zeroed, i opened the RAM doors, ignited the engine, and as i throttled up, it froze.

so, perhaps there is a dependancy on the main engine running before the RAMCASTER can be ignited, so far i think most people would have done that during ascent to avoid a brief period of zero thrust

I think you may be on to something there. Unfortunately I need to go to class in a few minutes but one of you should look into this.

 

[Grover]

done, ive the RAMCASTERS can in fact be ignited alone, which is strange, becasue there are few alternate explanations

any ideas guys?

 

[Hlynkacg]

Perhapse an interaction with O2 supply being internal vs external?

Any way, I gotta go but good luck solving it.

 

[Grover]

hmm, worth a shot

---------- Post added at 07:36 PM ---------- Previous post was at 07:31 PM ----------

nope, works even when mains are set to INT oxy

i also tried wings in each position, and with mains both ignited and cut, but nothing.

isnt it frustrating when you cant reproduce a really annoying bug that always comes when you dont want it!

 

[Moach]

i have figured there's a bug where Orbiter will inexplicably freeze and die.... i have honestly no idea what on earth that could be about... seems as random as whatever it could be :shrug:


i had it like 3 times in a row, then it simply stopped happening, and i didn't get it ever again since...

there is another bizarre thing (not sure what) that will have your scenarios save "wrong", then this happens when you load... that, i'm pretty certain is a save/load bug... the other thing, i really don't know


anyways, i've revised the placement of the switches on the engineers right knee-panel - i've swapped them with the ext-tank controls, makes a lot more sense now :thumbup:

i've also redefined the pilots "lean forward" position - it now looks down and closer to the MFDs, as was suggested (good call on that one!)

 

[halcyon]

Are you saving all these changes for WIP-2 or is there a patch for WIP-1?

 

[Moach]

i think that would be WIP-2...but worry not, i don't plan on keeping it long between them :thumbup:

 

[halcyon]

as for the excess lift on reentry, did any of you remember to flip the wings to featherd mode (lever to RTY) before taking 'er down the slopes?
doing so eases back about 30% overall lift - and that's what it's there for

Dohhhh!!!
I forgot to do this.

Well I just tried another reentry test (I have a saved scenario at 160km and descending just for reentry practice).
I still had to crank back on the stick and maintain max AoA. My stick was mostly at the limit.
AoA for the first s-turn was 48-50 degrees. Subsequent turns reduced it by a degree until I was maintaining about 45-46 degrees AoA which was putting me almost right in the middle of the reentry verticle speed corridor.
I was actually a little fast for my altitude in the screenshot below but I wasn't at max AoA so I had room to maneuver and create more drag, but the envelope is very tight.

The first s-turn also required a 95 degree bank, but with the wings up subsequent s-turns only required around 60 degrees or so of bank angle, as shown in the above screenshot.
So yeah, the wings helped but it's still hard as hell to initially slow down the aircraft.

 

[Hlynkacg]

i've also redefined the pilots "lean forward" position - it now looks down and closer to the MFDs, as was suggested (good call on that one!)

Thanks :tiphat:

As for the Ramcaster-deathspin-bug, it seems to have disappeared. Or rather, I have been unable to reproduce since I got back from class.

I've cold-booted my laptop since the last testing session so perhapse it was being caused by a memory leak or corrupted save file.

 

[cymrych]

isnt it frustrating when you cant reproduce a really annoying bug that always comes when you dont want it!

Indeed. Sometimes makes you wonder with these sometimes yes/sometimes no bugs if your rig is possessed. I also have been trying to get the freeze-out bug to manifest itself, but so far no joy.

---------- Post added at 03:43 AM ---------- Previous post was at 03:11 AM ----------

Hmmm, just managed to get that freeze-up in a new unique manner. During ascent, in Hi Ramcaster mode at about Mach 10, I crossed the terminator (or was close enough to it to put the cockpit in shadow). Panels went dim as expected, and the sim froze.

UPDATE:

Also noticed that on the coast to apogee during initial orbit insertion, I'm still producing contrails at 145km.

 

[River Crab]

Wow. Um...wow.
I haven't felt this way from flying for a long time... ♥ー♥

When custom engine sounds are implemented, I am going to shake the neighbourhood. :lol:

In my flights, I got an acceptable ~20 FPS in the VC with all the MFDs on, on my none-too-amazing 2.00 GHz 64-bit dual-core (with 32-bit Windows XP), Nvidia GeForce 6100 machine.

I did get the dreaded Orbiter freeze once, when I switched the RAMX to CUT when the throttle was still open and the main engines were running.

On my Japanese-locale computer, the fuel reserve screen has ￥ on it...I believe it's because it replaces backslashes. It would be nice if it weren't locale-dependent. Or even easier, don't use backslashes.

As Izack said, some of the switches should really be 2-position; for example, the visor should just have ON/OFF positions, no middle position.
Unless you plan to make it automatic...but I don't think that should be the case for any of the red switches on the centre console...

Speaking of, this might sound a bit odd, but could you make the visor extension/retraction animation slower? So you can look up and watch the view unfold. More dramatic that way. :lol:

Finally, I was messing around with Halcyon's checklist from before...only the ascent is there, and some wanted information is missing, most notably the table of takeoff performance for various loadouts...it should get more complicated as we get into using drop tanks and DARTS. There should be some section about cruising in case you're doing an off-plane launch and need to fly to your target inclination before blasting into orbit. Pitch values for certain times throughout the ascent would be nice. I'm not yet sure of the optimal ascent profile, but from following this, it shouldn't be hard. I started to do an orbiting checklist but decided to wait, since those features aren't implemented yet...
The PDF is attached, you can approve/disapprove of the font...
And yes, I know it will all be on the EFB, but still. ^^;

Keep it up, this is awesome. ;D

 

[Interceptor]

HI,Moach don't know if this is a bug ,or deliberate,but after awhile you can't switch between the Pilot,and the Engineer anymore, using tab.I Really enjoyed flying her into orbit,I haven't tried reentry yet, soon though.Thanks for the awesome ship,and it only will get better.:thumbup:

 

[Grover]

That is indeed a bug, can you recreate the bug?

 

[Moach]

i've had situations where Orbiter starts ignoring keyboard inputs altogether... maybe that's the cause? it seems it spans from window focus loss when using any of those pop-ups like object info or the scenario editor screen....
in that case, clicking anywhere on the render window a couple of times seems to straghten things out more often than not.... :hmm:

if that's not it, then i really don't know... one for the bug-list :shifty:

 

[Eli13]

I don't get it, on my computer it hasn't made any bugs, and ive done at least two full flights after following what some of halcyon said. I wasn't exactly sure on the re-entry. But still no bugs.

 

[jangofett287]

Right, the following has never failed to produce the space death spin bug for me:
sit in engineers seat.
Turbine cycle normal
Engine doors/inlets EXT
Engine mode normal
Turbine cycle Start
Turbine cycle normal
(At this point I normally thrust for a few secs to check engine start)
Burner/Reheat ON
(Again, I check for burner ignition)
RAMCASTER door OPEN
Wait a few secs
RAMCASTER door OFF
RAMCASTER mode LOW
RAMCASTER control IGN
Press 0 and say bye bye earth.
After a short time orbiter may then proceed to crash/CTD/Hang indefinitely

 

[Moach]

hmm wait, are you doing this with the ship sitting on the ground?


if that's the case, it might be some sort of out-of-bounds index problem on the thrustFX-ref lookup table... it's quite undefined what could happen if values outside the table range are fed into the engines model.... symptoms go from division-by-zero implosion or blast-into-outer-space with variable-popping from OMG max-thrust rating values :blink:


i know, doesn't sound very sane... but then again, i was't programmed by a very sane person :lol:


but i think that might give me a lead on the cause for that "engine model explosion" bug :hmm:


now, the hard part... getting me some able time to actually fix it... real life is going at it again :facepalm:

 

[Grover]

that may also be the cause of the ramcaster ignition crash when leaving re-entry, since my DnP was a little high... but maybe not.

have you considered using an equation rather than a data-table? it may be more efficient, if a little harder to calculate, but implication is rather easy i think :dunno:

ill let you make your mind up, those data tables might have been a lot of work, and you're probably reluctant to destroy them if thats the case

later dawg!

 

[HarvesteR]

I think the best approach here would be to just clamp the lookup table output to some sane valúes...

Reducing a table down to an equation isn't always easy... Sometimes to reproduce the output curves you need some seriously messed up calculations, that are more prone to giving insane values when out of bounds than a table...

I think it should be fixable just by doing some sanity checks on the tables output... And also extending it's coverage to have a safe buffer zone, just for good measure

Cheers