Hallo,

ich bin überzeugt, das man eine Chance hat, wenn man sich auf die Spezifikation der Schnittstelle beschränkt. Man definiert, wie die Datenpakete aussehen, die vom und zum FlightSim laufen.
Dabei muss man natürlich so abstrakt konzipieren, das es hardwareneutral (Serial, USB, TCP) und erweiterungsfähig wird.

Dann kann nämlich jeder sein Instrument mit dem Werkzeug seiner Wahl, von VB bis Assembler stricken. Das jeweils beste seiner Gattung wird sich dann als Nonplus Ultra durchsetzen.

Auf der Serverseite benötigt man dann ein Interface (modules unter MSFS) das diese Schnittstellen bedient.

Ich wäre bereit, eine solche Schnittstelle zu konzipieren und als OpenSource zur verfügung zu stellen. Als Zielgeräte sehe ich einfache Microcontroller mit mechanischen Anzeigen und Linux oder Windows PC's mit dem grafischen Krempel.


Gruss Dirk

Hallo Dirk,

"ich bin überzeugt, das man eine Chance hat, wenn man sich auf die Spezifikation der Schnittstelle beschränkt. Man definiert, wie die Datenpakete aussehen, die vom und zum FlightSim laufen.
Dabei muss man natürlich so abstrakt konzipieren, das es hardwareneutral (Serial, USB, TCP) und erweiterungsfähig wird.
ich kann Deinen Gedanken gerade nicht ganz folgen, da du das Thema Hardware mit einbringst. An welcher Stelle denkst Du, dass eine Hardwareanbindung Sinn macht und notwendig ist? Es ist natürlich klar, dass Hardware à la FSBUS angeschlossen werden muss, damit man was zu schalten hat. ;) Aber ich dachte dabei an eine Dreiecksbeziehung mit dem Flusi als zentralem Glied, an das sich einerseits Hardware anklemmt und andererseits Software wie ein Glascockpit.
Oder sprichst Du hier Probleme der Art "wie kann ich FSBUS und Project Magenta koppeln"?

"Dann kann nämlich jeder sein Instrument mit dem Werkzeug seiner Wahl, von VB bis Assembler stricken. Das jeweils beste seiner Gattung wird sich dann als Nonplus Ultra durchsetzen."
Auch keine schlechte Idee, die Instrumente Sprachenunabhängig zu ermöglichen.

Ich habe mir OpenGC mal flüchtig angesehen und finde das grundsätzliche Konzept gut. Dort gibt es einen Kern, an den auf der einen Seite eine Flusischnittstelle wie z.B. FSUIPC angebunden wird (aber auch beliebige andere Schnittstellen/Flusis) und auf der anderen Seite dann beliebige Instrumente/Flugzeugtypen auf dieser Basis entwickelt werden können. Deine Idee wäre dann also, eine Hardwareschnittstelle als dritte Komponente mit ins Spiel zu bringen, damit Systeme wie FSBUS vollen Zugriff auf die Funktionen des GC haben - richtig?

"Auf der Serverseite benötigt man dann ein Interface (modules unter MSFS) das diese Schnittstellen bedient."
Verstehe ich nicht. Reicht es nicht, auf FSUIPC als Flusi-Modul zuzugreifen? Was müsste dieses Modul können/zur Verfügung stellen?

"Ich wäre bereit, eine solche Schnittstelle zu konzipieren und als OpenSource zur verfügung zu stellen. Als Zielgeräte sehe ich einfache Microcontroller mit mechanischen Anzeigen und Linux oder Windows PC's mit dem grafischen Krempel."
Hier sprichst Du jetzt aber nicht von FSBUS, oder? Mir ist nicht ganz klar, warum hier zusätzliche Hardware notwendig ist. Könnte man das nicht auch über FSBUS erledigen?

Finde ich klasse, dass Du in Form einer Schnittstelle mitmachen würdest. Aber mir ist noch nicht genau klar, was diese Schnittstelle umfassen würde.

Gruss,
Ollie.

Meine Mutter hat mal gesagt: "Jung, hals Dir keine Arbeit auf, die nicht nötig ist!" Tja, eigentlich hat sie da ja recht, aber dieser Thread hat mich irgendwie inspiriert!:eek: :eek:

Da ich ja nunmal leider keinerlei Ahnung von Programmiersprachen habe (wenn man mal das alte Commodore Basic vergisst:D :D )könnte ich mich aber anbieten, einen Teil der Nav-Datenbankprogrammierung zu übernehmen, wenn mir jemand das nötige Format mitteilt.

Warum braucht man ein Datenformat ?

Klar kann man von einem Altimeter die Daten direkt vom fsuipc abholen.
Das bedeutet aber Abhängigkeit von fsuipc von widefs von Microsoft, vom Flusi usw.
Wenn man im Netzwerk von jeder beliebigen Stelle an jeden Flusi, ob MS oder XPlane oder was weiss ich was andocken kann, wäre das doch irgendwie toll.

Wenn ein Haufen Instrumente von genausovielen Leuten in Jahren erstellt wurden und dann kommt ein Update irgendeiner Abhängigkeit, haste einen Haufen nicht mehr zu gebrauchender Dinge.
Haste ne Schnittstelle, passt du die an und voila fertig.
Mit dieser Methode konnte ja fsuipc schon von FS98 bis 2004 wunderbar überleben.

Ausserdem kann man ja hoffen, das so ein Interface irgendwann einmal von den Flusi Herstellern selbst unterstützt wird.

Gutes Interfacing findet man bereits in X-Plane.

Gruss Dirk

Aber das Iface von X-Plane zu nutzen bringt dir auch nichts.

Aber so ein Gedankenspiel hatte ich auch schonmal.
Nen Zentraler Daten-Server, von dem man alle informationen bekommen kann. Wenn Daten von den Simulatoren Fehlen, kann man ja mit Scriptsprachen weiterarbeiten.(am besten Linux, ohne X oder sonstigem gefrimsel)

Dann Clients, die die ganzen Displays malen und input-clients, die Joystickbewegungen Tastendrücke etc interpretieren und dem Hauptserver widerum sagen: setze mal das dies und hasse nicht gesehen.
So kann man wunderbar modular nen GC aufbauen. Dafür reichen auch nen paar Rechner mit jeweils 400 oder 500mhz.

Aber mal ganz erlich, ein opensource Glasscockpit auschließlich für Ms Fs konzipiert? :lol:

Der arme FlightGear

Karsten

Glass Cockpit Software
 

Alle, die für die Gemeinschaft Software schreiben, und das dann auch noch unentgeltlich, haben meine größte Anerkennung.

Und auch die, die lange in ihrem stillen Kämmerlein sitzen, prima SW entwickeln, und dafür einen geringen Preis wollen.

Wenn es allerdings nur nach Profit riecht - dann stinkts !

Mal was ganz anders : ich bin nach viel basteln mit meiner Canadair nun auch bei PM RJ angekommen. Habe die Systeme mit viel Hardware gebaut, .... und doch vermisse ich etwas, was kein Glass Cockpit Projekt, ob nun Free - oder Payware bietet : dass ICH entscheiden kann, was ich auf den Rechnerclients alles anzeige.

Darum meine Idee : ( und vielleicht gibts das schon- und ich weiß es nicht ) : eine Software, mit der ich *.GAU oder *.XML Files aus dem FS nach belieben auf einem Client betreiben kann. Dann könnte ich mit jedem einfachen Paneldesigner soviele Monitore mit Gauges befeuern wie ich will. Diese Gauges reichen nämlich vielen Leuten aus, und es gibt für jeden Flugzeugtyp die Möglichkeit abgesetzte Panels auf Clients zu erstellen - eben wenn man mal zufällig keinen Airbus oder B737 will.

Abwegich ? Schwachsinn? oder vielleicht eine Idee........

Gruß
Joachim

Scheinbar hat niemanden mein Beitrag zu dem Thema erwischt.
Dann nochmal. Schaut hier:

http://www.bluecommerce.net/forum/viewtopic.php?t=694

Diese Software ( Aus Deutschland) soll angeblich alle deine Wünsche erfühlen.
Du kannst dir soviele GAU selbst machen und die dann über ein LAN auf einem Client laufen lassen (ohne FS auf dem Client).

Fast zu schön um war zu sein.

Gruss

Roger

Hallo Leute,

da ich aus einer Softwareschmiede komme und dort eine Menge Entwickler rumlaufen, habe ich bereits vor einiger Zeit jemanden dort auf meine Seite gezogen.
Dieses habe ich im kleinen Kreis zwar schon im Bereich des Stammes vom Hannoveraner FlusiStammtisches angesprochen, aber hier noch mal.
Dieser Mann wäre bereit Software zu entwickeln. Und zwar nicht nur Cockpit-Software sondern auch andere die ggf. benötigt/gewünscht wird.
Problem wird von unserer Seite nicht der Preis sein (kostenlos macht er es natürlich nicht) sondern eher die Software und den Umfang zu definieren.
Dieser Kollege ist lange Jahre im Geschäft und ein echter Programierer und beherrscht außer Delphi, Assembler und die C-Familie noch einige andere Programiersprachen.
Ich werde dieses, wie ich ebenfalls bei einigen schon erwähnt habe, ende Februar beim Treffen auf den Tisch bringen wollen, wenn Interesse besteht.
Über die Lizenzen habe ich mich auch mit ihm unterhalten. Die Leute die, die Software bezahlen bekommen volles Lizenzrecht, wobei auch er die Software alleine weiter entwickeln und anderweitig vermarkten dürfte. Dieses würde wiederum den Preis für seine arbeit nach unten korrigieren. Andere Einigungen sind auch möglich, man müsste sich halt nur zusammen einen Kopf machen. Aber wie gesagt Einzelheiten in drei Wochen.

mfg
Dirk

Hallo Dirk,

danke für Deinen Hinweis und es ist auch sicherlich nicht schlecht, solche Leute für den Notfall in der Hand zu haben. Dennoch denke ich, dass es für ein Projekt, welches ja Freeware und Opensource sein soll, schwierig ist, das Geld für professionelle Programmierer aufzubringen. Für einen dauerhaften Einsatz sehe ich hier keine Chance. Für vereinzelte Problemlösungen aber schon. ;)

Nur so als Hinweis: Auch ich bin professioneller Softwareentwickler, habe schon mit Pascal, C, C++, C#, etc. rumgefummelt. Aktuell bin ich zwar hauptsächlich in Web-Anwendungen und dessen Umfeld involviert, jedoch nicht in einfachen Webseiten, sondern in komplexen Anwendungen wie Provisionierungssystemen, sodass ich mich mit Entwicklungsprozessen, Datenmodellen, Schnittstellen, etc. gut auskenne.
Meine Schwäche ist eher, dass ich seit vielen Jahren nix mehr mit Grafik gemacht habe und in OpenGL noch keinerlei Erfahrungen habe. Zudem habe ich aktuell noch zu wenig Detailwissen über die Systeme in einem Flugzeug, sodass ich nicht sicher bin, ob ich eine ordentliche Architektur für die Software entwickeln kann, ohne dabei wichtige Dinge zu übersehen.

Mein aktueller Plan ist der folgende:
Soweit ich zwischendurch die Zeit finde (aktuell haut bei mir der Job gut rein), grübel ich an Konzept und Architektur rum. Das will ich dann hier mal zur Diskussion stellen und erstmal noch mehr Informationen über die zu simulierenden Systeme sammeln.
Sollte sich dann herausstellen, dass das Konzept aussichtsreich ist, werde ich mir überlegen, ob ich es wagen sollte, das Projekt wirklich anzufangen. Aber soweit sind wir noch nicht. ;)

Dann gute Nacht...

Gruss,
Oliver.

"Dieser Mann wäre bereit Software zu entwickeln. Und zwar nicht nur Cockpit-Software sondern auch andere die ggf. benötigt/gewünscht wird.
Problem wird von unserer Seite nicht der Preis sein (kostenlos macht er es natürlich nicht) sondern eher die Software und den Umfang zu definieren."

Softwareentwicklung ist sehr teuer.
Und ausserdem extrem zeitaufwendig.

Sowas in den Abendstunden nach der Arbeit jeden Tag zu machen zieht die Sache hin da es nur eine einzelne Person ist (die dann keine Freizeit mehr hat).

So ein Projekt wuerde im kommerziellen Umfeld mindestens einen fuenf, wenn nicht sechsstelligen Betrag kosten.



"Dieser Kollege ist lange Jahre im Geschäft und ein echter Programierer und beherrscht außer Delphi, Assembler und die C-Familie noch einige andere Programiersprachen."

Da gibts hier im Forum bestimmt mehr davon. z.B. Oliver :)

Ich bin auch Softwareentwickler.
Ich programmiere alles von Assembler ueber Scriptsprachen bis zu gaengigen Hochsprachen.

Ich hab in den Bereichen embedded, real-time, Systemprogrammierung, bis zu Graphik alles moegliche schon gemacht.

Das was ich beruflich programmiere gehoert (fast) immer dem Auftraggeber, das was ich privat programmiere wird als Open Source released.


"Über die Lizenzen habe ich mich auch mit ihm unterhalten. Die Leute die, die Software bezahlen bekommen volles Lizenzrecht, wobei auch er die Software alleine weiter entwickeln und anderweitig vermarkten dürfte. "

Der ist nicht bloed :)
Aber auf sowas wuerde ich mich nie einlassen. Ich hab sowas im kommerziellen Umfeld mehrfach gesehen. Eine Firma zahlt die Entwicklungskosten, der Entwickler verkauft die Software aber auch an die Konkurrenz der Auftraggeber, und dass natuerlich viel billiger...

Nee, wenn Auftragsentwicklung, dann bitte mit komplettem Sourcecode und allen Rechten.


Ganz ehrlich, da koennte man gleich die Projekt Magenta Leute fragen.
1. waere billiger
2. die haben schon viel Code
3. geht schneller
4. kennen sich mit der Materie aus.

Wenn jemand bereit ist Geld auszugeben, dann gebt es lieber denen.
Ich glaube das Enrico von PM inzwischen davon lebt.

Das Problem ist halt dass wenn ploetzlich viele Leute das was man eigentlich fuer sich selbst geschrieben hat auch haben wollen, dies immer mehr Zeit beansprucht, dass man nur zwei Optionen hat, erstens: aufhoeren, zweitens: es zum Fulltime job zu machen und entsprechend Geld verlangen damit man davon leben kann.
(Dies koennte der Grund sein dass PM teuerer wurde)


Oder, man findet genug faehige Leute und startet ein OpenSource Projekt.

Da kann jeder mitmachen (auch wenns nur Dokuschreiben oder Webseiten Erstellung ist) und es besteht die Moeglichkeit, seine eigenen Customizations zu machen.


Manuel