Jump to content

Update für sim-wings Hamburg Pro und Munich Pro via ASUpdater verfügbar zur Behebung von Jahreszeiten Problemen


OPabst
 Share

Recommended Posts

  • Developer

Einige Anwender berichteten von Problemen in sim-wings Hamburg Pro und München Pro für P3D V4/V5 bezüglich fehlender Änderungen an den Wintertexturen.

Wir scheinen einen möglichen Grund dafür gefunden zu haben und haben nun ein Update für beide Airports vorbereitet.


- Hamburg Pro wird auf die Version 1.0.2.0 für P3DV4 und P3DV5 aktualisiert

- München Pro wird auf 1.1.1.0 für P3DV4 und P3DV5 aktualisiert


Bitte aktualisieren Sie die Addons über ASUpdate und prüfen Sie, ob die Gebietsänderungen die Jahreszeiten korrigieren:


Hamburg mit Standard-Saisoneinstellung (kein Orbx im Config-Tool eingestellt) sollte wechseln:

- Sommer: März bis Oktober

- Herbst: November

- Winter mit Schnee: Dezember bis Februar

 

Hamburg mit Orbx-Jahreszeiten-Einstellung (Orbx im Config-Tool aktiviert) sollte wechseln:

- Sommer: April bis Oktober

- Frühling/Herbst: Februar,März und November

- Winter mit Schnee: Januar


München mit Standard-Jahreszeiten-Einstellung (keine Orbx-Einstellung im Config-Tool) sollte wechseln:

- Sommer: März bis Oktober

- Herbst: November

- Winter mit Schnee: Dezember bis Februar


München mit Orbx-Jahreszeiten-Einstellung (Orbx im Config-Tool aktiviert) sollte wechseln:

- Sommer: April bis Oktober

- Frühling/Herbst: März und November

- Winter mit Schnee: Dezember bis Februar


Das Problem scheint durch eine "nicht erwartete" Implementierung von Materialscripts in P3D zu entstehen. Skripte mit dem gleichen Dateinamen scheinen immer global verwendet zu werden, das zuletzt geladene wird genutzt. Nicht die lokal im gleichen Addon-Unterverzeichnis vorhandenen und per add-ons.xml registrierten Skripte werden zuerst verwendet.

Wenn also Entwickler verschiedener Addons den gleichen Dateinamen für die Materialskripte verwenden, kann das bei anderen Addons zu einem völlig unerwarteten Ergebnis führen, egal was sie tun.

Im Fall von Hamburg und München war der Effekt, dass die Jahreszeit in beiden Addons gleich schaltet, je nachdem, welches zuletzt installiert wurde.

Wir haben nun Namen verwendet, bei denen sich der Name auf sim-wings und den Flughafen ICAO bezieht, so dass wir hoffen, dass solche Namen in anderen Addons nicht verwendet werden.


Bitte melden Sie hier, wenn ein früheres Problem nun behoben ist. Wir können nicht sagen, ob alle Problem mit der Scriptengine jetzt mit dem Update behoben wird.

 

Link to comment
Share on other sites

Hallo,

 

Danke für euren Einsatz. Leider hat das Update sowohl in München als auch Hamburg bei mir keine Änderungen bewirkt. 

Nach wie vor habe ich keine Wintertexturen. Datum und Uhrzeit sind aktuell. Jahreszeit aufgrund des Datums ist "Winter". 

Anbei habe ich Screenshots angehängt. Gerne stehe ich für weitere Tests bereit :) 

 

Gruß

 

 

2020-12-29_16-48-36-488.png

2020-12-29_16-52-53-166.png

Link to comment
Share on other sites

  • Developer

Ok, ja das Luftbild rund um den Airport scheint ja Schnee zu haben.

Dann scheint hier noch ein anderes Scriptengine Problem vorzuliegen, das ja auch schon reported wurde, wo AI Flugzeuge offensichtlich die Scriptverarbeitung grundlegend crashed.

Link to comment
Share on other sites

  • Developer

Nur mal ein Test:

 

- Sichere im Scripts Unterverzeichnis von sim-wings Pro Hamburg mal die Datei SW-EDDH-Tiles.lua an einen sicheren Ort

- Dann ersetze die dortige durch die aus dem hier angehängten ZIP

 

Wenn dann nicht der Bodenbereich des Airport auch weiß ist, dann läuft der Script nicht. Denn der Testscript stellt egal welcher Monat die Engine meldet immer alles auf Winter.

 

Link to comment
Share on other sites

vor 3 Stunden , OPabst sagte:

Nur mal ein Test:

 

- Sichere im Scripts Unterverzeichnis von sim-wings Pro Hamburg mal die Datei SW-EDDH-Tiles.lua an einen sicheren Ort

- Dann ersetze die dortige durch die aus dem hier angehängten ZIP

 

Wenn dann nicht der Bodenbereich des Airport auch weiß ist, dann läuft der Script nicht. Denn der Testscript stellt egal welcher Monat die Engine meldet immer alles auf Winter.

Test only.zip 346 B · 3 downloads

 

Hab die Datei soeben getestet. Keine Veränderungen zu beobachten. 

 

Gruß

Link to comment
Share on other sites

  • Developer

Ok, dann wird da was die Scriptengine des P3D abschießen, da ist bisher der AIG Traffic ein heißer Kandidat, den ist der installiert und aktiv, dann läuft das content.log mit Fehlern voll. Da Du den ja wohl hast, kannst Du den mal temporär deaktivieren. Wenn es dann funktioniert, wäre diese Vermutung nochmals erhärtet. Nur da können wir keine Abhilfe schaffen.

Link to comment
Share on other sites

  • Developer

Ok, mit dem AI Traffic wird dass bei allen Scenerien schwierig, die Texturen für Winter automatisch via Texturescripts steuern. Es gibt ja auch noch andere Bereiche, wo die scripts Verwendung finden. Daher wäre es wichtig, den Entwicklern von den AIG Flugzeugen (da ist halt irgendwo der Bug drin) die Bereinigung nahezulegen.

 

Der einzige Workaround im Falle EDDM und EDDH wäre, die Texturen im Texture Ordner, die mit *_SU.dds/_SU_LM.dds enden zu sichern und die mit _HW.dds/_HW_LM.dds enden auf _SU.dds/_SU_LM.dds umzubennenen.

Die SU.dss steht im Material standardmäßig drin, der Name wird dann bei funktionierender Scriptengine zur Laufzeit in den entsprechenden Monaten halt auf die _HW.dds umgeschrieben, sodass die entsprechende Wintervariante gezeigt wird. Bei gecrashter Engine bleibt der Name halt immer auf Sommer (SU).

Ist jetzt aber eben ein blöder Workaround und mit Vorsicht zu betreiben.

Ist dann back to FSX, wo nur so per Configtools der Winter vorher „eingestellt“ werden konnte (zumindest wenn man nicht den „ollen“ BGLC Code (FS8/9) Code verwenden wollte, der das alles ja schon mal automatisch konnte.

  • Thanks 1
Link to comment
Share on other sites

Lua-Scripts sind nicht die einzige Möglichkeit Texturen für Jahreszeiten auszusteuern.

Was spricht dagegen das über die Visibility Condition der Groundpolys zu machen, so wie das auch für das Snow-Rain-Overlay von EDDH modelliert wurde? D.h. alle Jahreszeiten bekommen eigenes Material und werden entsprechend der Jahreszeiten sichtbar, bzw. unsichtbar gemacht.

Dann bräuchte man keine Lua-Scripts für Groundpolys und auch keinen Workaround. Alles sollte dann für jeden einwandfrei funktionieren.

  • Upvote 1
Link to comment
Share on other sites

  • Developer
7 hours ago, Schlotterknie said:

Lua-Scripts sind nicht die einzige Möglichkeit Texturen für Jahreszeiten auszusteuern.

Was spricht dagegen das über die Visibility Condition der Groundpolys zu machen, so wie das auch für das Snow-Rain-Overlay von EDDH modelliert wurde? D.h. alle Jahreszeiten bekommen eigenes Material und werden entsprechend der Jahreszeiten sichtbar, bzw. unsichtbar gemacht.

Dann bräuchte man keine Lua-Scripts für Groundpolys und auch keinen Workaround. Alles sollte dann für jeden einwandfrei funktionieren.

Die Visibility Conditions sind eine Alternative (verwende ich auch vielen der anderen Professional Scenerien). Aber es ist nicht die beste Option, denn es vervielfacht die Datenmenge (jedes Mesh muss für jede Jahreszeit vorhanden sein) und der Handlingaufwand ist enorm, da ja auch noch die Default und Orbx Varianten jeweils vorhanden sein muss. Und durch die Komplexe Terrain Struktur in Muc und gerade in Ham sind das mehrere Objekte, die da aufwändig zerlegt werden müssten. Bei jeder Änderung im Model fängst Du dann wieder von vorne an.

Und das nur, weil irgendein anderer die Scripte nicht im Griff hat und dies allen anderen die Material Script Nutzung verhindert? Sorry, dass kann es nicht sein.

 

Aber wenn sonst keine Lösung gefunden werden kann, wäre das die einzige Alternative. Nur den Mehraufwand will auch keine bezahlen, sind ja eh alle Addons zu teuer.

Link to comment
Share on other sites

@OPabst Guten Morgen Oliver,

 

hierzu noch ein kleines Problem von mir. Ich habe den Updater für die EDDH 1.0.2.0 (Scrips) ausgeführt.

Leider ist im Hintergrund noch der P3DV5.1 gelaufen. Ich habe einen Fehler vom Updater bekommen, leider aber nicht aufgeschrieben was er gemeldet hat.

Nun habe ich keine Ahnung ob alle Dateien aus dem Update im EDDH Ordner gelandet sind. Das Konfig Tool meldet schon die Version 1.0.2.0

Welche Dateien wurden verändert. Kann ich die noch mal Manuell reinkopieren. Dafür bräuchte ich sie aber. Gerne per PM

Leider kann ich das Update nicht noch einmal ausführen.

 

2. Leider hat sich bei mir nach dem Update in EDDM und EDDH nichts verändert. Grünes Gras und Rundum Schnee.

    Bin auch einer von den AIG Usern.

 

Gruße aus EDDM

und bleibe Gesund !

Frank

Link to comment
Share on other sites

  • Developer

Hallo Frank,

 

gehe mal in deinen Dokumenten Ordner -> Aerosoft -> Asupdater -> Products (oder so ähnlich) und suche dort die XML für Hamburg.

Diese kannst Du mit dem Notepad öffnen und die Versionsnummer darin von 1.0.2.0 auf 1.0.1.0 zurücksetzen, die xml speichern und dann den ASupdater nochmals laufen lassen, der entpackt dann alles nochmals, sofern der P3D gestoppt ist ;)

Link to comment
Share on other sites

vor 43 Minuten, OPabst sagte:

Und das nur, weil irgendein anderer die Scripte nicht im Griff hat und dies allen anderen die Material Script Nutzung verhindert? Sorry, dass kann es nicht sein.

Das Problem sind hier nicht fehlerhafte Lua-Scripts anderer Hersteller (die oft erwähnten Scripts von AIG sind eigentlich einwandfrei), sondern Bugs im Handling der Lua-Scripts in der P3D-Engine von Lockheed Martin, die unter unbekannten Umständen die Verarbeitung dieser Scripts verweigert.

Unterm Strich ist das ein Problem mit dem sich weder Aerosoft noch die AIG, sondern Lockheed Martin herumschlagen sollte. Leidtragender des ganzen ist am Ende der Kunde.

 

vor 58 Minuten, OPabst sagte:

da ja auch noch die Default und Orbx Varianten jeweils vorhanden sein muss.

Der Vollständigkeit halber... Das muss sie zur Laufzeit nicht, nachdem ihr Default- und Orbx-Varianten bereits zuvor über euer Config-Tool trennt.

 

Link to comment
Share on other sites

  • Developer

So, ich habe die Scripts nochmals verändert mit der Hoffnung, dass sie auch mit anderswo existierenden Scripts funktionieren und somit auch bei AIG funktionieren.

Anbei mal je eine Ersatz für das Scripts Verzeichnis für Hamburg und München. Die Updateversion 1.0.2.0 für Hamburg, bzw. 1.1.1.0 für München muss vorhanden sein,

dann das Script Verzeichnis aus dem jeweiligen ZIP im Ordner des Addons ersetzen.

Wer Orbx nutzt, anschließend das Configtool kurz starten und beenden, damit die Orbx Variante aktiviert wird.

Die Scripts können sowohl für die V4 als auch V5 Variante genutzt werden.

 

Sobald mir ein User mit AIG Traffic bestätigt, dass diese Variante auch dann funktioniert, mache ich ein offizielles Update.

ScriptTest for EDDM.zip ScriptTest for EDDH.zip

  • Thanks 1
Link to comment
Share on other sites

Vor 1 Stunde, OPabst sagte:

 

Sobald mir ein User mit AIG Traffic bestätigt, dass diese Variante auch dann funktioniert, mache ich ein offizielles Update.

 

Funktioniert leider nicht. Die vom Script angesteuerten Texturen bleiben im "Sommermodus".

 

Content-Errorlog wird mit zahlreichen Meldungen zugeschrieben:

Error executing LUA script: [string "..."]:8: attempt to index a nil value (local 'xOPEmiTex')

und:

Error executing LUA script: [string "local xOPmonth = varget("E:ZULU MONTH OF YEAR..."]:7: attempt to index a nil value (local 'xOPEmiTex')

 

Das lässt darauf schließen dass P3D die EmissiveTexture (varget("T:EmissiveTexture", "String")) nicht auslesen oder der lokalen Variable 'xOPEmiTex' zuweisen kann. Ersteres ist wohl wahrscheinlicher.

Interessant dass das scheinbar nur die Emissive-Texture, nicht aber die Diffuse-Texture betrifft.

 

Link to comment
Share on other sites

Guten Morgen,

 

bei mir hat das Testen ein wenig länger gedauert, aber was soll ich sagen: München funktioniert bei mir nun wie es soll, d.h. heute hatte ich auf dem Vorfeld den Schnee, wie auch in der Umgebung. 

 

VG Thomas   

 

P.S. Die oben angegebenen Scripts habe ich nicht eingespielt, AIG habe ich ja auch nicht. Das nur zur Info.

Link to comment
Share on other sites

vor 4 Minuten, OPabst sagte:

Komisch, denn Fehler hab ich nicht gesehen, das ist natürlich ein Bug im script. Wo war das, in EDDH oder EDDM?

 

Das war EDDH. Diese Fehler im Contenterrorlog gab´s aber auch schon mit alten Versionen der Scripts, nur halt mit den "alten" Variablennamen.
Ich glaube dass P3D generell Probleme hat wenn "zu viele" Lua-Scripts verarbeitet werden sollen. Dann tauchen auch plötzlich solche Fehler im Contenterrorlog auf.

Link to comment
Share on other sites

Ich habe jetzt in den neuen Scripts die Variablen so umbenannt, dass jede Variable im Script einen eindeutigen Namen erhaltet. Mit anderen Worten: Kein Variablenname wird in mehreren Scripts verwendet. (Im P3D-Forum gab´s irgendwann mal zu Problemen bei mehrfacher Verwendung von Variablennamen einen Hinweis.)

Dadurch verschwinden zwar die Fehlereinträge im Log, allerdings bleibt leider trotzdem der "Sommermodus" erhalten.

 

Ich bleibe dabei... Das Lua-Scripting von P3D ist nett, aber leider auch eine Baustelle. Irgendjemand sollte das Lockheed Martin bei Zeiten auch sagen.

Link to comment
Share on other sites

  • Deputy Sheriffs
34 minutes ago, Schlotterknie said:

 

Das war EDDH. Diese Fehler im Contenterrorlog gab´s aber auch schon mit alten Versionen der Scripts, nur halt mit den "alten" Variablennamen.
Ich glaube dass P3D generell Probleme hat wenn "zu viele" Lua-Scripts verarbeitet werden sollen. Dann tauchen auch plötzlich solche Fehler im Contenterrorlog auf.

Das würde ich so nicht unterstreichen. Ich habe alle AIG und EDDM ohne Probleme nach meinen AIG Anpassungen am laufen. Also die Anzahl ist egal.

Link to comment
Share on other sites

  • Developer
20 minutes ago, Schlotterknie said:

 

Das war EDDH. Diese Fehler im Contenterrorlog gab´s aber auch schon mit alten Versionen der Scripts, nur halt mit den "alten" Variablennamen.
Ich glaube dass P3D generell Probleme hat wenn "zu viele" Lua-Scripts verarbeitet werden sollen. Dann tauchen auch plötzlich solche Fehler im Contenterrorlog auf.

Ich habe nochmals die Modele geprüft, da steht die Nachttexture überall drin. Einen Tipfehler in den scripts konnte ich auch nicht finden, dann hätte ich das Log ja auch.

Aber es läuft immer mehr darauf hinaus, dass die Lua Engine da nicht stabil ist, zumindest wenn addons viele errors erzeugen.

 

Denn wie hier von @Masterhawk anschaulich festgestellt ...

... hilft ihm das Bereinigen der Fehler in den AIG scripts auch bei dem Problem in MUC, da läufts dann auch ohne Probleme.

 

Wenn eine Scenery ein Scriptfehler hat,dann sieht man den kaum, da ja nur dann das Problem in der Engine auftaucht, wenn die Scenery aktiv ist.

Nur AI Flieger sind halt überall aktiv und zudem noch in Masse vorhanden. Da die scripts ja in kürzesten Intervallen (ggf. jeden Frame) ausgeführt werden, ballert das natürlich die LUA module zu. Das es dann zu Lesefehlern in der Variablenabfrage kommen kann, die eine Script dann in Fehler treibt, ist nachvollziehbar.

Zumindest ist aufgrund des Test von @Masterhawk festzustellen, dass mit der Änderung im Script und dem daraus folgenden Wegfall der Fehler im Content.log auch das Problem in Muc weg ist, somit eine gernerelle Überlastung durch viele Scripts ja offensichtlich nicht vorliegt, solange alle sauber arbeiten.

LM könnte das ggf. noch besser abfangen, aber das ist ja dann auch nur ein "Protect" gegen Fehler die wohl in den Scripts entstehen. Solche Abhängigkeiten auf einer Platform sind aber immer nervig, für alle Beteiligten.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...