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,

Da stimme ich Dir 100%ig zu. Würden sich immerhin mal eine Hand voll Leute finden, sodass eine gemeinsame Basis diskutiert werden kann und dann parallel für 2-3 Modelle konkret entwickelt wird, wäre das natürlich ein idealer Einstieg.

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. 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.


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?


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