forum.heli-x.info

Hi @all,

nachdem ich heute die Version 2.0 installiert habe, habe ich Probleme mit verschiedenen Modellen.
Während z.B: der EC135 oder T-Rex 450 und 600 laufen, bleibt die Ausgabe z.B. beim Blade 4003D spätestens nach ca 30Sek. "hängen".

Mit "hängen bleiben" meine ich, dass Sound und Bild nicht mehr richtig funktionieren. Beispiele

-> am Boden bei Idle-Up: Sound und Motordrehzahl erreichen (B400 Idle-Up 1) ca. 735 U/min, dann "flattert" der Sound und kommt nicht weiter (durch Pause... lange warten... Fortsetzen kann man das Problem beheben)
-> Fliegen: Bild wir immer ruckeliger, bleibt schließlich ganz stehen, die FPS-Anzeoge zeigt aber meist noch volle Rate

In beiden Fällen, werden auch die Joystick-Eingaben immer schleppender umgesetzt, bis "alles steht". Das Problem ist reproduzierbar und tritt auf mind. zwei Rechnern auf. Da das Problem exakt identisch auf 2 völlig verschiedenen Systemen auftritt, schließe ich eigentlich eine Fehlkonfig aus, trotz die Randdaten

-> Rechner 1:
XP-SP3, Desktop
Intel Pentium D, 3.0GHZ, 3GB RAM, Phoenix Bios
NVidia GForce 6700 XL 128MB 1024*768 TrueColor @60HZ, neueste Treiber
Java 1.6 R13

-> Rechner 2:
Vista 32bit SP2, Laptop
Intel mobile DualCore 1.6GHZ, 3GB, Phoenix Bios
NVidia GForce9300M, 512MB, 1280*800 TrueColor @60HZ, neueste Treiber
Java 1.6 R13

Any ideas?

TIA Uli

Hoi Michael

Das ist bei mir unter Ubuntu 0904 auch so.

Gruss
Stephan

Hi Stephan, und (verspätet) hi Michael,

erst mal danke - ich lese aus deinem Beitrag, dass man sich hier direkt an Michael wende ...

Ubuntu auch... da scheint was mit den Modell-Parametern noch nicht zu stimmen.

CU Uli

Hi Uli

Das war die Macht der Gewohnheit, dass ich Michael direkt angesprochen habe. Wir waren Arbeitskollegen

Vielleicht hilft uns der Beitrag von Mario weiter viewtopic.php?f=5&t=257. Leider kann ich es hier in der Arbeit nicht testen. Aber es ist eine Erklärung warum es beide Betriebssysteme trifft. Ich dachte zunächst auch an einen Ressourcenfresser auf meinem Linux als die Framerate zusammengebrochen ist.

Beste Grüsse
Stephan

HI Stephan,

habe ein wenig getestet.. bei mir schient der entscheidende Wert (im Blade400.xml) die Masse zu sein. Bin wie folgt vorgegangen:
1) Kopie der TRex.xml (450er) für den Blade umbenennen
2) nach und nach die Parameter auf das Original umstellen
3) wenn ich den TRex Wert </Mass> von 0.85 (TRex) auf 0.667 (Blade) ändere ist das Problem sofort da und vice versa

Dein Link: weißt du welches die "Texturen" bzw. die Dateien derselben im Beitrag von Husky sind? Ich leider nein.

Kann sehr schnell die entsprechenden Dateien ersetzen, wenn es nicht die Masse sondern die Texturen sind, kann man das schnell herausfinden.

CU
Uli

Hallo,

danke für das Feedback und sorry für die Umstände. ich schau mal heute Abend in Ruhe, was da passiert ist. (Ich dachte, es wird nur noch der Rigid geflogen )

Gruss

Michael

Hallo,

ich habe drei Modelle überarbeitet. Bei den T-Rex 500 waren Texturen falsch, bei den Vision450 wurden Reibparameter überarbeitet. Die Probleme mit dem Blade kann ich nicht nachvollziehen. Gibt es nochmals mehr Details?

http://www.heli-x.info/models/Vision450/Vision450.zip
http://www.heli-x.info/models/TRex500CF/TRex500CF.zip
http://www.heli-x.info/models/TRex500FW/TRex500FW.zip

Gruss

Michael

hubschraubaer wrote: Das war die Macht der Gewohnheit, dass ich Michael direkt angesprochen habe. Wir waren Arbeitskollegen

Hallo Stephan,

wir können uns ja mal zum Fliegen treffen... Nächste Woche??

Gruss

Michael

Hoi Michael

Ja gerne. Der Blade geht gerade wieder
Vielleicht hat es ja auch mal einen windarmen Feierabend. In letzter Zeit war es für mich - trotz der vielen Übung mit heli-x - zu anspruchsvoll.

Ach ja, diese Bälle sind witzig, jetzt noch zwei Tore, dann könnte man mit der EC135-VStabi ein Match in einer Online-Session austragen.

Beste Grüsse
Stephan

P.S.: Zum eigentlichen Problem: Ein kopieren der B400-Dateien aus V1.1 - wo diese super funktioniert haben - in V2.0 hat leider nichts geholfen. Vielleicht kann ich heute Abend mehr testen und Euch etwas unterstützen analog zu Uli. "Leider" habe ich gestern Abend den Rigid entdeckt und dann war aus mit der Fehlersuche

Hallo Michael,

da ich gestern nicht mehr dazu kam, heute eine wenig mehr zum "Blade-Problem" seit Installation des Heli-X Version 2.0.

Da das genannte Problem - absinken der FPS-Rate bis auf null meist nach einigen Sekunden, nach einem Reset durch Crash oder direkt beim Idle-Up - bei mir auf unterschiedlichen Systemen (allerdings beide mit, wenn auch unterschiedlichen, NVidia Grafikkarten) nicht nu beim Modell Blade-400 auftritt, sondern bei recht vielen Modellen, habe ich einfach eine Testreihe über alle nach der Standardinstallation vorhandenen Modelle durchgeführt - vielleicht hilft das, das Problem einzugrenzen.

Alle Modelle wurden wie folgt "getestet".
1) Start Heli-X (Oldeslohe 2007)
2) Auswahl des neuen Modells (warum eigentlich wird da nicht Flugphase=FP 0 geladen?)
3) falls das "Stillstandsproblem" direkt auftrat -> Beenden und Neustart Heli-X (also Laden mit FP 0)
4) Idle-Up 1, falls OK, Idle-Up 2 und 0, dann wieder Idle-Up 1 und Flugtest
5) Flug mit zwei gewollten Crashes:
a) direkt nach dem Start durch mutwilliges Rollen aus ca. 2-3m Höhe,
b) falls nach Reset immer noch OK eine langsame Platzrunde ggf. mit Looping (ca 30-40Sek), dann auf ca. 8 Uhr (da ist eine Baumreihe auf dem Oldesloher Fligfeld) durch gewolltes unkontrolliertes Nicken in größeres Entfernung

I.F. nenne ich jeweils den Punnkt der Testreihe, bei dem es zum Stillstand vonHeli-X (FPS 0, wenn überhaupt noch aktuallistert) kam, ein OK steht sfür, dass das Problem mit dem/den genannten Modellen nicht reproduzierbar auftrat.

• A-109 OK
• AH-6/red OK
• AH-64 OK
• Blade400/HD => 3 und 4, in dem Moment, wo der Rotor von Einzelblatt- auf Kreisdarstellung umschaltet (ca. 850 U/Min)
• DNHPAirfox90AT OK
• Dragonus/C/LD => 5a und 5b (kein Reset)
• EC-135/V_Stabi OK
• EMaxx500 => 3 und 4 (780..900 U/Min)
• FWT/3D OK
• HELIX => 5a und 5b beim Idle-Up nach Reset
• HELIX10S-6x OK
• HELIX450/Night OK
• HoneyBeeKing2-FP OK
• Alle Hurricane550 => 3 und 4 bei ca 800..1200 U/min im Idle-Up
• King2 => 5a, dann 3 bei 100 U/min
• Lama OK
• LittleNelly OK
• Logo600 => 3 und , bei ca. 150 U/min
• MiniTitan/2.4/C OK
• NH90/_VStabi OK
• OEAMTC/_VStabi OK
• Protos => 5a dann 3 bei ca 850 U/min
• Alle Raptor => 3 und 4 bei 960..1100 U/min
• ThreeDee-RIGID/-color/-texture OK
• ThreeDee (NT) => 5b (kein Reset mehr)
• ThreeDee-RIGID/-color/-texture OK
• TRex (450) OK
• TRex500CF/FW/GF OK
• TRex600-6S_C /TRex600FW => 5a und b (kein Reset)
• alle anderen TRex600 OK
• UH-1D => 5b dann 3 (0 U/min, Reset unvollständig?)
• Vision450 OK
• Xynergy OK

Alles Testergenisse konnten auf zwei unterschiedlichen Windows-Systemen (siehe mein Start-Eintrag) reproduziert werden. Auf beiden Systemen wurde als einziger vom Standard abweichender Parameter unter "Leistung" testweise das V-Sync Signal zur Begrenzung der Framerate benutzt. Die FPS-Werte bei funktionierenden Modellen lagen bei Begrenzung durch V-Sync erwartungsgemäß ganz knapp unter den Bildschirm-Wiederholraten.

Interessant ist, dass z.B. das Blade-400 Modell mit dem .XML des TRex ohne Probleme läuft (fliegt dann aber eben auch wie TRex450). Auch nach Anpassung von HaRo und HeRo Distance-Parameter. Die Probleme fangen an, wenn man einen der Parameter ab "<Mass>" zurück auf die originären Blade-Werte setzt.

HTH
Uli