AROE verursacht definitiv Speicherleck.

[JOBIA]

Zu


"Bei dem Produkt waren echte Profis am Werk die sich vorher genau Gedanken gemacht haben wie man's machen sollte und wie nicht"



Nun ich kenne einige Produkte von Flugwerk. Ich weis bisher nur das der Heinz Rückeshauser und ev. ein Namensvetter (Bruder?) dahinter steht.

Egal wer dahinter steht, es handelt sich hierbei um Profis.

Ich kann mich nicht über das UT Team äußern. Aber man möge folgendes bedenken.

Es gibt mittlerweile Tools in Verbindung dessen man automatisch Straßenaddons erstellen könnte (SBuilder). Auch Gewässer z.B alternativ mit Slarti.

UT kommt zu einer Zeit wo so etwas bereits existiert.


Schaut man sich aber Flugwerk an, dann kann ich hier etwas ganz besonderes erkennen.

Flugwerk hat damals als die ATP2002 auf dem Markt kam Ihre Landclassinformationen in das Default worldlc.bgl des FS2002 integriert.

Sie mussten also damals schon den undokumentierten Kompressionscode von Landclass (zumindest ansatzweise geknackt/probiert) haben um dort Ihre Informationen unterzubringen.

Damit waren sie allen um einiges voraus.


Schauen wir weiter.

Mit Ihrem Addpack2 brachten sie VTP und LWM Addon Code großflächig in den FS noch bevor es irgendein Designtool gab welches so etwas konnte.

Richard Ludowise seine Macros die es überhaupt ermöglichten, dass Designtools wie Ground2K so etwas programmieren können waren auch noch recht frisch.

Nächstes Beispiel:

Die neue ATP für den FS2004.

In meinem Patch ist z.B für das Landclassystem eine neue Version der undokumentierten Hauptsteuerdatei lclookup.bgl enthalten. Ich kenne niemanden der jemals eine geänderte lclookup.bgl herausgegeben hat. Habe zumindest in renommierten englischsprachigen Designerforen nichts gefunden.


Außer wer natürlich. Das Flugwerk Team im Zuge der aktuellen ATP.

Wenn also irgendwo Profies verborgen sind, dann auf jeden Fall im Umfeld Flugwerk.

Flugwerk selbst wird das Landclassproblem als solches mit Sicherheit kennen.




Die große Frage jetzt warum so viele Pannen und auch Fehler.


Da stellt sich zunächst die Frage wer hat den Installer gemacht?

Ist der überhaupt von Flugwerk selbst?

Kann ich nicht beantworten.



Zu dem Problem, das durch die AROE ganze Inseln platt gemacht wurden.

Dazu hatte ich ja schon etwas geschrieben.


Ich gehe davon aus, dass Flugwerk mit eigenen Tools gearbeitet haben.

Sie werden erfolgreiche Tests über Ihre Automatismen gemacht haben.


Leider waren diese Tests vermutlich nie in kritischen Gebieten. Denn ich persönlich kenne dieses KFZ Navigationsmaterial als Endprodukt was aus NAVTEQ Daten erstellt wird.


AROE wurde aus NAVTEQ Daten erstellt wenn ich mich recht erinnere.


Müsste noch mal ins Handbuch schauen.


In diesen NAVTEQ Daten steckt eine Falle. Sie verschleppen in Ihren Länderprodukten hin und wieder Meergewässer in andere Hoheitsgebiete. Stört bei der Fahrzeugnavigation niemand.

Bei der AROE wurden diese verschleppten Gewässer leider über den Automatismus mit umgesetzt. Merkt man natürlich nicht unbedingt.

Peng ist eine Insel eines Nachbarlandes ev. weg.

Ok die anderen Küstenprobleme kommen zum Teil durch andere Addons zum Teil wie wir sehen sogar durch andere Landclassfiles was manch einer ev. nicht für möglich halten dürfte.


Es sind viele unglückliche Zustände zusammengekommen. Leider!

Was ich kritisiere, ist das man zuwenig Rücksicht auf andere Produkte genommen hat.

Wenn ich Micha verstanden habe bzw. Holger, dann hat man dieses bei UT beachtet. Man wird wohl gezielt störende Information in der UT abschalten können.

In welchen Flächenkacheln /Größenordnung?


Ich kann es nicht beurteilen. Aber ev. könnte man in eine Falle tappen. Sollte UT diese Straßendichte wie AROE bieten könnte es einen Barth LC Effekt geben.

Ev. steigt die Belastung für den FS durch Zerstückelung in zu viele Files stark an.

Sind aber ungelegte Eier muss man sehen ob die UT Straßen meshbeeinflussende Komponenten haben ob sie über Exclude arbeiten oder über Files die nur bestimmte Zellen oder Areas abdecken.


Zur AROE und dem Speicherleck noch mal.

Die Frage ob so ein Fehler vom Addon Produzenten rausgesucht werden müsste, kann man natürlich zunächst mit Ja beantworten. Die Frage ist aber ob dieser Fehler überhaupt an FS Quality oder Flugwerk gemeldet wurde. Seemann ist bekannt. Nur er hatte sich ev. durch seine Äußerungen und vorherigen Speicherprobleme vor Installation der AROE ev. selbst ins Abseits gestellt.


Meine Theorie zu den Flugwerk Pannen ist folgende.


Es fällt auf, dass die Flugwerk Produkte immer schon aufwendig kopiergeschützt waren. Siehe auch jetzt wieder die Meldungen von Usern mit dem Programm Alcohol 120. Sie hatten große Probleme AROE zu installieren. Ich glaube es wurde sogar geäußert, dass es erst ging nachdem Alcohol deinstalliert wurde.

Klar nützt natürlich Flugwerk alles nichts, wenn irgendwo eine AROE Variante ins Netz gestellt wird, die auf einer installierten Version basiert. Der Kopierschutz wäre überflüssig.



Wenn man aber schon so einen Aufwand hinsichtlich Kopierschutz betreibt, vermute ich ganz einfach mal, dass man auch das Risiko gescheut hat AROE im Vorfeld großzügig an ev. unzuverlässige Betatester zu verteilen. Bei so einem Flächenprodukt wie AROE wo man als Entwickler schnell den Überblick verlieren kann, ist das hinsichtlich Bugs die nicht entdeckt werden können gefährlich wenn man nur ein paar Betatester hat.

Hier ist man in der Tat nur mit sehr vielen Betatestern halbwegs auf der sicheren Seite.

Es sei denn man möchte einen Großteil der Kontrollen selbst durchführen.

Nur hat man alle Addons die so in der Gegend umherschwirren.


Es ist nur eine Theorie von mir. Ich vermute aber mal, dass es aus obigen Gründen nur wenige Betatester waren. Da wird vieles einfach beim Designteam nicht aufgefallen sein.