Beiträge von WernerK

Bei einer Repository-Abfrage bin ich über merkwürdige Straßentypen gestolpert. So was wie das hier:

standard/country_small_new-0001100000000000.lua

Die werden interessanterweise am Ende einsortiert. Hat jemand eine Ahnhung, was das ist?

Nachtrag: Inzwischen habe ich herausgefunden, dass die Straßen von einer Mod namens "Street (Fine) Tuning" von Lollus auf Basis anderer Straßen dynamisch generiert und nachträglich ins Repository geladen werden. Dies ist wohl erforderlich, um Busspuren etc. zu konfigurieren. Jegliche Bemühung, diese Straßen als Dateien irgendwo zu finden, wäre vergebens.

Zitat von Relozu

Warum die Zeile geändert wurde und was damit noch alles zusammenhängt, ist mir im Moment nicht klar.

Vielleicht schließt du dich nochmal mit dem Autor von NEP kurz, falls er nicht sowieso hier mitliest. Wäre ja ein grundlegendes Problem, und wenn du da jetzt schon einen Lösungsansatz hättest ...

Zitat

Wenn du von dort aus den state ändern willst, musst du ein ScriptEvent schicken und die Änderung im Script Thread machen.

Bingo! Ist zwar etwas kompliziert, aber andererseits auch einleuchtend.

Zitat

Aber prüfen ob das Fenster schon geöffnet wurde, kann man auch mit ner lokalen Variable machen

Im Grunde finden ja mehrere Dinge statt. Zunächst schicke ich einen Befehl von der Engine an GUI, um das Fenster zu öffnen. Da dieser Befehl mehrmals reinkommt (mal testen, wie es mit obiger Lösung funktioniert), muss ich prüfen, ob das Fenster schon offen ist. Das mache ich über die Id (Grüße an Enzojz ). Ich hatte da auch schon mit einer Variable außerhalb state gearbeitet, wollte aber dann doch irgendwelche mutmaßlichen Hacks vermeiden. Der dritte Vorgang ist die Übergabe von Strings an das Alert-Fenster, die in meinem hier veröffentlichen Code noch nicht implementiert ist. Ich hatte hierfür einen String in windowOpen reingepackt, aber - wie gesagt - er wurde schon wieder gelöscht, bevor er überhaupt an das Fenster übergeben wurde. Deshalb übergebe ich jetzt einen separaten String, natürlich auch in state, der hinterher nicht gelöscht wird und vermutlich bis in alle Ewigkeit im gameScript wie ein Pingpong-Ball hin- und herspringt. Aber vielleicht krieg ich das ja jetzt mit der von dir vorgeschlagenen Methode optimiert und kann womöglich noch eine der drei Variablen sparen.

Zitat

macht eig keinen Sinn, da ja state bei load wieder neugeladen wird.

Aber wie soll ich sonst das Fenster starten? Von der Engine zum GUI gibt es doch keinen anderen Weg als über state-Variablen? Oder irre ich mich da?

Ein interessanter Effekt dabei ist, dass state.openWindow schon wieder gelöscht ist, bevor das Fenster aufgebaut ist, allerdings gleichzeitig noch als Zombie-Variable irgendwo zwischen load und save herumschwirrt. Multithreading ist echt schwer zu verstehen. Auf jeden Fall sollte man mit state.openWindow keine Strings aus anderen Threads an das Fenster übergeben.

Kenn ich. Aber vielleicht auch noch ein paar ganz normale Pkws.

Wäre doch mal ne Idee, für Spezialeffekte Pkws als Linienfahrzeuge herauszubringen. Ich glaub, da gibt's momentan nicht allzuviele.

Ich glaube inzwischen eine Lösung gefunden zu haben. Sieht zumindest so aus, dass es auch ohne Kenntnis des Skalierungsfaktors funktioniert:

local function guiUpdate()
    if state.openWindow then -- trigger message
        local winId = "wkjsAlertbox"
        if not api.gui.util.getById(winId) then -- checks if window already exists to inhibit a new window every call :-)
            state.window = api.gui.comp.Window.new(_("alertboxTitle"),api.gui.comp.TextView.new(_("alertboxText")))
            state.window:addHideOnCloseHandler()
            state.window:setIcon("ui/icons/windows/attention.tga")
            state.window:setId(winId)
            local parent = state.window:getParent() -- not the screen size but the usable part of the game window
            uiSize = parent:getContentRect()
            local newSize = api.gui.util.Size.new(500, 150) -- regular size without UI scaling
            state.window:setSize(newSize)
            state.window:setVisible(false, false) -- can we really notice the window opening at the wrong place?
            state.window:setPosition(0, 0) -- opens the window, which must be opened extemporary to get the (scaled) size :-(
            local winSize = state.window:getContentRect() -- now we can get the scaled size
            local x = math.floor((uiSize.w - winSize.w) * .5 +.5)
            local y = math.floor((uiSize.h - winSize.h) * .5 +.5)
            state.window:setPosition(x, y) -- and now we can set the final position :-)
            state.window:setVisible(true, false)
            game.gui.playSoundEffect("attention") -- for warnings
            state.openWindow = false
        end
    end
end

An dieser Stelle gleich die Warnung, dass das alles noch experimentell und ohne Gewähr ist - für alle, die den Code übernehmen möchten.

Erstaunlich, welcher Aufwand getrieben werden muss, um ein simples Fenster zu öffnen. Erstaunlich auch, dass man wohl erst die tatsächlichen Maße des Fensters zurückgegeben bekommt, nachdem das Fenster bereits geöffnet wird. Aber immerhin hätten wir ein Workaround - womöglich schon den Königsweg. Vielleicht doch mal UG fragen ...

Eine weitere Überlegung wäre noch, das Fenster schon in guiInit anzulegen und später an entsprechender Stelle aufzupoppen. Dort wird es witzigerweise unabhängig von den in setPosition angegebenen Werten in den unsichtbaren negativen Koordinatenbereich geschoben, allerdings so, dass ein Teil noch in den sichtbaren GUI-Bereich hineinragt.

Ob setVisible überhaupt notwendig ist, ist mir nicht ganz klar. Für genau einen Frame müsste das Fenster an der falschen Stelle sichtbar sein. Alternativ könnte man es auch außerhalb des Bildschirms platzieren, in der Hoffnung, dass es dort nie jemand zu sehen bekommt. Und da scheint mir setVisible die sicherere Lösung zu sein.

Ganz sicher bin ich mir noch nicht, ob bei der obigen Anordnung irgendwelche Aktionen beim Framewechsel "verschluckt" werden könnten.

Ja, danke, das ist doch schon mal was. Da muss einer aber wirklich erst drauf kommen! Wozu soll das gut sein? Wenn man auf mehreren Monitoren spielt? Ahja, jetzt ist's klar - wegen der Schriftgröße. Die sich allerdings weniger ändert als die Größe der Fenster, wenn man diese mit calcMinimumSize() automatisch an den Text anzupassen versucht. Auch so eine Merkwürdigkeit.

Daraus ergibt sich allerdings eine weitere Frage: Kann man den Skalierungswert irgendwo abgreifen?

Die Bildschirmauflösung wird bei mir auch immer korrekt ermittelt. Aber was ist denn der mysteriöse UI Skalierungsfaktor?

Ääääh ... hab ich doch gemacht, hab nur statt mainView screen als Variable benutzt. Dürfte eigentlich nichts ausmachen. Hmm, dann weiß ich auch nicht mehr weiter., vielleicht haben die da ja tatsächlich was geändert. Oder mein Monitor tickt falsch. Du (oder war es jemand anders?) hattest auch mal was mit Faktor 0.9 drin. Ich hatte schon den Verdacht, das wär's, aber das würde dann ja wieder mit den Fällen kollidieren, wo es exakt stimmt.

Wieder eines dieser schrecklichen Probleme, an die man sich zeitraubend Schrittchen für Schrittchen herantasten muss Warum nur?!

Ich möchte doch NUR ein kleines Alert-Fenster aufpoppen lassen, und zwar exakt (!!!) in der Mitte des Bildschirms.

Theoretisch habe ich die Lösung gefunden:

local screen = api.gui.util.getById("mainView")
--local parent = screen:getParent()  -- @ eis_os: Auch das habe ich probiert, und die komplette tpfui._getRoot-Funktion, alles vergeblich :-(
--while(parent) do
--	screen = parent
--	parent = screen:getParent()
--end
local screenSize = screen:getContentRect()
state.window = api.gui.comp.Window.new(_("alertboxTitle"),api.gui.comp.TextView.new(_("alertboxText")))
state.window:addHideOnCloseHandler()
state.window:setIcon(icon or "ui/icons/windows/attention.tga")
state.window:setId(winId)
local newSize = api.gui.util.Size.new(500,150)
state.window:setSize(newSize)
print ("screen size", screenSize.w, screenSize.h)
local x = math.floor((screenSize.w - 500) * .5 +.5)
local y = math.floor((screenSize.h - 150) * .5 +.5)
state.window:setPosition(x, y)
game.gui.playSoundEffect("attention")

Aber nur theoretisch ...

Das Fenster klappt auch. Aber nur in der Auflösung 1920 x 1080 liegt es in der Mitte. Wähle ich z.B. meine Standardgröße 2560 x 1440, liegt es zu weit rechts. Wenn man die Gegenprobe macht und das Fenster einmal am rechten Rand ausrichtet (also screenSize.w - 500), liegt es nicht am rechten Rand, sondern überschreitet ihn. Daraus ist zu folgern, dass die GUI-Grundfläche kleiner sein muss als die Bildschirmauflösung, aber gleichzeitig über sie hinausläuft. Aber eben nicht in allen Auflösungen. Was ist da los - und wie bekomme ich den richtigen Wert? Oder ist das einfach nur ein böser Bug? Wobei es in den hauseigenen UG-Routinen ja zu funktionieren scheint, denn die Ingame-Fenster (z.B. die Warnmeldung oben im Spielfenster) werden exakt zentriert.

Und nein, es hat nichts mit Vulcan und OpenGL zu tun, hab ich auch schon getestet.

Lasst doch erst mal die dringend notwendigen und von der Mehrheit bemängelten Optimierungen durchführen, und zwar möglichst evolutionär und abwärtskompatibel. Bis das geschafft ist, gibt es wieder bessere Grafikkarten, und dann ist vielleicht Zeit für neue Features, wobei die Wünsche hier schwerlich alle unter einen Hut zu bekommen sein dürften. Sonst werden zig halbfertige Sachen eingebaut, die nur noch mehr Ressourcen fressen. Und dann sind alle noch frustrierter.

Zitat

Denn nur dort bekommt der Autor des Mods auch mit, wenn ein Nutzer ein Problem hat.

Ist dort schon mehrfach als Bug gemeldet.

Das Problem dürfte sein, dass die Mod nicht mit Linienänderungen und erst recht nicht mit Löschungen synchronisiert ist.

Zitat

Das sieht einfach deutlich besser (könnt auch gerne mal weiter nach vorne spulen) und absolut flüssig aus.

Das ist aber auch eine typische Führerstandssimulation. Da hört die Landschaft links und rechts der Strecke irgendwo auf. Folglich muss auch nicht viel gespeichert werden, da geht dann auch noch mehr. Siehe auch TrainSimulator etc. Wenn du aber auf dieser Basis eine großflächige Landschaft aufbauen möchtest, dann viel Spaß.

Zitat

Tja - was sagt mir das? Ein solches Spiel kauft man erst, wenn es weitestgehend ausgereift erscheint.

Das gilt heutzutage für fast alles.

Mit inkompatiblen Mods hatte ich bislang noch nie wirkliche Probleme. Sie sind IMHO eher Ausnahme als Regel. In den Anfängen von TPF2 muss es wohl da häufiger gerummst haben, aber da war ich nicht dabei. Als Einsteiger stolpert man allerdings gerne über Mods, die auf anderen Mods aufsetzen. Da crasht dann das Spiel, weil irgendwelche Dinge nicht vorhanden sind, und du erst einmal herausfinden musst, was genau fehlt. Es gibt einige wenige Mods, da brauchst du sogar eine zweistellige Anzahl anderer Mods, um sie ans Laufen zu bringen. Aber das ist kein Problem von UG, das ist ein Problem der Modder, wie auch irgendwelche - nicht allzu häufigen - Qualitätsprobleme.

Zitat

schau dir die anderen ähnlichen Titel an - etwa EEP ... wenn du da die gleiche Vielfalt haben willst wie in TPF(2), dann zahlst du dich dumm und dämlich.

So ist es. Und selbst dort ist mangelnde Performance ein regelmäßiges Thema.

Zitat

was man in Reallife macht, um diesem Effekt entgegenzuwirken, sind zumindest hier: Kurzführungen. Der Bus fährt nicht seine ganze A->B Strecke sondern dreht irgendwo mittendrin bei C um und fährt zurück zu A, damit wenigst irgendwie wieder Kontrolle in das Fahrplangefüge kommt.

Es gibt noch eine andere Lösung, und die habe ich auch bei mir nachrüsten müssen: die überschlagende Wende. Bei einem 10-Minuten-Takt bleibt ein Fahrzeug ca. nach Ankunft fast die gesamte Taktzeit an der Endhaltestelle stehen und hat auf diese Weise noch eine ausreichende Pufferzeit. Das bedingt aber zwei hintereinanderliegende Haltemöglichkeiten an den Wendeschleifen - für einrückende Fahrzeuge reicht ein reiner Ausstiegshalt - und mehr Fahrzeuge. Somit ist es dann auch etwas teurer, womit wir wieder bei der wirtschaftlichen Komponente wären.

Wenn man an dieser Stelle spart, kommt es selbst bei einem Stundentakt auf der Schiene zum Chaos und den beliebten Durchsagen "... wegen Verspätung aus vorhergehender Fahrt". Diesen Zustand kann man regelmäßig auf einer niederrheinischen Regionalbahnstrecke erleben, die von einem berüchtigten britischen Unternehmen betrieben wird, ich denke mal, jeder ahnt, wer hier gemeint ist.