Flightbase hat geschrieben:ich denke die user gui ist erstmal relativ egal oder?
ich prüfe gerade, ob die benutzung von opengl2 ein vorteil wäre, überfliege den code, etc.

Qt nimmt einem schon ne Menge arbeite ab.

was dann fenster oder so angeht: ich bin ehr gtk2 fan

Wäre für mich keinen Deut besser, als ne Windows Lösung

Das wichtigste ist doch nicht die GUI oder Grafik sondern die Simulation oder? Wie ist da der Stand bei dem Projekt?

Es ist sicher schwierig jemanden zu finden der die Physik und Aerodynamik so kleiner Fluggeräte gut programmtechnisch abbilden kann und auch Zeit hat freiwillig in so einem Projekt mitzuarbeiten.

Daher war der Ansatz in meinem Blender RC Simulator die Grafik schnell in einem (von mir) beherrschten Programm zu machen und die vorhandene (zugegeben etwas angestaubte) Gameengine zu nutzen und dann die Physik (abgesehen von Kollisionen und Gravitation) von Python"skripten" machen zu lassen bzw. den Ansatz "Pi mal Daumen" und dann so lange zu schrauben bis es für 80% der Piloten passt

Knackpunkt ist allerdings das leider unter Blender auf MacOSX die Joysticks nicht funktionieren ;-( Ist ein SDL Problem....

Gruß,
Carsten

tracer hat geschrieben:

Flightbase hat geschrieben:ich denke die user gui ist erstmal relativ egal oder?
ich prüfe gerade, ob die benutzung von opengl2 ein vorteil wäre, überfliege den code, etc.

Qt nimmt einem schon ne Menge arbeite ab.

was dann fenster oder so angeht: ich bin ehr gtk2 fan

Wäre für mich keinen Deut besser, als ne Windows Lösung

ne, ich sach ja qt hat momentan die nase vorne. das soll nicht das problem sein. nur ist der zeitpunkt in meinen augen noch weit entfernt, wo man über qt reden kann.
erstmal sollte man doch an sachen wie realitätsnähe und performance arbeiten? dann eye-candy - und wenn das alles ganz toll klappt, kann man es userfreundlich machen.

zum thema userfreundlich: ich bin eigentlich für wx. das nutzt nativ die liberys vom jeweiligen system.... und wir wollen ja auch an *bsd, apple, windows, hp-ux, sun user denken?
aber nun ja.

also bevor ich übber dialogboxen nachdenke will ich erstmal ne komplette bestandsaufnahme machen, um den aufwand zu schätzen.
evtl. müssen wir die jetzige physikengine komplett wegwerfen, weil sie nicht gut genug - oder nicht erweiterbar ist. dann ist nen 0.1 release mal eben um n monate nachh hinten delayed.
und bei der physikgeschichte darf man auch nicht vergessen, dass man evtl. mal nen multiplayer mode ermöglichen will - das muß man halt berücksichtigen - usw. usf.

greets, Nik

Puh, moment moment. Gui-Programmierung, Multiplayermodus....

Vielleicht erst mal eine Bestandsaufnahme ob es überhaupt Sinn macht, das Projekt weiter zu treiben. Vielleicht hatten die Entwickler ja einen Grund nicht mehr weiter zu machen, weil sie sich in eine Sackgasse manövriert haben.

Gruss Micha

PS. Kann mir jemand erklären wie ich mit SVN unter OSX arbeite? Würde gerne auch mal was sehen.

ich schreibe doch, dass ich eine bestandsaufnahme mache.
und dann weiß ich auch, was an arbeit auf uns zukommt. und sachen wie physikengine und multiplayer sind dazu schon wichtig. man kann nicht mit parametern asen, wenn man das alles mal übers netz jagen will.

mal sehen, ich hab ja noch sowas wie nen job und ne familie... wird nicht bis morgen fertig sein

greets, Nik

Hallo

Das ganze würde - glaube ich - nur Sinn machen, wenn da wirklich was besseres herauskommt, als es schon gibt.... Den verbotenen Simulator kenn ich ein bisschen, und was da z.B. bei den Bodenkontakten geschieht, ist wirklich nicht schlecht...

Features könnten sein:
- Beliebige Anzahl von Benutzern (lokal, internet, etc.)
- Mehrere Standpunkte in der Szenerie
- Offenes System, Plugin-Schnittstelle für die Flugmodelle, Helis, etc.
- Auch Sender-Objekte, d.h. auch die einzelnen Sender werden simuliert und könnten programmiert werden
- Simulationen mit Regeln: Pylon-Rennen, Aufnahme von Gegenständen, etc.
- und und und ....

Ich habe mir mal den Physik-Code angesehen. Da kann man sicherlich noch einiges dran arbeiten. Schwieriger wird das ganze, wenn Kollisionen dabei sind, Kontakt mit Reibung, und und und.

Wenn sich da wirklich ein Team bildet, würde ich (soweit es die Zeit erlaubt) mithelfen. Ganz konkret z.B. beim OO-Design und bei der Physik.

Michael

Einen Namen für den Sim gäbe es auch schon: RHF-Simulator

Steffen

Naja, allein Linux und MacOS Versionen wären schon nen Grund...

- Preis?

C.

Es geht hier glaube ich in erster Linie einen freien Simulator zu erstellen, der nicht nur auf Windows läuft. Denk ich.
Wenn es irgendwann mal besser als der böse Sim wird, um so besser, aber das dürfte noch etwas hin sein.

Wir wären schon 5, oder?

Gruss Micha

calli hat geschrieben:- Preis?

For free -> GPL

@Quaxxx: Klar, ich meinte das als Argument, das Fragezeichen sollte andeuten das Diskussion erwünscht ist *ob* das ein Argument ist... TCO und so

ich sehe die große gefahr, dass einige das ausmaß des ganzen nicht erkennen.
wir sprechen hier nicht von ein paar wochen oder soetwas. es geht viel mehr um VIELE monate.

der vorteil ist:

1. viele werden ihr können und wissen erweitern... quasi mitwachsen.
2. leute die mitlesen bekommen endlich mal mit, warum sonen sim auch gerne mal 200 euro kostet.
3. soetwas schweisst die community zusammen und bringt neue leute.
4. auch leute ohne programmierkenntnisse können sich einbringen - und so etwas zum "gemeinsamen kind" beitragen (doku, hilfesystem, packaging, qa, testpiloten - etc. pp)

es gibt im grunde nur ein problem: das ganze muß sauber koordiniert werden. dazu müßte man erstmal einen schuldigen finden. selbiger sollte obendrein auch noch genau wissen was er tut - und soetwas am besten nicht zum ersten mal machen.

greets, Nik

Der Satz "viele werden ihr können und wissen erweitern... quasi mitwachsen." gefällt mir ausgesprochen gut.

Das das ganze nicht bis zum Wochenede fertig ist, verteht sich.

Ich glaube den Schuldigen hast du schon gefunden. Bist du selber Schuld...

Flightbase hat geschrieben: erstmal sollte man doch an sachen wie realitätsnähe und performance arbeiten? dann eye-candy - und wenn das alles ganz toll klappt, kann man es userfreundlich machen.

QT ist ja nicht NUR eine GUI Schnittstelle.

QT ersetzt im Prinzip die ganze STL, und bringt auch eine (wohl) brauchbare OpenGL Unterstützung mit.

MichaelS hat geschrieben: besseres herauskommt, als es schon gibt.... Den verbotenen Simulator

Da hängt davon ab, wie man "gut" definiert.

Eine freie Software, plattformunabhängig, mit der Qualität des FMS wäre MIR 1000x lieber, als ein XTR/AFPD/G3 für Linux, der aber unfrei ist.

*Software is like sex, it's better, if it's for free*