Project G42-200 StarLiner

[RaR76]

Looking excellent!

I had only one issue: I followed the instructions in the text file, however the ramx door switch seems to be on the center panel now. The issue is: the ramx door switch does nothing - the doors do not open.

"when above mach 2, flip up the RAMX DOORS switch on the engineer side, push it back to center when that large door opens up fully
(gotta use spot view for that... no indicators in the VC right now)"

I tried at mach 2, mach 3, pumps off, pumps on. Any ideas?

I have a clean install + one of my mfd projects (Calc MFD) + G42 - other than that, no addons.

Either way, looking great Moach, thanks a million! This addons is excellent!

PS: do you need beta testers? I know we're basically beta testing, but if you need something in particular tested, give me a shout.

 

[Moach]

Looking excellent!

I had only one issue: I followed the instructions in the text file, however the ramx door switch seems to be on the center panel now. The issue is: the ramx door switch does nothing - the doors do not open.

"when above mach 2, flip up the RAMX DOORS switch on the engineer side, push it back to center when that large door opens up fully
(gotta use spot view for that... no indicators in the VC right now)"

I tried at mach 2, mach 3, pumps off, pumps on. Any ideas?

I have a clean install + one of my mfd projects (Calc MFD) + G42 - other than that, no addons.

Either way, looking great Moach, thanks a million! This addons is excellent!

that readme is outdated - theres no need to flip the switch back to center now... it can flip itself when the door stops

and that switch has been relocated to the center console, aft of the big red lever that pivots the wings - the one on the engineer side is the RAMX fuel pump... WIP-2 just ignores it (WIP-3 will not)

i have mostly removed that part of the code as i'm rewiring all the engines (added custom sounds, spoolup/spooldown, fuel-pressure dependency + overall deeper sim logic)
but that means i'm not all sure as to why you're having that problem... i do know it won't be there in WIP-3 (unless some new manner of defect takes its place)

maybe it doesn't work if the main engines are off... there might be a trick to it or something to that extent... :uhh:

PS: do you need beta testers? (...)

that's what you guys are :thumbup::lol:

anyways, if you're flying the WIP-2 build in any of the scenarios that came with WIP-1, do make sure you remove the VC_SWS line from the G42 entry in the .scn file - as that will give you grief, for it messes up the switches... (WIP-1 had a different lineup)
i guess i should have added a note about that in the WIP-2 zip... but i have A.D.D., and i forgot

 

[RaR76]

The VC_SWS line did the trick! Thanks!

 

[Spacethingy]

*Sigh*

5 FPS in the VC and dying fast...

This is one BEAUtiful craft! And she's not even finished...

Perhaps, one day, I'll have a better graphics card...

 

[Keatah]

What you got now?

 

[Moach]

*Sigh*

5 FPS in the VC and dying fast...

This is one BEAUtiful craft! And she's not even finished...

Perhaps, one day, I'll have a better graphics card...

have you tried it with the DX9 graphics client?
i usually get a nice >50% FPS boost with that... but maybe if that's being caused by lack of GPU muscle, then there's little it' might do to help

my home rig is no base for comparison... that GTX580 in there is akin to "cheating" :lol:
yet, when testing on my work rig (which is more modest on the GPU side, equipped with a 9500 or something) i still get solid FPS... about the same as with the DG or any other craft, for that matter....

are you running win7? and most important... what GPU you got?

 

[Moach]

well ok... Just spent the weekend working on it (i dont get that chance too often) and i finally got the engines rigged out again

All stages now feature custom sounds and more complex simulation, including fuzzy-logic fuel pump dependencies, spoolup/spooldown sequencing and a bunch of other stuff...

Yet im not really done still... Some features aren't fully implemented and none of it gets saved to scenario atm....
But shouldn't be too much further now - WIP-3 is gonna have some sweet new stuff to check out

I'd write more on details and stuff, but posting by cellphone can get a bit clumsy

---------- Post added 07-04-11 at 01:00 PM ---------- Previous post was 07-03-11 at 06:41 PM ----------

just a note to let you guys now that i've fixed the nosewheel steering problem... i had to re-invent the whole logic for it, but that's ok - now it can taxi like it should :thumbup:

 

[dgatsoulis]

Thank you very much for this wonderfull ship Moach. It has become my favourite.

Yet im not really done still... Some features aren't fully implemented and none of it gets saved to scenario atm....

When you get those features to be able to get saved on the scenario, would that mean, that they'll be also seen on a playback?

 

[Tommy]

When you get those features to be able to get saved on the scenario, would that mean, that they'll be also seen on a playback?

Saving to a scenario and saving animations for a playback are two completely different things. It will be up to Moach what events he chooses to support for playback, aside from the "standard" throttle positions, etc. It will require extra code to "record" the event, and extra code to handle the "playback events". Here's hoping he will make the effort once the basic functions are worked out - but I would think it will be a low priority compared to getting the features working in the first place, and having them saved to (and recovered from) the scenario file.

 

[dgatsoulis]

Thank you Tommy for explaining that to me.

I think that showing the external view animations on the playback, would be more than enough. I don't think that every button pushed in the VC, should be recorded and shown.

I recently flew a mission with the G42-200 (WIP2) that ended with a docking with the ISS in 1 hour 26 min after take off.

Watching the playback of that mission was great, and i could even use the g,n,v and b keys to control the gears, canards, visor and bay buttons respectufully, which was a marvel to watch, eventhough i had to do it by hand.

I wish the Ramcaster doors and the wing configuration could be used in a similar fashion. (Am i missing the hotkeys that can already do that?)

Ofcourse, if all those sequences could be shown in a playback, that would be just great. But those are just finishing touches on a work still in progress.

Thanks again for the clarification and many thanks to Moach for this wonderfull ship.

 

[Tommy]

It will be up to Moach how much support there is for the flight recorder, of course. It's not particularly difficult, just time consuming. If it were me, it would wait until the "polishing" stage of development. It doesn't make sense to add support for things that could still change before the "Gold version", since it just adds to the things that would need to be re-written.

For the vessel to work correctly under playback, anything that affects engine parameters, propellant sourcing, O2 use, etc would need to be implemented, or else fuel and O2 wouldn't get used correctly during playback (fuel usage isn't recorded - it's "calculated" by throttle position (which is recorded)).

For a vessel this complex, it will be a lot of work getting it to work correctly. Hopefully Moach feels it's worth the effort, and I hope he records elevator trim changes (no vessel I'm aware of does this - and it would make ascent "tutorials" much easier to follow).

Little details such as Nav lights could be omitted, or anything that's just "window dressing" and doesn't affect the way the vessel functions.

 

[Moach]

It will be up to Moach how much support there is for the flight recorder, of course. It's not particularly difficult, just time consuming. If it were me, it would wait until the "polishing" stage of development. It doesn't make sense to add support for things that could still change before the "Gold version", since it just adds to the things that would need to be re-written.

For the vessel to work correctly under playback, anything that affects engine parameters, propellant sourcing, O2 use, etc would need to be implemented, or else fuel and O2 wouldn't get used correctly during playback (fuel usage isn't recorded - it's "calculated" by throttle position (which is recorded)).

For a vessel this complex, it will be a lot of work getting it to work correctly. Hopefully Moach feels it's worth the effort, and I hope he records elevator trim changes (no vessel I'm aware of does this - and it would make ascent "tutorials" much easier to follow).

Little details such as Nav lights could be omitted, or anything that's just "window dressing" and doesn't affect the way the vessel functions.

if i may add, for a craft like this, even throttle positioning is a bit off from "standard"... :lol:
i've actually used a dummy-thruster to add a degree of separation between pilot input and engine response... that's how you get the engines revving up after a realistic delay following throttle-up
anyways - then there are more dummy thrusters for the ramcaster and another reserved for the (coming-soon) airbrakes...

without those, i couldn't very well get all the features i inteded in place... but then, this probably means without additional coding, those playbacks would be rather dull :hmm:

then again, Tommy is right - that is a polish-off aspect of the whole thing... i'm not gonna divert any effort into flight-recorder stuff until we have something that's actually worth recording


and yep - that trim gauge is right next up the line, along with a proper simulation of CoG-Shift, ground handling, APU, and that little tailstrike-wheel i keep forgetting to model :thumbup:

 

[Tommy]

if i may add, for a craft like this, even throttle positioning is a bit off from "standard"... :lol:
i've actually used a dummy-thruster to add a degree of separation between pilot input and engine response... that's how you get the engines revving up after a realistic delay following throttle-up
anyways - then there are more dummy thrusters for the ramcaster and another reserved for the (coming-soon) airbrakes...

If you are using thrusters (or thruster groups) for the ramcaster - as opposed to AddForce, it should sort of take care of itself. I say "sort of" for a reason, though.

The recorder doesn't so much record the "physical" throttle position as it does the "thrust level" of the thruster. This means that even the ramcaster's "thrust level" would be recorded. However, "thrust levels" are only recorded once in a while - or when the level changes by a certain amount (10%?). This would mean that in a playback, the ramcaster wouldn't "spin up" smoothly, rather it would happen in a series of distinct "steps". Might be good enough, or you might have to "force" updates at shorter intervals during "spin-up".

For an example of what I mean by steps, try this:

Take a stock DG, start the recorder, and use IMFD to perform an auto-burn. During the flight, the throttle will drop smoothly near the end of the burn. During the playback, the throttle wil drop in a series of distinct "steps".

As for the airbrake, it should be enough to record the animation of the airbrake for "cosmetic" purposes - and not worry about the "dummy thruster" since it's fuel use isn't important - and wouldn't affect the accuracy of the playback.

I certainly don't envy you having to figure out how to implement all this, and certainly appreciate the massive effort you've put into developing this vessel! :tiphat:

 

[Moach]

If you are using thrusters (or thruster groups) for the ramcaster - as opposed to AddForce, it should sort of take care of itself. I say "sort of" for a reason, though.

The recorder doesn't so much record the "physical" throttle position as it does the "thrust level" of the thruster. This means that even the ramcaster's "thrust level" would be recorded. However, "thrust levels" are only recorded once in a while - or when the level changes by a certain amount (10%?). This would mean that in a playback, the ramcaster wouldn't "spin up" smoothly, rather it would happen in a series of distinct "steps". Might be good enough, or you might have to "force" updates at shorter intervals during "spin-up".

For an example of what I mean by steps, try this:

Take a stock DG, start the recorder, and use IMFD to perform an auto-burn. During the flight, the throttle will drop smoothly near the end of the burn. During the playback, the throttle wil drop in a series of distinct "steps".

As for the airbrake, it should be enough to record the animation of the airbrake for "cosmetic" purposes - and not worry about the "dummy thruster" since it's fuel use isn't important - and wouldn't affect the accuracy of the playback.

I certainly don't envy you having to figure out how to implement all this, and certainly appreciate the massive effort you've put into developing this vessel! :tiphat:

you make a point... but luckily, the dummy thruster is getting recorded as well - and that's where i get the input for the actual thrusters - so by simply employing the same in-between logic during playback, it really doesn't matter how slow/fast the throttle gets moved... if it's in position, the engines should act accordingly in response

plus, now with the new engine code, that whole section is pretty much isolated from the update callback, so i can just call it in the playback event loop in the same way - and no code gets needlessly repeated

you see, my whole idea was that the "physical" throttle position, as you called it, is represented by the position of the dummy thruster (which itself has zero max-thrust and uses no fuel) - it's different from the DG-and-IMFD scenario, for there you have the "end thruster" getting ramped up, while the logic behind it goes unnacounted for.... here, the whole input logic is based on another thruster - so yes, in this case, it should get recorded, and the engines should ramp up smoothly then


and thanks for the appreciation! :thumbup: - tho i actually find it as much fun to program the '42 as it is to fly it (could that be "Schweigers disease"?) :lol:

 

[Tommy]

My main "concern" was that if the ramcasters are thrusters (rather than using AddForce), they would get recorded, and during playback the "throttle setting" dictated by your code may be over-ridden by the playback. This is what happens with regular engines, but I really don't know what will happen here. I don't remember when during the step playback calls are issued, so it's possible that your modules logic could "over-ride" the playback call.

Guess you'll have to burn that bridge when you come to it!

 

[Moach]

i'll do that



anyways - minor progress report -

we have a new texture revison in progress - the switches on the VC panels now have actual little "holes" from where they stick out... in place of that "insert actual switch here" line drawing there was before :lol:

i've done some refining on the panel seams - specially around the main dash... and now there are actual vents (which i drew by hand, erh... mouse) where before it said "vent"

i'm happy to say i've completely fixed the nosewheel steering problem - now it can taxi properly (but i think i've mentioned that already, no?)


a little more updating is pending on the VC model right up for the next few steps...

i've added a little switchboard (still empty) for the still-missing *DARTS command unit - it'll be just in front of the throttle handle, between it and the RCS knob (just under the wrist-guard padding)

*DARTS = disposable auxiliary rocket thrusters

now i gotta sort out the actual controls for the DARTS... which reminds me, i have to actually sort out the DARTS themselves :lol:


so yeah, it's looking like the lineup for WIP-3 will include the new engines code, custom SFX and some better ground handling

i already got the engines and sounds down.. ground-handling is a WIP - so in a bit we'll have enough to call WIP-3 a go!

then WIP-4 should be feature the DARTS and cargo capacity :hmm:


let's see how it goes 'till then

 

[Wishbone]

Where are the holes in the dashboard/avionics boxes to insert extinguishers in case of fire?

 

[Moach]

Where are the holes in the dashboard/avionics boxes to insert extinguishers in case of fire? :facepalm:

:uhh: uuuh... it's not supposed to catch on fi... *beep beep beeep* -- oh crud...

yeah well... :facepalm: i most certainly busted that up mighty bad :rofl:

Wishbone wins 42000 internets for pointing this out before anyone (else?) would meet ruthless doom when sharing a cabin environment with an open flame that cannot be reached and put out


ok, check - extiguisher ports put up high in the TO-DO list :lol:

 

[RaR76]

Thanks for the update!

 

[n72.75]

That looks nice...I feel so inadequate now.