Recent Posts

Pages: [1] 2 3 4 ... 10
Patches & Projects / Re: Convoi auto unbunching on line
« Last post by Dwachs on Today at 07:14:27 AM »
That wiki page also has some 'fixes' to the problem, among them minimum waiting time.

Another option would be to send full busses to the next step, where passengers want to leave. So the bus does not need to stop, where it is useless anyway, and might even take a short-cut to next station, where somebody wants to leave.
Scripting Scenarios and AI / Re: [line_x] Remove lines
« Last post by Dwachs on Today at 07:08:01 AM »
Please check r8274
or actually the facing of the stop which changes upon map rotation.
Attached example. Both lines are set for 15 min spacing, one waits at the north station, one at the south. In steady state, the north waiters end up with 30 min spacing.

Observe the first two convois arriving at the north station have the correct waiting times. Once a line into the station forms, the waiting time doubles. The reversing convoi is still counted as being in the station for the purposes of  halt->get_queue_pos(self) in the waiting time calc. For the south station waiters, the queue_pos remains 1 since the reversing completes before the next convoi makes it in all the way.

Rotate the map once so the north station becomes east. Now the waiting times return to the correct 15 min spacing. But the formerly south, now west, line ends up with the 30 min waits...

Technical Documentation / Re: Reversed order of way construction
« Last post by THLeaderH on Today at 12:21:15 AM »
As mentioned before: I think the overtaking patch and a oneway way/wayobj patch should be separated. Otherwise it gets more and more difficult to properly merge them.
Leaving oneway_mode road itself two way means we have to deal with facing traffic. I found that this becomes a big problem considering city cars. So, oneway road feature should not be removed from OTRP. I'll release the next version, v11, in about a week.
Of course, I update the base of code to the latest version of the trunk to make merging easy. Also, oneway way feature is written in specific files, wegbauer.h,, tunnelbauer.h,, brukenbauer.h, and When you want to inspect this feature, you have to check these 6 files.
Simutrans Extended Discussion / Re: industries arent producing goods
« Last post by jamespetts on Today at 12:10:52 AM »
Splendid, thank you for confirming.
Simutrans Extended Development / Re: Crash on placing stop on nonowned road
« Last post by jamespetts on Yesterday at 11:52:54 PM »
and there's another one called is_public_serivce().   look close!

Ahh - there was a spelling error (which may even have come from Standard, although I am not sure): "is_public_serivce" was sometimes used instead of "is_public_service". Very odd. In any event this is now fixed: thank you for spotting that.

You're deep into undefined territory there. MSVC is leading you down a path with a noose at the end. Standard gets the benefit of a couple more people passing the code through their choice of compilers to purge this type of thing... you'd need to try multiple compilers yourself on occasion so you don't end up with MSVC specific stuff in Extended.  Likely this type of undefined behaviour is the ultimate source of the desync problem going on with linux(gcc) and windows (msvc)...

32 nonnull compare warnings trigger during the build - I quickly scanned them and thought I seen 6 unique. There's actually 7. Attached is warning log - suggest you get rid of all 7.

Thank you for letting me know about that - it is useful to know which things should not be done. I wonder why checking whether "this" is null is illegitimate? It is quite useful to be able to do that. In any case, I have now removed this construct wherever the warnings pointed to it: thank you very much for that log: that was most helpful.

I do compile with GCC, incidentally: the automatic nightly builds all use GCC, including that used by the server, albeit I do not easily then see the warnings.

As to the Linux/Windows desync, that was fixed a while ago: the problem turned out to be the use of the built-in Simutrans min/max templates with 64-bit integers.

Thank you again for your help with quality checking the code: it is very useful to have a more experienced programmer look over this: it is quite challenging doing this mostly on my own as a self-taught coder, and all help is gratefully welcomed.
Bug Reports / "Promote to line" button is causing problems.
« Last post by yorkeiser on Yesterday at 11:38:03 PM »
Probably not really in topic, but I also noticed some problems on the "promote to line" button (Simu120.2.2 r8163 with pak128 2.6).
If I set a schedule, click on "promote to line" button and type line name in the textbox, I have to press the return key TWICE.
If I press return just once when the textbox has still focus (as I did in the previous versions), the text entered will not be considered and line name is a default name, e.g. Line123.
Pak64 Add-ons and Graphics / Re: British Trains for Pak 64
« Last post by Lewis on Yesterday at 09:51:38 PM »
Pretendolino? The DVT is still a work in Progress

Patches & Projects / Re: Convoi auto unbunching on line
« Last post by Ters on Yesterday at 09:01:58 PM »
One might say that dealing with those situations is what Simutrans is about. If bunching is because the player did something stupid, the player should have to clean up their own mess, not just wave a magic wand. But as I write again and again: Each player sees the game differently. Those just into world building probably don't want to deal with traffic planning and logistics, they just want it to flow in a visually pleasing manner.

Vehicles getting stuck behind other slower vehicles should in theory affect all vehicles just as much over time, I think, therefore splitting up bunches as much as creating them. Maybe it triggers the initial load imbalance.
Pages: [1] 2 3 4 ... 10