Straßen: FLugwerks "All Roads Of Europe"

[r_schon]

Hallo Rainer,

O.K. man kann schon in die Details gehen, wenn man das will.

Ich hatte eigentlich gedacht, man überlegt sich erst mal, wie man und wer verbindliche Konventionen setzt. Und ob das überhaupt möglich ist.

Und dann müßte man sich mal fragen, ob dieses Thema bei den Roads richtig angesiedelt ist oder nicht lieber im Designer Forum - aber da lesen vielleicht ideenreiche User nicht mit?

Wenn es so einfach wäre mit durch MS vorgegeben Struktur. Hast ja bereits die Problematik angerissen.

Wir haben ( durch Glück oder Voraussicht ??? ) unsere VTP Strassen alle in separaten Ordnern - also schon mal kein Problem mit den FS Quality Roads, unser Datei wird umbenannt und es paßt. Jetzt mal gesponnen - wenn alle Designer die VTP Strassen in eindeutig erkennbaren Ordnern hätten, qua Konvention, dann könnte man dieses Problem möglicherweise mit Automatismen bei der Installation lösen. Dahin geht jetzt mein Denkansatz.

Noch ein Detail, Holger spricht von eindeutigen Dateinamen - das wäre so ein Punkt, den man sicher mit Konventionen in den Griff bekäme.

Gruß
Rolf

[Andragar]

Wie der Ist-Zustand ist, ist wohl allgemein bekannt.
- Szenerien werden an allen möglichen Stellen installiert, diese Freiheit ist z.T. vom User gewünscht, zum anderen gibt es den Herstellerwildwuchs.
- Originaldateien werden durch umbenennen abgeschaltet und nur bedingt Ersatz geschaffen. (Woher soll ein zweites Addon wissen, dass bestimmte bgls abgeschaltet sind? Woher soll es der User wissen?)
- Addons lassen sich schwer auffinden um sein eigenes Addon entsprechend installieren zu können.

Da ein unverbindlicher Style-Guide (wollte schon Guido schreiben ) nicht wirklich möglich ist, weil sich kaum einer daran halten wird. (Die Ausreden kennen wir ja: keine Zeit, wusste ich nicht, hab ich immer schon auf die und die Art gemacht, ich pass doch nicht meinen alten Krempel an...)

Sehe ich eigentlich nur eine Lösung indem man Meta-Daten einführt. Diese muss ein Tool automatisch aus einem auf einem blanken FS installierten Addon erzeugen können. (Entfernte Dateien, Veränderungen, neue Dateien.) Idealerweise komplett, wenn es nicht geht auch mit manuellen Zusätzen (LOD Level, gewünschte config-Einträge, Versionen...).

Nun kann man hergehen und die Addons in seinem Gebiet so untersuchen zu lassen. Dann erzeugt man seine eigene Addon-Metadaten. Nun muss das Tool so gut sein, aus gewissen Regeln eine abhängige Installation zu erzeugen. (Wenn Addon XY vorhanden, dann diese und jene Dateien, e.t.c.) Diese Regeln sollten allgemeiner Natur sein, eine Abhängigkeit weil ein ganz bestimmtes Addon installiert ist sollte es nicht geben sondern sich alles aufgrund der Struktur des Flusis und der installierten/zu installierenden Dateien ergeben.

MetaDaten könnten so frei ausgetauscht werden oder auch zur Not on the fly erstellt werden. Im Prinzip hätte man so einen universellen Installer, der auf das jeweils existierende System Rücksicht nimmt und trotzdem "kinderleicht" zu bedienen ist, da es keine Interaktion mit dem User erfordert.

Das Blöde dabei ist: Es gibt Addons, die ihre Installationen der Files ändern. (Austauschtexturen e.t.c.) Die eierlegende Wollmilchsau werden wir nie bekommen. Die Frage ist also die der Nutzen/Aufwand/Kosten um so ein Meta-Daten-Installer zu schreiben.

[Rainer Duda]

wenn alle Designer die VTP Strassen in eindeutig erkennbaren Ordnern hätten, qua Konvention, dann könnte man dieses Problem möglicherweise mit Automatismen bei der Installation lösen. Dahin geht jetzt mein Denkansatz.

Ja Rolf. Wohl die Möglichkeit, die mir schlußendlich bleiben würde. Nur... Genauigkeit hat seine Grenzen und ich kann zumindest nicht von mir und meinen Arbeiten behaupten, metergenau zu liegen. Lasse ich es also schlußendlich einfach zu, meine Straßen (wobei dies ja nur der obere Teil des Eisbergs ist) nicht anzuzeigen, so liegen dort die Straßen des anderen Addons, die folglich niemals (selbst bei noch so gepriesener Genauigkeit) wirklich da liegen werden, wo ich es möchte. Noch schlimmer z.B. bei Brücken, da dort das andere Addon ja nicht wissen kann, wo ich eine Brücke gesetzt habe oder nicht.

Da bleibt schlußendlich nur Prüfung, ob es (nach Erscheinen des anderen Addons) möglich ist, in gewissen Grenzen deckungsgleich zu sein oder zumindest so, dass einem User Probleme gar nicht oder kaum auffallen.

Und dann gibt es möglicherweise noch den Fall, dass es von anderer Seite einen gewissen Installationsart-Zwang gibt, der eine der obigen Regeln erst mal wieder in Frage stellt.

Was man zumindest im ersten Schritt machen sollte ist eine Offenlegung der eigenen Dateistruktur, genutzer Layer, Gebietsabgrenzungen etc. Und die Erkenntnis einzufordern, dass man nicht alleine auf der Welt ist und die Allwissenheit gepachtet hat.

Und dies ist schon schwer genug, leider.

Ciao,
Rainer.

[wazlaf]

Hallo,

ich spreche hier nur als interessierte User und würde mir wünschen, dass bei allen Produkten so eine Beschreibung der Dateien und Änderungen wie bei Holger vorhanden ist. Der, der sich nicht Auskennt den wird es nicht interessieren und den der es braucht (aus welchen Grund auch immer) wird es helfen.
Ich zum Beispiel richte mir momentan Österreich aus AP und AA1 + AA2 so her wie es mir gefällt. Alleine beim vergleichen von doppelt installierten Texturen konnte ich 220 Mb einsparen. Ich habe festgestellt, das es zum Beispiel bei AA überhaupt keine Struktur gibt.
Es ist kein System innerhalb eines Produktes vorhanden, hier könnte meiner Meinung nach zum Beispiel ein Publisher zumindestens für die von ihm vertriebenen Produkte Vorgaben machen.
Meine Hoffnung das dies geschieht ist aber sehr klein.

lg walter

[r_schon]

Hallo Miteinander,

@ Rainer:

Du hast natürlich Recht - Probleme zwischen Flächenszenerien, wie die, die Du jetzt machst und globalen Addons wie den Roads sind natürlich immanent, solange Du Deine andere Genauigkeit hast.

Daher, an den Grenzen wird es mit regionalen Szenerien räumlich und von der Machart eigentlich nicht passen mit den Roads - ich sage einfach mal, das wird sich grundsätzlich nicht lösen lassen, ohne daß man nachträglich richtig anfasst ( dann kannst Du Deine Szenerie in Teilen neu bauen) - liegt auf der Linie Airfields und Fotoszenerie.

Es wird wohl tatsächlich so sein müssen, daß auch der Erbauer regionaler Szenerien mit GPS Genauigkeit arbeitet. Wie Marc schon sagt - so etwas wie die Roads werden wohl Referenz und der Rest muß nachziehen. Für Dich nicht einfach, diese Situation und selbst mit allen Infos nur als Kompromiß lösbar, fürchte ich.

Aber da laß ich mich gerne belehren - vielleicht hat Holger einen Tipp aus seiner Zusammenarbeit mit UT/ Flight 1.

@ Michael:

Dein Ansatz gefällt mir sehr - weiß allerdings nicht, wie man so etwas programmieren könnte. Wenn das jemand hinbekommen sollte - dieses Tool wäre ein neues FSUIPC - da käme dann keiner mehr dran vorbei. Vielleicht hat jemand diesbezüglich Ideen ?

@ Walter:

Ich würde sagen, die Publisher sind eine falsche Adresse. Viele sind mit der Problematik und Vorgaben zur Datenorganisation überfordert - ist nicht deren Job. Zudem, dann hättest Du nur Funktionalität mit einem Publisher. Aber da ist bekanntlich schon Aerosoft mit einem Matthijs Kok überfordert - ich meine das jetzt wirklich nicht vorwurfsvoll, sondern ich habe dafür weitgehend Verständnis.

Gruß
Rolf

[Andragar]

@Rolf: Mit entsprechenden systembedingten Einschränkungen ist das schon machbar. Nur seeehr aufwendig. Außerdem muss man Einschränkungen bezüglich Verteilung machen, da man sonst jedesmal beim Installieren das ganze System scannen müsste. Und das dauert.
Dazu kommt, dass man wohl an ein lesen des BGL-Inhaltes nicht herum kommt. Noch ein zeitintensiver Job.
Installation am besten auch nur über das Tool erlaubt. Und da spielen die Kopierschutzfunktionen der heutigen Installer nicht mit.
Andererseits braucht man nur einmal die MetaDaten. Aber selbst dann ist diese "Fremdinstallation" nicht einfach, besonders wenn es dort noch Optionen gibt.

@Alle
Ja, mir erscheint es inzwischen auch so. Vor eins, zwei Jahren war die Entscheidung die MS Standardwelt mit den Flugplätzen als Referenzpunkte zu wählen. Auch aus dem Onlineaspekt heraus, wer will schon seine Mitflieger 50 Meter weiter durch die Botanik rollen sehen. Heutzutage wo mit Mesh, Straßen, Photoszenerien die eingeGPSste Welt immer mehr durchschlägt sollte man sich für die Zukunft als Addon Designer generell überlegen alles GPSgenau zu positionieren.

[Horst LOWW]

Hallo,
Wollte diesen Text nach Holgers „standing ovation“ shreiben.
(leider war es unmöglich, oder bin ich für diese Themen gesperrt? – ein neuer Versuch)
Hier der Text (falls es diesmal funktioniert):
______________________________
Also ich dachte ich schreibe nichts mehr zu diesem Thema.
Aber manchen Aussagen kann ich nicht widerstehen.
Was ich von „Dali“-Taburet halte, habe ich geschrieben! (nämlich sehr wenig)
(Auch „swiss und austrian waters“ gibt es schon länger)

Holger, ich verstehe deine Argumente nicht ganz, bzw. diese „Offensive“ für ein Gebiet, wo du wahrscheinlich kein Addon hast, bzw. eines erzeugen willst.
(vielleicht kann man ja dein Innsbruck Addon berücksichtigen?)

Schon alleine die Belehrung für die Grundelemente von Wasser an Flugwerk!?
Hierzu kann ich dir nur mitteilen, dass Austrian Professional sämtliche Hydropolygone mit Höhen darstellt! (auch die Donau, usw.)
Und die Änderung in deiner „Ausführung“ (Uferlinie (selbe Breite und Textur) und ein paar Wasserklassen) hat mich für Österreich knapp eine Stunde gekostet. Auch bei Flüssen mag ich Uferlinien
Natürlich habe ich mir selber keine Welleneffekte (man kann hier nicht „Wellenreiten“) eingebaut, und die Uferlinienbreite nicht mit 30 – 35 Punkte definiert!

Also sicher auch für Flugwerk kein Problem dies darzustellen!

Aber egal, zwischen Prince Rupert und Wien liegen ja auch sehr viele nautische Meilen!

Nur den Hinweis zu UT verstehe ich nicht!
Was man auf dieser Seite lesen kann, kann man auch großflächig umsetzen, ja!
Ein wenig Vectorautogen (mit Licht, oder vielleicht noch Autos?), gesteuert über die terrain.cfg (auch diese Zahl erhöhen), der Rest: landclass und vtp. Wurde hier schon alles besprochen!!

Daher sind wahrscheinlich deine Sorgen um Misty Fjords größer!
Und die Anpassung an vorhandene Addons? In Europa?

Hier in Europa besteht das Problem, der vielen Objekte und VTP Polygone, die nicht mehr passen!!

Die Austrian Professionals 2004 (ATP 2004) kann mir kein Addon ersetzen!

Aber eine „Legoplatte“ für ganz Europa zu einem akzeptablen Preis finde ich gut!!!
Und da verlasse ich mich vielleicht doch lieber auf FSQuality/Guido!?

Also, vielleicht doch zurücklehnen und lesen, wie Marc schreibt?
____________________________________

Und nun mein neuer Kommentar:

Wo sehe ich das Problem:

Siehe Mesh Daten: Dem Anwender ist es egal (dem Großteil): Im Prinzip greift er zu Daten die er global bekommen kann.

Jeder hat etwas in der „Pipeline“ und keiner sagt es, oder Details!
(Siehe Taburet – Information nehmen und umsetzen – verstanden hat er es bis heute nicht!, welche Daten er verwendet . Er war halt sehr schnell.)

Und wahrscheinlich ist es unmöglich, während der Phase der Entwicklung, das Endprodukt (Layer und sonstiges) für qualitative Produkte korrekt darzustellen, bzw. mitzuteilen.

Nur für uns Konsumenten wird es immer schwieriger, dem einem oder anderem den Qualitätsunterschied zu erklären, bzw. sein Problem zu lösen.
Wir habe nicht alle Addons! – und der Designer kann es sicher auch nicht an alle Addons anpassen!

Ich finde diese „Legoplatten“ in Ordnung, für große Gebiete, und auch wichtig!

Nur; welche ist die Richtige?

Auch Legoplatten können ein Problem für den Anwender sein! Siehe Misty Fjords – hat da noch jemand Durchblick bei diesen (zwar Freeware) Addons (fiktiv oder nicht)?

Vielleicht gibt das Zugeständnis des Datenlieferanten auch MS die Möglichkeit „kostengünstig“ diese Daten in der nächsten Version zu verarbeiten?
Wir hätten zumindest eine einheitliche „Legoplatte“!

Was dieses Addon betrifft, habe ich keine Ahnung!
Damit man wieder zum Thema zurückkehrt.
(Qualität hat sich normalerweise immer durchgesetzt)

Lösungsvorschlag habe ich keinen – ich würde dies eher als freie Marktwirtschaft und Marketing bezeichnen. Für den Konsumenten zu durchschauen?
Nein, selbst für Holger anscheinend ein Problem, wer seine Daten verlegt.

Horst
Der sich seinen FS selber anpasst, aber leider kein Möglichkeit sieht seine Daten zu „teilen“
(copyright)

[BC_Holger]

Hallo zusammen,

an Horst:

Und die Änderung in deiner „Ausführung“ (Uferlinie (selbe Breite und Textur) und ein paar Wasserklassen) hat mich für Österreich knapp eine Stunde gekostet. Auch bei Flüssen mag ich Uferlinien
Also sicher auch für Flugwerk kein Problem dies darzustellen!

Na, wenn das "kein Problem" ist, warum werden die dann nicht mitgeliefert? Oder willst du damit sagen, dass das jeder User, so wie du, bei Bedarf Uferlinien und Wasserklassen in "knapp einer Stunde" selbst einbauen sollte?


Mein Beitrag war auch nicht als Belehrung gemeint, sondern als Wunsch eines potentiellen Users, der es schade findet, dass wichtige optische Elemente der Gewaesser "ausgeklammert" werden. Realismus ist fuer mich persoenlich eben mehr als nur akkurate Positionierung.

Sorry, deine Aussagen ueber UT kann ich auch nicht nachvollziehen. Nochmals: es geht nicht darum, was hier bereits theoretisch durchdiskutiert wurde, sondern was letztlich auf dem Markt erscheint. Reden koennen wir alle halt viel

UT und Flugwerk benutzen, soweit ich weiss, dieselben NavTeq/GDT/TeleAtlas Grunddaten, daher werden die Basiselemente wohl sehr aehnlich sein. Ich habe UT auch nur erwaehnt, weil die eben die Gewaesser und andere Aspekte der Landschaft offenbar kompletter darstellen werden, als das bei Flugwerk AROE der Fall ist. War aber nur ein Hinweis, denn ich habe ja selber auch weder AROE noch UT Europe gesehen. Und von AP habe ich sowieso nicht gesprochen

------

Zum Thema Konventionen:

Ich denke, dass in vieler Hinsicht diese Diskussion fruchtlos ist, denn in der Praxis gibt es halt immer andere Prioritaeten und Sachzwaenge, die eine Einhaltung von Konventionen verhindern wird. Daher appelliere ich mehr an die einzelnen Produktionsteams, zumindest die Stolpersteine durch "Open Book" Projektdesign und Dokumentation so klein wie moeglich zu klopfen und, wo immer praktikabel, sich auch ueber die eigenen Firmengrenzen hinaus ueber Kompatibilitaeten zu verstaendigen.

Zu Michaels Meta-Daten Idee: gefaellt mir auch sehr gut, ist aber wohl wirklich nur durchsetzbar, wenn das direkt vom MS Designteam vorgesehen wuerde, z.B. in der Form von SDK Tools.

Uebrigens hat Jim Keir bereits vor ein paar Monaten mal ein kleines Tool erstellt - bglpatch, siehe http://forums.avsim.net/dcboard.php?...ng_type=search - das direkt beim User LOD8 Zellen aus Defaultfiles "herausstanzt" und, bei Deinstallation des Add-ons, wieder mit Defaultdaten fuellt. Also ein aehnlicher Ansatz, wie es das JABBgl Tool mit den FL9*.bgl Default-Flugplatzflattens macht.

Das Problem mit solchen Tools besteht aber darin, dass sie, theoretisch zumindest, das FS EULA verletzen. Ich verteile zwar auch selber munter gepatchte Defaultdateien, trage aber damit selber das "Risiko", anstatt es dem Tooldesigner aufzubuerden. Daher mein Gedanke der Implementierung via SDK Tools. Angeblich haben die FS Macher ja angekuendigt, dass fuer die naechste Version die SDKs bereits vorab zur Verfuegung gestellt werden, aber das glaube ich erst, wenn ich es sehe

Ciao, Holger

[JOBIA]

Schaue auch mal wieder rein.

Interessante Diskussion

Ich hatte schon damals den Verdacht als Guido mal von "Wir" beim Projekt All Roads of Europe sprach, dass der Heinz dahinter stecken würde.

Ich bin mir auch ziemlich sicher das es ein Must Have Addon werden wird. Der Heinz ist technisch dazu in der Lage und er weis auch über die Feinheiten des FS bescheit und wo es drauf ankommt.

Diese dezente Wirkung der Haupt und Nebenstraßen der A.R.O.E ist im wesentlichen auf die verringerte Breite zurückzuführen, so sieht es zumindest bei den Screenshots aus. Ich hoffen nur das sie jetzt hinsichtlich Realität nicht zu schmal sind.

Ich werde auf jeden Fall ein Käufer dieses Produktes werden.

Habe sie ja leider in der Verlosung der FXP nicht gewonnen.


Normale Default Straßen waren eigentlich immer schon zu breit.


Aus diesem Grunde hatte ich das damals auch über meine Tauschtexturen für den FS2002 korrigiert. Damals gab es noch keine anderen Möglichkeiten, der VTP Code war noch nicht bekannt.

Unabhängig wie gut oder schlecht Taburet ist. Würde er nicht auf Default Straßenbreiten zurückgreifen sondern auf eigene dann würde er beim optischen Vergleich nicht ganz so schlecht bei den Vergleichsscreenshots wegkommen.




Zu dieser Problematik vor der wir bei erscheinen der All Roads Of Europe stehen also dem Addon Chaos mit vielen doppelten Straßen, Gewässern usw. habe ich schon länger einen Bereich in meiner Dok.

Er beschreibt wie man auf effiziente Weise seinen FS nach versteckten Landclass, Waterclass, Mesh, LWM, VTP Code usw. abscannt. Wie man dann mit diesen gefundenen Daten weiterarbeitet.

Wie man LOD Level von Mesh ermittelt usw.

Hat man alle Dateien auf die Schnelle identifiziert kann man auch persönlich mit den Möglichkeiten die man dann als normaler Anwender hat handeln. Also gezieltes Deaktivieren von BGL Sceneryfiles.

Nur die Arbeit der Bereinigung die kann ich keinem Anwender abnehmen.

Ich denke hier wären auch Automatismen nicht unbedingt sinnvoll.

Der Anwender sollte selbst entscheiden was ihm wichtig ist.

Momentan bin ich aber beruflich und privat sehr eingeengt, so das mir für die Dok keine Zeit bleibt.

Ev. wird es aber doch noch Veröffentlichung der All Roads of Europe etwas, denn die hinken ja auch hinterher.



Was Default FS Files betrifft. Ich denke nicht das es hier rechtliche Probleme geben sollte. Wenn Microsoft es nicht wollte das jemand an den Daten des FS arbeitet, dann würden sie auch keine SDKs rausgeben.

Ich denke für Microsoft ist es wichtiger das sich der FS gut verkauft.

[Rainer Duda]

Joachim

Zu dieser Problematik vor der wir bei erscheinen der All Roads Of Europe stehen also dem Addon Chaos mit vielen doppelten Straßen, Gewässern usw. habe ich schon länger einen Bereich in meiner Dok.

ich finde Deine Arbeit allgemein sehr sehr gut. Nur... von Aussagen wie "habe ich schon lange in meiner Dok" (die wir ja jetzt schon seit Monaten hören, ich kenne Deine Problematik auch bezüglich Webspace) habe ich leider recht wenig und die kommen dann irgendwann zu spät. Ist kein Vorwurf an Dich, nur mal eine Feststellung über viele Beiträge von Dir zu eigentlich brennenden Themen. Immer wieder erstaunlich, was Du herausfindest. Tolle Arbeit!

Ich selbst freue mich auch schon auf die Arbeit von Heinz, den ich für die Austria Pro sehr bewundere. Was ich halt verurteile ist diese Sicht der Dinge, keine Absprachen untereinander zu treffen. Vielleicht aber nur für jemanden zu verstehen, der monatelang eine Region aufgebaut hat, die in sich schlüssig ist und mit Standardmitteln das vielleicht überhaupt mögliche herausholt.

Von daher ist das von Holger (und ja auch von mir) vorher schon angesprochene Minimalziel absolut nötig zu erreichen. Wenn das noch nicht mal geht, dann "Gute Nacht".

Ciao,
Rainer.