WCM Forum - Einzelnen Beitrag anzeigen

mbessler · 30.01.2005, 23:27

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

30.01.2005, 23:27	#13
mbessler Veteran Registriert seit: 28.01.2003 Beiträge: 234	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 ____________________________________ http://wiki.varxec.net The Simbuilder\'s Wiki FlightGear, the free open-source, multi-platform Flight Simulator under GPL (http://www.flightgear.org)