Project G42-200 StarLiner

Just got WIP-2.
Going to see how it is and give feedback in the next few days.

Thanks!

*edit*
HAHAHA!!! Minecraft! YES! I love minecraft too. Nice easter egg.
And one more thing....I am totally, totally, totally BLOWN AWAY by the VC. It takes a lot to impress me, and I am fully impressed.
Just wow. This is quickly becoming my most favorite addon ever.

P.S.
Thank you for the seatbelts. :)
 
Last edited:
Wow, that's really a great spaceplane. Impressive VC you made here, looking forward till everything is functional. ;)

I quick tried a ascend as mentioned in the manual, but got a orbiter freeze at about Mach 1.5 with RAMCASTERs full on, throttle closed, but the turbine switches not off. I also accidentally flicked the SCRAM-Door to clse and then back to open while the engines were working. But I have to try it again on a clean orbiter install, mine is the absolute opposite of this. ;)

I found out, that I can switch seat by clicking on the other crewmember. Do you intend to include seat switching like the XR-2 or Descartes use it (Ctrl-Arrow) or moving free around the cockpit (Shift-Arrow) the get a better view out of the window or something?

I also missed an indicator for my trim setting. Is there somewhere one, or is it already on your to-do list?

Thanks a lot for your amazing work here! :D
 
Eicas

I see a lot of eicas pages in the textures folder. Is it already possible to use them, or is that for a future release?
 
that trim indicator is high on the "needs doing" list... you can see where it will be located, as it's clearly marked by a crude drawing of a trim gauge just to the right of the main MFDs panel (it also says "pitch trim" on it... should be easy to find) :lol:


if you try the ctrl+shift arrow key combinations, you'll see there is a set of three "leaning" positions for each side of the cockpit, which should allow you a better view out the windows or the panels

i can try to reproduce that CTD scenario you brought up... maybe there's something thats in need of a fixing, but it could just be a random event as well... if you could see if it goes on in a clean install, then it's one for the bugs-to-fix list, for sure :hmm:


also, besides the minecraft internal joke, (my brother had suggested the EFB displays were mostly useful for such type of dont-tell-boss activities :rofl: ) there's yet another easter-egg on that cockpit -- see if you can find that :cheers:
 
Last edited:
Awesome Moach!

I don't know if this was in the pipeline or not, but, please don't do any key combos like Ctrl-Alt-arrow_key!

On certain laptops this rotates the screen through 90 degrees (which means I can't navigate DanSteph's Arrow's cockpit sadly :().
 
Awesome Moach!

I don't know if this was in the pipeline or not, but, please don't do any key combos like Ctrl-Alt-arrow_key!

On certain laptops this rotates the screen through 90 degrees (which means I can't navigate DanSteph's Arrow's cockpit sadly :().

hmm, actually, those are already set...
unfortunately, in your laptop-bound case, there is little i (or mr. Steph) can do... those "leaning" keys are a built-in Orbiter feature...

all that an addon craft has acces to in that area, is to set the viewpoint positions for each of those leaning directions... the keys that actually trigger this are not up for changing...
(at least not without seriously nasty hacks)



if this causes problems (i'm aware it i does in several situations such as yours), then it's most likely something to take up to Martin :huh:

it might be simpler to see if you can disable the screen-rotating feature on the laptop itself.... unless that's hard-wired in there somehow
 
Found a CTD bug.
After MECO and you shutdown the rocket engines, if you flip the turbine switches back to start and run Orbiter crashes.
 
I got a freeze again while ascending with the ramcasters at the end of their envelope, when I switched the scram mode to low.

btw: can you remove the big bright glow of the ramcasters inside the middle of the fuselage. It looks a bit weird.

btw2: Know I found the trim indicator... :D
 
I got a freeze again while ascending with the ramcasters at the end of their envelope, when I switched the scram mode to low.

btw: can you remove the big bright glow of the ramcasters inside the middle of the fuselage. It looks a bit weird.

btw2: Know I found the trim indicator... :D

hmm, it appears she doesn't like having the engines "reverted" to previous cycle modes during ascent... looking at the code driving this, i don't see anything that could be the cause...
but anyways, i was just about to replace that whole section in order to better accomodate a more elaborate engines simulation... so i won't go debugging code that's destined for deletion shortly... :hmm:

as for the ramcaster engine glow - that's a check! - i actually had that corrected just yesterday :cheers:

and that trim gauge doesn't work... it's just "painted on" until i get around to it :thumbup:
 
Wheres the button to open the payload bay?
 
Wheres the button to open the payload bay?

just in front of and aligned with the center of the space bar... it's a square-ish push button marked with a capital "B" :lol:

yeah, i didn't get that one installed on the VC - you just gotta push "B" for now :cheers:

---------- Post added at 05:35 PM ---------- Previous post was at 04:52 PM ----------

i wanna hear your thoughts on the possibility fuel tanks [ame="http://en.wikipedia.org/wiki/Ullage_motor"]ullage [/ame]simulation for the '42...

i take it that fuel line pressure would be affected by how the liquid metapropellene* fuel and oxidizer as well deposits about inside the tanks at micro-g conditions

* made-up cool-sounding, near-future, non-magical combustible substance used as main fuel on the G42


this would have a sim-worthy impact on orbital restart procedures for the main engines...

(the Apollo stages used solid boosters to "accelerate the tanks against the fuel mass" pressurizing the drain valves) -- in the G42, the OMS could be used instead, making restart-on-command operations possible...


this could reduce the triviality of switching from OMS to MAIN before a more powerful burn, as fuel pressure on those lines would be subject to vessel acceleration (otherwise fuel blobs up in the tank and gurgles the drains)

as for how to implement this, i'm all set... the G42 already has code in place for a G-meter... so it's just a matter of reusing that logic - but i mean to gauge some opinions on how to make this an interesting feature...

i was thinking in the lines of, when you pop up the starters in orbit, the engines would stay on a standby-ignition mode until the throttle is pushed all the way up, then the OMS does a quick burn to de-bubble the tanks and mais engines fire

or there could be a thumb-switch on the FADEC grip (analogued by the space bar for us sim-pilots) that "triggers" the ullage burn and main ignition when under those conditions

then the checklist for orbital start would be:

fuel pumps: on (left and right)
oxy pumps: on (left and right)
mode switch: check "int" and switch on "stby"
rocket cycle: start (switch stays there)
engines pct gauge: above 40%
throttle: max
engines pct gauge: above 80%
ullage burn: press

burn on...


are you guys up for it? sounds cool as i play it out in my head :hmm:

the OMS and RCS tanks have a bleed-air pressurized tankage, so they don't need all this to fire, but you do have to watch that they have enough pressure (run APU), otherwise you're becoming an orbit-stuck reason for a rescue mission :lol:

just thought i'd get some feed on it... i don't think any other fictional addons account for this :rolleyes:
 
YHS settled (no pun intended) on an automatic ullage burn in the Martian nuclear rocket, right now without taking into account the quantity of fuel. Simplistic? Yes.
 
Hmm I can't get the OMS engines to fire.
I could in WIP-1.

After MECO I'm cutting off the rocket ignition then switching thrust authority from main to OMS...is there something else I'm missing?
 
there could be a bug that prevents the OMS from firing when the main tanks are empty... i have fixed that, but i don't remember if that was before or after i packed WIP-2 :hmm:

if they're not firing on scenarios from the WIP-1 release, then it's because the switches are messed up... open the .scn file, find the G42 entry and remove the VC_SWS line from there - doing that resets the switches and should fix the problem :rolleyes:
 
sounds complex, but it should be good!

and i have an idea for the engine bugs: whi not do something similar to what you saw i had tried with my Haworth, using a complete function to redefine engines... unless thatw what youre already trying...

and i found a wierd bug:
when taxiing, and turning at the same time, the craft nosewheel seems to lift unreasonably preventing any further turning, but the problem goes away as soon as i go into cockpit view :hmm:

cant explain the cockpit view thing, i thought it may have been a force, but the forge drawing in orbiter is incomplete, and i couldnt get any good leads for ya

just try taxiing around WIN on the turbines, it goes crazy when you put full rudder on in EXT view
 
sounds complex, but it should be good!

and i have an idea for the engine bugs: whi not do something similar to what you saw i had tried with my Haworth, using a complete function to redefine engines... unless thatw what youre already trying...

and i found a wierd bug:
when taxiing, and turning at the same time, the craft nosewheel seems to lift unreasonably preventing any further turning, but the problem goes away as soon as i go into cockpit view :hmm:

cant explain the cockpit view thing, i thought it may have been a force, but the forge drawing in orbiter is incomplete, and i couldnt get any good leads for ya

just try taxiing around WIN on the turbines, it goes crazy when you put full rudder on in EXT view

yeah, that nosewheel is actually driving me bananas... and i really don't care for that fruit :banana:

i think i'll rig it to my own logic... instead of using the default orbiter nosewheel steering thing, i can just adapt a more "hands on" solution and override the whole thing :stirpot:

on account of the engines, the G42-100 did have a function that redefined the engines completely...
i didn't port that over for it was mostly incompatible with the new setup -- the '200 has separate inlets for the RT66 nacelles, so they're not exclusive with the ramcaster as before...
anyways, that's all moot now - i'm recoding all the engine update routines... those bugs should go away now :hmm:

'cause if they dont... :chainsaw:


i'm also in the process of reworking those exhausts... texture work is mostly done, now i'll redo those contrails (set their params manually, instead of the kludge i did before :uhh:)


a-compiling i go! :cheers:
 
there could be a bug that prevents the OMS from firing when the main tanks are empty... i have fixed that, but i don't remember if that was before or after i packed WIP-2 :hmm:

if they're not firing on scenarios from the WIP-1 release, then it's because the switches are messed up... open the .scn file, find the G42 entry and remove the VC_SWS line from there - doing that resets the switches and should fix the problem :rolleyes:

The fuel tanks have 12.37K left after my launch, so they're not empty.
I edited the .scn file and removed the VC_SWS line, but I still can't fire the OMS engines.
I also can't fire the Rocket engines anymore, but strangely I can fire the RAMX engines.

Attempting to run the main turbine engines after MECO results in either a CTD, or the VC disappearing completely.
 
Wow what a nice VC we got here! It really screams SPACEPLANE! like no other.

Do you plan on making all the switches and controls work? If so I can see that becoming quite involved. Perhaps take it one step at a time. OR enlist the help of others once you have the concept of what each switch is supposed to do worked out.
 
Just tried this. It's just epic. Only one problem though: At 60km, when I re-start the main engines (flick the switches), I end up flying out of the Solar System. Is there a solution to this?
 
Back
Top