|
Freie Glascockpit Software entwickeln?
Hallo Leute,
mir ist gerade vor ein paar Minuten mal so eine Schnapsidee gekommen. Ich habe nicht lange nachgedacht, sondern will gleich mal eure Reaktionen darauf lesen. Viele hier brauchen dringend Glascockpit-Software à la Project Magenta, etc. für die Realisierung ihres Projekts und selbst weniger enthusiastische Flusi-User würden sich gerne ein Laptop neben den Flusirechner stellen, auf dem ein Glascockpit mit ordentlicher Wiederholrate läuft. Aber die Software ist dann meistens doch recht teuer. Was bei einem kompletten Cockpit für viele tausend Euro vielleicht noch in der Masse untergeht, ist spätestens für die Semi-Freaks ein teurer Spass (ich zähle mich hier aktuell noch dazu ;-). Jetzt die entscheidende Frage: ====================================== Könnte diese Community nicht diverse Entwickler, KnowHow-Träger, etc. hervorbringen, die gemeinsam so eine Software selber entwickeln? Ich denke da an die vielen Sourceforge- und wie-sie-nicht-alle-heissen-Projekte, wo sich engagierte Leute zusammentun in erstaunliche Dinge entwickeln. Mir ist natürlich klar, dass man eine Menge KnowHow braucht - insb. von dem System, welches man nachprogrammieren möchte. Aber alleine in diesem Forum sollte schon genug KnowHow gesammelt sein, um diese Probleme zu überwinden. Vielleicht kann man ja auch den Author von FreeFD überzeugen, seine Erfahrung mit in so ein Projekt einzubringen. Der Vorteil ist meiner Meinung nach, dass man eine quelloffene Software hätte, an der viele mitarbeiten können und so kleine Fehler auch schnell bereinigt oder Features zeitnah implementiert werden können. Und natürlich würde es nix kosten. Also was meint ihr? Ist das realistisch - also könnte es funktionieren? Hättet ihr interesse an so einer Software? Ich glaube, ich bastel einfach mal eine Umfrage... ;) Ich bin sehr gespannt, was eure Meinung zu diesem Thema ist. :) Gruss, Oliver. |
Re: Freie Glascockpit Software entwickeln?
Hallo Oliver,
> Ist das realistisch - also könnte > es funktionieren? Hättet ihr Interesse > an so einer Software? das funktioniert ganz sicher, sofern du die geeigneten Leute findest. Ich bastle ebenfalls an einer Glasscockpit-Software für die Boeing 747-400. Das mache ich seit etwa 2 1/2 Jahren und habe dabei schöne Ergebnisse erzielt. Aber warum von vorne anfangen? Es gibt soviele verschiedene Projekte, alle mit verschiedenen Schwerpunkten... http://www.displays.glideslope.de (meine eigene Seite) http://freefd.homelinux.com/freefd/ (FreeFD, hattest du schon erwähnt) http://www.opengc.org/ http://glassflightdeck.flightdecksoftware.com/ http://cockpit.varxec.net/software/x11gc.html http://flyreal.free.fr/English/index_en.php http://www.systemsim.co.uk/mos/?page=consult Es gibt sogar noch mehr, ich habe nur nicht alle Links zur Hand. Das Problem ist also nicht die Machbarkeit, sonder die Umsetzung. DIE eine Glasscockpit-Software wird es nicht geben, denn die Anforderungen sind oft zu unterschiedlich. Du mußt also entweder von vorne anfangen, eine bestehende Software (OpenGC ist OS) weiterentwickeln oder anpassen oder alle Entwickler unter einen Hut bekommen. Markus |
Re: Re: Freie Glascockpit Software entwickeln?
Ein Nachtrag ... das ist mein Entwicklungstand nach 2 1/2 Jahren Arbeit. Das passiert ausschließlich in der Freizeit und ohne Hilfe...
(PFD und ND sind allerdings nur zusammen mit dem Aerowinx PS1.3 zu verwenden.) |
Und wie ist das Passwort oder willst du Geld dafür?
|
> Und wie ist das Passwort oder willst
> du Geld dafür? *lach* Geld will ich dafür nicht haben. Die Software ist (noch) nicht Open Source, aber Freeware. Die Sache mit dem Passwort ist eine alte Tradition unter Nutzern des Aerowinx-PS1.3. Fast alle Add-Ons sind mit einem Passwortschutz versehen. Die Wörter stehen ausnahmslos im gedruckten Handbuch vom PS1.3. Der Hintergedanke ist der, daß nur Benutzer der Originalsoftware die Add-Ons nutzen können, da Besitzer von Kopien oftmals kein Handbuch besitzen. Aber wie gesagt, die Software läuft nur mit dem PS1.3, nicht aber mit dem Microsoft Flight Simulator. Markus |
Ach soo sagt mir natürlich keiner!!!!!!!:heul: :heul:
Nein ich las eben den Text nicht durch. :rolleyes: |
Die Idee ist super!
Ich selber muss eine eigene GC-Software programmieren, wenn ich will, dass das EFIS meines Simulators der Fokker 70/100 entspicht. Es ist noch einige Zeit bis ich mich dann ernsthaft mit der GC-Software beschäftigen muss. Trotzdem schau ich mich ein bisschen um, welche Möglichkeiten ich habe. Ich finde es ist sehr wichtig eine Software zu schaffen, die leicht für verschiedene Flugzeugtypen adaptierbar oder umprogrammierbar ist. Ich kenn mich in C++ zwar noch nicht gut aus, denke aber das man das slles mit einigem Zeitaufwand lernen kann. Man sollte einfach einen Anfang machen!! lg. Andreas |
Was denkt ihr: Kann man sowas auch mit Delphi umsetzen? Kennt jemand gute Handbücher und Anleitungen zur Programmierung von OpenGL mit Delphi? Gerne auch kostenlos aus dem Internet....
http://hnac.org/members/martin/banner_m_2.jpg |
Schaut mal hier.
http://www.bluecommerce.net/forum/viewtopic.php?t=694 Der interessante Teil: >>For COCKPIT BUILDERS: - Ability to run the gauges on an other PC without FS linked via a LAN network>>> Gruss Roger |
> Was denkt ihr: Kann man sowas auch mit
> Delphi umsetzen? Kennt jemand gute > Handbücher und Anleitungen zur > Programmierung von OpenGL mit Delphi? > Gerne auch kostenlos aus dem Internet.... Man kann das sogar sehr gut. Mein komplettes 747-400 Paket ist in Delphi 6.0 programmiert. Die OpenGL-Header stammen von http://www.delphi3d.net , einer ganz brauchbaren Seite, wenn es um Delphi und OpenGL geht. Inzwischen hat Delphi3d.net allerdings wohl schon deutlich bessere OpenGL-Header als die, die ich verwende, aber da bin ich nicht auf dem Laufenden. Mein funktionieren jedenfalls bestens... Sonst braucht kann gar nicht viel mehr. Als TCP/IP-Schnittstelle verwende ich die "Indy"-Components... http://nehe.gamedev.net/ ist auch nicht schlecht ... Markus |
Ich danke!
|
Hallo Leute,
danke für die Antworten. Markus, Dir erstmal herzlichen Dank für die Links (die meisten kannte ich dann bei genauem hinsehen dann schon) und Glückwunsch für die tolle Software! Tja, leider kann ich sie als FS2004-User nicht verwenden - zumal ich eher an Airbus interessiert bin. ;) Das OpenGC-Projekt entspricht am ehesten dem, an das ich dachte. Nämlich ein Opensource-Projekt, mit dem sich GC's für verschiedene Flugzeug-Typen entwickeln lassen. Bei OpenGC ist natürlich der Wahnsinn, dass man damit auch diverse Flugsimlatoren und alles noch unter Linux oder Windows verwenden kann. Mehr Flexibilität gibt es sonst wohl nirgends. Dennoch fehlt mir etwas. Es sieht so aus, als wenn aktuell nur ein Entwickler an der Software arbeitet und zudem nur ein Flugzeugtyp konkret erarbeitet wird. In meiner (durchaus optimistisch bis naiven) Vorstellung sollten gleichzeitig eine Hand von Entwicklern mehrere Flugzeugtypen entwickeln und dabei eine gemeinsame Grundlage - wie auch bei OpenGC - schaffen. Alles muss noch besser dokumentiert sein, damit die Leute motiviert sind, mitzuarbeiten. Bzgl. der Programmiersprache muss man sich natürlich einigen. Es stünden da einige zur Auswahl: * C# * Java * C++ * VB * Delphi Welche man dann nimmt, hängt von dem Ziel des Projekts und diversen Rahmenbedingungen ab. OpenGL sollte wohl die Grafikschnittstelle der Wahl sein. Aber muss es Platformübergreifend sein? Sollen diverse Simulatorprogramme laufen und z.B. auch welche unter Linux? Außerdem sollte man die Verbreitung einer Sprache nicht unterschätzen. Je mehr Leute das können, umso toller. Es gäbe noch hunderte Fragen zu klären, jedoch kommt es im Endeffekt zunächst nur auf wenige Fragen an: * Sollten wir es wagen? * Wer ist wir? * Sind genug Leute motiviert, mit KnowHow, Kritik und Programmierfähigkeiten zu helfen? Bin gespannt... Gruss, Oliver. |
Hallo Oliver,
zu der Liste von Markus koennte ich noch ein Projekt beisteuern, a340gc. http://a340gc.iradis.org/about/ Es ist auch ein OpenSource Projekt, lag ca 2 1/2 Jahre brach, scheint aber (wie ich gerade sehe), im Dezember wieder aktiv geworden zu sein. Die haben auch eine library (libgc) geschrieben wo der GC Kram abstrahiert ist. Der a340gc ist eine Implemenation die diese libgc verwendet. http://a340gc.iradis.org/download/index.en.html Evtl koennte man dies auch als Basis nehmen, spez. da du ja nach Airbus GC Zeugs suchst. Ob der Code brauchbar ist, weiss ich allerdings nicht, ist schon ne Weile her als ich mir dieses Projekt angesehen hatte. Das hier schein auch neu zu sein: http://www.iradis.org/projects/a340/...els/index.html Scheinbar entwickeln die auch Software panels. Sieht aus wie ein komplettes Overhead. "Das OpenGC-Projekt entspricht am ehesten dem, an das ich dachte. Nämlich ein Opensource-Projekt, mit dem sich GC's für verschiedene Flugzeug-Typen entwickeln lassen. Bei OpenGC ist natürlich der Wahnsinn, dass man damit auch diverse Flugsimlatoren und alles noch unter Linux oder Windows verwenden kann. Mehr Flexibilität gibt es sonst wohl nirgends." Ja, OpenGC ist vermutlich die beste Loesung. "Dennoch fehlt mir etwas. Es sieht so aus, als wenn aktuell nur ein Entwickler an der Software arbeitet und zudem nur ein Flugzeugtyp konkret erarbeitet wird." Es ist hauptsaechlich ein Entwickler, der soweit ich ihn verstanden hatte, die Software auch fuer seine Lehrtaetigkeit einsetzt. Das mit dem einen Typ stimmt glaub ich nicht. Ich weiss dass OpenGC auch fuer reale Glass Cockpit Instrumente verwendet wird (nur bei experimental aircraft, also nicht zertifiziert oder sowas) "In meiner (durchaus optimistisch bis naiven) Vorstellung sollten gleichzeitig eine Hand von Entwicklern mehrere Flugzeugtypen entwickeln und dabei eine gemeinsame Grundlage - wie auch bei OpenGC - schaffen. Alles muss noch besser dokumentiert sein, damit die Leute motiviert sind, mitzuarbeiten." Die beiden letzten Punkte sind die schwierigsten ueberhaupt. So ein Projekt anzufangen ist leicht, aber dabeizubleiben, zu koordinieren und Leute rekrutieren wird vermutlich nicht leicht. Und dann die Leute noch ueber laengere Zeit zu halten und motivieren... Speziell wenn noch nix da ist, ist es schwer. Wenn ein Projekt mal "laeuft" also Code da ist, Releases gemacht wurden und das ganze sich "etabliert" hat, dann ist es einfacher. (Bzw. schwer wieder aufzuhoeren) Ich glaube dieses Muster kann man bei vielen OpenSource Projekten beobachten. Bei diesem speziellen Projekt ist es sogar eher noch schwieriger, da es ein Nischen- Projekt/Produkt ist. (Es gibt halt nicht so viele Cockpitbuilder auf der Welt, und wer von denen kann schon "richtig" progammieren?) "Bzgl. der Programmiersprache muss man sich natürlich einigen. Es stünden da einige zur Auswahl: * C# * Java * C++ * VB * Delphi " C++. Alles andere ist unpassend. Warum?: VB ist keine "serious programming language" C# und Delphi sind praktisch Windows-only (Reden wir nicht ueber Mono und Kylix). Java ist nicht schnell genug. "Welche man dann nimmt, hängt von dem Ziel des Projekts und diversen Rahmenbedingungen ab. OpenGL sollte wohl die Grafikschnittstelle der Wahl sein. Aber muss es Platformübergreifend sein? Sollen diverse Simulatorprogramme laufen und z.B. auch welche unter Linux?" Linux ? Definitiv! OpenGL? auf jeden Fall. Am Anfang muss man sich ja noch nicht unbedingt an ein Sim-hookup Gedanken machen. Erstmal die elementaren Routinen schreiben. Dann die I/O so generisch wie moeglich halten. Mittels Modulen oder Plugins die Hookups realisieren. "Außerdem sollte man die Verbreitung einer Sprache nicht unterschätzen. Je mehr Leute das können, umso toller." Das spricht auch fuer C++. Und mal ganz ehrlich... diejenigen die sich fuer grosse Programmierer halten und nur VB koennen sollte man sowieso nicht miteinbeziehen. Dies hat 100%ig Auswirkungen auf die Code Qualitaet. "Es gäbe noch hunderte Fragen zu klären, jedoch kommt es im Endeffekt zunächst nur auf wenige Fragen an: * Sollten wir es wagen? * Wer ist wir? * Sind genug Leute motiviert, mit KnowHow, Kritik und Programmierfähigkeiten zu helfen?" 1. Nein, ich melde mich nicht als Freiwilliger! Ich hab selbst ein GC projekt dass im Moment eingefroren ist da viel Zeit in mein Cockpit Interface geht. (Fuer Kritik und Know-How stehe ich aber gerne zur Verfuegung) 2. ein "Project Leader" muss her. Jemand der koordinieren kann und auch andere anspornt. Derjenige wird viel seiner Freizeit opfern muessen um so ein Projekt ins Rollen zu bringen und am Laufen zu halten. Er wird vermutlich auch den ersten Code schreiben. Manuel |
Hallo Marius, Oliver & Co,
> So ein Projekt anzufangen ist leicht, > aber dabeizubleiben, zu koordinieren > und Leute rekrutieren wird vermutlich > nicht leicht. Das sehe ich auch so. Denn ... > Am Anfang muss man sich ja noch nicht > unbedingt an ein Sim-hookup Gedanken > machen. Erstmal die elementaren > Routinen schreiben. > Dann die I/O so generisch wie moeglich > halten. Mittels Modulen oder Plugins > die Hookups realisieren. ... am Anfang muß erst mal Vorarbeit geleistet werden. Wenn man sich auf eine bestimmte Plattform, eine bestimmtes Interface und einen bestimmten Simulator festlegt (so wie bei mir), ist es nicht ganz so schwierig, aber wenn man entweder verschiedene Simulatoren oder (!) verschiedene FLugzeuge (und sogar noch verschiedene Plattformen) unterstützen will, dann muß sich lange, bevor man die erste Zeile OpenGL schreibt Gedanken über die Programmstruktur machen, über die Schnittstelle usw... Mit anderen Worten, man programmiert erst mal, ohne dabei Resultate zu bekommen und dafür braucht es ein zielstrebiges Team. > Linux ? Definitiv! > OpenGL? auf jeden Fall. Die Antwort war klar ;) ... wobei vermutlich die meisten Cockpit-Rechner dann doch unter Windows laufen. ;) Zwar sollte mit C++ die Plattformunabhängigkeit kein Problem sein, aber mit dem Userinterface hat man sicher zu kämpfen. Wenn keiner der Programmierer Linux verwendet, ist das eher eine akademische Frage. (Und ich will hier keine Grundsatzdiskussion anfangen. Ich mag Linux.) > 2. ein "Project Leader" muss her. > Jemand der koordinieren kann und auch > andere anspornt. Derjenige wird viel > seiner Freizeit opfern muessen um so > ein Projekt ins Rollen zu bringen und > am Laufen zu halten. Er wird vermutlich > auch den ersten Code schreiben. So sehe ich das auch. Im Prinzip jemand, der die Software selbst benötigt und andere davon begeistern kann mitzumachen. Und es geht nicht nur um Programmieren ... (Ich bin sicher nicht dabei. :o Meine Software läuft recht zufriedenstellend und ich habe noch genug Pläne dafür, die mich auslasten.) Vielleicht ein paar Tips... es gibt immer genug Problem zu lösen. - für ein ND braucht man z.B. eine Navigationsdatenbank. Von dem Problem, eine Route darzustellen, mal gar nicht zu reden. - ein ND sollte auch in Polargegenden vernünftig darstellen. Mit einer Mercatorprojektion wie auf vielen Landkarten kommt man da nicht weiter - OpenGL und Fonts ist ein kleines Problem, für das es keine ideale Lösung gibt ... Markus |
Hallo,
Zitat:
Zitat:
Meine Erfahrung mit C++ ist, dass man seeeehr sauber programmieren muss, damit man insb. bei Pointer-Fummeleien nicht alles zum Absturz bringt. Im Endeffekt leidet die Produktivität darunter. Das sieht bei C# und Java anders aus - dort muss man sich um diverse Dinge nicht kümmern (Garbage-Collection, ...). Bezüglich der Java-Geschwindigkeit ist natürlich klar, dass C++ schneller ist. Aber die Frage ist, wie krass der Unterschied noch ist. Da hat sich einiges getan seit damals. Hast Du Dir mal https://jogl-demos.dev.java.net/ angesehen? Ist zwar nur Kleinkram, aber flüssig. Und ein PFD, etc. sollten eher geringere Anforderungen stellen. Vorteil bei Java wäre dann die Platformunabhängigkeit. Zitat:
Bei OpenGL stimme ich Dir zu. Bei Linux bin ich mir nicht soo ganz sicher. Auch wenn ich selber Linux mag und viele Linux-Rechner administriere stelle ich mir dann doch die Frage, ob sich der Aufwand lohnt und wie viele Leute Linux wirklich nehmen würden. Denn OpenGL, Treiber für aktuelle Grafikkarten, etc. unter Linux zu installieren ist ja leider noch immer kein Kinderspiel. Diese Frage hängt meiner Meinung nach auch von der Frage der zu unterstützenden Simulatoren ab. Soll das auch mit FlightGear laufen? Lohnt sich der Aufwand? Wer baut ein Cockpit mit FlightGear? Kann man die Unterstützung von Flusis auf anderen Platformen notfalls nicht auch über eine WideFS-ähnliche Schnittstelle realisieren, sodass das GC dann trotzdem unter Windows läuft? Viele Fragen. Aber gerade bei platformübergreifenden Lösungen würde ich Java durchaus nochmal in Betracht ziehen. Das setzt natürlich ganz klar einige Performance-Tests der OpenGL-Unterstützung voraus. Aber sollte ein 400 MHz Rechner sowas auch mit Java bei 25 Frames hinkriegen - warum nicht? Zitat:
Das gibt es zwar sicherlich auch fitte Leute drunter, aber ich halte VB auch nicht wirklich für die Sprache der Wahl. Zumal ich persönlich die Syntax von VB zu kotzen finde. Aber das ist ja auch nur mein persönlicher Eindruck. ;) Gruss, Oliver. |
"Hier wollen wir natürlich keine langen Diskussionen anfangen, aber... ;)
Meine Erfahrung mit C++ ist, dass man seeeehr sauber programmieren muss, damit man insb. bei Pointer-Fummeleien nicht alles zum Absturz bringt. Im Endeffekt leidet die Produktivität darunter. " ja, C++ erfordert etwas mehr Nachdenken vor/beim Programmieren. Aber das ist gut so! Man muss dann tatsaechlich Grips reinstecken. Dieser "Zwang zum Nachdenken" hilft dabei guten Code zu schreiben. .. ja, dies macht es fuer C++ Neulinge nerviger, aber irgendwie muss mans halt doch lernen. C++ ist halt doch um einiges mehr als C mit Objekten. Das mit den "Pointer-Fummeleien" ist eigenlich ja eher ein C Problem. Da hat C++ bessere Moeglichkeiten. Man kann zwar noch viele der C-pointer Sachen in C++ verwenden, aber es ist nicht "recommended". "Das gibt es zwar sicherlich auch fitte Leute drunter, aber ich halte VB auch nicht wirklich für die Sprache der Wahl. Zumal ich persönlich die Syntax von VB zu kotzen finde. Aber das ist ja auch nur mein persönlicher Eindruck. ;)" BASIC (wie in Visual _BASIC_) ist eine Anfaengersprache. Deshalb "Beginner's All-purpose Symbolic Instruction Code" Manuel |
Hi!
Finde eure Idee gut. Ich entwickle seit gut einem Jahr an einer Airbus GC SW. Bilder findet man unter der Webadresse in meiner Signatur. Falls ich noch nicht angefangen hätte wäre ich bei euch dabei :). MfG Stephan |
so schwer ist das mit pointern garnichtmal.
Man muss vorher den Pointer IMMER initialisieren und nachdem dem selben Pointer eine andere Funktion zugeschrieben wurde, wieder neu initialisieren. Un auf einmal stellt man fest, das pointer die geilste sache auf der Welt.. naja.. im Computer sind :lol: |
Finde eure Idee gut. Ich entwickle seit gut einem Jahr an einer Airbus GC SW. Bilder findet man unter der Webadresse in meiner Signatur. Falls ich noch nicht angefangen hätte wäre ich bei euch dabei :).
Ja, ich habe von Deinen Erfolgen in der FlightXPress gelesen. Das hört sich wirklich Spitze an! Wie in den meisten Dingen nehmt Ihr euren Job sehr genau und wollt wirklich alles exakt simulieren. Das wäre natürlich der Hammer, so ein Projekt gemeinsam mit mehreren Entwicklern zu realisieren. Naja, wenn ich euren Ansatz richtig verstehe, habt ihr ja durchaus kommerzielle Ambitionen, sodass Du Deine Erfolge wohl nicht direkt preisgeben magst, hmm? ;) Ich frage mich, woher ihr eure Informationen nehmt. Gerade da sehe ich ein grosses Problem, da ich ausser einige Foren und ein AOM kaum informationen habe. Und ich habe bei dem Überfliegen des AOM nicht gerade das Gefühl gehabt, als würde dort wirklich alles drin stehen. :( Hast Du denn irgendwelche Tipps für uns? Wo muss man besonders aufpassen? Was hättest Du anders gemacht? Ich habe die Sorge, dass - sollte man so etwas anpacken - wegen unvollständiger Kenntnis über die simulierten Systeme direkt am Anfang konzeptionelle Designfehler entstehen, die sich später schwer ausbügeln lassen. Gruss, Ollie. |
Ich frage mich, woher ihr eure Informationen nehmt. Gerade da sehe ich ein grosses Problem, da ich ausser einige Foren und ein AOM kaum informationen habe. Und ich habe bei dem Überfliegen des AOM nicht gerade das Gefühl gehabt, als würde dort wirklich alles drin stehen. :(
Wir sind im Besitz von einem original FCOM. Wie du bereits gesagt hast: Dort steht wirklich nicht alles drin, was man gerne wissen täte. Da hilft nur DVDs sich anzuschauen wo man die displays in Aktion sieht oder einen Piloten fragen. Hast Du denn irgendwelche Tipps für uns? Ich würde mir mal OpenGC ansehen, das ist ein guter Einstieg und man bekommt einen guten Überlick wie man an so ein Projekt herangeht. MfG Stephan |
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 |
"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)" Ziemlich aehnlich mache ich das mit X11GC. "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. " dito. "Aber mal ganz erlich, ein opensource Glasscockpit auschließlich für Ms Fs konzipiert? :lol:" Hehe :) Aber wenns wirklich opensource ist, kann jemand schnell hingehen und dass anpassen. Evtl werden die Anpassungen besser als das Original, und irgendwann stirbt dass Original aus ;-) "Der arme FlightGear" Die meisten hier sind scheinbar doch recht fixiert auf ein Stueck Software das MS vor ein paar Jahren gekauft hat :) |
X11GC. Ist dein Projekt OpenSource? - Ist es mir vergönnt, mal in dem Code zu schnuppern?
MfG Karsten |
Hallo.
Das passt vielleicht jetzt nicht so zum Thema aber ich stelle trotzdem die Frage. Hat vielleicht jemand noch das Setup Programm von FreeFD? Die jetzige neue Homepage funktioniert leider im Moment nicht. Emmanuel |
jup, hier ist einmal freefd vorhanden.
ich werd sobald ich mal zeit habe es hochladen (muss sagen is eifnach geil :) ) |
Hi.
Danke! Ja ich nutze es im moment auch auf meinem Laptop aber ich brauch die Setup Datei damit der die Einträge in die Registry richtig einfügt. Emmanuel |
Zitat:
Da es aber fuer nicht-Programmierer noch recht wenig nuetze ist, gab es noch nie einen release. Aber diverse Leute die mich danach gefragt hatten haben auch den Code bekommen :) Screenshots gabs ja schon laenger. (Hier: http://cockpit.varxec.net/software/x11gc.html) Zum Compilieren wird benoetigt: * Linux (koennte man evtl auch mit cygwin und dessen X11 hinbekommen) * GNU C++ compiler * X11 (mit include files nat.) * t1lib (fuer die Type1 PS Fonts, Version 5.0.x evtl reicht auch die 1.3.1) * Lua (ab Version 5.0) Maile mir mal direkt, email addr hier: http://cockpit.varxec.net/contact/ Manuel |
Hallo.
Ich könnte euch mit Grafiken oder bei einer Website behilflich sein. Ich mache in meiner Freizeit ein bisschen Webdesign und programmiere PHP mit MySQL Anbindung. Mit Photoshop kann ich auch umgehen. Also wenn Ihr in so einem Bereich noch hilfe benötigt lasst es mich wissen. Ciao Emmanuel |
@ Roger,
hallo Roger, danke für den Tipp. Ich habe mir http://www.bluecommerce.net/forum/viewtopic.php?t=694 mal angesehen, aber da habe ich mich wohl etwas mißverständlich ausgedrückt : ich will ja gerade keine Gauges selbst basteln ; ich suche nach einer Software ( oder rege es hier eben als Idee an ) die folgende Funktionen hat : - Erstellen eines Fensters, auf dem ich Standard FS.GAUInstrumente anordnen kann ( wie zB FS-Panel Studio ) - dieses aber nicht als Panel Datei im jeweiligen FS Flugzeug, sondern als Fenster auf einem Client PC - Verbindung den Datenströme über WideFS und FSUIPC Und nochmal gefragt : gibts sowas, oder könnte sowas keiner gebrauche? Als ich noch auf FS2002 war, hatte ich am Hauptrechner neben der Hauptansicht auch noch 4 Instrumentenmonitore über PCI Grafikkarten angesteuert - lief wunderbar, und ohne Einbrüche der Performance. Das gleiche mit dem FS2004 wird zur Diashow. Da gehts dann nur über Clients. Gruß Joachim |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 01:50 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag