[FS9] Rollreibung MOD

  • Hallo zusammen,


    ich bin gestern irgendwie auf die Idee gekommen, die Rollreibung im Flusi zu verändern, damit man nicht mehr so viel Schub zum Losrollen braucht.


    Also gesagt, getan und das Google Orakel konsultiert: http://www.wcm.at/forum/showth…lwiderstand-152620p3.html



    Das Ganze geht also über die SIM1.dll, die mit einem Hexeditor geöffnet wird und dann bearbeitet wird.


    Und raus kommt eine DLL, die den Rollreibungskoeffizienten von 0.05 auf 0.025 heruntersetzt, was zur Folge hat, dass man nur noch etwa die Hälfte des Schubs braucht, um zu Rollen. Das ist gerade bei großen Fliegern realisitischer, als 50% N1, um überhaupt erstmal aus den Pötten zu kommen :D


    Um wirklich aus dem Quark zu kommen, braucht es im allerersten Moment allerdings immer noch etwas mehr Schub, da der Flusi auch Haftreibung kennt, und diese für gewöhnlich größer, als die Rollreibung ist. Danach kann man aber locker mit ganz wenig Thrust auch große Flieger am Rollen halten.


    Ich habs mit der PMDG 747 getestet: Auf den Flug gibt es absolut keine Auswirkungen, genauso wenig wie auf das Verhalten beim Takeoff. Umso besser ^^



    Ich will allerdings noch ein wenig mit den Werten spielen und ausprobieren, wie es sich bspw. bei 0.03 macht.


    Die DLL hab ich mal hochgeladen, die gehört einfach in den Modules Ordner (vorher die original SIM1.dll backuppen!!!) und dann muss der Flusi neugestartet werden :)


    Download: KLICK!



    Viel Spaß beim Testen! :beer:



    EDIT: Download lüppt auch wieder!

  • Tested (A340-600) und für gut befunden, danke Tömsche :thumbup:


    Ich empfinde das so deutlich realistischer:


    Glaubhafte Breakaway-thrust Werte.+Zwar rollt der Bus deutlich schneller auch in Idle und man muss gut wegbremsen, allerdings denke ich, das dies auch der Realität entspricht. Wenn so ein 350t Hobel erstmal in Bewegung ist .... :D


    Sehr gut.

  • Danke euch! Allerdings hatte ich diese Umrechner auch schon gefunden. Versteh nur nicht so wirklich, wieso 257698.... dann 0.025 ergeben soll. Eventuell teilt der Flusi noch durch 1000, aber das muss ich noch testen :)

  • Vielen Dank Tom. Immer wieder toll, dass man mit solchen "neue" Erkentnissen dem "Realismus" wieder ein Stück näher kommt!!

  • Ja ich find das auch Klasse was ihr da alles so rausfindet und mit uns teilt, auch der Maik mit seinem Treibstoffverbrauch damals, vielen Dank und fettes dickes Bussi! :love:

  • Mein Flusi stürzt beim Laden ab, mit Fehlerverweis auf die sim1.dll...Also nur damit ich nix falsch machen, ich mach ein Backup der sim1.dll, dann lösche ich die originale sim1.dll, dann kopiere ich deine SIM1_edited.dll rein und ändere den Namen auf sim1.dll, richtig?

  • Jep, genauso isses. Es kann aber gut sein, dass in deiner SIM1.dll noch zusätzlich was drin steht, durch nen Addon oder so. Dann müsstest du das manuell editieren bei dir :gruebel:


    Bist du sicher, dass du das FS9.1 Patch draufhast?

  • Weiß jemand, wie man 9999993F in eine Dezimalzahl konvertiert, bzw. umgekehrt?

    Danke euch! Allerdings hatte ich diese Umrechner auch schon gefunden. Versteh nur nicht so wirklich, wieso 257698.... dann 0.025 ergeben soll. Eventuell teilt der Flusi noch durch 1000, aber das muss ich noch testen :)


    Hallo,
    euer Umrechner rechnet nur mit ganzen Zahlen. Was ihr braucht ist ein Umrechner für IEEE-754 Gleitkommazahlen.
    Z.B. hier zu finden (der erste link).
    0.025 ergibt z.B. als 64 bit double-Gleitkommazahl: 3F9999999999999A



    Auf Intel-Prozessoren ist das ganze im Speicher noch paarweise gedreht (Little-Endian/Big-Endian Problematik), so dass die Zahl im Hex-Editor etwa so aussehen müsste: 9A 99 99 99 99 99 99 3F


    Viele Grüße,
    Andreas

  • [...]dass in deiner SIM1.dll noch zusätzlich was drin steht, durch nen Addon oder so[...]


    Bist du sicher, dass du das FS9.1 Patch draufhast?

    Das kann ich mir kaum vorstellen, der Flusi ist quasi jungfräulich...


    Der Patch ist mit Sicherheit drauf ;)



    EDIT: Es klappt. Ich habs nochmal probiert, diesmal die Backup-Datei aus dem Modules-Folder rausgenommen, und schon klappt es...

  • Ich muss den Thread noch mal hochholen, weil ich gerade wieder an den Werten schraube.


    Ich bin aber noch nicht so ganz hinter diese Gleitkommazahlen gestiegen ?(



    Also, ich brauche jetzt z.B. 0.001 als Wert. Wenn ich das umrechne mit dem Rechner, den Andreas oben gepostet hat, dann kommt folgendes als 64bit raus:


    3F747AE147AE147B


    Ich vermute stark, dass ich diesen und nicht den 32bit Wert brauche, wegen folgendem Zitat im WCM Thread:


    Zitat

    Alle Werte sind als 32-bit Double gespeichert (z.B. 99 99 A9 3F für 0.05), bei diesen kleinen Zahlen meist an der Endung 3F zu erkennen


    Auch wenn dort 32bit geschrieben steht, muss es ja 64bit sein, weil ich sonst keine 3F hätte. Scheint ja ein Indikator zu sein :gruebel:



    Das nächste Problem ist, dass die Zahl viel zu lang ist. Denn in der SIM1.dll gibt es immer nur 8-stellige Werte, dieser hier ist aber 16-stellig.


    Ich hab also, wie Andreas oben geschrieben hat, erst das ganze umgedreht und dann die letzten 8 Stellen inklusive 3F genommen:


    E17A743F


    Nur ist das ja irgendwie kein richtiger Wert mehr...?(

  • Hallo Tom,
    sorry, ich war im Urlaub und hab erst grade gesehen, dass du nochmal was zu dem Thema geschrieben hast.


    Ich hab mir grad nochmal Yves Beitrag im WCM-Forum angeschaut. Dort scheint mir einiges durcheinander geraten zu sein. Die Werte, die Yves im Hex-Editor hervorgehoben hat sind nicht vollständig - die jeweils 8 Ziffern vor den fett markierten gehören zu den Zahlen mit dazu.
    840000009999993F --> konvertiert nach Big-Endien: 3F 99 99 99 00 00 00 84 --> 0.025
    8C000000E17AE43F --> konvertiert nach Big-Endien: 3F E4 7A E1 00 00 00 8C --> 0.64
    940000006666E63F --> konvertiert nach Big-Endien: 3F E6 66 66 00 00 00 94 ist 0.7


    Zitat

    Alle Werte sind als 32-bit Double gespeichert (z.B. 99 99 A9 3F für 0.05), bei diesen kleinen Zahlen meist an der Endung 3F zu erkennen


    Diese Aussage ist somit tatsächlich falsch (und macht auch keinen Sinn, da ein double per Definition 64 bit lang ist). 3F ist übrigens kein Indikator für eine 64 Bit Gleitkommazahl.
    Auch die angegebenen Offsetwerte scheinen somit falsch zu sein (jeweils um 4 Bytes verschoben):
    Rollreibungskoeff. ist nicht auf der 48cbc, sondern auf der 48CB8
    Gleitreibungskoeff ist nicht auf der 48cd2 sondern auf der 48CCE
    Bremskoeff ist nicht auf der 48ce8 sondern auf der 48CE4
    Ich vermute mal, dass auch die anderen angegebenen Offsetwerte jeweils um 4 Bytes falsch sind.



    Stimmt, dass kann so nicht funktionieren. Wenn du eine 64 Bit Gleitkommazahl einfach in der Mitte durchschneidest, kommt einfach nur Datenmüll dabei raus. 0.001 müsste FC A9 F1 D2 4D 62 50 3F sein (bereits gedreht in die Intel-Reihenfolge).
    F747AE147AE147B ist übrigens nicht 0.001 sondern 0.005.
    Ich hoffe, ich konnte dir ein wenig weiterhelfen.
    Viele Grüße,
    Andreas

  • Hallo Andres,


    danke für deinen Post. Das hilft mir sehr weiter. Ich hatte schon ne Vermutung, dass da irgendwas nicht gestimmt hat. Nur leider kenn ich mich gar nicht damit aus, daher bin ich froh, wenn ich Experten Hilfe bekomme :)


    Ich werd es mal ausprobieren und dann Bericht erstatten :beer: