Project G42-200 StarLiner

[squeaky024]

I think it would be good to have a programmable ascent autopilot for this, where you can set the orbit and the plane flies itself up to that orbit.. or at least for the majority of the ascent

edit: Also has anybody found a good distance from a base and altitude to do the deorbit burn at? I'm not too proficient with reentry accuracy yet, still trying to get that down.

 

[Interceptor]

You replace the first 13 lines of the calculationmfd.txt in your orbiter directory with this. Just before you turn on the ramcaster, open up calculationmfd. It should take over control and pitch up to meet the nominal ascent. Then you engage the ramcaster and it will control the climb out. You still have to change to HPC wing config and Hi mode when necessary. Once you are switched over to Internal engines after T3, just close or pause the MFD for manual control for orbital insertion.

When you say replace, do you mean erase the first 13 lines,and then add them in?or,do you just add them in at the end of the text file?

 

[icedown]

When you say replace, do you mean erase the first 13 lines,and then add them in?or,do you just add them in at the end of the text file?

You remove the first 13 lines, then add this back in their place. If you look at the file, each line starts with "<line number> 3 f:" you will see those in the part that I put in my post. Each line in the file is one line in the MFD. Your just changing what is shown there.

 

[Cras]

Also has anybody found a good distance from a base and altitude to do the deorbit burn at? I'm not too proficient with reentry accuracy yet, still trying to get that down.

Best bet it to do it half way around the planet from the base. When you get the hang of it, you can then experiment with closer. You can use BaseSync as a guide for this sort of thing.

I find the G42 behaves very well with Glideslope MFD and its steering autopilot. And that following the Shuttle's descent path works well. Sometimes I cannot stay on course as well as I would like, but still works well enough. And with extra fuel in the tanks, fire up the turbines and make a powered landing.

I do like performing unpowered landings with most space planes in Orbiter, but with the G42, it shoot for powered landings. Its just that something that looks like that, just doesn't feel right landing unpowered. Turn on the turnbines and make a nice landing on a normal 3 degree glidepath.

--------

This is my first experience with Calculation MFD. This thing is very impressive.

 

[Moach]

the '42 isn't built for unpowered landings...

it's design is based around having enough fuel to land and taxi back, and takes advantage of that to better adapt to operation from standard airports... hence, the triple-boogie main gears are quite bulky and thus create a lot of drag when deployed

so other than in case of emergency, a powered approach and landing is the standard practice for this bird


this also allows the G42 to fly without the need for airspace no-fly zones - it can manage around ATC with comparatively very low requirements for special treatment...

i mean, for ATC, the '42 a well behaved kid that plays nicely with others, whereas conventional spacecraft in comparison, are akin to hyperactive brats mothers dare not take outside lest they promptly become embarrassed


so when below mach one - you're basically flying a large cargo plane that happens to be on the way to/from space and makes other planes look slow as pigs :lol:


just mind tho, when restarting after reentry - the engines are not to be windmilled above mach 1 - 'cause even if with the currently released version they don't explode if you do, in the future you may find yourself in a bit of a bind for not giving this fact due consideration

 

[RaR76]

Looking good Moach!

OT: Also, if anyone has issues or questions about calculationmfd, just message me. I bought a new laptop and just noticed the ap.txt file is a bit whacky. I'll rerelease it with fixes sometime this month.

Ok, gotta run, diaper changing time lol we were just blessed in december with a baby boy!

 

[Cras]

Moach,

just letting you know the Starliner WIP 303 appears to not be D3D11 client compatible. It CTDs when a throttle up the engines for the take off roll.

 

[Grover]

strange, since it does indeed work (much better in fact) on D3D9

hopefully not too mard to fix, since id ratehr like to see how the '11 can make the '200 even better

 

[Cras]

It has something to do with the EICAS I think. It displays a bit differently and the fuel flow indicators didn't seem to work right. Just sitting there it is all right, but once I throttle up, it CTDs. Of course that could mean also that the exhaust texture for the afterburners is at fault, haven't tested enough for that.

Under the latest Orbiter Beta, there is no CTD when throttling up for the takeoff roll, so that is no the issue. However, what ever the difference is in 2010P1 and the p2 beta, with regards to MFD displays in the virtual cockpit, there is an issue, as the MFDs do not display in VC. They do however under the D3D11 client.

 

[plainsight]

After some test flights:

I hope you'll get to implement even more systems (a battery switch), for a complete start-up sequence and even more immersion. Right now, the battery is already running and displays are all lit up.

I always enjoy doing startups from cold and dark in every sim. This cockpit is very cool and certainly unique in orbiter, it really adds to the immersion.

Great job putting scram engines on a hover axis, works awesome with a split throttle.

Does flood lightning work? Because when it gets dark in the pit, it's difficult to see position of the switches.

:thumbup:

 

[Moach]

well, a fully functional (or mostly so, at least) electricals simulation is planned to be worked on in a near future....

working cockpit lighting settings would be a neat little trick to have - this would be indeed easier if we had access to custom shaders, so i could write up my own little emmisive map deal and have the pit kinda light itself up (instead of having to switch between pre-baked textures)... so i'll wait for D11 to evolve a bit, then i'll adapt whatever needed for it to work


i haven't gotten much done on it these past few days... you know, real life and all...

but now i'm about to take a 10-day vacation, cleverly arranged to make use of some strategic weekends... so it's actually 12 days

anyways - at least 5 of those will be spent at home (not travelling) - so that sounds like a good call for work on the '42 to resume :hmm:


i'm not making any more specific feature promises - i'll just keep you guys posted on what gets done and what can be expected in general...

no expected release dates either, sorry - unless somebody decides i should get paid for doing this (anyone? :shifty, i'm stuck with making progress only as fast as my free-and-able time allows - and unpredictable as the availability of those moments is, it means any attempt on setting deadlines will only bring frustration for everyone....


so it'll be out when it's done - and hopefully not too long for WIP-4 now :thumbup:

 

[Hurricane]

The way we do cockpit lighting in X-Plane

working cockpit lighting settings would be a neat little trick to have - this would be indeed easier if we had access to custom shaders, so i could write up my own little emmisive map deal and have the pit kinda light itself up (instead of having to switch between pre-baked textures)... so i'll wait for D11 to evolve a bit, then i'll adapt whatever needed for it to work

I don't know how it works in Orbiter - but in X-Plane we don't use custom shaders. We make cockpit lightings in several ways:

Firstly, there's the panel lights, for when the cockpit is dark, for example during night-flights. We have a normal panel texture, named like this:

Aircraft_name_panel.png

(Or so I think.) Aircraft_name is pretty obviously the name of your aircraft.

Now we have a night texture, where the panel itself is dim and the letters and markings on it are bright, called:

Aircraft_name_panel_LIT.png

We apply the first one (as far as I remember) to the corresponding panel, and then we have a proceedure:
We define a so-called 'dataref'. Datarefs are lines of code in X-Plane that define what a 3D object in the VC does in that particular aircraft. The particular dataref (again, as far as I remember) is responsible to the texture of the panel. So, for example we define that dataref to a dial, and so when we spin the dial inside the simulator, the simulator interpolates between the two textures, from a value of 0 to a value of 1, 0 being only original texture, and 1 being the LIT texture file only, and anything in-between being a linear interpolation between the two.

About light sources in the cockpit, we define those by either defining their location inside a bundled software in the sim, or inside the 3D model of the aircraft. X-Plane then draws the light, and in the latest version it also supports shading caused by that light.

Again, all that is as far as I can remember, and I'm also not familiar with the Orbiter rendering engine & its methodology, it's simply an analysis of what we do in X-Plane and perhaps a suggestion to find a way to implement that in Orbiter, because I find it simple & intuitive with predictable results.

~Take care, Oz.

 

[MaverickSawyer]

Well, if only we could use local light sources for this, since it's a meshed surface, right?

 

[Moach]

for the dome lights, yes - a simple point light setup should do the trick.... IF those work in internal meshes, that is.....

if not - then i guess we could use some material self-lighting trickery to achieve a similar, but less proper effect




then there are the flood lights (dim spots mounted under the glareshield), those would require a different texture set....

and then there's the panel and console backlights - that make the white labels and markings pop up in a fluorescent green hue - that's another set of textures

then add one more full set for those two combined.....


each set would be something around 7~8 images of 1024px² size.... we'd be running up quite a tally on textures, no? (at least we don't have to render more than one set at a single time)


well - this IS the originally planned approach, anyways....

but with shaders it would be a lot easier to pull off and maintain - that way i could use a threshold color value to "find" white areas that must be backlit, and overlay a nice flood lighting effect on those panels without needing more than one texture set

so it would be preferable - no doubt

 

[PrestonJames]

If I could request any feature from Moach, I think it would be a cockpit switch to change the HUD from SI units to Kts, ft/min, etc. for airport operations. It would definitely be a pain converting every atc instruction in your head.

 

[Moach]

hmm, unfortunately that's kinda out of my reach....

those HUD bits showing speed and altitude are drawn by the default HUD function, so while i can easily draw more stuff around it, changing the basic stuff would require doing them all over again (which i don't really feel like doing)


but anyways - i've been using the FlightInstrumentsMFD available in the hangar to get my imperial units... i find it quite helpful to have around when flying in atmosphere



or well, i have yet to code the additional hud options (those six buttons left of the reflector) - and one of those functions should get more airplane-type info shown on the HUD as a secondary readout :hmm:


but for now - i suggest the MFD :thumbup:

 

[MaverickSawyer]

new Scenario: G42 at Wideawake International!

Ok, folks. I know I alwats wanted this, but now you can have it too!

BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 55985.4904818858
END_ENVIRONMENT

BEGIN_FOCUS
  Ship Evernaut
END_FOCUS

BEGIN_CAMERA
  TARGET Evernaut
  MODE Extern
  POS 6.75 132.31 -15.75
  TRACKMODE TargetRelative
  FOV 40.00
END_CAMERA

BEGIN_HUD
  TYPE Surface
END_HUD

BEGIN_MFD Left
  TYPE Surface
  SPDMODE 1
END_MFD

BEGIN_MFD Right
  TYPE Map
  REF Earth
  POS 0.00 0.00
END_MFD

BEGIN_VC
END_VC

BEGIN_SHIPS
Evernaut:G42-200 Starliner
  STATUS Landed Earth
  POS -14.4175140 -7.9594880
  HEADING 27.00
  AFCMODE 7
  PRPLEVEL 0:1.000000 1:1.000000 2:1.000000 3:1.000000
  NAVFREQ 0 0
  XPDR 0
  GEARS 2
  CNRDS 2
  VISOR 1
  RCSDOORS 1
  INLET_MAIN 2
  INLET_RAMX 1
  WING_WVRD 1
  WING_FTHR 1
  CGO_BAY 1
  MAIN_ENG_MD 0
  BURNER_TGGL 0
  RAMX_ENG_MD 0
  THR_AUTH_MD 0
  ENG_MAIN_L 0 1 0.0000 0.0000 0.0000 0.0000 0.0000
  ENG_MAIN_R 0 1 0.0000 0.0000 0.0000 0.0000 0.0000
  ENG_RAMX 0 1 0.0000 0.0000 0.0000
  ENG_APU 0 1 0.0000 0.0000 0.0000
  VC_SWS ====-=v=vvvvvvvvvvvvvv=--=vvvvvvvvvv^v===-=====---
END
END_SHIPS

BEGIN_VistaBoost
END

BEGIN_ExtMFD
END

BEGIN_ReFuelMFD
  SCENARIO_TREE 
    NAMED Computers
    END_NODE 
  END_NODE 
END

 

[TG]

What's a good velocity/rate of climb/thrust for the initial subsonic ascent? I waste a lot of fuel and struggle the most at this stage of the flight...

Great plane by the way.

 

[Moach]

i usually try to keep it around mach .60~.80...

anything more, you get too much drag - so i usually fly this stage mostly as an airliner... i.e. no burners except on takeoff and transitioning to supersonic (between mach .9 and 1.5)


you'll find the turbines are very efficient when the burners are off, so keep that in mind and you should have it a little easier :thumbup:

 

[TG]

i usually try to keep it around mach .60~.80...

anything more, you get too much drag - so i usually fly this stage mostly as an airliner... i.e. no burners except on takeoff and transitioning to supersonic (between mach .9 and 1.5)


you'll find the turbines are very efficient when the burners are off, so keep that in mind and you should have it a little easier :thumbup:

Thanks. It just occurred to me that I should have given my own numbers when asking that question :facepalm:

I barely get up to mach 0.55 with full thrust by the time I reach 10km altitude. I think the problem is that I turn the afterburners off too quickly after take-off and kind of semi-stall the whole way up. My speed throughout the climb stays at around 140-150 m/s with 20-25 m/s vertical speed. It's not too bad, I was just wondering why the checklist said stay subsonic when I didn't seem to have a choice!

I'll try to experiment with other velocities before shutting the afterburners off in the beginning.

Edit: Yep, that did it. Cutting off afterburners at 200 m/s made a dramatic difference overall.