WCM Forum

WCM Forum (http://www.wcm.at/forum/index.php)
-   Simulationen (http://www.wcm.at/forum/forumdisplay.php?f=27)
-   -   RealGermany 3 ist draußen! (http://www.wcm.at/forum/showthread.php?t=153748)

JOBIA 27.12.2004 10:44

Ja im allgemeinen sind Fotoscenerien sehr genau. Auch die RG1 war was Positionierung betrifft schon sehr genau.

JOBIA 27.12.2004 11:23

Zitat:

Original geschrieben von panda41
Bei der RG3 scheint die Genauigkeit allerdings recht hoch zu sein.

Ich habe inzwischen einen Punkt verglichen, für den mir GPS-Daten vorliegen, und da liegt die Abweichung bei geschätzten 50 m. Wobei diese Abweichung natürlich auch GPS-Ungenauigkeit sein kann. (Wahrscheinlich sogar!)

GPS Naviagtions Daten und der FS selbst nutzen das WGS84 Erdmodell als Referenz von daher kann man die Koordinaten direkt ohne weitere Fehler vergleichen. Klar auf das gleiche Format muß noch geachtet werden,also Dezimalgrad, Grad:Minute oder Grad:Minute:Sekunde aber ansonsten absolut vergleichbar.


Die theoretische Genauigkeit ist fast 100%. Nur noch das Pixelformat selbst ca. 4,77m ist der Restfehler der bei der Fotoscsnery übrig bleibt.

Wenn das Luftbild passend zum LOD Raster vorliegt (parallel zum Raster) dann ist die ganze Luftbildsceneryproduktion nur noch ein automatischer Prozess mittels des SDK Tools resample.exe


Das ist ein automatischer Vorgang.

Habe zwar die SG3 noch nicht. Aber ein Nachteil von Fotoscenerien sind halt die vielen tausenden an Einzeltexturen.

Jede einzelne Textur verschwendet aber eine einzelnes Cluster auf der Festplatte.

Von daher sind sie nicht nur Speicherkiller auf Festplatte sondern es gibt natürlich auch Adressierungsprobleme. Aber das hatte ja Buschflieger schon erwähnt.

Aber auch unter XP mit NTFS nervt es doch manchmal wenn man mal globale Suchroutinen über Festplatten laufen lässt wenn es dann wegen der Fotoscenerien elendig lange dauert.

Leider sind diese vielen Texturen die nervige Seite bei Fotoscenerien.

chrieger 27.12.2004 11:24

Hatte ich nicht bestritten, nur kann ich auf diese Art die VFR-Airfields nicht programmieren, daher wird es immer überschneidungen geben.

Aber ohne eine Funktionierende Installation keine Anpassung! Schade um das Geld was man für so eine Schachtel ausgibt.

panda41 27.12.2004 11:25

Zitat:

Original geschrieben von chrieger
... Denn Der Entwickler von RG ist eh der Meinung das alles um ihn rum anzupassen hat. ...
Deine Verärgerung kann ich verstehen.
Deine Reaktion nicht. Es sind doch auch deine Kunden, die verärgert werden.

Bisher war eine Ungenauigkeit in der Lage von Flugplätzen ja auch kein Thema, denn man hats ja nicht gesehen.
Das ist aber mit den Luftbildscenerien schon etwas anderes. Da fällts dann jedem auf.

chrieger 27.12.2004 11:38

Soll ich mir jetzt die Zeit aus den Rippen schneiden um den Rechner neu aufzusetzen?
Oder gleich einen neuen Rechner kaufen...
Laut Handbuch soll Fat32 funktionieren (Schachtel übrigens auch)

Natürlich sind es meine Kunden, umso mehr ärgert mich das ganze das man mich zwingt nach der Veröffentlichung zu patchen, nur weill man nicht gewillt ist mir rechtzeitig funktionierende Betas zu schicken.

Andragar 27.12.2004 12:20

Hallo Christoph,

nun, nachdem das Problem FAT32 gelöst ist - einem Peter Dimitri hat das den 23./24. versaut - wundert es mich wirklich warum man da nicht früher drauf reagiert hat. Du hast doch dein Installationsproblem weitergegeben. Und KEINER ist auf eine Lösung gekommen bis Aerosoft die DVDs (mit dem ausdrücklichen FAT32 und höher Hinweis) gepresst und auf den Markt geworfen hat?

Zumal es eine recht einfache Lösung gegeben hätte: Man hätte nur die 5 Szenerien weiter aufteilen müssen.

Das FAT32 auf NTFS konvertiert werden MUSS halte ich nur für eine Notlösung. Hier sollte unbedingt eine Nachbearbeitung passieren, alleine der falsche Hinweis auf der Schachtel ist ein Rückgabegrund der jedem eingeräumt werden muss. Leider hat man vorher vermutlich intensive Bastelarbeit betrieben, die Zeit bekommt man leider nicht zurück.

Ein anderer wenig schöner Tip wäre eine eigene NTFS Platte zusätzlich an den Rechner zu hängen, nur mit der RG Szenerie.

babalu 27.12.2004 12:27

Es könnte auch noch ein anderes Problem infrage kommen, so war es jedenfalls bei mir: Die Installation verabschiedete sich mit Hinweis auf Dateifehler etc nach ca. 60%. Ähnliches hatte ich auch schon mal früher bei RG2. Lösung war aber eine ganz andere: Ich hatte nicht mehr genug Platz auf der Festplatte. Sah zwar so aus, aber war anscheinend zu knapp. Erst nachdem ich einiges von der Platte genommen hatte und eine gewisse GB-Reserve vorhanden, funktionierte die Installation ohne Probleme.

Und da Jochen hier im Forum ist, wiederhole ich nochmal schnell meine Frage von oben: Kann man auch R8-Ground-Texturen "transparent" machen, so dass man die Fototextur drunter sehen kann? Hast Du eine solche Ersatz-Datei, bzw, wie könnte man sie herstellen? Oder ist es in dem Fall besser, die bgl zu bearbeiten? Aber wie.

TiAr 27.12.2004 17:37

Hallo Babalu,

ja, sollte funktionieren - r8 zu einem BMP konvertieren, z.B. mit BMP2000 von Martin Wright. Mit dem Programm kannst Du dann Transparenzen zuweisen. Dann als r8 (und mit dem gleichen Namen abspeichern - fertig. Je nach r8-Textur musst Du evtl. noch die Textur horizontal spiegeln (oder war es um 180 Grade drehen? Hmm einfach ausprobieren)

Gruß
Thomas

Marc 27.12.2004 20:07

Zitat:

Original geschrieben von chrieger
Soll ich mir jetzt die Zeit aus den Rippen schneiden um den Rechner neu aufzusetzen?
Naja, einerseits muss schon gesagt werden, dass bloß ein „convert -ntfs“ in der Command-Shell erforderlich ist. Von Neuaufsetzen kann also keine Rede sein. Andererseits ist NTFS bewusst undokumentiert von Microsoft gehalten, so dass andere Entwickler keine vollwertigen Treiber schreiben können. Wer also entsprechend des immer beliebteren Trends eine Parallelinstalation mit Linux betreibt, schaut mit schwer in de Röhre. Read-Only-Treiber oder kostenpflichtige und fehlerbelastete Zusatztreiber sind keine schöne Perspektive. Hier kann ein NTFS-Erfordernis in der Tat die ganze Systemkonzeption über den Haufen werfen.

Flusi-Michi 27.12.2004 20:17

Hi Leute!

Ich hab eben auch Real Germany 3 für den Fs04 installiert, wollte "schnell mal fliegen", hab also alle Grafikeinstellungen exakt wie in der Beschreibung angegeben gesetzt und gewartet.....
.....mehr als 10 Minuten, fast 15 von "Auf geht's" bis ich dann endlich auf meinem gewählten Platz stand :ms:
Er hat die ganze Zeit fleißig gerechnet, wobei das 61te Prozent am längsten gedauert hat :rolleyes: Sobald man dann mal "drin" ist, läuft das ganze ohne Probleme und ruckelfrei, was mich fast noch etwas mehr erstaunt hat.
Ich frage mich also: Ist das bei euch genauso? Ich weiß, dass hier eine ganz schöne Datenmenge verarbeitet werden muss, aber kann man das nicht in einer einigermaßen humanen Zeit schaffen?:confused:

Wäre schön, wenn hier irgendwer eine Lösung für dieses "Problem" anzubeiten hätte! ;)


Gruß

Michi

Buschflieger 27.12.2004 20:21

Zitat:

Original geschrieben von Flusi-Michi
Hi Leute!

Ich hab eben auch Real Germany 3 für den Fs04 installiert, wollte "schnell mal fliegen", hab also alle Grafikeinstellungen exakt wie in der Beschreibung angegeben gesetzt und gewartet.....
.....mehr als 10 Minuten, fast 15 von "Auf geht's" bis ich dann endlich auf meinem gewählten Platz stand :ms:
Er hat die ganze Zeit fleißig gerechnet, wobei das 61te Prozent am längsten gedauert hat :rolleyes: Sobald man dann mal "drin" ist, läuft das ganze ohne Probleme und ruckelfrei, was mich fast noch etwas mehr erstaunt hat.
Ich frage mich also: Ist das bei euch genauso? Ich weiß, dass hier eine ganz schöne Datenmenge verarbeitet werden muss, aber kann man das nicht in einer einigermaßen humanen Zeit schaffen?:confused:

Wäre schön, wenn hier irgendwer eine Lösung für dieses "Problem" anzubeiten hätte! ;)


Gruß

Michi

Hast Du die "Erweiterten Geländestrukturdetails" ausgeschaltet?
Abgesehen davon lädt der FS massenweise Dateien, das kann, je nach Hardware, schon mal länger dauern. ;)

TheFlyGuy 27.12.2004 20:52

Zitat:

Original geschrieben von Buschflieger

Abgesehen davon lädt der FS massenweise Dateien, das kann, je nach Hardware, schon mal länger dauern. ;)

Stimmt schon, nur so sehr viel mehr als bei den anderen Real Germany Produkten dürfte es eigentlich nicht sein, und die laden bei mir um einiges schneller. Diesbezüglich kann ich Michi´s Erfahrungen voll und ganz bestätigen. Was der Rechner da 10 Minuten lang in meine 1 GB RAM reinpumpt ist mir schleierhaft.

Ciao
Peter

Mosquito 27.12.2004 21:18

Jungs, ich hab zwar die RG3 nicht, dafür aber CHpro und ich denke das die Texturmengen durchaus vergleichbar sind.
Deshalb:

versucht mal die EInstellungen die Thomas hier vorschlägt:

http://www.fsc-ev.de/forum/thread.ph...eid=&page=1#17

wirken bei mir bei CHPro wunder !

TiAr 28.12.2004 00:43

Ja, diese Einstellungen sollten auch mit der RG3 funzen. Zumindest die Ladezeiten und ein flüssiges Nachladen der Texturen im Flug bewirken.

Es kann aber gut sein, dass jemand noch bessere Einstellungstipps hat - würde mich sehr freuen, wenn es hier etwas Neues geben würde.

RG3 ist meiner Meinung nach ein suuuper Produkt, die besten Textursets, die es jemals für D. gab - es wäre doch gelacht, wenn wir nicht trotzdem noch einen Tick rausholen könnten???

Gruß
Thomas

JOBIA 28.12.2004 09:33

Man muß bedenken das man mit erweiterten Geländestrukturen ""erheblich""" mehr Bodentexturen laden muß.


Mal sehen werde das mal berechnen wieviele das sind.

Erkennbare Unterschiede zwischen RG1, RG2, RG3 sollten sich aber nicht ergeben. Es sei denn man liegt im Randbereich der Scenery so das dieser mit dem Schalter "erweiterten Geländestrukturen" erweiterte Bereich bei der einen Scenery schon in einen normalen Landclassbereich fällt das würde dann den FS weniger belasten.

Aber noch etwas kann hier der Auslöser für längere Ladezeiten sein.

Ihr habt ja nun vom FAT32 Problem gehört. Eine Einzeltextur ist sehr klein belegt aber trotzdem ein einzelnes größeres Cluster auf der Festplatte. Wir verschwenden eigentlich viel Speicher aber es geht nun mal nicht anders.

Logisch auch das man Probleme bekommt wenn man nicht mehr viel Platz auf der Festplatte hat. Über den Explorer ist ev. wesentlich mehr Platz vorhanden als man ev. für die RG3 benötigt. Aber dadurch das man pro Fototextur die nur 43KB groß ist sehr viel mehr Platz auf der Festplatte durch die Clustergröße benötigt, bläht sich hier die Fotoscenery auf.

Was das Ladeproblem betrifft kann ich mir hier sehr gut vorstellen das z.B die RG1 installiert wurde als die Festplatte nicht fragmentiert war. Ev. liegt die RG1 auch in Bereichen auf der Festplatte wo die Zugriffszeit schneller ist.


Jetzt installiert irgendwer die RG3 die Festplatte ist z.B über die letzten Monate fragmentiert. (die Texturen werden weitläufig über die Festplatte verteilt) bzw. die RG3 liegt in Bereichen wo die Zugriffszeit langsamer ist. Ergo wird der Ladevorgang der RG3 schon allein durch fragmentierung länger dauern. Bei demjenigen der die Auslagerungsdatei von Windows verwalten lässt kann auch nicht ausgeschlossen werden das diese jetzt wenn die Festplatte durch die RG3 sehr voll ist schon geschrumpft ist.


Windows selbst könnte langsamer werden.

Flusi-Michi 28.12.2004 11:09

Danke, danke!

Jetzt ist "Erweiterte Geländestrukturdetails" deaktiviert, die fs9.cfg verändert und er schafft das Laden innerhalb von sage und schreibe 2:46...:D
Gott sei Dank, andernfalls wär ich vermutlich verzweifelt...oder man hätte die Ferien verlängern müssen :cool:
Danke für eure Hilfe, jetzt geht's erstmal mit der Centurion von EDMO aus an den Chiemsee....mit RG3 ;)

Ciao

Michi

Marc 28.12.2004 12:00

Zitat:

Original geschrieben von JOBIA
Eine Einzeltextur ist sehr klein belegt aber trotzdem ein einzelnes größeres Cluster auf der Festplatte.
....
Ergo wird der Ladevorgang der RG3 schon allein durch fragmentierung länger dauern.

Hi, hier sehe ich aber einen Widerspruch. :) Files, die nur noch einen Cluster belegen, können nicht mehr fragmentieren. Je kleiner die Files, desto geringer die Wahrscheinlichkeit, dass ein File an physisch aufgeteilten Orten gespeichert wird. Ich denke sowieso, dass Defragmentieren hier manchmal überschätzt wird. Ein schulterzuckendes „Defragmentier mal“ ist manchmal einfach der letzte hilflose Rat.

r_schon 28.12.2004 13:09

Hallo Miteinander,


In einem Beitrag weiter oben ist die Frage der Kundenfreundlichkeit
im Hinblick der Anpassung unserer VFR Airfields an das Scenery Addon
Real Germany 3 angesprochen worden.

Bevor nun das Etikett " Kundenunfreundlich" an uns hängen bleibt,
möchte ich als Mitautor der VFR Airfields Stellung nehmen:

Unser Produkt ist ein Addon zum Microsoft Flight Simulator. Der Kunde
kann erwarten, daß wir die Software so erstellen, daß er sich aus dem
Flughafenverzeichnis heraus, jeweils auf der angewählten Startbahn der Standard
Szenerie befindet. So sind unsere Plätze grundsätzlich angelegt.

Das Platzlayout ( Rollwege, Abstellplätze ) der Standardszenerie kann, wegen der
Gesamtoptik in den meisten Fällen nicht übernommen werden. Die Neuerstellung auf
der Basis von Charts und Luftbilder ist Teil unseres Szeneriedesigns. Daher wird
selbsterstellter Traffic auch regelmäßig nicht funktionieren. Wir bieten aber
angepaßten Verkehr auf unserer Homepage zum kostenlosen Download an oder haben
ihn bei unseren Updates mit eingefügt.

Das Aerosoft Addon Real Germany 3 ist nun bezüglich einiger Standard- und wie wir von
Usern erfahren haben, damit auch mit einigen unserer Airfields nicht kompatibel.
Ein eigenes Bild haben wir uns, aus den im Thread von Christoph geschilderten
Gründen, davon allerdings noch nicht machen können.

Es wird nun die Erwartung geäußert, daß wir unsere Plätze an das Aerosoft Addon anpassen.

Zum Arbeitsaufwand dafür: die abliegenden Objekte - je nach Platz +- 100 Objekte - müssen
einzeln angefasst und in die zur Fotoszenerie passende Position verschoben werden. Das
Selbe gilt für die als Polygone definierten Taxiways, Tarmacs, Parkplätze und so weiter,
die aus jeweils 20 und mehr Punkten bestehen, die alle neu gemacht werden müssen.
Ferner müssten alle Polygone farblich an die Fotoszenerie angepaßt werden - das wäre
für uns noch zu erkundendes Neuland und vom Aufwand her nicht abschätzbar. Insgesamt
müßte aber mit allen Vorarbeiten ( u.a Justieren und Skalieren der Vorlage aus der
Fotoszenerie ) um die 10-20 Mannstunden pro betroffenem Platz angesetzt werden.

Diese Szenerie müßte dann eigenständig und nur für die User der Aerosoft Produkte
aus der Real Germany Reihe erstellt werden - mit der Standart Szenerie wäre sie ja
nicht mehr kompatibel, weil der User in manchen Fällen aus dem Standard Platzauswahl
Menue heraus entsprechend entfernt von der Bahn abgesetzt würde. Als solche müßte sie dann auch
auf der Aerosoft Homepage vorgehalten werden.

Ich weiß nicht, ob man von uns ohne Weiteres erwarten kann, daß wir auf das Fremdprodukt
einer Firma patchen, die im Vorfeld trotz unserer Bemühungen wenig Interesse gezeigt hat,
uns Daten für eine Adaption verfügbar zu machen. Auf jeden Fall überschreitet der Aufwand das,
was man als kommerzieller Designer kostenfrei für die Adaption an ein Fremdprodukt leisten kann.

Vor allem kann der größte deutsche Publisher Aerosoft nicht als Selbstverständlichkeit voraussetzen,
daß Andere dazu beitragen, daß Kundenzufriedenheit grundsätzlich für ihn als kostenfreie Einbahnstrasse abläuft.


Gruß
Rolf

babalu 28.12.2004 14:01

Danke Thomas!! Werde es ausprobieren!

Buschflieger 28.12.2004 14:39

@Rolf:

Mehr braucht man dazu nicht zu sagen. Ausser; man(n) kann auch OHNE Aerosoft im FS "glücklich werden". ;)

Viele Grüsse

Börries

chrieger 28.12.2004 15:38

Ich bin leider wieder etwas später dazugestossen, daher nochmal kurz zu NTFS.
Nach Rüchsprache einiger Spezialisten habe ich mich entschlossen meine 50GB nicht einfach so umzuformatieren, ohne Datensicherung. Da liegt jahrelange Arbeit, wäre schade wenn die wegen eines Fehlers hinter her futsch sind.
Wenn VFR-Airfields Vol.3 in seidenen Tüchern gehüllt ist, werde ich mir eine neue Platte einbauen und dann das ganze mal testen.

Zu Rolf Hinweisen:
Wenn ich mir ein Bild über die Probleme gemacht habe, könnte man sich den Aufwand überlegen. Ob ich mit 10 Stunden pro Platz hinkomme weiss ich noch nicht, es sei denn es gibt ein Tool wo man den Platz automatisch per Script verschiebt:confused:

Ansonsten bin ich zur Zeit eher dagegen unsere Produkte an RG3 zu patchen, denn die Zeit zahlt wirklich keiner! Oder seid Ihr bereit dafür Geld auszugeben, dass zwei Produkte kompatibel bleiben????
Ich programmier jetzt an VFR-Airfields Vol.3 weiter, sonst muss ich meine Release termin so wie andere Firmen auch noch nach hinten verschieben.....

TheFlyGuy 28.12.2004 21:44

So schlimm ist das mit dem Umformatieren nun auch nicht Christoph. In meinem Fall gab´s so um die 25 GB auf eine andere Partition zu verschieben (=30 Min.), dann die Flusi Partition über die "Datenträgerverwaltung" unter XP umformatieren (Quickformat = 1 Min.), und zu guter Letzt alles wieder zurückzukopieren (=30 Min.). Nach einer Stunde war also alles erledigt. Die Installation der RG3 hat dann noch einmal etwa 30 Min. gedauert.

Auch wenn Werbung hier verboten ist: Aldi hat ab morgen schicke 250 GB externe Festplatten im Angebot ;)

Bin übrigens angenehm überrascht wie schön Eure VFR Airfields 2 in die RG3 Szenerie passen.

Ciao

Peter

JOBIA 29.12.2004 06:21

Zitat:

Original geschrieben von Marc
Hi, hier sehe ich aber einen Widerspruch. :) Files, die nur noch einen Cluster belegen, können nicht mehr fragmentieren. Je kleiner die Files, desto geringer die Wahrscheinlichkeit, dass ein File an physisch aufgeteilten Orten gespeichert wird. Ich denke sowieso, dass Defragmentieren hier manchmal überschätzt wird. Ein schulterzuckendes „Defragmentier mal“ ist manchmal einfach der letzte hilflose Rat.
Marc das hast Du falsch verstanden. So eine Fototextur einzeln kann natürlich nicht fragmentiert sein das ist klar. Aber der Speicherplatz wo die Texturen dann bei Installation hin kopiert werden der ist ev. fragmentiert. So kann es dann dazu kommen das die tausende an Texturen der RG3 wild auf der Festplatte verteilt sind.

Sehr viele der FotoTexturen werden aber zeitgleich beim laden benötigt.

Von daher muß auch hier der Lesekopf der Festplatte genau wie bei einer großen Datei erst mal diverse Stellen auf der Festplatte anfahren um ev. alle Texturen für den Betrieb der Fotoscenery zu sammeln. Das dauert natürlich bei wilder Verteilung über die Festplatte länger als wenn der Lesekopf ev. ganz wenig Arbeit hat und nur die Drehbewegungen der Festplatte ausreichen um fast alles zu erwischen.

chrieger 29.12.2004 07:36

Zitat:

Original geschrieben von TheFlyGuy


Bin übrigens angenehm überrascht wie schön Eure VFR Airfields 2 in die RG3 Szenerie passen.

[/b]
Ich habe gerade Dank Michael die ersten Screnshots gesehen. Wenn Euch das genügt Prima, dann werde ich diesen teilweise erheblichen Aufwand nicht betreiben. Einige Plätze liegen extrem daneben. Durch ein zusätzliches Feature in der Vol.3 werden die Probleme geringer sein. Damit kann man leben. Aber alle anderen sind schon mit einigen Verschiebungen behaftet.
Ich versuche die Tage mal die Stückzahlen der RG zu ermitteln. Erst dann entscheide ich ob es überhaupt relevant ist, oder ob es nicht auch so geht.
SG1 wurde auch nie upgedated, die hatten meines Wissens die gleichen Probleme wie wir jetzt. Wie sieht es eigentlich mit Augsburg und Bayreuth aus (German Airports) Haben die mehr Glück?

PS: @Peter, ich werde mr jetzt keine Platte bei Aldi kaufen, da fehlt mir die Zeit, mich ärgert es eh schon genug, dass ich mich damit beschäftigen muss.
Das ist wieder so ein Grund die Entwicklung der VFR-Airfields einzustellen. Viele andere wurden ja schon vorher hier diskutiert.

Gruss

panda41 29.12.2004 10:33

Zitat:

Original geschrieben von TheFlyGuy
... Bin übrigens angenehm überrascht wie schön Eure VFR Airfields 2 in die RG3 Szenerie passen. Peter
Dann hast du wohl eine andere Variante von VA 2.

Wie Christoph gerade schrieb liegen einige der Plätze schon sehr daneben. Das ist dann nicht besonders schön anzusehen.

Derzeit bin ich dabei für die Plätze AFCAD Files zu erstellen, da ich mit dem kostenlos gelieferten Traffik nichts anfangen kann. Ich verwende GA-Traffic und der erwartet einige Parkplätze.
Schaut euch doch mal Kempten-Durach an, da sehe ich keine Landebahnen nur teilweise versunkene Markierungen.

Bitte das nur als Hinweis verstehen, ich bin total happy, dass es für den bayrischen Raum einige so schöne Plätze gibt. Da nehme ich auch ein paar kleine Abweichungen in Kauf.

r_schon 29.12.2004 10:45

Hallo Gert,

Kempten Durach ist als Platz mit Runwayneigung angelegt. Da funktioniert kein AI Traffic und deshalb hast Du auch keine Runways in der Anzeige.

Wir haben mal eine Umfrage gestartet, was mehr gewünscht ist auf solch kleinen Plätzen - Bahnneigung oder AI - da waren die meisten für geneigte Bahnen.

Im Übrigen finde ich es, auch für uns als Entwickler, sehr angenehm, wie sachlich Du mit Deiner Kritik und Anregungen umgehst. Damit kann man gut leben - wir machen alles, was mit vertretbarem Aufwand möglich ist,um den Käufer unserer Produkte zufrieden zu stellen. Das betrifft auch VFR Airfields und RG3. Wir prüfen noch, was machbar ist.

Gruß
Rolf

Andragar 29.12.2004 10:45

Vorsicht wie getestet wurde. Ich habe bei mir alle Terrain Szenerien der VFR 1-2 (und 3 Beta) abgeschaltet. Wenn ich das wieder zuschalte sieht es wieder anders aus. (->lokale LCs.)

Kempten-Durach ist noch einmal ein Spezialfall da dort schiefe Landebahnen "eingebaut" wurden. Deswegen kann man dort auch keine AFCADs finden. Bei mir passt Kempten-Durach aber mit oben genannter Methode ganz gut in die Landschaft, allerdings bin ich dort nicht gelandet. Wenn du dort AFCADs erzeugst zerstörst du wieder die schiefe Bahnen. Du müßtest dann auch ein Flatten erzeugen.

Wenn man nur einzelne Dateien in den Terrain Szenerien deaktiviert (sprich LCs) dann sollte es zu noch besseren Ergebnissen führen, da in dem Fall das Mesh wieder zu den erwähnten Markierungen passen.

panda41 29.12.2004 11:31

An die schiefen Bahnen habe ich nicht gedacht. Ist aber sicher kein Problem mal einen Platz ohne AI-Traffic zu haben.
Sollten da Texturen auf den rwy´s sichtbar sein?

Das mit dem Abschalten von VFR-2 und wieder einschalten habe ich gerade probiert, hat bei mir nichts gebracht.

EDMN sieht bei mir so aus: (wobei auch die Startposition des Fliegers aus dem FS2004 nicht stimmt und an dieser Scenery habe ich noch nicht rumgefpfuscht)

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

chrieger 29.12.2004 12:21

Michael meinte die terrain Scenerien von VFR-Airfields zu deaktivieren.
Dort sind unsere Lokalen Landclass Dateien und Mesh Details.

Von dem her sollte es keinen Unterschied vor und nach dem Deaktieren der Vol.2 geben. Denn schliesslich werden die Airfields nicht kalibriert :D
Ich habe in der Zwischenzeit einige Screenshots von Michael und Martin, die mir deutlich machen, dass kein Platz passt.

Was mich an der Sache nur stört, dass die Verkaufsstrategie im Hause des Publishers aussagt, das alles Kompatibel ist. Leider ist es das nicht und Kunden werden wie immer mal wieder Verarscht.
Ich überlege noch ob ich dazu auf unserer Homepage Stellung nehmen muss, um Enttäuschungen auf beiden Seiten zu verhindern.

Andragar 29.12.2004 12:35

Eigentlich ist das ja logisch.
Wenn RG3 nach den VFR Airfields 2 rauskommen, muss, wenn von RG3 Kompatibilität behauptet wird, RG3 dafür sorgen - ansonsten ist es RG3 anzulasten diese Behauptung aufgestellt zu haben. (Es sei denn man stellt sich auf den Standpunkt: "Wieso? Ist doch alles da von den beiden Szenerien. Sieht zwar doof aus aber was solls.")

Insofern sehe ich es für VFRA2 keine Veranlassung etwas auf die Webseite zu schreiben. Wie es für VFRA3 aussieht steht wieder auf einem anderen Blatt. :(

Leider nehme ich auch an, dass die Käuferschicht bei den beiden Produkten nahezu deckungsgleich sein sollte.

Peters Aussage bezüglich passt doch ganz gut interpretiere ich so, dass der erste Eindruck ok ist. Aber das entspricht natürlich überhaupt nicht den Ansprüchen eines Christoph Rieger und Rolf Schon.

Da kommen wir aber zu einem Punkt, den alle Photo-realen Szenerien haben (zumindest soweit ich es bisher gesehen habe). Fast sämtliche Flugplätze passen nicht in die Szenerie. Je nach Anspruch eigentlich ein Todesurteil. Ich würde liebend gerne 20€ mehr für Photoszenerien zahlen wenn die Standardplätze deckungsgleich gemacht würden. Wie woanders erwähnt sitze ich jetzt selbst dabei diese Arbeit zu tun. Wann ich damit mal fertig werde steht in den Sternen.

panda41 29.12.2004 13:05

@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).

chrieger 29.12.2004 13:32

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)?

JOBIA 29.12.2004 13:52

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.

r_schon 29.12.2004 14:29

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

JOBIA 29.12.2004 14:29

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.

Andragar 29.12.2004 14:29

@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. :)

JOBIA 29.12.2004 14:44

Zu

Zitat:

Original geschrieben von Andragar
[B

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 - oder diese ganz zu entfernen. Ob im zweiten Fall sich dann eine Anschaffung noch lohnt sei dahin gestellt. :) [/b]
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.

panda41 29.12.2004 16:11

Zitat:

Original geschrieben von r_schon
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? ...
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

JOBIA 29.12.2004 16:24

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.

babalu 06.01.2005 15:00

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.


Alle Zeitangaben in WEZ +2. Es ist jetzt 12:20 Uhr.

Powered by vBulletin® Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag