The International Simutrans Forum

 

Recent Posts

Pages: [1] 2 3 4 ... 10
1
Ich beginne meine Spiele immer mit crossconnect_factories (cf) on und suche mir die interessantesten Verbindungen heraus. Wenn die unerwünschten Verbindungen überhandnehmen, schalte ich cf aus und schließe problematische Verbindungen wie von makie beschrieben. Leider gibt es ohne cf keine Übersicht mehr über die durch das Wachstum hinzugekommenen Möglichkeiten, so dass ich zu einem späteren Zeitpunkt in einer gesonderten Sitzung cf wieder anschalte, um mich auf den aktuellen Stand möglicher Verbindungen zu bringen. Die neuen Wunschverbindungen notiere ich mir, kehre zum Spielstand ohne cf zurück und richte die notierten Verbindungen ein.

Ich habe nichts gegen ST-gesteuerte Querverbindungen, solange sie nicht zu unerwünschten Problemen führen.
Um nicht missverstanden zu werden: Ich unterstütze wolfgangs Vorschlag, in welcher Form er auch immer realisierbar ist. Aber denkbar sind auch andere Wege zum Ziel und ich habe mit der Stationsauftrennung gute Erfahrungen gemacht.

EDIT: Die Bilder fußen auf PAK128.german.
2
Bug Reports / [r9579] Client crash when editing schedule on server
« Last post by ceeac on Today at 08:50:27 AM »
When pressing the "edit schedule" button of a convoi in a depot on the server, all clients crash.
Backtrace for the client:
Code: [Select]
#0  schedule_t::start_editing (this=0x0) at ./dataobj/schedule.h:131
#1  0x0000000000807e42 in tool_change_convoi_t::init (this=0x2620030, player=0x25e6ad0) at simtool.cc:7033
#2  0x0000000000615eab in nwc_tool_t::do_command (this=0x2622a90, welt=0x25d6750) at network/network_cmd_ingame.cc:1197
#3  0x000000000083ba64 in karte_t::do_network_world_command (this=0x25d6750, nwc=0x2622a90) at simworld.cc:7139
#4  0x000000000083b583 in karte_t::process_network_commands (this=0x25d6750, ms_difference=0x7fffffff933c) at simworld.cc:7089
#5  0x000000000083c01c in karte_t::interactive (this=0x25d6750, quit_month=2147483647) at simworld.cc:7249
#6  0x00000000007c6b3d in simu_main (argc=9, argv=0x7fffffffdcf8) at simmain.cc:1520
#7  0x000000000088629f in sysmain (argc=9, argv=0x7fffffffdcf8) at sys/simsys.cc:1126
#8  0x00000000008b2cb2 in main (argc=9, argv=0x7fffffffdcf8) at sys/simsys_s2.cc:828
3
In recent weeks, the join times and lag on the Bridgewater-Brunel server have 'swung between the sublime and the ridiculous' (= changed between very good and very bad).

Now that we have good performance, I am very keen that we keep it and reflect on how things got so bad for so long. It seems to me that this was partly due to misunderstandings: it was not adequately recognized that memory bandwidth and usage had become the main performance bottleneck. And it was partly because James and other coders have been adding new features on a regular basis, which is a really great problem to have!  ;D

But at the moment, the high-level design goals of the project make no reference to performance. I think that is a mistake, because poor performance means many, maybe all, of the benefits listed in that document become unattainable and unappreciated.

I propose that it should be not only a design goal, but a design rule, that the game should be coded so that the Bridgewater-Brunel game never exceeds ~7.5GiB, so that it never goes into swap space. This is a measurable, achievable design goal that brings immediate and obvious benefits.

I can think of three objections to this change.

Firstly, it is rude of a non-coder to impose burdens and limits on the coders who generously give their time and energy to the project. There is a lot of truth in that, but this is only a proposal; it will be up to coders to decide whether you wish to limit yourselves in this way.

Secondly, it is selfish, because I am a Bridgewater-Brunel player and I am limiting the whole community so that I can have fun. That is also a fair point, but I think it should be recognized that B-B is Sim-Ex pushed to its performance limits. If B-B has poor performance, then the experience of other players is likely to be even worse, either because their large/compex maps are unplayable or because their map sizes and complexity are limited.

Thirdly, that it it is wrong in principle to base the general development of Sim-Ex on a single server. This is a good point in theory, but I think it falls down in practice for three reasons. As mentioned above, B-B is very demanding in terms of memory bandwidth and usage. For a long time I only used single-player mode, mainly for personal reasons, but partly because B-B's memory requirements were unaffordable. So it is a good test of the principal bottleneck. In addition, B-B is by far the most active multiplayer game on the listserver. Maybe there is a hidden community of Sim-Ex multiplayers in Japan, but I think it's fair to say that if B-B performance is poor, a large percentage of the active playerbase has problems. Finally, I think that this particular chicken has long since flown the coop (= this argument is not good because we already break it). The most recent and obvious example is that when B-B upgraded to Ubuntu 20.04, the official releases dropped support for almost all other Linux versions. I think (and I said at the time) that it was a sensible use of James' time to upgrade B-B to 20.04. But the system requirements of the whole project were based on the needs of that one server and nothing else. I could give other examples, but I think that one is sufficient.
4
Simutrans-Extended development / Re: Performance analysis
« Last post by Matthew on Today at 05:59:52 AM »
A couple of posts ago I was complaining about how slow multiplayer join times were. What a difference a few days (and a lot of effort) makes!

For the benefit of posterity, here is what good performance looks like. On recent builds, it has taken Bridgewater-Brunel about 40 seconds to prepare a very large map. Transferring the map took as little two minutes (and my Internet was slow because of poor weather). Three days ago the game was unpausing and began progressing faster than real time in no more than two minutes, and I think that was a transitional phase; yesterday it was as little as six seconds. The whole join process from requesting a join to running faster than real time can now be completed in about three minutes. If you are lucky enough to have an SSD, a client crash is not such a big deal anymore.

Thank you very much to Freddy for the improved code and to James for code review!



Appendix: Loading times
(Columns: Build ­— GMT time started — join requested — save prepared on server — save transferred — save loaded — game unpaused — game runs faster than real time)
5
Scenarios and Challenges / Re: Pak128 Scenario Tutorial
« Last post by Yona-TYT on Yesterday at 11:52:17 PM »
I got another error, it happened just before I was to start placing electrical lines.

Hi, how are you? I really appreciate your help with this!
I was reviewing this but ran into other non-script issues maybe, and until they are fixed I can't move on. :(
6
Social & Contests / Re: Simutrans Steam Screenshot Contest
« Last post by Isaac Eiland-Hall on Yesterday at 11:28:13 PM »
Wait, I didn't know Hooray was his first name! :)
7
Simutrans-Extended major projects / Re: Incorporating changes from Standard
« Last post by Roboron on Yesterday at 11:17:20 PM »
Trying to compile with UPNP support is failing to find the library. Seems that Extended import it using  "#include <miniupnpc.h>" while Standard import it with "#include <miniupnpc/miniupnpc.h>". Is this because the miniupnpc changes are not yet fully incorporated or for other reason?
8
michelstadt: diese Vereinzelung von Teilen eines Bahnhofs wird dich aber auch nicht vor ungewollten Verbindungen schützen. Sobald ein neuer Betrieb im Einzugsbereich einer der Bahnhöfe aufmacht oder ein bestehender Betrieb sein Angebot erweitert, wird er den entsprechenden Bahnsteig verstopfen.

Ich habe noch etwas über die Idee nachgedacht, Liefer-/Transport-Verträgen aktiv zuzustimmen und die gefällt mir immer besser. Dazu könnte man sogar einen Zeitbonus vergeben: wenn du einem Liefervertrag zustimmt, also den Transport der Waren vom Versender zum Empfänger übernimmst, musst du innerhalb einer bestimmten Zeit die Verbindung stehen haben, sonst gibt es diesen Bonus nicht. Und wenn es zu lange dauert, vergibt der Auftraggeber den Auftrag erneut. Wäre z.B. wichtig im Mehrspielermodus.

Nachtrag:

1.
Nur der Neugier wegen: aus welchen Pakset sind eigentlich die Bilder?

2.
Habe mir gestern noch mal ein paar Spielstände angesehen, und bin zu dem Ergebnis gekommen, daß die aktive Zustimmung zu einem Transportauftrag durch den Spieler zumindest davor schützen würde, daß neu gegründete Betriebe im Einzugsbereich bestehender Ladestationen sämtliche Transportkapazitäten kapern. Das wäre eine große Hilfe, denn wie schon Freahk erwähnte, kann und darf im realen Wirtschaftsleben nicht einfach ein Hersteller seine Waren auf zufällig vorbeikommende Fahrzeuge verladen. Am Anfang eines Spieles sind wenig Betriebe vorhanden, und das eigene Transportnetz kann recht mühelos effizient eingerichtet werden. Kommen später neue Betriebe hinzu, müssen deren Transportaufträge erst aktiviert werden.

Aber vor ungewollten Querverbindungen kann das nicht wirklich schützen, denn wenn der Algorithmus eine Route für eine Ware findet, weil sie z.B. eine kürzere Strecke benötigt, sie aber vom Spieler wegen der Auslastung oder Fahrtrouten der Fahrzeuge nicht benutzt werden soll, wird sie das Spiel sie trotzdem benutzen.

Mögliche Lösung: eine Auswahl der erlaubten Zwischenstationen für eine Ware beim Versand!

Wenn der Spieler an einer Fabrik eine Ladestation baut, und in der Liste der Waren der Fabrik für jede Ware auswählt, ob er sie transportieren will, könnten als nächster Schritt in einer Liste aller möglichen Zwischenstationen diejenigen ausgewählt werden, an denen die Ware abgeladen werden darf.

Damit sollte die Ware dann nirgends auftauchen, wo sie nicht erwünscht ist und die exakte und gewünschte Route ist festgelegt.

9
I no longer produce release builds in Visual Studio, only debug and optimised debug builds. Release builds are built on the Bridgewater-Brunel server. For this reason, the release build configuration is not set up to work. I suggest using the optimised debug build instead.
10
Mit "Industrieanlagen mit Verträgen verbinden" kann man Fabriken verbinden.
Wenn man die Strg Taste drückt (und "Crossconnect" nicht aktiv ist) dann kann man Verbindungen damit auch lösen.

Vielleicht wäre das Gegenteil zu "Crossconnect" in den Einstellungen eine einfach Lösung für Leute die dies wünschen.
Also ein "No auto connect" der Spieler muss alle Verbindungen die er wünscht manuell mit "Industrieanlagen mit Verträgen verbinden" schaffen.
Das könnte man dann auch nach Spielstart, setzen damit keine neuen Verbindungen dazu kommen.

------------------------
Eine weiter Möglichkeit wäre mit "industry increase every" das entstehen neuer Fabriken zu verhindern.
Pages: [1] 2 3 4 ... 10