Posts by WernerK

Willkommen in der Transport Fever Community

Welcome to the fan community of Transport Fever and Train Fever, the economic simulators of Urban Games. The community is free for you to share and inform yourself about the game. We cultivate a friendly and objective interaction with each other and our team will be happy to answer any questions you may have.

 

Registration and use is of course free for you.

 

We wish you a lot of fun and hope for active participation.

The Team of the Transport-Fever Community

    Quote

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

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


    Quote

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

    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. :D Auf jeden Fall sollte man mit state.openWindow keine Strings aus anderen Threads an das Fenster übergeben. ?(

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

    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. :thumbup: 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?

    Ääää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 :(:huh::rolleyes::cursing:<X|| 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:

    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.

    Quote

    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ß. ;)

    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.

    Quote

    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. ^^