[Closed] BETA 1 of DeltaGliderIV (first beta release)

[DanSteph]

Twilight a écrit:
*just reproduced it*
It seems to be a special situation, if you have only External power, and the Seatbelt light is on, then you undock
(losing external power) the seatbelt light then turns off, and you die without pressure.

Ah ok got it... it's the same then "seat belt & Apu fail" bug... it was solved in my version
this is why... (spacesuit was a wrong display in this case, they had only cloth)

Dan

[Twilight]

Also, this has bugged me forever... can you make it so you can turn the emergency fuel cell off?


When you turn it on, you can't turn it off agian.... it's kind of annoying...

[DanSteph]

Sorry, no valve here but a solid plastic that separe chimical component, when you
press button you make in fact a hole in the plastic starting the chimical reaction...

Once started the best you must do is to manage power consumption closely
so the cell last the longest time possible.

It's an emergency things, not a kitchen light

Dan



Message modifié ( 29-12-2006 02:02 )

[Twilight]

PRO500SPEC0 - Missing from Checklist MDF's list of autopilots.

[DanSteph]

Yes Check list have to be reviewed completely...

Thanks,

Dan



Message modifié ( 29-12-2006 05:54 )

[n122vu]

Well, I hate to have done such damage to such a beautiful ship, but I'm afraid both crew members did not survive
reentry.  Seems PRO104SPEC40 doesn't like time acceleration. (I'm assuming you already knew this.  I'm just finding
out for myself).  Breakup began somewhere over the Pacific.  I did however make a sizeable dent in the west side of
Chicago, and probably started a fire that would put Mrs. O'Leary's cow to shame (sirens were a nice touch!).  One
thing I did find interesting, though.  I believe Chicago Midway, maybe O'Hare, cleared my charred remains for landing
just before impact.  Nice to know that ATC has respect for the dead ha ha!  

Other than this little quirk (the ATC, not the autopilot), things seem to be working as expected.  No further issues that
I have run into.  You've build us a good ship, Dan.

Regards,

n122vu

[Quick_Nick]

PRO104SPEC command is programmed to disengage with time acceleration.

[reverend]

First off, thank you very much for a great upgrade to an already excellent addon.

A few of the things I'm about to post about have already been mentioned, here I will simply detail my entire
experience with the DGIV so far...

System: AMD 3000+ 1.8Ghz, 2.0 GBs DDR RAM, 256Mb GeForce 5500 FX, AGP8x
OS: Windows Vista Ultimate Edition (RTM Build 6000)
Orbiter Version 2006 P1

Downloaded and Installed.  Edited Configuration for Long Trip (Mars to Earth) and saved configuration.  No Problems

Planned first flight Mars to Earth.  The first think I noticed is that the scenario for the DGIV on Mars is named DIII...
Preflight Checks for Startup from Safe Mode OK, No problems except that when putting the main engine gimbal to
Comp/Auto the gimbals don't re-center themselves, they remain fully deflected.

Loaded Configuration OK.

Planned trip using TransX, no problems.

Takeoff, PRO200SPEC8, A-OK

Ascent Autopilot PRO903SPEC107 (107 degrees calculated by TransX).  Seemed to work ok until about 70km altitude,
then started spinning me out of control.  I immediately disengaged the ascent autopilot, performed a kilrot, then
oriented prograde using the prograde autopilot.  I fired the main engines to get Ap up to 4.068M (as default on
TransX).   Cut off engines and coasted to Apd.  

Used BurnTimeMFD with autocirclization function, calculated a 56 second burn at ApD to circlize orbit.   Performed A-
OK, circlized Orbit.

Next in perparing for the plane alignment burn I switched to Linear RCS.  The moment I hit the "/" key I got an
immediate CTD...

Luckily I have a module I wrote called AutoSave that saved the scenario about 5 minutes before the CTD.  
I reloaded the AutoSave'd scenario.  The first think I heard was the callout "80 knots" <note I was already in orbit>
Then I recieved Hover Engine Failure, Gear Failure, and Gear Collapse alarms.  I cleared the alarm and checked out
the outside of the ship.  The gear appeared to be up and the hover doors seemed to be slightly open.  

I quit the scenario (CTRL+Q), and opened the Current State scenario in notepad.  I compared it against the
AutoSaved scenario. About the only difference was the failure flags (and the RVEL/RPOS).  I reset the failure flags to 0
and saved CurrentState, then reloaded the scenario, again I got 80 knots, gear fail, gear collapse, hover fail.  I
cleared the alarms and then tried to switch RCS modes again, immediate CTD pressing Numpad "/".

I was sort of reading this topic while testing it out and came across n122vu having the same issue, and he says it
works ok on a clean install.  So I figured it must be some addon that is causing a conflict.

I went to the Modules Tab in the launch pad and disabled all modules.  I then reloaded the DGIV Mars scenario in safe
mode.   I powered on the APU and pressed the "/", changed modes no problem, No CTD.  So I've got about 25 extra
modules installed, I started enabling them 3 or 4 at a time expecting to find the culprit.    I however did not...

After re-enabling all the modules, I still was able to press "/" without any CTDs (on the ground with just the APU
running).  So I decided to do a full powerup and takeoff and see if "/" caused a CTD in orbit.  Nope, after this I have
not been able to replicate the CTD from pressing "/".  I have absolutely no idea what might have caused this.

After going to orbit to try to CTD and failing, I decided to return to olympus,  I turned around and fired ye ole engines
and used AeroBrakeMFD to plan a trajectory back to Olympus.

I was about 30km from the base and 10km altitude when I realized I was coming down too steep and figured this
would be a good time to try out the damage simulation.  Immediately upon impact with the ground I got a CTD.

This is about when I gave up and decided to type up my synopsis of what's gone on so far.   I don't quite think it's
ready for a Mars -> Earth trip just yet, but it's definetely coming along.

Nice work 8)

[DanSteph]

For some other it's true, for 104 I'm not sure...

Dan

[Travis Reed]

I've noticed that 104 does in fact shut off at any timeaccel greater than 1x. Whether it's supposed to do this or not, only
Dan knows (and if he forgot, he's the only one who can review the code and find out...). It seems that LandMFD does not work
with the DGIV (as mentioned in other posts in this thread). I haven't tested to see if this is specific to the DG3/4 in my
particular case. This means I'll have to find something else to land on airless bodies on target...in the meantime, I'll have
to do it the old fashioned way.

Also, it just occurred to me that I might be able to use AeroBrakeMFD to assist me in landing on Mars.

[nero]

Confabulous wrote:
Great upgrade of DGIII Dan, really fantastic! One tiny thing, probably is more of an Orbiter problem, if you dock 2 DGIVs and
turn off both APUs (no emergency power), both External Power Units will work! Just wondering where all that power is coming
from. It'd be fine if you could power both from one APU or emergency power, maybe there's batteries there that aren't seen by
us? It's very minor really.

If you dock two DGIVs with empty fuel tanks they can even refuel. But this is as minor as the EPU thing, since there is an
easy workaround: just don't do it!

Another little thing: Could you change the "realistic" fuel setting so that it's really for "ISS only"? Currently it's easily
possible to reach the moon using this setting and Mark II engines.

Apart from that: Great work, Dan!

[Redburne]

Fantastic work, Dan!

I finally got around to downloading the beta, and my intended "quick look before going to bed" turned into a three hour
flight ... sooo much fun!

A few things I noticed (I've not read the complete thread, so they may already be known):

* the "inner airlock" button behaves differently (it toggles its state independently of where you click it, while you have to
click the upper or lower half of all the other switches)
* (U-Mmu) Turbo still available (but not visible) after turbopack is back and grappled on the DGIV
* Not a bug, but a design deficiency: In the thruster and retro doors switch, the dangerous state "OPEN" should not be in the
middle (better: "OPEN", "AUTO", "CLOSED" ). This way, you can *always* (even during reentry) switch from "AUTO" to the safe
mode "closed", and it will *never* open unintentionally.
* minor nitpick: the gimballing switches are labeled "left" and "right". In aviation and spaceflight, that would usually be
"port" and "starboard" (or short "stbd" ).

[DanSteph]

reverend a écrit:
First off, thank you very much for a great upgrade to an already excellent addon.
A few of the things I'm about to post about have already been mentioned, here I will simply detail my entire
experience with the DGIV so far...

My theory on all this is that a DGIV on a fresh install never caused any CTD until now (I don't say this can
never happen but DGIV seem to be very reliable on this matter yet as all CTD where other addon related yet)

The "/" CTD come probably that another addon is holding the rotation/translation sound causing CTD when DGIV try
to access it. Maybe when you disabled the module the DGIV was able to load them and as you never quit the
launchpad the DGIV still had them when you allowed other modules again ? Would be intteresting to confirm, try a
fresh launch with all modules activated as at the very start of test. Anyway by security I copied both sounds in the
DGIV directory and now it use it's own copy only. (those two were the only sound not in DGIV directory)

If it's not a sound problem I really don't know as the "/" key do only that: call Orbiter function that change from
rotation to translation and play sound. So at 95% it must be sound related.

The "crash" CTD come probably from another addon trying to access vessel by handle without validating it heach
frame, as the DGIV is deleted during the crash (and another one with same name but another handle recreated) the
handle is invalid and may CTD other dll that still access the old handle. (InterMod at least can cause that)

Another things is XP keeping handle, XP for whatewer reason and even with pack 2 love to hold file that were
accessed. The good idea is to install the DGIV fresh after a computer boot and NOT just after having runned Orbiter
or worse with launchpad activated.
If you never installed the DGIV or Ummu there is no problem as the DGIV use only it's file but it may be a problem if
you had it or ummu installed before.

Today later or this evening I'll release the BETA 2 with all corrections made yet and start a fresh beta thread.

Dan

[DanSteph]

Redburne a écrit:
* Not a bug, but a design deficiency: In the thruster and retro doors switch, the dangerous state "OPEN"
should not be in the
middle (better: "OPEN", "AUTO", "CLOSED" ). This way, you can *always* (even
during reentry) switch from "AUTO" to the safe
mode "closed", and it will *never* open unintentionally.

Nice one ! will do that before BETA 2 release today.

About inner button: green light doesn't indicate open or closed state at all but if you are allowed to actionnate this button or not.

About Ummu strange, you say that the mmu still has power without the pack mounted ?

Gimmballing, this dated from DGIII or even stock DG, I'l let this like that as non-english people
are not very familliar with port & starboard (I'm unable to tell you if port is right or left for example

Dan



Message modifié ( 29-12-2006 09:55 )

[DanSteph]

Ok Done, Thruster door button changed...

Will release beta 2 after sleep.

Dan

[DanSteph]

nero a écrit:
If you dock two DGIVs with empty fuel tanks they can even refuel. But this is as minor as the EPU thing, since there is
an easy workaround: just don't do it!

Or uncheck dg4config.exe "allow docked refuelling"

nero a écrit:
Another little thing: Could you change the "realistic" fuel setting so that it's really for "ISS
only"? Currently it's easily possible to reach the moon using this setting and Mark II engines.

mhhh I'll leave this as it is... from iss to moon there is not so much dv and noobs may need that extra fuel
and I've enough work

Thanks anyway...

Dan

[Redburne]

Nice one ! will do that before BETA 2 release today.

Wow, quick work! Thanks!

About inner button: green light doesn't indicate open or closed state at all but if you are allowed to actionnate this
button or not.

It is not about the green light. It is about where you click the button. If the outer door or nose cone is open, the switch
is in the upper position. If you click the upper half of the button, nothing will happen (which is OK). But if you click the
upper half of the inner door button, the door will open. I do not think that this is intentional.

I'm not sure if I make myself clear, so here's a simple example. Start one of the "What's cool" EVA scenarios (they are on
Earth, so opening a door is allowed). Now click on the upper half of all four airlock buttons (as if you want to confirm that
everything is closed and ready for take-off). The inner door alone will start to open.

About Ummu strange, you say that the mmu still has power without the pack mounted ?

Yes. And it took me a while to find out what I did ...

Looks like I grappled the Turbopack with the DGIV while the astronaut was still wearing it. The pack disappears from the EVA
mesh and is attached to the DGIV, but the MMU still has hover and main engines (and Turbopack fuel).

Gimmballing, this dated from DGIII or even stock DG, I'l let this like that as non-english people
are not very familliar with port & starboard (I'm unable to tell you if port is right or left for example

They could look it up in the same dictionary they consult to find out what "yaw", "pitch" and especially "gimbal" mean ...

But you are starboard ... err ... right! "Left" and "right" should cause less confusion.

Oliver

[wolfast]

Good work.... new File cured wierd Name Problem....  Dan , Thank you for your hard work!!!!