[Closed] [BETA9] of DeltaGliderIV

[sunshine135]

MattNW wrote:
Only bug I keep coming up with is the CTD at the airlocks and I'm pretty sure that's caused by other ships in the scenario.
Especially Spacecraft3 ships.

My thoughts are that if the incompatability cannot be overcome, we probably need to think about adding that to the DGIV FAQ.
Some of these "nit-picks" we have been pointing out are sure to be ones that newbs will have, and this way we can politely
tell them to read the manual/ sticky thread.

In your case Matt, you found the solution was to place the Spacecraft3 ship at the end of the scenario right? If that
consistantly works for you, then we need to consider that as a solution unless, as Dan recently pointed out, we are all
piloting DGIV from a wheelchair wearing coke-bottle glasses.

[killingsnake]

Voyager wrote:

killingsnake wrote:
I have another problem here. For some reason, my new keyboard doesn't have any seperate Ins and Del keys.
They are combined with the numpad 0 and  ( . ). So I can't control the camara's anymore. I'm probally the only one with  this
problem, so anyone knows how I can solve this problem?

To use the insert and del keys of the numpad you need deactivate the numlock (press the numlock key so the light will go
off). Dont forget to turn it back on or you cant control the ship anymore! (if you're not using a joystick to fly)

Now that's the problem there voyager... I know this would normaly be the solution, but even with the numlock off I still
can't use those keys... Under normal circumstances they work, like ctrl-alt-del, but not in orbiter... Thats why I posted
this in the forum... Srry I didn't mentioned this before.

And no offense, but did you really think I didn't know what those 3 Led's are for?

[Voyager]

Hehe. I've seen a few people who had trouble finding the "Any" key on the keyboard when dos would ask for it



Post Edited ( 05-02-07 15:35 )

[killingsnake]

Maybe that program that can change the keys used by orbiter could help me? Or are those keys Prelude II binded?

[sunshine135]

You can bind your own key mapping through the windows menu. Depends how motivated you are!!

[MattNW]

sunshine135 wrote:My thoughts are that if the incompatability cannot be overcome, we probably need to think about
adding that to the DGIV FAQ. Some of these "nit-picks" we have been pointing out are sure to be ones that newbs will have,
and this way we can politely tell them to read the manual/ sticky thread.

That's exactly why I've been testing in depth. A clean Orbiter with just the default ships and DGIV seems to be very stable.
Throw in some add on ships and do some crazy things and you get a greater percentage of bugs but nobody can test everything
in every situation. Users will always come up with something that didn't get tested. A trouble shooting FAQ in the
documentation might be very helpful.

sunshine135 wrote:

In your case Matt, you found the solution was to place the Spacecraft3 ship at the end of the scenario right? If that
consistantly works for you, then we need to consider that as a solution unless, as Dan recently pointed out, we are all
piloting DGIV from a wheelchair wearing coke-bottle glasses.

It's not 100% consistant (more like 85%) but it seems to only be present in very complex ships most often with Descartes
which is made up of a dozen or so modules connected by attachment points.

Of course there's those downright wierd things like last night my scenario with just DGIV and Prelude base kept CTD'ing
whenever I switched from Translational to Rotational thrusters. Nothing worked until I reinstalled Orbiter Sound and DGIV.
I've no idea what went wrong. Didn't make any changes to any files or anything out of the ordinary. Gonna blame Windows on
that one. Another one for the FAQ. If nothing else works reinstall.

[Murdock]

Hi Dan, sorry for the delay (work work work)
as you requested on previous posts, I did some performance tests on DGIV BETA 8 including stall speeds and
damaging speeds.
(I don't know if you had a chance to have a look at them)
I got a reply from Quick Nick complaining that altitudes were needed. Well, when you fly aircrafts and use Indicated
Airspeed altitude is definitely not a factor, but since orbiter and DGIV go well above aircrafts altitude I repeated all
damaging speed tests at all altitudes from 0 to 60000m,
here are the results:

                             -------------ALTITUDES----------------
                            0k    10k   20k   30k   40k   50k   60k
            GEAR      280   342   635    --      --      --       --
HOVER DOOR       --     351   278  302   390   531   920
RETRO DOOR        --     --       --      --      --      --       --
DOCK  CONE       49     49     51     61   100   249    657
   ANTENNA          51     51    53     63   107    271   701
     CARGO           49     49     51     61   100   249    655
 TURBOPACK       51     51     53     64   108   274    701
    CANOPY          52     52     54      --     --      --       --
  RADIATOR         40     40     41     46    66    146    426

All speeds are Indicated Speeds (IAS) in meter/sec. using Surface MFD.
Where no value is reported it means that thermal damage occurs before aerodynamic damage
As expected no significant change occurs at relatively low altitudes up to 30000m above that the extremely low air
density cause them to increase significantly.
The only exception is the gear that overspeeds at 635m/s at 20000m which I find a little bit unrealistic, you know,
mach 1 is about 340 m/s at sea level, so that means that the overspeed occurs well above mach 1!!
Generally on most aircrafts gear overspeed is below 300KTS (about 150 m/s) and definitely subsonic speed anyway!
Let me know if you're happy with this data or anything more that might be needed.
I'll be happy to help
Virgilio

[n122vu]

n122vu wrote:
DGIV docked to ISS, undock, EVA, grapple left or right turbopack on back. Fly the UMmu around a bit. When not near
any object, press G to grapple with hand. HUD now reports TU-00 as hand-attached object. Press B to grapple with
Back, HUD reports TU-00 as back-attached object. Now, return to DGIV near open turbopack door. detach turbopack
from back. Switch to DGIV and attempt to grapple the turbopack. The DGIV reports "no free turbopack in
range,"
even when the turbopack is clearly floating in the "turbopack bay" totally detached from the UMmu.
n122vu

Today was the first chance I had to test this.  I can confirm that this bug is cleared.  

Thanks,

n122vu

[Pagir]

When I make a reentry on mars, I use (in upper atmosphere and after the heat peak) the hovers to slow down the
ship (like many other "real" spaceship.

But I can't anymore!

I think you prohibited the use of hovers when the P104SXX is in function, even if the doors are wide open.

We should be able to use the hovers "at our own risks". (If someone want to try this during Earth Reentry, he will be
destroyed). Otherwise, it's impossible to make a good aerobraking followed by a good landing, since the speed of
this little DG doesn't go below mach 2 before the landing (well... in this case before the crash) with aerobraking only...

Pagir

[Pagir]

I don't remember if it was summited before, but the temp reading of the DGIV in space (about -150C) is not the same
than the uMMu (-273, almost 0 K). Well... maybe it should be corrected.

Another thing: during the descent to the Earth, the uMMUtemp change from -273 to -50 in a fraction of a second,
then go down til abour -100C...

Pretty sure it shouldn't be like that!

Pagir

[DanSteph]

Pagir a écrit:
I don't remember if it was summited before, but the temp reading of the DGIV in space (about -150C) is not the same
than the uMMu (-273, almost 0 K). Well... maybe it should be corrected.

DG** use a complex temperature calculus based on real know data, I don't want to use
this in UMmu for performance concern. So UMmu use the rough Orbiter temperatures table.

Pagir a écrit:
Another thing: during the descent to the Earth, the uMMUtemp change from -273 to -50 in a fraction of a second,
then go down til abour -100C...

Rough I said

Dan

[Jay Gatsby]

Hmm... I definitely think I got something here:  The DGIV is giving me contradicting instructions on the error prompter,
catch twenty-two style... Here's the situation:

I was playing around a little bit with the Vespucci_D, and performed a direct earth to Neptune transfer... just to say
that I did... so naturally I brought along four DGIVs.  Because Neptune is so far away, I put them all in safe mode
once I had used every single newton of force I could squeeze out of them to assist the orbit ejection burn.  at closest
Neptunian approach, I used the Vespucci_D's docking panel to undock all four DGIVs.  I had forgotten that I had put
all of my DGIVs in safe mode, so when I switched to the cockpit of one of them I realized my mistake, but thought I
just might be able to get the situation back under control by pulling back out of safe mode, which I could not do.  
Please note that this is not the bug, because it would make sense that I would not be able to restart my ship if the
crew really has left the DGIV and boarded the Vespucci_D.  What I believe to be buggy is this:  The DGIV tells me I
need to turn on the apu to exit safe mode, but it also complains that apu cannot be started when I attempt to do so
because it doesn't have any power (as epu has been disconnected, but I cannot activate the battery or emergency
power because I am in safe mode).  The resulting functionality is accurate (I am unable to do anything) but the DGIV's
prompts are contradict each-other.

Shouldn't it just complain that the crew is unable to board or something?  I'm not exactly sure what I think it should
say, but right now I try to leave safe mode and it says I need to provide power, and when I try to provide power it
tells me I need to leave safe mode, and when I try to leave safe mode... I'm just saying, I think it should
say something a little less contradicting, that's all-- I still shouldn't be able to do anything.

EDIT:

After restarting such a scenario at this point, I was then able to use the battery, but only after saving and then resuming from the orbiter launch pad-- a very weird inconsistency...



Post Edited ( 05-05-07 01:51 )

[sunshine135]

Not too wierd.

Think about it. The DGIV is telling you, the  pilot getting into the seat,  that you have to press the APU to come out of
safe mode to board the crew. It is informational only to the extent to inform you that no crew is on board, otherwise, how
else would you get the crew back onboard? The only way is to hit the APU START button while docked. This simulates what a
crew would do to get the DGIV fired up and ready for the mission, so it is a logical choice.

Now, the only way to circumvent what you are describing would really be to not let you into the DGIV at all when in safe mode
and undocked. I don't know how hard that would be. If I say it would be easy to overcome, Dan will say it will take 30,000
more lines of code. If I say it will be hard, Dan will say, no- it is easy.

Now, what you could do is use the UMmu SDK and see if you can't make Vespucci contain 100 UMmus! Then you could just go out
the airlock with your Captain and retrieve your accidently disconnected DGIVs. That would be pretty cool.

Just don't forget to eject your helmsman who released the DGIVs in the first place

There will always be a gap in the process should you execute an unforeseen release of the DGIV, but be glad Dan even offers
this functionality. Most add-ons would simply leave the crew in place for that long, tedious mission.

[Jay Gatsby]

All things mentioned here are indeed true (I was, after all, only pointing out that the prompt was misleading-- the
behavior, as I said, is completely accurate, no doubt about it), though I still find it weird that you regain control of the
starter system after (and only after) reloading the scenario.



Again, the functionality of the DGIV is absolutely amazing; there's no question there.  The only things even worth
pointing out at this point are the intricate nuances that come with exceedingly unexpected circumstances.  Quite
frankly, I'm astounded that an add-on such as the DGIV even exists, because quality like this can only come into
being when an incredibly crafty and clever programmer spends an enormous amount of time and dedication on
something, and being a programmer myself, I have firsthand awareness of all of the frustrations and difficulties that
come through this.  If I said anything to the contrary, please excuse the confusion.  The DGIV is a masterpiece,
enough said.

[DanSteph]

streb2001 a écrit:
Not sure if this is a bug but I can't get the ascent AP to work in the following:

Solved with the new AP, please check in beta 10.

See post here:
http://orbiter.dansteph.com/forum/index.php?topic=12016.msg185375#msg185375

Thanks

Dan

[DanSteph]

DocHoliday a écrit:
Well, I've just downloaded it, and I can't get the Prelude scenario to work.... Orbiter CTDs and I can't find out what to
problem is.. orbiter.log lists everything OK, OrbiterSound_Log.txt is also OK.

Bug submited here, no news about investigation so no solving for yet:
http://orbiter.dansteph.com/forum/index.php?topic=12016.msg185392#msg185392

Thanks for more informations

Dan

[DanSteph]

scinrd a écrit:
I think I found a couple bugs:  
1.)  I have noticed that the RCS fuel gauge in the bottom panel does not show the little blue number in the middle
that indicates fuel level in Kgs, but only when you use the Vespucci_D (Mabye a shared variable?).
2.)  I have also noticed that the BTC ver1.3 MFD causes a CTD when activated in same scenario (SEL-&gtBurn
Time
Calculator).
3.)  Kulch's Mir 2 space station modules load fine in any DG IV scenario, but when I exit to the Launchpad and load
current state.scn, I get a CTD. This is really annoying because I am trying to use it as a Jupiter orbital spaceport!!

1. Is solved, 3 was 93 doking port problem but no news for 2...

Thanks for more informations if possible

Dan

[DanSteph]

Pagir a écrit:
But I can't anymore!

I think you prohibited the use of hovers when the P104SXX is in function, even if the doors are wide open.

You asked a while before for safety locking of keys

I don't think I'll remove this one (I flaged as "solved"), there is much more chance that
someone press hover key during reentry (opening the doors and kaboom) then peoples
that use hovers during reentry (wich is a bad practice if you want my opinion, I'm able
to do reentry on mars using the 105 and it work well without hover)

Dan

[willy88]

Is the next beta today?

[DanSteph]

willy88 a écrit:
Is the next beta today?

I fix last things for Beta 10 release, at worse in 11 hours from now ("tomorrow" for me as it will be after my sleep)

Dan