[closed] BETA 5 Of DeltaGliderIV (fifth beta release)

[Quick_Nick]

DanSteph wrote:

Quick_Nick a écrit:
Big nasty bug(ew): Payload gallery scenario. I used the DGIV already there and picked up the FUEL cargo..

Wow... and I mean... wow... Will try that, can you reproduce this one ? You added ship with scenery editor
or by hand ?

Adding ship by scenario editor is a bit tricky, maybe just DGIV related but it might be possible also...
I wait more info to reproduce it and I'll try.

Dan

Added one in Scenario Editor, then a second one. I think it is likely that the problem is crew with the same name,
making values go crazy. Obviously a big problem if you plan on being able to make DGIVs with Scenario Editor. I decided to make a scenario with 7 DGIVs already on the Cape pads and with names like Pilot1, Pilot2, Pilot3, so they wouldn't have the same name. I will try making two of the same name and see what happens.
EDIT: Did a test. I made a scenario with them already landed in their positions. Two with same crew names. No problems on EVA. I've noticed places with multiple vessels of the same name working many times. Still don't know the problem.



Post Edited ( 04-02-07 03:57 )

[Pagir]

I'm testing the automatic reentry for now...

What is the difference between Pro105Spec10 ou Spec20 ou Spec40???

Pagir

[n122vu]

Dan,

First flight complete, no bugs to report thus far.  Flight details as follows:

I edited the KSC to ISS scenario to include a cargo container to simulate an ISS resupply mission.
1.  Took off from KSC with payload container in cargo bay, mass 1800kg.  
2.  After successful orbit insertion, opened cargo bay door, completed rendezvous with ISS.
3.  After reaching ISS, undocked, released pressure in airlock, opened outer door and performed EVA with secondary
crew member.
4.  After MMu was in safe location, re-docked the DGIV with ISS
5.  Opened turbopack door, with MMU near pack, released from DGIV and grappled with MMU
6.  Moved MMU to vicinity of cargo bay, released container and grappled with MMU
7.  Moved container to ISS dock 2 and released from MMU, docking the container to the ISS.
8.  Moved crew member with turbo pack back to DGIV, moved close to turbopack storage door and released pack
9.  Grappled pack with DGIV
10.  Moved MMU near front of DGIV
11.  Switched to DGIV and undocked (outer door still open, lock still no pressure from when EVA was released
12.  Stabilized negative closure rate between DGIV and ISS
12.  Moved MMU to airlock and re-entered crew member to DGIV
13.  Re-docked DGIV to ISS (just as sunset arrived!)
14.  Undocked from ISS and made small prograde burn to open distance from ISS prior to De-orbit.
15.  Completed De-orbit burn
16.  After ensuring reentry condition was safe (D65), engaged PRO105S40
17.  Using 10-20 degrees of banking, bled off excess speed during reentry.
18.  At Alt=~26k, Autopilot routine complete, disengaged.  Continued descent to KSC
19.  Over-shot KSC, fuel expended.  Had to ditch crew in Atlantic ocean.  Assuming in real-world scenario all would
survive.

All-in-all, I'd call it a successful failure.  The only suggestion (really more of a request) I would have is this:  If no
robotic arm for the DGIV, at least a way for crew to EVA while the nose cone is being used for dock?  It would make
a "resupply" mission with ISS, such as the one I performed, more feasible and less awkward to perform.  Other than
that, she flies like a dream.  I can't express how awesome this entire package is, from the MMU to the many payload
options.  Everything is very clean and has a polished, "ready-for-final-release" feel to it.  

Thanks for all of your time and effort on this vessel.  It really is an amazing accomplishment.  


n122vu

[DanSteph]

n122vu a écrit:
at least a way for crew to EVA while the nose cone is being used for dock?

Well, I don't think this would be very suitable, mean I should add animations for side door, another airlock etc etc...
much work and realism spoiled. (15m long aircraft with two airlocks ?) With autopilot (NULL speed and auto dock)
releasing docked payload, EVAing and docking to payload again is no work and may even add to the fun.

n122vu a écrit:
First flight complete, no bugs to report thus far.  Flight details as follows:

Much thanks for what I call a complete flight test

Pagir a écrit:
I'm testing the automatic reentry for now...
What is the difference between Pro105Spec10 ou Spec20 ou Spec40???
Pagir

Well, no difference, you can type either.

Quick_Nick a écrit:
Two with same crew names. No problems on EVA. I've noticed places with multiple vessels of the same name working
many times. Still don't know the problem.

Might be only Orbiter and editor limitation, for example when you spawn a ship and click "copy state" to have same
ground location and exit editor it may bug because Orbiter for unknow reason don't like at all that two vessels are at
the exact same location. Result are unpredictable, sometime it work, sometime one vessel is ejected light speed or do
strange things etc etc... solution is usually to move the new ship some meters away before closing editor.
I'm not sure either if you "copy state" from a container instead of DGIV etc etc, I don't know exactly how you have
done that the first time but "warp time mr sulu" (Light speed) and R+e is typical an Orbiter problem with ground
contact.

Maybe not related but DGIV also doesn't support very well "editor shaking" when editor hold it and do some space
warp this might kill passengers and spoil systems because the main loop continue to run and check for normal physic
law.  A good way to reset all to normal when editor is used is to exit and reload the current state scenario. Problem
may arrive also if you play with date and put it far in the past.

No real solution for that, maybe editor should just spawn the mesh model and not run any vessel code until released ?
(editor closed) still it would cause problem with edited ship instead of new ship. All complex ship are prone to such
consistancy trouble not only DGIV.

Anyway, most time editor work fine and is more practical than hand editing of scenario, it's just a bit sensitive and
may bug from time to time (and most time when two ships at same location) , from my experience as position/orientation of ship isn't controlled at all by DGIV when spawned it's more an Orbiter & editor problem..

This said I do not exclude *completely* a DGIV bug in your case of course, only complete tests with bug reproduced
100% time can tell that.

Much thanks for your time

Dan



Message modifié ( 02-04-2007 10:07 )

[Quantum Burrito Meal]

EDIT: Problem was a crappy text editor. Sorry for wasting your time.



Post Edited ( 04-02-07 20:28 )

[R Groszewski]

Dan, I must congratulate you on the quality of the DGIV.  I say around now is the time to release it!  But anyways, No
crashes, errors, or anything like that, with the exception of this one; I'm not sure if it is my Video Card, My Screen, my
Mouse, or the DGIV.  When I am zoomed i close to the DGIV or a related object, it "skips" when Iright click to change
my view direction.  Anything that can be done about it? I mean, It's not a serious error or anything, but it can be
annoying.


P. S. My Video card is an intergrated Intel Cerelon M proessor with an ATI xPRESS 200M Video system. ( I'm using a
laptop.

[Quantum Burrito Meal]

Oh, and Dan, just a thought, but if you made the flap covering the radiator open toward the back of the DGIV, it wouldn't
interfere with the cargo bay.

[Quick_Nick]

DanSteph wrote:
Might be only Orbiter and editor limitation...

Well I just moved one to the Cape pads and took off and put a second one on the pads and it was automatically,
before closing anything, tailsitting.

[DanSteph]

Quick_Nick a écrit:
Well I just moved one to the Cape pads and took off and put a second one on the pads and it was automatically,
before closing anything, tailsitting.

And crashed after unpausing ?
I Tried, unable to reproduce this one, can you reproduce it and tell me exactly what you do ?
Starting scenario, button clicked, exact editor method to spawn one, all is important...

Thanks

Dan

[dudrea]

Bonjour,

Cela va être difficile de trouver des bugs ;-)   J'ai rejoué le scénario complet consistant à aller secourir un GL perdu su
IO depuis Europe, et je n'ai eu aucun souci, aucun dysfonctinnement....

Me suis amusé ensuite avec diverses EVA à partir du scenario "UMmu transfer to docked ship.scn". Transféré tout le monde dans
les deux sens, désacouplé les deux GL, fait quelques EVA, enfilé un MMU et joué avec, et là à force de jouer j'ai envoyé un
équipier à perpete (puissant le hoover). Je suis allé le rechercher avec l'un des DG, je l'ai "pêché" directement par la
porte ouverte, puis fermeture de la porte et retour vers le premier DG. Aucun bug tout marche de façon impecable, sauf, mais
pour moi ce n'est pas un bug mais lié je pense à la gestion d'Orbiter : si le MFD "docking" conserve bien ses paramètres
lorsque je passe d'un vaisseau à l'autre (Ctrl F3) ce n'est pas le cas du "Hud" qui se recale sur l'autre GL. Je pense que
c'est du à ce que tout ce petit monde utilise la même fréquence 108 sur le transpondeur...

J'ai alors essayé le programme de docking automatique d'un GL vers l'autre. Il a bien démarré... Et par vice, et aussi par
ennui j'ai lancé le même programme en symétrique sur l'autre GL !!! Le résultat est croquignolesque.... Cela marche les deux
vaisseaux finissent par s'accoupler (dans ce cas là en se traversant par l'arriere d'ailleurs !) au terme d'une folle course
poursuite, chacun essayant pour son propre compte de se synchroniser avec l'autres.  Cela non plus n'est pas un bug...
J'espère que je ne serais pas puni si je n'en trouve pas ;-)  Mais je vais continuer mes essais...

Toutefois J'ai eu, semble - t-il, un problème semblable à celui signalé par Zarb-dusk hier vers 14h00 (désintégration
"imméritée vers 40km) , mais comme j'ai mal noté les paramètres cela n'apportera rien. Je vais essayer de le reproduire..

En tout cas excellente version, bien plus fiable que la précédente.....

[woo482]

can u pm me whith the link dan

[zarb-dusk]

Dan j'ai été sadique avec le DG, j'ai ouvert toutes les portes et autres sas et j'ai accéléré jusqu'a mach 1 et plus, c'est
bien fait le fais que ça devienne des "Wreck" au lieux qu'il disparaissent ou qu'ils se détachent c'est du bon boulot Dan;)
aller fini la rigolade ce soir voyage juqu'a jupiter on va voir sont comportement sur la durée normalement ça devrait y aller.

[DanSteph]

dudrea a écrit:
Bonjour,
Cela va être difficile de trouver des bugs ;-)   J'ai rejoué le scénario complet consistant à aller secourir un GL perdu su
IO depuis Europe, et je n'ai eu aucun souci, aucun dysfonctinnement....
Me suis amusé ensuite avec diverses EVA à partir du scenario "UMmu transfer to docked ship.scn".
Transféré tout le monde

Excellent testing, merci  

dudrea a écrit:
Toutefois J'ai eu, semble - t-il, un problème semblable à celui signalé par Zarb-dusk hier vers 14h00 (désintégration
"imméritée vers 40km) ,

Bizarre, pensez à sauver un quicksave juste après la mise a feu de déorbitation comme cela on peut "rejouer"
la réentréesi elle ce passe mal.

zarb-dusk a écrit:
Dan j'ai été sadique avec le DG, j'ai ouvert toutes les portes et autres sas et j'ai accéléré jusqu'a mach 1 et plus, c'est
bien fait le fais que ça devienne des "Wreck" au lieux qu'il disparaissent ou qu'ils se détachent c'est du
bon boulot Dan;) aller fini la rigolade ce soir voyage juqu'a jupiter on va voir sont comportement sur la durée
normalement ça devrait y aller.

Excellent aussi, c'est en le secouant et en faisant des trucs inhabituel qu'on decouvre des bug caché...
Pense aussi a sauvegarder si tu fait des réentrées. Un "no burn reentry autopilot" qui fait cramer c'est pas sympa.

A++

Dan



Message modifié ( 02-04-2007 19:51 )

[woo482]

wear can i join the beater testing team dan? can i have the link

[paddeh]

just wanted to say i too have experienced the crash to desktop that picto experienced. apart from that i have
nothing to report so far!  have flown the dg to the iss and to the moon without problems

[sunshine135]

Dan:

Fine machine you have built.  I performed the autopilot automatic reentry scenario and did not experience any CTD, but have a
few suggestions:

- Have the user burn at 17.15M instead of 17.24- I would rather have too much energy approaching the cape rather than not enough.

- When you start the scenario, the reentry control display is up rather than the deorbiting display. I know, I just know that
a noob out there is not going to read the directions and they are going to burn until the reentry control display reads an
angle of 1.2. Then it isn't going to work and they will complain. Recommend you add verbiage that states to ensure that
Display 3- Deorbiting display is active and burn until the predicted reentry angle reads 1.2.

Will comment on any CTDs I come across accurately. So far, very nice machine.

 

Cheers,

[Quantum Burrito Meal]

I don't know if this belongs here, buts it's a bug. When a container being carried by an MMU docks, it does not lock in
plcae, and still moves with the MMU until the MMU ungrapples, at which point both the MMU and the container jump to the
'docked' position.

[Pagir]

Salut!

I tried many (say, 5 or 6) automatic reentry and for now... I didn't manage to reach the Cape: In fact, I'm too short by
more than 300km... Anyway, this can be corrected, it's not that bad.

But I found (with Aerobrake MFD) that even if you desorbit at the precise distance from the cape with the correct
reentry angle (1.2) you can have at least 80km of variation between the "low 1.2" (near 1.19) and the high (near
1.21) angle. And I'm not speaking about weight variation or different starting orbit altitude... And the final speed of
Mach 2.5 is not really high: it's too late to allow any corrections. At the end, the pilot has at best a controled gliding
distance of 40, maybe 60km (without any turns)...

As is, I must sadly say that Pro105 is not really useful... appart to avoid to be destroyed (well, that's not that bad
after all )


So.... I was wondering... Could you implement a "second phase" in Pro105, i.e. allow the user to manually control (to
a certain extend) the pitch below -say- Mach 12. This would be useful to glide longer - and reach greater distance - or
glide shorter (to reach a nearer base)...

The top-notch feature : If the pro105 was able to "override" a dangerous pilot operation to avoid any overheat...
I.E.: The pilot want a pitch of 20. The computer says: "Too low pitch. Command overrided".

But I know FsP is on your radar, sooo...

Pagir (on the test field)

[zarb-dusk]

J'aurais une question vous ne savez pas si il y a un mfd qui peux etre utiliser pour sauver les donner télémetrique parce que
on peut les voir mais pas les sauvegarder ça m'aurais permis de voir exactement la variation de temperature a 40Km
d'altitude, en sachant que chose étrange avec le CTV j'ai reussi a faire une réentrer en ne faisant presque pas de plasma
j'aurais du faire un "control C" pour verifier... Tiens je crois que je vais faire une réentrée avec les memes parametres et
te donner le playback comme ça tu pourra constater mes dires.

[hfbldprince]

ok, i have found a CTD:

in the mission earth scenary =>takeoff to iss, I didnt dock but i went into orbit, and came back at KSC.

After landing, i pressed F3 to change to the 2nd DG, and then it CTD'd


Also what is the correct KSC cfg for if i have kukantos' med res KSC?

[Pagir]

zarb-dusk a écrit:
J'aurais une question vous ne savez pas si il y a un mfd qui peux etre utiliser pour sauver les donner télémetrique
parce que
on peut les voir mais pas les sauvegarder ça m'aurais permis de voir exactement la variation de temperature a 40Km
d'altitude, en sachant que chose étrange avec le CTV j'ai reussi a faire une réentrer en ne faisant presque pas de
plasma
j'aurais du faire un "control C" pour verifier... Tiens je crois que je vais faire une réentrée avec les memes
parametres et
te donner le playback comme ça tu pourra constater mes dires.

Tu peux aussi essayer le flight data monitor accessible par CTRL F4. En cliquant sur les paramètres que tu veux
sauvegarder et en cliquant sur "log" puis "start" un fichier contenant les paramètres sera créé. Pas certain que ce
soit très utile, cependant...

Pagir

[R Groszewski]

Just a little idea: Since the cargo pods can be both grappled, and docked, It would be cool to be able to fit MMUs into
it.  I do not have any experience in making/ editing modules, and I know you are one busy fellow, but could it be
possible to make a "mini panel" for the Habitible pods?  And what I mean by mini panel is Just a Passenger display
and the EVA switch.

[Quantum Burrito Meal]

It doesn't have to be made by Dan, it could use the cargo container SDK, combined with the UMmu SDK, plus a little extra
programming skill. Could be done by anyone who can code C++

[R Groszewski]

What SDK? Nobody ever told me about an SDK for the Cargo pods orthe UMMU!?!?!

[DanSteph]

paddeh a écrit:
just wanted to say i too have experienced the crash to desktop that picto experienced. apart from that i have
nothing to report so far!  have flown the dg to the iss and to the moon without problems

The other DG is a default Orbiter DG, picto had problem with this default dg wich CTD often even without DGIV.
Notice in the incoming beta I removed all the standard ship of Orbiter,
doing addon is enough sensitive to not risk CTD due to others addons.

hfbldprince a écrit:
ok, i have found a CTD:
in the mission earth scenary =&gttakeoff to iss, I didnt dock but i went into orbit, and came back at KSC.
After landing, i pressed F3 to change to the 2nd DG, and then it CTD'd

Again standard DG, might be same problem as above. Can you try to start the scenery without ascent and just switch
DGIV/DG to see if this problem happen each time or just after reentry ? (I just tried this scenario, no CTD)

Quantum Burrito Meal a écrit:
I don't know if this belongs here, buts it's a bug. When a container being carried by an MMU docks, it does not lock in
plcae, and still moves with the MMU until the MMU ungrapples, at which point both the MMU and the container jump to
the 'docked' position.

Orbiter feature: grappled objects must be released to dock. Maybe I'll add a "tutorial scenario" to teach that.

sunshine135 a écrit:
Have the user burn at 17.15M instead of 17.24- I would rather have too much energy approaching the cape rather
than not enough.

Will shorten it a bit... about display I'll have a look, noobs must read instruction anyways, if he's not able to make
retro burn he doesn't deserve to live

Pagir a écrit:
As is, I must sadly say that Pro105 is not really useful... appart to avoid to be destroyed (well, that's not that bad
after all )

PRO105 is a "do-not-flood-my-forum-with-ooh-nooo-I-burn-always-thread" autopilot
Of course maybe we might have "ooh-noo-I-miss-cap-always" thread but at least peoples would not burn.
Giving control to user on AOA would render this autopilot much complex and it will not be anymore "burn proof"
This autopilot might teach also peoples how to do a reentry (keep about -80 m/s) so if one want full control
of reentry one should use pro104 (wich was reworked also for more precise control)

Variation of arrival might depend also of FPS, I tend to be always right on the money at about 50km
of landing strip but I have a very stable FPS at about 100 FPS during all reentry.

Anyway I think I'll add a third or even a fourth number to reentry prediction angle so it will be more precise,
maybe this can cure the problem ? (instruction say "burn preciselly until 1.125°" instead of "about "1.2°")

Thanks to all for testing !

Dan



Message modifié ( 02-04-2007 22:14 )