tracer hat geschrieben:

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.

momentan ist das gesamte projkt nen fall für vi(m). oder von mir aus "Microsoft Office 2003" oder notepad - vielleicht sogar:

01110110 01101111 01101110 00100000 01101000 01100001 01101110 01100100 00100000 01101001 01101110 00100000 01100100 01100101 01101110 00100000 01110010 01100001 01101101 00100000 01100111 01100101 01110011 01100011 01101000 01110010 01101001 01100101 01100010 01100101 01101110

nochmals: das reden über qt ist in meinen augen noch lange nicht an der zeit.
meine bescheidene absicht:

- übersicht erschaffen, quasi bestandsaufnahme.
- projektziele definieren
- ziele in milestones verpacken
- einteilung von teilverantwortlichkeiten, programmierern, und sogar leuten mit ahnung von physik
- erstellung von design-regeln. (bloß keinen ansi flame ^^)
- projektplan entwerfen

und dann kann man koordiniert in kleinen teams an seinen teilaufgaben arbeiten - und vielleicht pro team 2-3 neulinge mitschleppen.

bevor jemand schimpft: natürlich weiß ich, dass dies keine "ihk- oder universitätsprojektplanung ist - aber wir sind auch keine firma. mit der von mir vorgeschlagenen gliederung hat man über die ganze zeit seinen spaß.

na ja - nd so weiter.

greets, Nik

FInde ich ne Hammer Idee, ich hoffe dass das klappt!

Ich habe leider keine besonderen Programmierkenntnisse, würde aber trotzdem gerne helfen!
Ich könnte dann gerne das Programm testen oder auch Designideen liefern...
Oder vielleicht auch ne HP gestalten, wo wir das ganze dokumentieren!

Es scheint ja Moment (physikalisch zu verstehen ) hervorzurufen, mal sehen ob es genauso schnell abebbt wie bei meinem Vorstoß in diese Richtung. Den Schuh muss ich mir natürlich auch selbst anziehen.

C.

@Calli
Ich hätte Dir gern geholfen, das Problem ist Blender. Das ist einfach zu speziell. Auf meinem Mac war z.B. keine Joystik unterstützung.

Gruss Micha

Interessant, was da auf einmal für ein Traffic ensteht, bei dem Project. Is heute schon mehr als im vergangenen Jahr.

Gruss Micha

Tja, der Bedarf nach einem Simulator, der auch unter anderen Betriebssystemen funktioniert, ist schon da, was fehlt, ist eine Umsetzung...

Steffen

so, nach einigen mails mit dem projektleiter kann ich folgendes berichten:

1. das projekt ist nicht tot. er war/ist nur etwas arg eingespannt, was sein berufsleben angeht.

2. zur flugphysik - ich laß es mal unübersetzt:

I might have an "easy way" to do the physics simulation, but currently I can't
get into that right now due to some NDAs, but I can tell you that if this
(longshot, granted) comes through, we'll have a physics-engine easily rivaling
all current RC simulators.

leider sind das ungelegte eier....

kommen wir zur weiterentwicklung:

natürlich macht ein fork keinen sinn, wenn das mutterprojekt nicht tot ist - und wir das gleiche ziel haben.

helfer sind natürlich ausdrücklich erwünscht. wichtig ist nur, dass gewisse regeln eingehalten werden:

- der geschriebene code muß unter BSD oder LGPL lizenz stehen, damit er kompatibel zum rest des programms ist.

- kommentare im quelltext, sowie klassen- und funktionsnamen müssen auf englisch sein, damit alle entwickler den code besser verstehen können.

- beim coden niemals vergessen, dass collective ein cross-platform produkt ist. deshalb bitte folgende sachen beachten: 32/64bit spezifische sachen vermeiden, endians, grafische sachen abstrahieren - um sich nicht zu sehr an opengl zu binden.

ich habe heute nacht mal ein wenig rumcompiliert und verschiedene plattformen überprüft... sicher läuft es (selbst probiert) auf:

* Linux x86, Linux x86-64, Linux PPC
(von mir benutzt: debian sid, debian sid amd64, debian für ppc)

* MacOS X
(von mir benutzt: os x 10.4 - man muß das xcode projekt nen wenig anpassen...)

* SGI IRIX (32 & 64bit versions)
ließ sich bauen, gespielt hab ich es nicht. allerdings hab ich X getunnelt und konnte das game sehen...

* Windows 2000/XP
benutzt habe ich 2000 sp4 und xp sp2

* Sony Playstation Portable
kein witz - geht ps.: vielen dank ans nachbarkind für die leihgabe ^^


so, nu mal butter bei die fische:

2 sachen sollten zuerst geamcht werden:

1. unter unix nen usb joystick (z.B. /dev/input/js0) zum laufen bringen.
2. die physikengine läßt echt zu wünschen übrig. schweben ist ganz gut gemacht - aber das normale rumfliegen ist - nun ja - *zensiert*.

bis die NDA sachen durch sind (wenn sie es jemals sein werden...) sollte ein wechsel der physikengine in betracht gezogen werden. man muß das rad ja nicht neu erfinden.
wer kann hier mal ein paar freie, offene kandidaten vorstellen?

was auch etwas refactoring braucht ist das laden der modelle...
in den .mod files sollten L und Y integriert werden.... eine gute infoseite:
http://homepage.mac.com/slowcoder/modfiles.html

für windows fehlt ein treiber um den eigenen sender über die soundkarte anzuschliessen. vielleich sollte man das auch so lassen?

dann wäre da noch die settings gui. da fehlen noch ein paar sachen...

so, das war mein kleiner bericht.
natürlich bin ich noch nicht fertig mit der schadensaufnahme - aber ich wollte mal ton abgeben zwischendurch.

all `da best, Nik

Flightbase hat geschrieben: - der geschriebene code muß unter BSD oder LGPL lizenz stehen, damit er kompatibel zum rest des programms ist.

Damit wär ich dann raus.
GPL ja, BSD nein. LGPL auch nicht wirklich.

- kommentare im quelltext, sowie klassen- und funktionsnamen müssen auf englisch sein, damit alle entwickler den code besser verstehen können.

normal

- beim coden niemals vergessen, dass collective ein cross-platform produkt ist. deshalb bitte folgende sachen beachten: 32/64bit spezifische sachen vermeiden, endians, grafische sachen abstrahieren - um sich nicht zu sehr an opengl zu binden.

Wenn man mit QT arbeiten würde, bräuchte man sich damit nicht auseinander zu setzen.

ich habe heute nacht mal ein wenig rumcompiliert und verschiedene plattformen überprüft... sicher läuft es (selbst probiert) auf:

Wie hast Du es unter Linux compiliert?

make bricht ab.

Habe freeglut 2.4.0 drauf. Welche Version hast Du?

tweety:/home/nik/kerneldevelopment/smp_patch# dpkg -l |grep glut
ii freeglut3 2.4.0-4 OpenGL Utility Toolkit
ii freeglut3-dev 2.4.0-4 OpenGL Utility Toolkit development files
ii glutg3-dev 3.7-25 the OpenGL Utility Toolkit development files

läuft super durch. danach nicht vergessen nen paar sachen in den dist/Linux folder zu verschieben. selbigen haben ich gerade mal kurz gepackt...

greets, Nik

ups, anhang vergessen....

Die Erweiterung bz2 ist hier verboten

argh! warum? zu kleine files? scnr

greets, Nik

Flightbase hat geschrieben:

tweety:/home/nik/kerneldevelopment/smp_patch# dpkg -l |grep glut
ii freeglut3 2.4.0-4 OpenGL Utility Toolkit
ii freeglut3-dev 2.4.0-4 OpenGL Utility Toolkit development files
ii glutg3-dev 3.7-25 the OpenGL Utility Toolkit development files

läuft super durch. danach nicht vergessen nen paar sachen in den dist/Linux folder zu verschieben. selbigen haben ich gerade mal kurz gepackt...

Hmm, glutg3-dev habe ich nicht verfügbar.
Aber Dein Binary läuft.
Wie kann man den Heli steuern?

mit einer ferbedienung die an die soundkarte angeschlossen ist -_-

deshalb hab ich oben in dem posting erwähnt, dass man kurzfristig nen /dev/input/js0 interface machen sollte....


greets, Nik

p.s.: zu den lizenzen: wenn sie dir nicht zusagen - schade. ich werde aber lieber so an dem projekt mitarbeiten als alles von vorne zu machen...

Hallo, für den FMS gibt es ein Plugin um die Fernsteuerung an die Soundkarten anzuschließen.
Das heisst Smartpropo. Funktioniert meinem Meinung nach super.

Flightbase hat geschrieben: 2. die physikengine läßt echt zu wünschen übrig. schweben ist ganz gut gemacht - aber das normale rumfliegen ist - nun ja - *zensiert*.

bis die NDA sachen durch sind (wenn sie es jemals sein werden...) sollte ein wechsel der physikengine in betracht gezogen werden. man muß das rad ja nicht neu erfinden.
wer kann hier mal ein paar freie, offene kandidaten vorstellen?

Wenn es um die Flugphysik geht keine Ahnung, ansonsten schmeiß ich mal das rein: http://www.continuousphysics.com/Bullet ... /index.php

C

Flightbase hat geschrieben:mit einer ferbedienung die an die soundkarte angeschlossen ist -_-

deshalb hab ich oben in dem posting erwähnt, dass man kurzfristig nen /dev/input/js0 interface machen sollte....

Warum so umständlich?
Warum nich teinfach das PPM Signal auslesen?
Für den FMS gibt es doch eine USB Lösung, die das macht, oder?

p.s.: zu den lizenzen: wenn sie dir nicht zusagen - schade. ich werde aber lieber so an dem projekt mitarbeiten als alles von vorne zu machen...

Naja, evtl. kann man ja mit den Leuten reden, von BSD auf GPL zu switchen?