Schuhlöffel zu XML-Gauges

2. August 2005

In einem früheren Thread suchte ich Unterstützung in der Absicht, einen Tourenzahl-Einsteller per Mausrädchen zu verwirklichen. Aber nur eine einzige Antwort - Dank an Beat - traf ein und zeigte ungefähr in die Richtung.

Das Thema Gauges (deutsch: Anzeigen aller Art auf einem FS-Armaturenbrett - phonetisch: geitsch, Mehrzahl geitschis) scheint nicht gerade ein beliebtes Thema zu sein - wenig verwunderlich, wenn man sich näher damit befasst.

Die vorgegebene Tastaturbelegung F1...F4 war mir schon bewusst. Als primäre Bedienung würde sie aber bedingen, dass ich meine Linke fast ständig auf der Tastatur behalte - ergonomisch zweifelhaft.

Die Idee bestand also darin, mit der bei mir bereits links neben der Tastatur herumliegenden zweiten Maus bzw. deren Rädli etwas zu machen, so ähnlich wie mit einem separaten Hardware-Schubregler.

So bin ich der Not gehorchend in den Gauges-"Keller" hinunter gestiegen und will hier für Interessierte kurz darüber berichten. Dass ich mich dabei ausschliesslich auf englischsprachige Unterlagen beziehen muss ist bedauerlich, aber scheinbar unvermeidlich.

*****************************

1. Es gibt 2 Sorten Gauges: die ursprünglichen "*.gau"- und die neuen "XML"-Anzeigen. Die *.gau kann man als Anfänger zwar beliebig in eigene Panels einbauen und dabei die Darstellungsgrösse beliebig anpassen, aber man kann sie nicht einsehen und nicht verändern.

2. Die XML-Gauges - mit dem FS2002 eingeführt - sind grundsätzlich anders und transparenter aufgebaut. Mit gewissen Vorkenntnissen bekommt man eine Chance, selber aktiv zu werden.

3. XML ist eine Weiterentwicklung der Websprache HTML und eine Art von Klartext. Der FS benützt aber nur eine spezifische Auswahl. Höchste Instanz ist das M$-Entwicklungspaket "Building Panels and Gauges" (Panels_SDK), aber als XML-Instruktion gänzlich unbrauchbar.

4. Die geduldige Suche im Internet hat einige brauchbare, aber leider ausschliesslich englischsprachige Tutorials ergeben:

4.1 http://www.simviation.com/fsdesign_panels1.htm

Zuunterst auf dieser Website findet sich das Tutorial PDToot.zip eines ungenannten Autors. Es umfasst 10 sorgfältig gestaltete Lektionen mit Beispielen und Übungen. Allerdings befasst sich erst die letzte Lektion auf ca. 20 Seiten kompetent mit den XML-Gauges, kommt aber nicht weit über eine Einführung hinaus.

4.2 http://www.fs2x.com/ , linke Spalte: "Tutorials", führt zu "Making FS9 gauges using XML code" by Nick Pike.

Vorzüglich, mit praktischen Beispielen, aber auch nicht umfassend.

- Teil 1: Main Body Sections, 17 Seiten

- Teil 2: Interaction Sections (Mausbenützung), 10 Seiten

- Teil 3: Variables, 9 Seiten

- Workshop über ein VSI (Vertical Speed Indicator)

Weitere praktische Beispiele sind versprochen...

Online erst seit Juni 2005, d.h. 4 Jahre nach den ersten XML-Gauges!

4.3 http://www.homepages.mcb.net/bones/index.htm

Interessante Website, durchklicken zu:

http://www.homepages.mcb.net/bones/04fs/tutorial/XML.htm

Nicht sehr ausführlich, aber illustrativ.

5. Foren in Englisch

Alle Threads in diesen Foren sind bequem mit der Funktion "Printer-friendly copy" ausdruckbar (jeweils oben links).

5.1 Eine hoch ergiebige Infoquelle ist http://forums.avsim.net/

bzw. dessen "MSFS Aircraft and Panel Design Forum" unter

http://forums.avsim.net/dcboard.php?az=show_topics&forum=122

An erster und oberster Stelle steht da das Thread "XML FAQ".

Weiterhin ergibt die Suche nach "XML" eine ganze Flut von Threads.

Eine amüsante und nützliche Illustration für Anfänger ist:

http://forums.avsim.net/dcboard.php?az=show_topic&forum=122&topic_id=414&mesg_id=414 mit dem Titel: "Stupid beginner (XML)"

5.2 Hilfreich ist auch http://forums.flightsim.com/dc/dcboard.php?az=show_topics&forum=6 , zwar nicht XML-spezifisch, aber mit einschlägigen Threads:

- "Working with XML..." unter

http://forums.flightsim.com/dc/dcboard.php?az=show_topic&forum=6&topic_id=138331&mesg_id=138331

- "XML Gauges and their lo and hi res bitmaps" unter

http://forums.flightsim.com/dc/dcboard.php?az=show_topic&forum=6&topic_id=137269&mesg_id=137269

*****************************

Als Einstieg ist mir immerhin gelungen,

meine Idee mit der Maus-Steuerung des Schubreglers zu verwirklichen.

Das ganze Gauge besteht wie erwartet aus wenigen Zeilen und ist im Gauges-Ordner, Unterordner "MouseInput" als "rpm.xml" abzuspeichern:

............

</Element>

<Mouse>

</Area>

</Area>

</Mouse>

</Gauge>

............

Das ist reines ASCII, quasi "txt", nur Buchstaben und Zeichen ohne Formatierung. Es empfiehlt sich, dazu ein einfaches Textprogramm wie Editor oder Wordpad zu verwenden. Es geht auch mit Word, bedingt aber besondere Sorgfalt.

Ich verzichte auf eine ausführliche Erklärung des Codes, weil es den Rahmen weit sprengen würde - siehe die erwähnte Literatur. Nur soviel zur Funktion: es werden zwei Felder (Areas) nebeneinander gelegt, in denen auf Mausfunktionen gewartet und dann die passende Funktion ausgelöst wird. Die beiden Felder werden auf oder unter den Tourenzähler gelegt und funktionieren trotz ihrer Unsichtbarkeit - siehe die nachfolgenden Bemerkungen zum Hintergrundbild. "THROTTLE_DECR/INCR" bezeichnet den Empfänger beim FS-Kernprogramm, wo die Befehle zur Ausführung übernommen werden.

Wie bereits erwähnt: Die fertige Datei erhält den Namen rpm.xml (rpm = revolutions per minute oder U/min). Notfalls rpm.txt auf rpm.xml ändern! Gespeichert wird rpm.xml in einem Unterordner "MouseInput" im allgemeinen FS-Hauptordner namens "Gauges".

Dann braucht es noch das quadratische Hintergrundbild "Background_100x100.bmp" mit absolut schwarzem Inhalt, RGB 0,0,0. Reines Schwarz wird im FS generell als transparent verarbeitet, ist also wunschgemäss unsichtbar. Die Dimension des bmp sei etwas grösser als das anvisierte Instrument, hier frei gewählt 100x100 Pixel. FS2004 passt das Ganze später automatisch gemäss dem Grösseneintrag in panel.cfg an (siehe gleich nachfolgend).

Background_100x100.bmp wird im gleichen Unterordner bei rpm.xml abgespeichert.

*****************************

In der Konfigurationsdatei panel.cfg des betreffenden Fliegers (in dessen Ordner "Panels") muss nun das rpm.xml unmittelbar vor dem Tourenzähler eingesetzt werden, etwa so:

gauge26=MouseInput!rpm, 8,244,97,90

gauge27=cessna172!Tachometer, 8,244,97,90

"MouseInput!" mit Ausrufezeichen weist auf den Unterordner hin und das rpm auf die darin enthaltene XML-Datei gleichen Namens (es könnten darin auch noch andere sein).

Die Koordinaten (8,244) und Grössenangaben (97,90) der Zeile gauge26 entsprechen hier genau jenen des Tourenzählers (allgemein und fälschlich als Tachometer bezeichnet). Massgebend sind nicht diese Beispielangaben hier, sondern die dort effektiv zutreffenden.

Die Gauge-Nummern müssen einmalig sein, aber nicht unbedingt aufsteigend geordnet. Die cfg-Dateien sind wiederum reines ASCII - siehe oben.

*****************************

Theoretisch müsste es eigentlich bereits funktionieren.

Nach dem Aufstarten des Fliegers erscheint der Mauszeiger im Tourenzähler als Händchen. Die Tourenzahl kann nun wahlweise durch Einzelklick, Dauerdruck oder per Mausrad verstellt werden.

Wird der Mauszeiger in die linke Hälfte des Tourenzählers gestellt, dann ziehen Einzelklick und Dauerdruck den Zeiger nach links, zu tieferer Tourenzahl - und umgekehrt in der rechten Hälfte des Tourenzählers hin zu grösserer Tourenzahl.

Gedankenstütze: der Mauszeiger "zieht" den Instrumentenzeiger.

Leider bedingt (gemäss meinem gegenwärtigen Stand des Irrtums) die FS04-interne Programmierung, d.h. die Verquickung von Einzelklick, Dauerdruck, Rädchen und Vorzeichen, dass die Vorzeichen in den Händchen zur Funktion in dieser Situation verkehrt sind. Aber sie sind ja auch klein genug um nicht sehr zu stören.

Das Mausrädchen hat auf dem ganzen Tourenzähler - unabhängig vom angezeigten Vorzeichen - die gleiche Funktion: ziehen des Rädchens gegen sich reduziert die Tourenzahl - stossen von sich weg erhöht sie. Das entspricht der Funktion des Gaszugs, wie zu beobachten ist.

*****************************

Die Mausbedienung der Tourenzal mit der ansonst unterbeschäftigten linken Hand dient vorwiegend den fortwährenden kleineren Anpassungen. Das ist nun sehr komfortabel, weil nicht ständig über die ganze Tastatur hinweg an den Schubregler des Joysticks gegriffen werden muss. Das aktive Feld ist auch mehrfach grösser als die entsprechende Funktion beim Gaszug und damit wesentlich leichter zu treffen.

Im Gegensatz zu einem Hardware-Schubregler sind die Endstellungen Leerlauf und Vollgas nicht direkt setzbar. Deshalb habe ich zusätzlich die Tasten F1 mit Leerlauf und F2 mit Vollgas belegt. (FS-Bedienfeld -> Einstellungen -> Zuordnungen -> Triebwerkbefehle. Allerdings gibt es da wegen fehlerhafter Übersetzung keinen "Leerlauf". Stattdessen ist "Triebstoffzufuhr stoppen" auf F1 zu legen und funktioniert korrekt als Leerlauf. F3 und F4 bleiben anderweitig verfügbar.)

Übrigens: der Schubregler des Joysticks funktioniert weiterhin und verhält sich in statischer Stellung problemlos. Im ersten Moment einer manuellen Betätigung muss er sich allerdings zuerst quasi "durchsetzten" gegenüber den bestehenden Software-Einstellungen.

*****************************

Ob sich das Ganze in der Praxis bewährt, das muss sich noch zeigen. Aber der Gewinn aus der ganzen Übung bleibt doch gesichert.

Ich hoffe und nehme an, dass meine Ausführungen für einige Besucher/innen von Interesse waren - aber sonst würden sie ja diesen Satz auch nie zu Gesicht bekommen. Kommentare aller Art sowie Rückfragen und Berichte sind willkommen, namentlich auch Hinweise auf deutschsprachige Einstiegs-Unterlagen.

Happy Flying, und happy XML-Bastel!

Heinrich

2. August 2005

Ciao Heinrich

Gratuliere und Danke, dass Du Dein neu erworbenes Wissen mit uns teilst!

[...]Aber nur eine einzige Antwort - Dank an Beat - traf ein und zeigte ungefähr in die Richtung.[...]

"Nur" eine Antwort, die in die richtige Richtung weist ist immer noch tauend aml besser, als 20 Antworten, die allesamt in eine andere, falsche Richtung weisen.....

Gruss Jimmy

2. August 2005

Hallo Heinrich!

Danke für Deine ausführliche Dokumentation. :008: :008: :008:

Mein Vorschlag vorhin wäre eigentlich genau das gewesen, was Du da umgesetzt hast in xml.

Das einzige was Du Dir bei Deiner Umsetzung sparen kannst ist der Event "MouseWheel Flip", der bringt meines Erachtens an dieser Stelle gar nichts. Sollte auch ohne funktionieren. Check it out!!!

Im FS kannst Du per Mousewheel so ziehmlich alle Werte verstellen z.B. Drehknöpfe oder so, muss also nicht extra mit dem Mousewheel Input definiert werden.

XML gauges kann man auf 2 Wege schreiben, kompliziert auf umwegen, oder ganz einfach mit ein paar wenigen Zeilen. Ich bin auf dem Weg sie auf's Minimum zu reduzieren, also wenn möglich immer z.B. ohne Nonlinearity Variablen oder so.

Bei meinem letzten Panel Projekt Tiger F5-E Photoreal habe ich

einige auch in C++ gemacht, also echte .gau Dateien, die meisten aber in xml, kannst ja mal ein Auge voll nehmen auf meiner Homepage :005:

3. August 2005

Gruss, Jimmy und Beat

Ich bin im Nachhinein nicht so sicher, ob die nachwachsenden Turnschuh-Generationen noch wissen, was denn ein Schuhlöffel ist?? :006:

Ich hoffe aber, dass mein "Erfahrungsbericht" manchen Lesern etwas bringt. Schade nur, dass die Referenzen alle englisch sind - gewiss eine massive Hürde. Sehr zu wünschen, dass hier deutschsprachige Literatur genannt wird - so es das überhaupt gibt...

Das einzige was Du Dir bei Deiner Umsetzung sparen kannst ist der Event "MouseWheel Flip", der bringt meines Erachtens an dieser Stelle gar nichts. Sollte auch ohne funktionieren. Check it out!!! Im FS kannst Du per Mousewheel so ziehmlich alle Werte verstellen z.B. Drehknöpfe oder so, muss also nicht extra mit dem Mousewheel Input definiert werden.

Genau. Und nachdem ich auch noch die Up/DownArrow austauschte, stimmen jetzt auch die Vorzeichen in den Händchen. Das hatte sich mit dem MouseWheelFlip gebissen.

Dann habe ich den Code "abgemagert". Aber wer kann das genau wissen, wo gibt es eine schlüssige Dokumentation? Ich kommen mir vor wie vor einem guten Jahrzehnt, als ich mir schon wegen des kuriosen WordBasic die Haare raufte... Das sind halt so freischaffende Künstler in Redmont...

Und das ist die endgültige Fassung:

.............

<Mouse>

</Area>

</Area>

</Mouse>

</Gauge>

.............

Wie ist das eigentlich mit der Gross/Kleinschreibung? Gilt durchgehend die M$/Windows-Usanz, wonach das beliebig ist, oder lauern da weitere Fallen?? Wenn ja, wo?

Schliesslich noch eine Frage: Es gibt das kleine Hilfs-Gauge, um xml-Dateien editieren, speichern und neu ins Panel laden zu können, ohne dazu den FS immer neu zu starten.

.............

<Mouse>

<Click>(>K:RELOAD_PANELS)</Click>

</Area>

</Mouse>

</Gauge>

.............

Das r.bmp ist ein reguläres 20x20px-Bildchen mit einem grossen R für Reload. Organisation wie oben, d.h. gemeinsamer Ordner, und in das panel.cfg kommt die Zeile: gaugexx=ReloadGauges!Reload, 412,226,20,20 Aber ich bringe es auch nach Stunden kreuzweisen Pröbelns nicht dazu, dass das R auf dem Panel angezeigt und die Funktion ausgeführt wird. Wo liegt da der Hund begraben?

Bei meinem letzten Panel Projekt Tiger F5-E Photoreal habe ich einige auch in C++ gemacht, also echte .gau Dateien, die meisten aber in xml, kannst ja mal ein Auge voll nehmen auf meiner Homepage

Das habe ich gemacht - ganz gewaltig - wow!! Das ist für mich jenseits der Schallgrenze. Ich halte mich vorläufig an den einfachen Hausgebrauch und werde auf C+Co wohl verzichten.

An Jimmy einen schönen Gruss nach Gonzbu!

Immer dankbar für aufmunternde Hilfe

Heinrich aka flowe

4. August 2005

Hallo Heinrich!

Dein Gauge funktioniert nicht weil Du einen Schreibfehler hast!

Du hast Aera, statt Area geschrieben in der vierten Zeile!

Kleiner Tipp, öffne Deine XML Gauges immer noch im Internet

Explorer zur Kontrolle, weil dort eben solche Fehler angezeigt werden.

Soviel zu schreibfehlern in xml :009:

Wichtig ist auch dass Du immer noch ein ImageSizes = hinzufügst!!!

<Mouse>

<Click>(>K:RELOAD_PANELS)</Click>

</Area>

</Mouse>

</Gauge>

4. August 2005

Achja....soweit ich weiss ist xml nicht Gross/kleinschreib-sensitiv,zumindest was die Benennung von Bitmaps angeht soviel ich weiss. Beim C++ schauts dann anders aus, dort ist z.B. eine Variable var, nicht gleich einer Variable Var. Generell kann man aber sagen dass man bei Variablennamen immer vorsichtig sein muss, schleichen sich doch rasch etliche Fehler ein. ;)

5. August 2005

Tja, die Schreibfehler... es ist eben nicht eine Aera (=Zeitraum), sondern ein Area(l =Fläche). Gute Gedankenstütze. Neckisch sind auch: Right, Height – Length, Width.

Darüber hinaus gab es einen Doppelfehler: das bmp hatte ich irrtümlich mit rle (run length encoding) abgespeichert, und das kann er nicht aufmachen. Jetzt klappt es. :009:

Es gibt übrigens 2 funktionierende Varianten für das Reload:

als auch

<Click>(>K:RELOAD_PANELS)</Click>

wobei mir die erste zur Zeit noch besser verständlich ist.

Zur Benützung des Reload: Man muss das Reload-Gauge vorerst einmal betätigen. Dadurch werden die im Panel aktiven Gauges von ihren Dateien abgekoppelt. Dann den FS mit der Windows-Taste minimieren und erst anschliessend die Datei im Editor aufmachen. Jetzt kann der editierte Code auch gespeichert werden, und mit dem nächsten Reload wird das aktive Gauge aktualisiert. Unterlässt man das erste Reload, dann sperrt Windows das Überschreiben der Datei.

Übrigens wird der Vorschlag gemacht, das Reload-bmp ganz oben links ins 2D-Panel.cfg zu schreiben, also etwa "gauge00=ReloadGauges!Reload, 5,5,10,10". Finde ich hübsch und praktisch.

Zur Gross-/Kleinschreibung: Ich habe dazu in den "Normen" nachgeforscht (Selfhtml bzw. W3C). Wörtlich: "XML unterscheidet in Gegensatz zu HTML strikte zwischen Gross- und Kleinschreibung." Aber das gilt natürlich nur ausserhalb von Redmont. Dort treffen sich halt Genie mit entsprechender Disziplin und subversiver McKinsey-Strategie: Verwirre den Kunden! Konsequenz: man ist verunsichert...

Ich habe mittlerweile eine Quelle von deutschsprachigen XML-Stoffen (neben Selfhtml) gefunden: http://www.user-archiv.de/index.php?seite=web_xml_alles . Da wird mir nun langsam klar, was das "gauges.xdr" im Panels-SDK bedeutet: Es ist ein offiziell so genanntes "Schema", die in diesem Fall von M$ erstellte Liste von Befehlen, die der von M$ selber geschriebene FS-XML-Decoder (alias Parser) bezüglich Gauges überhaupt versteht. Schöne Theorie - wird sich weisen, wieviel das in der Praxis wert ist. Wenn man den M$-Stil seit bald 20 Jahren kennt...

Das "eXtensible" in XML betrifft auch nicht uns als Enduser, sondern allein die Programmierer der Anwendung. XML ist eben nicht eine Programmiersprache, sondern eine Art übergeordneter Grammatik, mit der dann die Applikation geschrieben wird. Uns bleiben nur die konkreten Regeln im "Schema", multipliziert mit der Sorgfalt von Umsetzung, Pflege und Vermittlung.

Gemäss "gauges.xdr" ist z.B. das ' Version="1.0" ' in der ersten Zeile zwingend - aber es geht auch bestens ohne, während das ' ImageSizes="xx,yy" ' fakultativ ist. Allerdings beziehen sich die Dimensionen im "Area" auf die wahre Pixel-Grösse des bmp. Um sich diese vor Augen zu behalten ist die ImageSizes-Angabe durchaus sinnvoll. Das Gauge als Ganzes wird schliesslich im panel.cfg auf die dort festgelegte - und veränderbare - Grösse umgerechnet - wie oben z.B. auf 10x10, ist noch gross genug.

Beat, deine Arbeiten:008: lassen mich vermuten, dass ich da Wasser in den Rhein (ehhmm... da wohnen doch die Bebbis?) trage. Ich hoffe aber, dass einige ausser-basler Leser/innen davon einen Nutzen haben. Den ersten Nutzen habe ich allerdings selber, wenn ich mir überlegen muss, was ich überhaupt schreibe. Egoist! :)

Gute Zeit!

Heinrich alias flowe

5. August 2005

Hallo Heinrich :008:

hmm.....interessant :005: also nochmals zurück zu Deinem Tool, bezw. Reloadgauge. Also für mich hört sich das ganze etwas kompliziert an, wahrscheinlich auch weil ich nach meinen 3 Wochen Ferien nun die erste "nach den Ferien Depressionswoche" hinter mir habe :002:

Ich benutze diese Tool; KLICK

Dort mache ich einfach meine Änderungen im xml File, lade bezw. überschreibe das File im Gauge Ordner im FS, lade das Flugzeug neu ohne den FS neu zu starten und das wars dann auch schon.

Es gibt Situationen wo es nicht funktioniert, je nach Änderung die man im xml getätigt hat. Ich hab mich ziehmlich gut mit dem Tool angefreundet und komme echt gut zurecht damit.

Natürlich gibt es verschiedene Varianten wie man die Files in den FS rüberbringt, da hat jeder Designer seine vorlieben :)

Ein schönes Weekend wünscht Dir ein Bebbi, der immer offen für neue xml-Inputs ist :008:

5. August 2005

[...]An Jimmy einen schönen Gruss nach Gonzbu!
[...]

Danke!

... mal einer, der nicht im Michelsamt wohnt und doch weiss, wie man den Namen der Gemeinde ausspricht, die den Landessender beheimatet;)

Heimweh- Michelsämter?

Gruess Jimmy

17. August 2005

Hoi Heinrich

Vielen Dank für die Einführung.

Ich bin auch gerade dabei, mich in die Panel Entwicklung einzuarbeiten. Da kommt deine Anleitung sehr gelegen und wird mir bestimmt sehr hilfreich sein.

Gruss, Toby

18. August 2005

@Toby: wenn es da also tatsächlich konkrete Interessenten wie dich gibt, dann kann ich ja an der bereits angefangenen - und dann liegen gebliebenen - Fortsetzung weiterstricken...

@Jimmy: nicht gerade im Michelsamt aufgewachsen, aber im westlich angrenzenden. Du solltest wohl eine Spende machen für einen Kessel Farbe, ansonst der Landessenderturm gelegentlich abgerissen wird...

@Beat: Ich habe deinen PC-Schreck mitverfolgt und bin froh, dass er sich offenbar in Wohlgefallen aufgelöst hat. Und das nicht nur, weil ich das genau gleiche Mainboard habe. Anfänglich hatte ich grosse Mühe damit, aber heute ist es aus meinem Bewusstsein entschwunden. Darüber hinaus sichere ich System und Daten systematisch - ich will mich hier nicht darüber auslassen, bei Interesse schickst du mir ein Mail.

@Beat:

...Reloadgauge. Also für mich hört sich das Ganze etwas kompliziert an, wahrscheinlich auch weil ich nach meinen 3 Wochen Ferien nun die erste "nach den Ferien Depressionswoche" hinter mir habe

Nachdem du diese kritische Lebensphase mit Ferienstress, Depression und PC-Schreck wohl überstanden hast, komme ich nochmals auf das Reload zurück - einfach im Sinne eines Berichts, und wie immer: hoffentlich auch von Interesse für stille Mitleser.

---------------------------

Ich habe in der Zwischenzeit einiges am Panel meines Privat-RealAirC172 gebastelt und dabei die Situation besser kennen und das Reload-Gauge sehr schätzen gelernt. Es ist wirklich sehr elegant.

Die cab-Dateien sind in keiner Weise zwingend - cab ist einfach das M$-eigene Kompressionsformat für ganze Ordner, sinngemäss wie zip und auch vielfach innerhalb von Windows eingesetzt. Beide sind auch interessant, weil der Inhalt besser gesichert ist. XP und FS04 können die einzelnen Dateien direkt im cab lesen. Der Total Commander ( http://www.ghisler.com ) kann zips wie cabs auf Mausklick quasi virtuell zur Besichtigung öffnen, und ebenso die enthaltenen xml-Dateien. Ich kann den TC allgemein nur wärmstens empfehlen.

Regulär mit TC entpackt entsteht aus einem cab-Packet ein völlig regulärer Ordner. Das cab bleibt dabei bestehen und sollte zur Vermeidung von Frust z.B. mit einem angehängten Unterstrich unterscheidbar gemacht werden. Beim Aufruf aus dem panel.cfg heraus wird nämlich nur der Name ohne die Extension cab benützt, und wo FS dann tatsächlich zugreift, das bleibt ohne Unterscheidungsmerkmal dem Zufall überlassen.

Im regulären Ordner kann man natürlich auch die einzelne xml-Datei regulär öffnen und - solange sie nicht vom FS "besetzt" gehalten wird - auch wieder speichern. Und da kommt das Reload zum Zug: es entkoppelt die geladenen Gauges von ihrer Stammdatei, die nun - im Fall von xml - beliebig geöffnet, bearbeitet und wieder gespeichert werden können. Reload ist übrigens eine originale M$-FS-Funktion - siehe Code.

Nun kommt der alte Trick: mit Alt+Tab kann man frei zwischen den Anwendungen, d.h. hier zwischen Editor und FS wechseln. Im FS klickt man noch das "R"-Symbol und das geänderte Gauge wird in einem Sekundenbruchteil geladen. Wieder im Editor steht der Cursor noch am gleichen Ort, und mit Ctrl+Z kann man sogar die letzten Verschlimmbesserungen gleich wieder rückgängig machen. Beim Pröbeln ist das Verfahren blitzschnell.

Zusammenfassend:

1. cab zu einem regulären Ordner (bei mir mit TC) und mit Unterstrich unterscheidbar machen.

2. FS starten, Gauges mit Reload von den Dateien abkoppeln, FS mit Windows-Taste minimieren.

Vorher mit Vorteil in den FS-Einstellungen/Allgemein die Option "Pause bei Anwendungswechsel" abwählen (sonst muss man immer das "P" lösen), sowie aktuell nicht benötigte andere Anwendungen schliessen.

3. Im Editor das xml-File aufmachen, bearbeiten und speichern - nicht schliessen.

4. Mit Alt+Tab in den FS springen und die Änderung mit Reload laden.

5. Mit Alt+Tab beliebig hin und her springen.

Der bereinigte Reload-Code:

<Mouse>

<Click>(>K:RELOAD_PANELS)</Click>

</Area>

</Mouse>

</Gauge>

Das "Reload_20x20.bmp" kann unauffällig oder ein poppiges "R" sein, nur darf es nicht mit rle komprimiert abgespeichert werden.

Die Grössenangabe im bmp-Namen ist meine private Vorliebe und dient nur der Eigeninformation. Die reale Grösse dieses bmp bestimmt nämlich die sog. "Leinwand" des ganzen Gauges, und alle Massangaben im Code beziehen sich darauf - hier z.B. Area/Width/Height. Die Massangaben im Dateinamen informieren mich bereits in einem Verzeichnis, ohne das xml aufzumachen, und gelegentlich kann man sowas andernorts wieder brauchen. Die bmp-Dimensionen sind quasi die Konstruktionsmasse, die man im panel.cfg in Länge und Höhe noch verschieden skalieren kann.

Hingegen ist die oft vorhandene Angabe ' ImagesSizes="xx,yy,zz,uu" ' rein historisch, weil früher 2 verschiedene Grössen in den Ordnern 640 und 1024 bereitgestellt werden mussten. Bei Monitoren ab 1024 Pixel Breite ist diese Angabe völlig ohne Bedeutung: xml- und bmp-Dateien wohnen im gleichen Ordner. In den M$-FS04-cabs ist allerdings die alte Struktur mit ImageSizes/640/1024 teils noch erhalten, damit sie auch auf kleineren Bildschirmen laufen. Aber das kann man problemlos vereinfachen.

Die "Case Sensitivity", d.h. die Gross-/Kleinschreibung, ist kurios:

- Die <Tags></Tags> verlangen keine definierte Schreibweise: Gauge oder gauge oder GAUGE - alles ein Ding. Aber jedes einzelne Paar muss zwingend bei der Öffnung wie Schliessung identisch geschrieben sein, ansonst sie nicht als zusammengehörig erkannt werden und das Gauge schlicht nicht ausgeführt wird.

- Alle Attributnamen wie X="", Name="", Left="" oder Type="" etc. müssen zwingend mit einem Grossbuchstaben begonnen und der Rest klein geschrieben werden (und die Attributwerte müssen unbedingt in Anführungszeichen stehen - im Gegensatz zu HTML, wo es bestens ohne geht).

- Bei den Interaktionen zwischen dem Gauge und FS wird es noch neckischer. Im obigen Code muss K:RELOAD_PANELS durchgehend gross geschrieben werden, während in meinem AGL-Anzeiger 'A:Radio Height, feet' sowohl in dieser gemischten Schreibweise als auch durchgehend gross akzeptiert wird.

- Dateinamen und Erweiterungen wie 'Reload.xml' dürfen wie üblich beliebig geschrieben werden.

- Konsequenz: grundsätzlich Substantiv-Schreibweise mit grossem Anfangsbuchstaben verwenden, aber die FS-Interaktionen durchgehend in Grossbuchstaben. Ausnahmen vorbehalten...

---------------------------

Ausser dem RELOAD habe ich die oben erwähnte Maus-Drehzahlsteuerung weiter entwickelt - das ist mit der 2. Maus in der linken Hand hochgradig praktisch. Weiter hat sich die Digitalanzeige für die Höhe über Grund (AGL) im hiesigen Gelände als virtuell besonders gesund erwiesen. Aktuell ist noch eine digitale PitchTrim-Anzeige mit wählbaren Presets in Arbeit. Also lauter so kleine Sachen ohne besondere grafische Anforderungen - Anfängerübungen eben.

---------------------------

XML oder C&GAU? - fragte Toby im parallelen Thread. Dazu ein paar Gedanken: Erstens ist XML ein Mega-Trend, wie auch der Umstieg von M$ zeigt. Ein wichtiger Grund unter vielen ist wohl, dass XML Klartext und darum leichter zu handhaben ist - wie oben aufgezeigt. Hingegen ist bei C&GAU die erforderliche Compilierung umständlich und macht die Lernkurve unnötig steiler. Schliesslich ist die gau-Datei nicht transparent, was sie allerdings auch vor Neugierde schützt. Es scheint insgesamt wenig sinnvoll, nur für FS-Zwecke heute noch mit C anzufangen - das Bessere ist der Feind des Guten.

XML-Programme? Weder nötig noch sinnvoll. In allen Foren wird überwiegend einfachen Editoren wie etwa dem Windows-eigenen notepad.exe der Vorzug gegeben. Komfortabler ist (unter vielen anderen) das Freewareprogramm Notepad++ ( http://notepad-plus.sourceforge.net/de/site.htm ) in deutscher Sprachversion. Seine Hauptvorteile sind die schön gegliederte, farblich unterstützte Darstellung sowie Zoomfunktion Ctrl+Mausrad und Register wie beim Firefox.

XML-Dokumentation? Verstreut, unsystematisch und praktisch nur in Englisch. Das liegt wohl an der lauen Motivation von M$. Oberste Instanz bleibt das spröde Panels_SDK (Software Development Kit) von 2004. Darüber hinaus habe ich oben, im ersten Posting dieses Threads, bereits einige Hinweise gegeben. Bezüglich FS-XML-Tutorials ist für mich der Nick Pike auf http://www.fs2x.com erste Wahl/Hilfe (im Moment offline - kommt wohl wieder).

Dann ist Arne Bartels eine Art Guru und in vielen (englischen) Foren präsent. In seiner älteren Datei XMLGAU01.zip (Google!) erklärt er u.a. die XML-Rechenweise mit Stackregister, wie bei den früheren HP-Taschenrechnern. Das übliche "10 * 10 = 100" wird zu "10 10 * macht 100" - wer das kennt, der liebt es. Viele im FS übliche Operatoren hat Bartels aufgelistet, und sie stehen natürlich auch im SDK-doc, Seite 80ff.

Eine vorrangige, wenn auch komplexe Informationsquelle sind die praktischen Beispiele in beech_baron.cab und boeing747-400.cab im Gauges-Ordner von FS04, ebenso wie die vielfältigen Beispiele in Foren aller Art.

Letzlich ist XML gedanklich/logisch wohl kaum einfacher als C&GAU, aber viel besser einseh- und handhabbar und allein schon darum zukunftsträchtiger.

Neben der Codierung steht gleichrangig die grafische Gestaltung - ziemlich ausführlich beschrieben im SDK-doc ab Seite 84. Hilfreich sind Erfahrung in Digitalfotografie und damit im Umgang mit Programmen wie Photoshop (sehr teuer) bzw. Paint Shop Pro und ähnlichen (preiswert). Für einfache Aufgaben soll auch Windows Paint den Dienst tun - ich habe das nicht ausprobiert.

Ich schreibe hier als XML-Anfänger, der gerade den Schuhlöffel weggelegt hat. Gerade deshalb sind meine Ausführungen vielleicht für andere von Nutzen. Rückfragen sind willkommen - aber in Grenzen, wenn ich realisiere, was andere Leute so machen - Beat etwa.

Mit freundlichem Gruss

Heinrich alias flowe

21. August 2005

Hallo Zusammen!

Danke Heinrich für Deine exzellenten Ausführungen, auch für mich wieder mal gut solche Dinge ins Bewustsein zu rufen. :009:

Wie Du schon erwähnt hast bietet die XML grenzenlosen Einblick in den Aufbau für jeden. Für mich macht es darum wenig Sinn die Gauges zu copyrighten und habe mich darum bei meinen Gauges dafür entschlossen, im read me zu erwähnen, dass man damit tun kann was man will. Ich denke auch ich hab schon viel von anderen Programmierern profitieren, oder Dinge eins zu eins übernehmen können. Darum möchte ich den Einblick und die Verwendung auch für alle offen lassen. :007: Einzig die Panel BMP's dürfen nicht für andere Zwecke verwendet werden :005:

Bei den gau. Dateien schaut's dann anders aus, obwohl man die Dinger zum Teil auch mit einem Tool knacken kann, um zumindest die Bitmaps auszutauschen.

Darum verwenden wohl auch die meisten Payware Designer diese Form der C++ programmierung, damit nicht jeder Grenzenlos damit machen kann was er will. :rolleyes:

Was wohl noch erwähnenswert ist beim xml gegenüber dem C++:

Es gibt ein paar wenige Einschränkungen, bezw. Dinge die im xml nicht gehen. :eek:

Man kann in XML z.B. keine wirklichen Vektorgraphiken zeichnen, außerdem kann man nicht mit Dateien arbeiten(z.B. dass man den Stundenwert des Motors in eine Datei schreibt und somit alle Stunden zusammenzählen kann und beim nächsten Flusistart wieder abrufen kann). :o :001:

Ansonsten kann man eigentlich XML und C++ als gleichwertig ansehen. :008:

Was ich beim Zusammenfassen von verschiedenen XML Gauges festgestellt habe ist dass die Performance des Flusis extrem drunter leidet. Anscheinend ist es für den Simulator einfacher 50 einzelne xml cab Dateien zu öffen und zu lesen, anstatt eine cab Datei mit 50 Instrumenten drin.

Ich hab beim neuen Tiger beide Versionen ausprobiert, 2 Cab's oder eben 50 einzelne kleine Cab Dateien. Bei den 2 Cab's stürzte dann schlussendlich der Flusi ab. :confused:

Dies nur so nebenbei, vielleicht hat jemand andere Erfahrungen gemacht...

21. August 2005

Hallo Beat,

nur kurz eine kleine Anmerkung von meiner Seite.

"Man kann in XML z.B. keine wirklichen Vektorgraphiken zeichnen,"

Das geht ohne Einschränkung. Schau Dir mal das GPS Gauge an. Hier ist fast alles mit Vektoren erstellt. Des weiteren gibt es im Avsim Forum bereits etliche Tips wie sich auch komplexere Elemente mit Vektoren anstelle Bitmaps realisieren lassen (HSI, ADI, komplexe Kurven, usw.). Hier gibt es in XML keinerlei Einschränkung gegenüber C.

"außerdem kann man nicht mit Dateien arbeiten(z.B. dass man den Stundenwert des Motors in eine Datei schreibt und somit alle Stunden zusammenzählen kann"

Das stimmt, allerdings gibt es eine Interim-Lösung von Doug Dawson. Diese läßt zu, dass L: Variable via einem C gauge in eine ini Datei geschrieben werden, von der sie sich auch wieder auslesen lassen. Die Funktionsweise ist ähnlich seinem Sound Gauge, d.h. Du kannst L: Variablen definieren die dann, unabhängig von der Unit, geschrieben und gelesen werden. Das von Dir erwähnte Gauge zum Schreiben und Lesen der Betriebsstunden des Motors ist somit möglich wenn Du die ausgelesene Betriebsstundenzeit temporär nach dem Laden in einen Zwischenspeicher nimmst und die neuen Stunden der selben Variablen hinzuzählst, die dann wieder beim Verlassen gespeichert werden. Resetten kannst Du sie mit einem einfachen Button der dieser Variable wieder den Wert 0 zuweist.

Leider hat Doug dieses Gauge nie offiziell veröffentlicht (dsd_xml_config.zip), Du findest es aber in Rob's COP Paket rcbco-20.zip auf Avsim. Mit etwas Handarbeit, kannst Du es Deinem Bedarf anpassen. Prinzipiell kann man mit XML Variablen schreiben und lesen. Leider hat MS die entsprechenden Befehle nicht in die dll Dateien integriert, weshalb sie, wenn vorhanen, ignoriert werden. Ist aber nur eine Frage der Zeit bis das geht.

"Bei den 2 Cab's stürzte dann schlussendlich der Flusi ab."

Das liegt aber sicherlich nicht an der Anzahl der verwendeten XML Dateien. Bei meinem letzten Panel habe ich weit über 150 XML gauges in einer Cab Datei (insgesamt 1100 Elemente mit Bitmaps). Das dauert zwar beim Laden des Flugzeuges etwas, aber danach keine Einschränkung auf die Frames (und ich habe wirklich einen sehr sehr langsamen Rechner der bereits einige Jahre alt ist). Wenn Du die Ladezeit verringern möchtest, kannst Du alle Dateien auch ohne Packen in eine Cab Datei in einem separaten Ordner (sonst wird's unordentlich :-)) im Gauges Ordner aufrufen. Musst lediglich den Link in der Panel.cfg korrekt setzen. Das spart enorm Zeit beim Laden. Packen in Cab Dateien ist nicht zwingend erforderlich.

Gruß

Matthias

21. August 2005

XML oder C&GAU? - fragte Toby im parallelen Thread. Dazu ein paar Gedanken: Erstens ist XML ein Mega-Trend, wie auch der Umstieg von M$ zeigt. Ein wichtiger Grund unter vielen ist wohl, dass XML Klartext und darum leichter zu handhaben ist - wie oben aufgezeigt. Hingegen ist bei C&GAU die erforderliche Compilierung umständlich und macht die Lernkurve unnötig steiler. Schliesslich ist die gau-Datei nicht transparent, was sie allerdings auch vor Neugierde schützt. Es scheint insgesamt wenig sinnvoll, nur für FS-Zwecke heute noch mit C anzufangen - das Bessere ist der Feind des Guten.

Hoi Heinrich

Da ich mittlerweile schon mehrmals ein Jahrzehnt alltägliche Berufsrefahrung mit C/C++ habe, und C++ als meine "Muttersprache" betrachte, muss ich sie zum Glück nicht mehr lernen.

Wie sieht es denn eigentlich bezüglich der Performance aus? C/C++ ist ja eine Compilersprache, der compilierte Code muss nur noch ausgeführt werden. XML hingegen ist eine Interpretersprache. Wird der XML Code vor jeder Ausführung wieder neu übersetzt, oder nur einmal beim Laden? Kann man sagen, ob und wieviel XML Gauges langsamer sind als C/C++ Gauges?

Gruss, Toby

Schuhlöffel zu XML-Gauges

Empfohlene Beiträge

flowe

Link zu diesem Kommentar

Auf anderen Seiten teilen

Micky Miranda

Link zu diesem Kommentar

Auf anderen Seiten teilen

Isra

Link zu diesem Kommentar

Auf anderen Seiten teilen

flowe

Link zu diesem Kommentar

Auf anderen Seiten teilen

Isra

Link zu diesem Kommentar

Auf anderen Seiten teilen

Isra

Link zu diesem Kommentar

Auf anderen Seiten teilen

flowe

Link zu diesem Kommentar

Auf anderen Seiten teilen

Isra

Link zu diesem Kommentar

Auf anderen Seiten teilen

Micky Miranda

Link zu diesem Kommentar

Auf anderen Seiten teilen

Toby-SRMD11

Link zu diesem Kommentar

Auf anderen Seiten teilen

flowe

Link zu diesem Kommentar

Auf anderen Seiten teilen

Isra

Link zu diesem Kommentar

Auf anderen Seiten teilen

Matthias Lieberecht

Link zu diesem Kommentar

Auf anderen Seiten teilen

Toby-SRMD11

Link zu diesem Kommentar

Auf anderen Seiten teilen

Dein Kommentar

Forum

Die ILS

Events

Benutzer

Flightsim Weekend