@Michael

so logisch ist das für mich nicht.

Was wissen wir denn?
- viele der Plätze im FS liegen geografisch nicht an der richtigen Stelle.
- die Luftbildszenerie RG3 scheint zumindest sehr genau geogrfisch positioniert.

Jetzt kann man sich aus Entwicklersicht endlos streiten wer was machen müßte, an den Gegenheiten kommt man nicht vorbei.

M.E. gibt es langfristig nur eine vernünftige Lösung, die Plätze im Bereich von Fotoscenerien exakt zu platzieren.
Ob das für vorhandene fertige Scenerien wirtschaftlich vertretbar ist möchte ich bezweifeln.

Was ich aber gern hätte, wären AFCAD-Files, die auf die faktische Lage im FS ausgerichtet sind. Einige könnte ich sogar liefern, wenn euch die Qualität ausreicht (sind etwas mit der heißen Nadel gestrickt).

Ich blick jetzt nicht mehr, wo ist das Problem mit den AFCAD Dateien. Wir richten Plätze nach MS aus und liefern passende AFCAD Dateien f�r die Plätze.
Wo fehlt es jetzt (ausser in Kempten, Blaubeuren, Degerfeld)?

So ich habe noch mal nachgeschaut. FAT 32 ist bei mir auch schon ein bischen her.

(FAT= File Allocation Table 32 welches z.B die Information enthält in welchen Clustern sich die einzelnen Dateien aufhalten. )


Bei FAT32 ist die kleinste erreichbare Clustergröße 4096 Bytes. Vorrausgesetzt derjenige der riesige Festplatten nutzt teilt diese in mehrere Partitionen auf.

Nehmen wir mal an man hat jetzt die optimale kleinste Clustergröße (kleinste Zuordnungseinheit die man mit FAT32 adressieren kann)

also 4096 Bytes.


Dann gilt folgendes Dateien die kleiner als 4096 Bytes sind werden in so einem 4096 Bytes großen Datenbereich untergebracht. Sind sie genau 4096 Bytes dann reicht so ein Datenbereich genau aus.


Sind Dateien doppelt so groß dann müssen zwei 4096 Bytes große Bereiche genutzt werden. Leider haben Dateien selten solche Größen das sie sich genau in solche 4096 Bytes große Bereiche aufteilen lassen. Ist eine Datei 2,5 mal so groß dann kann man natürlich nicht 2,5 mal 4096 große Bereiche verwenden das geht nicht. 4096 ist die kleinste Einheit. Also muß ich drei 4096Bytes große Bereiche verwenden. Folglich verschwende ich jetzt 2048 Bytes ungenützt.

Das passiert in der Regel sehr oft auf der Festplatte. Die meisten Dateien sind sehr groß sie belegen sehr viele Cluster da stört es nicht wenn man mal fast ein komplettes Cluster vergeudet weil man noch ein paar Bytes einer Datei unterbringen muß.

Ein Satz mit der Clustergröße oben war bei mir nicht präzise genug ausgedrückt. Eine Fototextur ist nicht kleiner als ein Cluster sie benötigt aber zusätzlich ein Teilcluster.

Daher hier noch mal das ganze präzise.

Wie sieht es bei Fototexturen einer Fotoscenery genau aus.

Diese haben eine Größe von 43762 Bytes. So eine Textur müssen wir auf unsere 4096Bytes Clusterbereiche aufteilen. 43762 / 4096=10,684... Cluster. Geht nicht also müssen 11 Cluster herhalten um die Datei unterzubringen.

11x4096 Bytes sind 45056 Bytes. Wir verschenken also bei einer einzelnen Fototextur immer (45056Bytes - 43762 Bytes)= 1294 Bytes

Uns geht also über 1/4 eines Clusters an Speicherplatz verloren.

Hat man riesige Festplatten unter FAT32 in ungenügend viele Partitionen aufgeteilt kann die kleinste Einheit z.B auch 8192 Bytes betragen. Hier werden die Verluste sogar noch höher.
Hat man andere Datenträger z.B CDs dann gibt es dort eine andere Datenstruktur hier haben wir nicht diesen Verlust wie auf einer Festplatte unter FAT32. Auch bei XP unter NTFS sind die Verluste geringer.


Dieses ist mit einer der Gründe der hier zuvor erwähnten Probleme. Die Fotoscenery bläht sich unter FAT32 künstlich durch die Speicherplatzverschwendung auf.

Übrigends da man sieht das eine einzelne Textur sich auf 11 Cluster aufteilt kann selbst eine einzelne Textur sehr wohl auf der Festplatte fragmentiert vorliegen.

Berechenen wir doch einfach mal wie groß die Real Germany 1 wäre wenn sie optimal untergebracht wäre und wie es tatsächlich unter FAT 32 aussieht.

Meine RG1 besteht aus 21914 Bodentexturen. Das ergibt eine theoretische Größe von 21914 x 43762Bytes= 959000468Bytes sind ca. 936523,9KB


Tatsächlich werden die Texturen unter FAT 32 auf der Festplatte aber 21914 x 45056Bytes= 987357184Bytes beanspruchen sind ca. 964216KB

Wir sehen ganz grob geschätzt fast 30 MB Unterschied bzw. Platzverschwendung.

Aufgrund der Masse an Texturen, wo jede einzelne im Extremfall durch Fragmentierung noch zerstückelt auf der Festplatte vorliegen könnte, kann man sich gut vorstellen das der Ladevorgang schon extrem dauern kann.

Was die Installation betrifft.

Bzw. das man ev. voher auf der Festplatte den verfügbaren Festplattenspeicherplatz kontrolliert und der Vergleich mit der CD zunächst ein positives Ergebniss bringt.

Bei der Installation bläht sich die Fotoscenery jetzt auf. Zusätzlich wird der Festplattenplatz ev. durch die Auslagerungsdatei von Windows während der Installation minimiert. Irgendwann kommt es dann zum Crash nichts geht mehr.

Ich kenne die RG3 nicht. Aber in der Tat wie Andragar schon sagte ev. hätte eine Aufteilung der Installation in mehrere Einzelschritte/Bereiche das Problem halbwegs für FAT32 Nutzer behoben.

Das war jetzt noch mal zum Thema FAT32 und zur Ergänzung woher ev. die Unterschiede der Ladezeiten bei RG1 und RG3 kommen könnten.

Was die Ladezeiten der Scenery allgemein aufgrund der vielen zu ladenden Texturen betrifft habe ich noch nicht gerechnet. Auch nicht wie hoch der Unterschied ist wenn die erweiterten Geländestrukturen aktiviert sind.

Hallo Miteinander,

Nochmals eine Verständnisfrage ( weil ich RG3 aus o.g. Gründen nicht habe):

Es ist doch richtig, daß auch die Standartplätze nicht genau deckungsgleich in der RG 3 liegen? So interpretiere ich auch das Foto von EDMN, der Flieger wird im FS 2004 auf dem Taxiway der Fotoszenerie abgesetzt?

Bekannt ist mir auch, daß es zwischen FS 2002 und FS 2004 an einigen Plätzen Lageverschiebungen gibt. Ein Beispiel, was auch hier schon diskutiert wurde, ist Konstanz (EDTZ) mit einer Ablage von ca. 1,4km nach Süden im 2004 im Vergleich zum 2002.

Jobia hat dazu damals eine mögliche Erklärung geliefert.

Wir sind anhand der Koordinaten der Charts damals davon ausgegangen, daß der FS 2002 Platz richtig liegt. Daher haben wir EDMN auch an der FS 2002 Position belassen.

Was mich jetzt sehr verwundern würde wäre, wenn Aerosoft Kompatibilität mit den Plätzen des FS 2004 zusagt?

Das habe ich doch irgendwie mißverstanden? Denn das wäre dann eindeutig falsch und eine bewusste Irreführung des Käufers. Das ist für mich eigentlich eine abwegige Vorstellung, so daß ich mal von einem Mißverständnis bei mir ausgehe.

Gruß
Rolf

Wer jetzt was anpassen muß ist immer so eine Sache. Schaut euch doch mal um wie wenig Fotoscenerien es im Vergleich zur Oberfläche der Kontinente gibt. Selbst Deutschland ist was Luftaufnahmen betrifft die Patrick für seine RG Serie nutzt laut der Homepage des Lieferanten noch nicht abgedeckt. Wir werden in dieser FS Generation also noch nicht mal den FS in Deutschland komplett abdecken können.

Microsoft hat nun mal ein paar Positionsfehler bei Ihren Airports. Weiterhin gibt es in einigen Designtechniken aufgrund des festen Rasterformates gar nicht die Möglichkeit eine 100% Anpassung an eine Fotoscenery vorzunehmen.


Auch ist es aufwendiger einen Defaultairport vom Grundsatz her zunächst bis ins letzte platt zu machen um ihn von vorneherein wo anders richtig mit den Möglichkeiten die wir haben gemäß einer Fotoscenery wieder aufzubauen. Zumal eine Fotoscsnery ja auch Fehler haben könnte.

Übrigends es ist kein Thema auch eine Fotoscenery (auch wenn sie korrekt sein sollte) künstlich an einen FS Airport anzupassen so das diese künstliche Verfälschung überhaupt nicht auffällt.

Es kann also auch ein Fotosceneryproduzent seine Fotoscenery anpassen.

Bei einem Kleinstairport muß er ev. sogar nur 1 oder 4 Texturen anpassen das war es schon. Das geht wesentlich schneller und einfacher als umgekehrt einen ganzen Airport komplett zu überarbeiten.

Ev. kann er den ganzen Airport der Einfachheit halber aus seiner Fotoscenery optisch herausretouschieren.

Denn nicht immer ist es mit einem einfachen Verschieben eines AFCAD2 Files getan. Da ist der Weg der Manipulation der Fotoscenery einfacher.

Was die AFCADS an geflatteten Böden betrifft da sehe ich bei den VFR Airfields keine Probleme.

Zu

"Schaut euch doch mal Kempten-Durach an, da sehe ich keine Landebahnen nur teilweise versunkene Markierungen"

habe ich keine Probleme mit.

Hätte auch eigentlich nichts mit RG zu tun. Aber wenn ich mich recht erinnere gab es ein Problem. Christoph müsste sich daran erinnern das wurde aber mittels eines Patches behoben. Es war ein ähnliches Problem wie man es jetzt auch wieder aktuell von den Austrian Airports hört. Flackernde bzw. versunkene Texturen.

Weis allerdings nicht mehr auf welche der Airports der VFR Airfields das zutraf.

@Gert

Um dir zu antworten.

"Ob das für vorhandene fertige Scenerien wirtschaftlich vertretbar ist möchte ich bezweifeln."

Um andere Addon-Szenerien geht es hier nicht. Diese müssen mit der Standard-Szenerie von MS kompatibel sein. Alles andere ist Nice-To-Have.

Aber wenn ich eine Photo-Szenerie wie RG heraus gebe und alle Standard-Flugplätze sind verschoben dargestellt, dann halte ich das für die Aufgabe der Photo-Szenerie das Manko zu beheben.

Ob mittels AFCAD oder Texturmanipulation mir egal. Wobei letzteres den Vorteil hätte das andere Addons passen würden. :)

Zu

Meiner Meinung nach muss man davon ausgehen das ein Anwender keine Addon Airports hat. Wenn er nur FS2004 Defaultairports hat werden diese aus genannten Gründen zwangsweise Abweichungen zu den in der Fotoscenery liegenden Airports haben. Schon alleine weil die Designtechnik bei den Airports hier gewisse Einschränkungen hat. Sprich die Taxiways werden nicht die selben Breiten wie die in der Textur haben. Vorfelder sind nicht ganz korrekt usw.

Von daher denke ich wäre es sinnvoll wenn die Airports aus der Fotoscenery optisch herausretouschiert werden.

Denn die Airports sind ja durch den FS bereits vorhanden.

Eine sehr gute Alternative wäre wenn der Fotosceneryproduzent diese paar zu retouschierenden Texturen zusätzlich optional anbietet. So kann der Anwender eine neutrale Fotoscenery ohne Airports bzw. mit Airports in der Fotoscenery verwenden.

Und ich bin natürlich der Meinung das sich eine Anschaffung einer Fotoscenery bei herausretouschierten Airports auf jeden Fall lohnt. Insbesondere dann wenn hier die alternative anhand Tauschtexturen geboten wird.


Ich denke der Aufwand des Herausretouschierens ist auch nicht sonderlich groß. Bei Großairports mit Autobahnanschlüssen wird es etwas aufwendiger das ist schon klar, aber bei Kleinstairports würde ich aufgrund von meiner Texturerfahrung bei Landclasstexturen sagen geht es sehr schnell.

Das sehe ich auch so, denn der Screenshot zeigt das ja deutlich. Wenn ich mich mit der Funktion "go to airport" auf die Startposition setzen lasse, stehe ich bei euren Szenerien in der Pampa. Schalte ich VFR-Airfields aus , stehe ich auf der Startposition der rwy.

Ich kann dabei auch keine Parkpositionen (FS2004) auswählen, sondern nur die rwy´s. Also gehen bei mir eure AFCADS nicht.

Da ich dachte, in meiner Installation wäre ein Fehler, habe ich VFR-A. neu installiert.
Dabei bin ich darauf gestoßen, dass man ja durch Position über- oder unterhalb von RG festlegen kann, wie die Umgebung des Airport dagestellt wird.

So sieht es aus mit der Einstellung auf Winter. Ist natürlich Blödsinn, da die Fototextur ja nur Sommer darstellen kann.

http://fs.gesal.net/_RG_VFR_Winter_013.jpg

Mit der Einstellung auf Frühjahr oder Sommer sieht das schon recht brauchbar aus. M.E. ist das ein guter Kompromiss, da hier inder Umgebung des Airport Autogen angezeigt wird (nicht dieser Tapeteneffekt!) und die Lageungenauigkeit kaschiert wird. Ob man die Grenze der Kachel als störend empfindet, muß jeder selbst entscheiden.

http://fs.gesal.net/_RG_VFR_Spring_013.jpg

Wie gesagt das könnte man alles schön anpassen.


Um nochmal auf das Thema Ladezeiten generell bei einer Fotoscenery zurückzukommen. Habe mal berechnet wieviele Texturen bei einer Fotoscenery vom FS in den Speicher geladen werden müssen.

Beispiel

1) Der Schalter erweiterte Geländestrukturen ist im FS Display Menü nicht aktiviert. Dann muß der FS 5376 individuelle Fototexturen laden bis man das vereinfachte Weltmodell des FS2004 sieht.

2)Der Schalter erweiterte Geländestrukturen ist im FS Display Menü aktiviert. Der FS muß nun sage und schreibe 21504 Fototexturen laden bis die Sicht auf das vereinfachte Weltmodell stösst. Auf RG1 bezogen fast die komplette Scenery muß hinsichtlich Texturen geladen werden. Da darf man sich nicht wundern das dieser Schalter extrem die Ladezeiten erhöht und weiterhin die Performance belastet. Nur dadurch das in der Tiefe des Raumes niederwertige MIP Level der Texturen verarbeitet werden müssen wird das ganze gemildert.

Ist der Schalter deaktiviert also werden wenig Texturen geladen empfiehlt es sich die Sichtweite auf 30 Milen zu begrenzen damit man nicht sofort das vereinfachte Weltmodell sieht.

Die Thematik gilt ähnlich für Landclasstexturen. Hier gibt es zwar nicht so viele Texturen da sie immer wiederholt eingesetzt werden. Dafür muß die Grafikkarte diese berechen der Schalter hat also auch da Auswirkungen.

Ob das Herausretuschieren immer eine gute Lösung ist, wage ich zu bezweifeln. Als Angebot, warum nicht. Aber es enthebt nicht der Aufgabe, die einzelnen airports wirklich gut anzupassen. Irgendeinen Platz draufsetzen kann auch ganz schön blöd aussehen...
Die Probleme wurden ja schon angesprochen. Das VFR-Team kann im Prinzip nichts dafür und es ist auch nicht zu verlangen, dass sie jetzt alles umprogrammieren!
Es gibt zur völligen Entfernung eigener Boden-Texturen, zur völligen Anpassung aller Details an die Fotoszenerie (das sieht auch nicht immer toll aus) ja auch die Alternative, die Summons vormacht, wenn auch mit Vorteil, da die kräftigen Farben von EnglandVFR es leichter machen: Ein an die Fotos angepasstes Bodentexturset. Das an manchen Stellen möglichst klein ist, um Raum für den Untergrund zu schaffen,und an anderen Stellen womöglich etwas größer, um störende Details zu überdecken, die aus der nicht hundertprozentigen Passgenauigkeit resultieren. Vorausgesetzt, dass der jeweilige Platz wenigstens ungefähr an der richtigen Stelle liegt, aber davon gehe ich aus. Z.B. sind auf die Weise daneben liegende rwys oder twys kein Problem. Kniffliger wird es bei Straßenanschlüssen usw. Aber auch das scheint ein eher geringes Problem. Auf diese Weise könnte mit deutlich geringerem Aufwand doch eine zumindest optische weitgehende Kompatibilität hergestellt werden.Wäre das nicht eine gute Alternative zu gar nicht oder ganz?
Summons zeigt auch, dass man das jeweilige Bodenset mit geringfügigen Abweichungen wahlweise für den user sowohl für Standard als auch für RG/EnglandVFR bereitstellen könnte.Es handelt sich dann im Wesentlichen nur um einen etwas anderen Zuschnitt.

Auf diese Weise wäre RG dann nicht nur eine gute Ergänzung zu den VFR-Plätzen, sondern VFR Germany auch eine gute Ergänzung zu RG.