Für RLUND unsichtbare Runway

[JOBIA]

Hier ein Beispiel von mir. Die unsichtbar programmierte Runway ETSM Memmingen. Nur die Anflugbefeuerung habe ich als Beweis für die Existenz der Runway sichtbar gelassen. Aber auch dieses könnte deaktiviert werden. Es ist alles neue Airporttechnik über AFCAD2. Allerdings noch die erste AFCAD2 Version. AFCAD2 selbst unterstützt die Technik unsichtbar nicht. Ich meine ich habe das damals mit dem Hex Editor gemacht. Ev. ist das bei der neuen Version implementiert. Ich vermute aber nicht da es keine offizilelle Geschichte ist. Muß mal schauen ob ich mir was aufgeschrieben habe wo das entsrechende Byte im Code sitzt. Werde das wenn ich Zeit habe mal mit der aktuellen AFCDAD2 Version von letzter Woche testen.

Im Prinzip könnte man auf diese Weise Bodenscenery komplett mit ILS, Anflugbefeuerung jeglicher Art, Taxilines , AI Traffic machen ohne die FS2004 Texturen als sichtbare Oberfläche zu nutzen. Bei geflattetem Airportboden könnte man jetzt Fotoscenery mit extrem hoher Auflösung als Bodenscenery verwenden. Bei unebenen Boden eben nur mit ca. 4,7m pro Pixel. Der neue Runwaybefehl des FS2004 hat ein paar Vorteile gegenüber dem des FS2002. Er hat zum Teil das Verhalten des FS2000 Befehles darüber möchte ich aber noch nicht plaudern mir fallen da ein paar schöne Zaubereien ein.


Hier das Bild im Anhang:

[BC_Holger]

Hallo Joachim:

bin wieder im Lande...

Habe mich gestern und heute mit dem Transfer meiner FS2002 AI Helikopter und Wasserflugzeug Files befasst, da es in letzter Zeit vermehrt "geht nicht" Kommentare gegeben hat. Klappt aber doch alles wunderbar und das neue AFCAD 2.21 ermoeglicht das Unsichtbarmachen von allen Szenerieteilen - man braucht also keinen Hex-Editor mehr. Daher sind unsichtbare Heliport- oder Wasser-Overlays ohne Probleme zu erstellen.

Mein "Test-Bericht" findet sich hier:
http://www.flightsimmer.com/forums/s...&threadid=7939
und ein paar Screenshots hier: http://www.flightsimnetwork.com/dcfo...D21/11325.html


Ab morgen dann aber wieder zurueck zur Ground2K4-Arbeit. Ich werde meine Projektdateien nochmals mit der neuesten Version kompilieren; mal sehen, ob sich was am "Weihnachtsgletscher" aendert.

Ciao,

Holger

[Horst LOWW]

Nachdem ich eine computer- und internetlose Zeit hinter mir habe (eigentlich auch sehr angenehm), darf ich jetzt wieder sehr, sehr viel nachlesen und aufarbeiten (bis mein Hirn raucht) und manchmal meinen „Senf“ dazugeben.

Als die BGLcomp_SDK erschienen ist, habe ich damit etwas „herumgespielt“, und für mich einige Ungereimtheiten gefunden (in der SDK selbst). Deshalb habe ich dies auch versucht mit diesem Artikel auszudrücken:
http://www.wcm.at/forum/showthread.p...t=Auswirkungen
ohne vorher damit weiter zu forschen.
Ich dachte halt, etliche Antworten werde ich später finden. Und etliche Antworten auf meine Fragen, habe ich jetzt im Avsim Scenery Design Forum nachlesen können.
Danke an alle Bastler, man erspart sich manchmal viel Arbeit, wenn man das „Kastl“ eine zeitlang nicht aufdreht.

Ich finde es nämlich sehr wichtig, wie eben Daten kompiliert werden (natürlich!), und habe damals den Zusammenhang zu verschiedenen Werkzeugen gesucht.
Es gibt eben neue Parameter z.B in der terrain.cfg, die richtig interpretiert werden wollen.
Abgesehen von den Fehlern, die jeder Anwender durch Unkenntnis selbst erzeugt.
Auch den Hinweis in der SDK auf die makemdl (wird auch sicher bald erscheinen), eben über das Mdl Format, finde ich sehr wichtig. (erklärt vielleicht auch den CTD bei Flugzeugwechsel).

Zu dem Thema hier:

Heißt dies, dass ich sozusagen auf jedem Terrain eine Landebahn erzeugen kann? Oder braucht diese unbedingt einen Flattencode?

Und noch ein paar Fragen:

- Gibt es Kenntnis, ob in der neuen Version von AFCAD 2.21 auch die Kompilierung anders ist? (obwohl ich mit Lee Swordys bisheriger, großartiger Arbeit bei mir noch keinen Fehler finden konnte)

- „spielt“ jemand mit Chris Wrights AutoAsm herum? Und ist dies eventuell ein Werkzeug mit dem man sich ein „Gesamtpaket“ für ein größeres Gebiet (Wasser, Straßen, Eisenbahn usw.) erzeugen kann?

- Gibt es neue wichtige Erkenntnisse seit Weihnachten, die ich vielleicht überlesen habe?

Horst

[JOBIA]

Zu Holger

Ja das Du mit der aktuellen Ground2K Version noch mal Deine Projekte neu kompilierst hätte ich auch vorgeschlagen.

Ich hatte hier im Forum diesbezüglich vermutet das die Routine die bei Ground2K die gezeichneten Flächen in Polys zerlegt Fehler verursacht und meiner Meinung nach zu aufwendige Polys erzeugt. Würde man das von Hand im Kopf machen käme da etwas besseres bei raus. Leider ist das über eine mathematische Routine doch recht komplex umzusetzen das gebe ich zu.

Rainer Duda antwortete aber darauf das eben diese Routine bei Ground2K jetzt geändert wurde. Deshalb habe ich mir bevor es mit der neuen Version nicht gecheckt ist keine weiteren Gedanken über das Problem gemacht.

Kannst ja mal hören lassen ob es mit dieser Version ohne Fehler klappt.

Zu AFCAD2. Das man unsichtbare Taxiways erzeugen kann im Prinzip nur mit der Mittellinie usw. ist klar. Aber eine Runway direkt in AFCAD2 ohne jeglichen Oberflächenbelag wie Asphalt, Beton oder Dreck das wäre mir neu. Ich habe nichts dergleichen bei AFCAD2.21 gesehen. Es sei denn ich habe etwas übersehen. Welche Runwayoberfläche soll denn als Platzhalter dafür stehen, das man praktisch nur die Landclasscenery sieht. Ich habe es wie gesagt damals doch mit dem HexEditor gemacht.

Es geht wie gesagt darum das man z.B Anflugbefeuerung in FS2004 Technik nutzen möchte (das erfordert zwingend eine Runwaydefinition)die Runway selbst aber optisch vom Belag her nicht vorhanden sein darf.

Es geht hier nicht um Löschfunktionen für Runways oder ähnlichen.

zu Horst im Prinzip benötigt sie kein Flatten. Man kann sie auf jedem Terrain einsetzen. Sie hat keine feste Oberfläche mehr wie der FS2002 Befehl. Sie verhält sich ähnlich wie der erste alte Runwaybefehl. Der Boden müßte natürlich smooth gemacht werden so das es nicht staubt wenn man Asphalt VTP2 Polys drunter legt. Das wäre ideal für schräge Runways da man die Anflugbefeuerung trotzdem definieren kann. Bisher hat man ja darauf verzichtet und bei schrägen Runways in der Regel auf VTP2 Polys allein zurückgegriffen. Man könnte auf beiden Seiten Anflugbefeuerung einsetzen auch wenn diese unterschiedlich hoch sind. Man müßte dann einfach zwei kurze Runways definieren. Probleme hätte man dann aber wenn die seitliche Beleuchtung über die ganze Länge der Runway gehen sollte. Ev. könnte man das dann abfangen indem man die Runway aus mehreren Runwaysegmenten aufbaut. Aber man bedenke folgendes. Es ist bisher nur Theorie die ich nur in Teilen getestet habe. Ich denke es wird auf jeden Fall Probleme geben wenn man auf diesem Airport AI Traffic einsetzen möchte. Ich weis nicht was der macht mit unterschiedlichen Höhenangaben. Ev. Hopserei. Ich denke zu viele Segmente sind performance störend.



Zu Auto ASM. Habe mir das neulich mal durchgelesen. Planen tue ich zumindest momentan nichts. Einfach zu wenig Zeit. Problematisch sehe ich bei diesem Tool das man eigentlich dafür sorgen muß das ein Straßensystem im Prinzip so vorbearbeitet werden muß das die einzelnen Linienenden keine Verbindung zu einander haben dürfen.

Auch das eine Linie auch an Kurvenradien/Ecken immer nur ein Pixel breit sein darf wenn ich das richtig verstehe. Gut ist eigentlich auch logisch. Ich hatte als das FS2002SDK rauskam auch mal eine Routine geschrieben die automatisch Vectoren aus einer Bitmap ausliest.
Hier ging es aber um geschlossene Formen wie Polys. Bei Linien in einer Bitmap weis man ja nie welcher Pixel mit welchem verbunden werden muß. Ich denke das wird bei Autoasm der Grund sein das man sie auftrennen muß. Das bedeutet viel Vorarbeit bei der Rohdatenbitmap die ausgewertet werden soll. Ich denke viel kann man da mit einem guten Photoprogramm abfangen. Als ich damals mal Landclass über Photopaint automatisch programmiert habe, nutze ich dort auch die Funktion von wachsenden und schwindenden Masken usw. Da kann man schon einiges machen.

[Horst LOWW]

@ Joachim

Verstehe.
Muss mit beiden Sachen etwas mehr herumspielen und ausprobieren. Bei Afcad mit Phototexturen und bei AutoAsm mit dem Rohdatenbitmap.
Vielleicht kommen ja Ideen, die von Designern in ihren Scenerien umgesetzt werden können.
Auch ich habe leider immer chronischen Zeitmangel für meine Freizeitbeschäftigung, daher werde ich fertig sein, wenn der FS10 erscheint.

Horst

[JOBIA]

Nur zur Info. Zu meinem Text und Bild mit dem unsichtbar machen von Runways bei Erhaltung von Anflugbefeuerung usw.

Hier schrieb Holger:

"Habe mich gestern und heute mit dem Transfer meiner FS2002 AI Helikopter und Wasserflugzeug Files befasst, da es in letzter Zeit vermehrt "geht nicht" Kommentare gegeben hat. Klappt aber doch alles wunderbar und das neue AFCAD 2.21 ermoeglicht das Unsichtbarmachen von allen Szenerieteilen - man braucht also keinen Hex-Editor mehr. Daher sind unsichtbare Heliport- oder Wasser-Overlays ohne Probleme zu erstellen."


Habe mich über Mail mit Holger unterhalten, da er diesen Thread nicht weiter verfolgt hatte. Er hatte es wohl falsch interpretiert. AFCAD2 beherscht diese Technik für Runways nicht. Damit sind diese Tricks auch weiterhin nur über HEX Editor möglich. Früher konnte man den Trick im SCASM Code direkt anwenden. Bei AFCAD2 kommt man aber an nichts dran. Nur über das neue BGLCOMP SDK sehe ich da Möglichkeiten.

Wenn man das Lee Swordy mitteilen würde wäre es aber ein leichtes für ihn das einzubauen.

[JOBIA]

Horst Du hast das Tool Autoasm angesprochen und ob jemand damit schon Erfahrung hat. Wir könnten uns da ev. austauschen. Ist ev. auch für andere z.B Rolf bzw. das Team interessant. Daher zunächst das was ich dazu sagen kann. Daher hier die ganze Geschichte mal umrissen. Nun an dem Tool selbst arbeitet der Chris Wright seit dem das FS2002 Terrain SDK rausgekommen ist. Die erste Beta konnte man sich im Zeitraum Dezember 2002 downloaden wenn ich mich recht zurückerinnere. Ich hatte damals auch damit rumgespielt nutzbar war es aber eigentlich noch nicht.

Die Grundsatzidee selbst was er da vor hat ist eigentlich genial.

Mal ausgeholt was wir momentan haben zum programmieren von Straßen, Gewässern usw. sprich Bodenscenery nach Vector Terrian SDK. Ich nenne hier die bekanntesten wie sie grob arbeiten. Zunächts mal Ground2K von Christian Fumey. Geniales Tool. Nachteil es muss im Prinzip alles von Hand gemalt werden. Sprich man muß sich eine Karte oder ähnliches als Bitmap in Ground2K hinterlegen und alle Elemente von Hand zeichnen. Oder wie Rainer es neulich mal ähnlich gesagt hat, alles von Hand abklicken. Das ist sehr viel Handarbeit die leider sehr monoton.


Das Straßennetz von Deutschland ist schon sehr verzweigt. Wenn es nicht nur genauer sondern auch optisch besser mit z.B allen Autobahnabfahrten sein soll dann ist das eine Arbeit für ein paar Monate. Daran sieht man vermutlich auch das sich noch niemand bereit dazu erklärt hat dieses großflächig freiwillig zu machen. Bei dem Handwerkszeug Ground2k kann man eigentlich nicht viel falsch machen. Wenn doch wäre das in der Regel nicht so tragisch wenn man sich schön seine Projekte aufhebt, so kann man das wesentliche nachträglich auch noch mal korrigieren. Ich habe da neulich wohl richtig gelegen mit meiner Vermutung das die Polys aus Ground2k zu komplex sind. Offensichtlich behebt die neue Routine von Ground2K dadurch diverse Probleme wie unerklärliche Nachtpolys die eigentlich dunkel sein sollten. Zumindest bringt es wohl Linderung bei dem Problem. Ausschließen kann man das Problem trotzdem noch nicht ganz.

Vorteil bei Ground2K. Man klickt nur die Punkte an, wo eine Straße z.B eine Richtungsänderung macht. Denn wir wissen die kürzeste Verbindung zwischen zwei Punkten ist eine Gerade. Logisch reicht es uns dann aus, wenn wir hier nur die zwei nötigen Punkte definieren wenn wir eine schnurgerade Autobahn haben.

Haben wir Kurven nehmen wir mehr Punkte. Im Prinzip macht es Ground2K so. Das was wir anklicken wird später als Vector Point im BGL Code genutzt. Das was da zwischen liegt in der Regel nicht, es sei denn es wird benötigt. Spezielle Besonderheiten bezüglich Code mal außen vor. Sprich wir haben eigentlich einen Framerate freundlichen Code. Selbstverständlich muß Ground2K auch darauf achten das alle Vectorpoints im LOD Raster liegen.

Das macht Ground2K im Hintergrund alles allein, da braucht man sich nicht drum kümmern. Will man z.B Flächen zeichnen müssen diese gezeichneten Eckpunkte der Flächen auch in Vectorpoints umgesetzt werden. Bei Flächen ist zu beachten das auch im Fs2004 für VTP2 Polys es immer noch gültig ist, dass Flächen nicht nach innen gewölbt sein sollten (gilt zumindest noch für VTP2 Polys nach FS2002 SDK). Der FS lässt hier gewisse Toleranzen zu. Übertreibt man es aber, kommt es zwar nicht zu einer Fehlermeldung, man wird aber hinterher wenn man genau hinschaut feststellen das die Flächen dann nicht so dargestellt werden wie man sie gezeichnet hat. Der Vectorpoint in einer Wölbung wird ausgelassen, dass Poly springt dann in der Regel zum nächsten Vectorpoint so das erst gar keine nach innen gewölbte Fläche entsteht. Kann man sehr schön sehen wenn man mit einem Designtool programmiert welches voraussetzt das der Anwender mitdenkt und die Polygone selbst in mehrere nicht nach innen gewölbte Polys aufbricht.

Abhilfe wie gesagt, die Flächen müssen in Einzelpolygone aufgebrochen werden damit es zu keiner Fehldarstellung kommt. Auch über dieses müssen wir uns keine Gedanken machen. Ground2k erledigt das über interne mathematische Routinen automatisch. Diese sind übrigends vor kurzem geändert worden. Vorher waren die Polys mathematisch korrekt aber extrem aufwendig und verschwenderisch hinsichtlich Vectorpoints. Das führte wie gesagt nicht nur zu Problemen sondern knabbert auch an der Performance.

Jetzt ist die neue Routine denen wie die Default FS Polys aufgebaut sind sehr ähnlich. Ob bei der neuen Ground2K Version die neuen Routinen zur Fehldarstellung führen können habe ich bisher nicht geprüft. Darum geht es hier auch nicht. Es geht mir nur um die Erklärung der Problematik von Autoasm.

Als nächste Möglichkeit gibt es z.B Konvertierungstools wie E00VTP von Falko Dienstbach. Diese lesen bestehende Topografie Daten (hier E00 Daten) aus und konvertieren sie. Diese E00 Daten sind im Prinzip schon so eine Art Vectorpoints. Falkos Tool rechnet diese um bringt sie dann ins passende FS LOD Raster der Vectorpoints und erzeugt den Code so das sie in eine BGL kompiliert werden können.

Zweifelsohne die eleganteste Lösung. Nachteil diese E00 Daten kosten meines Wissens etwas. Zweitens sind sie doch arg grob. Es sieht im Fs hinterher nicht unbedingt viel besser aus als jetzt.

Einen Testbericht über Railwaystrecken in Italien die auf E00 Daten basieren konnte man damals auch in einer FXP lesen.

Vorteil sie sind wesentlich genauer als das die Microsoftdaten. Das Highlight wäre meiner Meinung aber ein Tool welches Daten von GPS Autonavigationssystem ausliest. Das schwebt mir momentan vor, da ich persönlich festgestellt habe das diese Daten durch nichts zu toppen sind. Bei mir ist sogar jeder kleine Popelfluss in den Navigationsdaten enthalten. Auch als Basis einer Vectorpolygonscenery wären sie mit Abstrichen nahezu ideal.

[JOBIA]

Leider haben Polgonscenerien die Eigenschaft das sie optisch doch recht hart an den Rändern ausfallen. Reines Landclass löst das wesentlich eleganter, hat dafür allerdings speziell im Fs2004 den Nachteil das es mit der genauen Positionierung optisch nicht so richtig passt.

Auch kann man an der Formgebung einer kleinen Ortschaft oder Waldes mit Landclass nicht viel drehen.

Um auf die Navigationssystemdaten zurückzukommen. Leider sind diese Daten komprimiert und so wie ich mit bekommen habe reinrassig vektorisiert also keine X/Y Punkte. Ich habe bisher leider keine vernünftigen Erkenntnisse aus den Daten ziehen können.

Die Firmen selbst hüllen sich leider in Schweigen. Im Prinzip kommt vermutlich nur jemand mit Beziehungen an den Code dran.

Die dritte Möglichkeit wäre halt das Tool Autoasm.

Hier arbeitet man mit einem anderen Prinzip. Es soll nichts von Hand gezeichnet werden müssen es werden auch keine Vektordaten oder was auch immer konvertiert sondern es wird quasi eine Bildanalyse durchgeführt.

Sprich man hat eine Bitmap einer Karte. Diese Bitmap wird ausgelesen und daraus dann der Code von Straßen, Flüssen, Seen usw. automatisch erzeugt. Geniale Idee. Nur leider nicht ganz so einfach. Zum einen stellt das Tool gewisse Ansprüche wie es diese Informationen in der Bitmap haben möchte. Diese zu erfüllen bedeutet eine nicht unwesentliche Vorarbeit sonst wird das nichts. Leider nimmt diese Vorarbeit auch schon viel Zeit ein.
Eine einfache Karte geht nicht. Für Straßen sollte es nach Möglichkeit auch nur eine 1 Pixel breite Linie sein wo nach Möglichkeit nicht 3Pixel im rechten Winkel aneinanderliegen sollten. Dieses hat man sehr schnell wenn man eine Straße hat die in einem schärferen Winkel abbiegt. Da empfiehlt es sich das Eckpixel zu löschen wenn man Fehler möglichst verhindern möchte.

(Kommt vieles aber auch auf das Rohdatenmaterial an) Ist man schlampig bei der Bitmap muß man mit Fehlern rechnen die bei komplexen Gebieten zunächst nicht auffallen.

Auch ist Autoasm so intelligent das es Unterbrechungen einer Linie erkennt. Man kann hier sogar den Suchradius eingeben wo nach einer ev. zugehörigen Linie gesucht werden soll. Insofern ist das Stadium schon ganz schön fortgeschritten.

Diese ganze Geschichte mit der Bitmap und dem auslesen sehe ich aber nicht unbedingt als das Problem.

Ich habe jetzt in den letzten Tagen ein paar Stunden mit Autoasm rumprobiert. Die Bitmaps waren immer ideal vorbereitet so das keine Fehler hätten entstehen dürfen. Trotzdem kam es auch bei den mitgelieferten Demofiles/Bitmaps bei mir immer wieder zu Fehlern wobei hier von Chris selbst alle Parameter schon vorgegeben waren und ich ein Fehler meinerseits eigentlich ausschliessen kann. Bei der TS_demo habe ich bei den LWMs immer ein zusätzliches kleines LWM Poly in Area 4,22 der entsprechenden Cell wo regulär korrekt LWMs umgesetzt wurden. Da es immer die selben Vectorpoints sind tippe ich auf einen Fehler in der Routine.

Habe da aber noch nicht weiter nachgeschaut.

Wer Autoasm bisher schon mal benutzt hat kann ja mal kontrollieren ob es bei dem mitgelieferten TS_demo File bei ihm zu dem selben Problem kommt.

Ich hatte alle Tests nicht auf dem eigenen PC gemacht. Ev. waren auf dem Test PC nicht die aktuellen VB Runtime Module installiert, die Installation dieser lag schon etwas zurück. Ich denke aber nicht das das der Grund für das Problem ist.

Auf jeden Fall kann man so etwas mit diesem falschen Poly auf die Schnelle beheben wenn man sich im Code auskennt.

Ein Hauptproblem sehe ich aber momentan wo anders. Beispiel ich habe in meiner Bitmap/Karte mit 1024x1024 Pixeln eine gerade Autobahn/Linie von 600 Pixeln Länge woraus mal im FS eine gerade Autobahn werden soll. Wenn ich die Bitmap nun einlese werden exakt diese 600 Pixel erkannt.

Schön!

Egal mit welchen Parametern ich rumspiele es werden diese 600 Pixel auch als Vectorpoints im ASM Code umgesetzt.

Weniger schön!

Dabei muß natürlich auch Autoasm zum Teil interpolieren. Selbst wenn meine Linie in der Realität nur einer kurzen Entfernung entspricht (der Maßstab meiner Bitmap anders ist) , sind diese 600 Vectorpoints im Code zu finden. Da der Abstand der Vectorpoints im FS fest steht, fängt Autoasm jetzt an gleiche Vectorpoints im Code zu wiederholen um diese 600 unterzubringen. Egal was ich an möglichen Beeinflussungen (und Maßstäben) ausprobiert habe. Es waren die 600 Pixel immer als Vectorpoints umgesetzt.

Was bedeutet dieses?

Autoasm funktioniert bis auf kleinere Probleme einwandfrei. Es lassen sich im Prinzip wenn die Bitmap den Vorgaben entsprechend vorbereitet wurde komplette Scenerien automatisch erstellen. Das können auch sehr große Flächen sein. Nur der PC sollte mitspielen.

Super Sache wenn da nicht das Problem wäre, dass jedes Pixel z.B dieser 600Pixel langen geraden Straße umgesetzt werden würde.

Wenn ich jetzt mal Besonderheiten die beim Code erfüllt sein müssen außen vor lasse dann würden theoretisch zwei Punkte ausreichen um diese Straße mit Vectorpoints zu beschreiben. Im Code stehen aber mindestens die 600 Vectorpoints. Das ist nicht gerade sehr gut für die Performance im FS.

Da sehe ich momentan das Hauptproblem. Egal was ich programmiere VTP2 Polys, VTP2 Linien, LWMs immer wird jeder Pixel der Bitmap umgesetzt.

Jeder Vectorpoint im FS ist eine Information die verarbeitet werden muß. Das gilt generell für alles weniger Polys, Vectorpoints, Verticies bedeutet immer eine bessere Performance. Nicht umsonst wurden Mip Level z.B bei Texturen und dynamisches Verhalten in Form von LOD beim Mesh oder Aircrafts eingeführt.

[JOBIA]

Sollte jemand bei Autoasm irgendeine Stellschraube gesehen haben die definitiv zu weniger Vectorpoints führt würde mich das brennend interessieren. Ist es bei euch genau so, würde ich sagen kann man Autoasm mit guten Gewissen noch nicht für großflächige Scenerien verwenden, schon gar nicht wenn man große Scenerien aus flächenmäßig kleinen Gebieten und hoher Kartenauflösung zusammen setzt.

Was dem Tool momentan aus meiner Sicht fehlt ist eine Routine die bei einer Linie z.B vom aktuellen zu den folgenden Vectorpoints Richtungsänderungen der X,Y Werte beobachtet. Abhängig vom Maßstab müßte das Tool dann entscheiden ob man diesen Vectorpoint nutzt oder erst spätere zur Beobachtung heranzieht. So müsste das Spiel immer weitergehen bis eine ausreichende Änderung erfolgt bzw. bis man sich einer Area oder Cellgrenze nähert.

Erst dann dürfte der Vectorpoint genutzt werden. Ev. Zwischenpunkte könnte man einfügen wenn der Code optisch hängt.

Das ist da was mir bisher aufgefallen ist. Sollte sich das bei Dir Horst oder jemand anders bestätigen wäre mir das als Scenery noch zu gefährlich.

[Horst LOWW]

Viel Stoff zum durcharbeiten und mitdenken
Meine Annäherung zu AutoAsm von Chris Wright:
http://forums.avsim.net/dcboard.php?...&mesg_id=16520
war eigentlich nur folgende:

a) Ich habe damals den FS9 installiert und schade, im Eurw-Ordner passt leider wieder nichts. Und nachdem sich im Scenery Design das Meiste geändert hat, habe ich begonnen, meinen bereits vorhandenen Daten selbst einen kleinen Update zu verpassen. Bis eben neue Daten vorhanden sind.

b) Warum man bei MS nicht grundsätzlich Daten verwendet die zusammenpassen? keine Ahnung

c) Die größte Sorge derzeit für mich im FS9: hoffentlich pfuscht kein Designer an diesen Originaldaten herum. Und hoffentlich liefert MS Informationen in der nächsten SDK, wie dies zu umgehen ist. Ich will damit nur an Af-Daten im FS2002 erinnern, und Lee Swordy einen Orden verleihen, dass er dies (warum auch immer?, oder zufällig, obwohl es wieder viel Bastelarbeit ist) geändert hat. Man pfuscht an Originaldaten, nur mit Zustimmung des Anwenders herum. Oder sucht Wege dies zu umgehen.

d) Bei Flugwerk finde ich leider derzeit keine Bilder, bei Stefan Rausch schaut dies ja schon sehr gut aus. Also bei beiden Produkten kein unmittelbarerer Bedarf noch mehr zu ändern. Also für Österreich habe ich Geduld, und die Geduld sollten auch die Autoren haben. Und derzeit bin ich überzeugt, ich werde belohnt.

e) Aber für den Rest Europas (und die ganze Welt)? Und hier, muss die Genauigkeit nicht unbedingt stimmen, zumindest für mich. Vielleicht kann man in den Srtm Daten Löcher einfach bearbeiten (siehe AF_2: Toll wie die Flusigemeinschaft dies relativ rasch wieder bastelt) für den kleineren Raum? Aber halbwegs zusammenpassen soll es.

Joachim, ich habe ehrlich gesagt noch nicht mit AutoAsm „herumgespielt“, da ich mich zu den Konsumenten zähle.
Aber vielleicht ist dies ein Werkzeug der Annäherung an dieses Problem. Und vielleicht wartet Chris Wright auf Benutzer, um es weiterzuentwickeln. Wir werden ihm vielleicht helfen, seine Probleme zu lösen, bzw. helfen sein Werkzeug zu entwickeln.
Ich habe eigentlich nur abgewartet, ob Szenerien erstellt werden, die damit entwickelt wurden, oder welche Fehler sich daraus ergibt.

Aber Recht hast du, man soll Ideen versuchen und ausprobieren. Indem man ganz einfach und simpel Dinge ändert.
Ich glaube Chris Wright wartet auch nur auf Fragen und Erfahrungen.

Meiner Zeit entsprechend werde ich natürlich versuchen mich einzudenken und einzuarbeiten, und anschließend oder zwischendurch hier in diesem Beitrag berichten.

Derzeit:
- Ich hoffe, du hasst ein System, deine oft aussagekräftigen Texte zu sammeln, und diese als Zusammenfassung auf deine Homepage zu stellen. Ich muss leider öfters nachlesen, und dies ist mit viel Zeitaufwand verbunden.

- Zur Landclass-Zusammenfassung finde ich toll, dass du anscheinend auf die Sdk wartest. Gut so.

- Zu Areafill – keine Ahnung (bzw. Verständnis für die Zusammenhänge) was ich da gemacht habe (ich habe nur das Bild noch gehabt bei diesem Beitrag)

- Zu Finkenwerder oder deiner simflyer Frage damals :Area16N schummelt sich anscheinend in der Priorität immer vor. Warum? Keine Ahnung.

- Hast du ein paar Links in deinem „Hirn-Google“, zu dem angesprochenen GPS-Daten und deren Umsetzung?

Und noch eine Bitte, da ich zu keinem Designer oder Produzenten und nicht mal zu einem Flusikollegen Kontakt habe, auch nicht per Mail, (schützt zum Glück meine Zeiteinteilung und ist auch gewollt): Kann sich nicht manchmal, eine deiner Kollegen oder Freunde, bei gewissen Beiträgen auch öffentlich einbringen?
Siehe auch deine derzeitige Abänderung der terrain.cfg. Dies sind für mich die Vorteile des WWW. Nicht nur um Wissen zusammenzutragen.

Horst