The International Simutrans Forum

Community => Community Discussion => Randomness Lounge => Topic started by: Isaac Eiland-Hall on May 22, 2015, 01:46:26 PM

Title: Just testing
Post by: Isaac Eiland-Hall on May 22, 2015, 01:46:26 PM
It's been... silent in here for two days. I've been at the theatre most of those two days.... so I'm making sure nothing's broken. lol.
Title: Re: Just testing
Post by: DrSuperGood on May 22, 2015, 05:22:40 PM
Simutrans as a whole seems to have taken an activity dive over the last half year. Look at the commits to the SVN, there have been only a few in the past months.
Title: Re: Just testing
Post by: gauthier on May 24, 2015, 01:44:59 AM
Indeed. Anyway, as long as there are motivated people, how much they are does not count. In fact, I prefer little activity with nice people to much activity with idiots as it is often seen on popular games.
Title: Re: Just testing
Post by: IgorEliezer on May 24, 2015, 02:31:49 AM
Quote from: gauthier on May 24, 2015, 01:44:59 AM
Indeed. Anyway, as long as there are motivated people, how much they are does not count. In fact, I prefer little activity with nice people to much activity with idiots as it is often seen on popular games.
That's why I keep coming here, even if I haven't played Simutrans recently.
Title: Re: Just testing
Post by: AK on May 26, 2015, 07:47:06 PM
Quote from: DrSuperGood on May 22, 2015, 05:22:40 PM
Simutrans as a whole seems to have taken an activity dive over the last half year. Look at the commits to the SVN, there have been only a few in the past months.

No servers -> No (new) players
Simple,isn't it ?

After 50 closed his servers there wasn't really any long-term server. (thanks for your work,you da s**t)
Who wants to play offline (single) these days ?
Title: Re: Just testing
Post by: Ters on May 26, 2015, 08:57:05 PM
Quote from: AK on May 26, 2015, 07:47:06 PM
No servers -> No (new) players
Simple,isn't it ?

After 50 closed his servers there wasn't really any long-term server. (thanks for your work,you da s**t)
Who wants to play offline (single) these days ?

DrSuperGood wasn't writing about the multiplayer servers. At least half of it deals with how work done on (not in) Simutrans has declined. And besides, I only play single-player games. (I can't imagine anything else working out.)
Title: Re: Just testing
Post by: gauthier on May 27, 2015, 12:54:44 AM
QuoteWho wants to play offline (single) these days ?
Me.
Title: Re: Just testing
Post by: DrSuperGood on May 27, 2015, 05:17:45 AM
The main problem is that it seems that Simutrans has no direction at the moment. By this I mean that there is no "long term" plan where to go with it.

Last release had the focus of "double height" so a lot of features to support that were added. It also required a lot of work from both pakset authors and coders to support double heights.

However since that release Simutrans has been without a direction where to take it. Most of the commits made were random new features (eg JIT2 system) or bug fixes (MSVC build, pakset hashing, cyclic intersection stack overflow etc). As bugs were fixed and activity died down so did the frequency of such commits.

I am not sure if it would help restore activity, but having someone in charge write down a list of goals/jobs for next Simutrans release might be a good idea. That way people have something concrete have something concrete to work towards as opposed to randomly making changes.

Here are a few suggestions.
Title: Re: Just testing
Post by: gauthier on May 27, 2015, 09:51:37 AM
Am I the only person who can't stand convoys'bunching and who wants an automatic convoy spacing ? :p
Title: Re: Just testing
Post by: DrSuperGood on May 27, 2015, 02:21:09 PM
QuoteAm I the only person who can't stand convoys'bunching and who wants an automatic convoy spacing ? :p
If you can suggest a way of achieving this that is not a usability nightmare like in Experimental then feel free.

Some form of filter control algorithm for convoy delay might work.
Title: Re: Just testing
Post by: gauthier on May 27, 2015, 02:47:11 PM
Well, I don't know how it works in experimental (experimental nearly melted my computer last time I tried it), however I thought of two ideas:

_ Simulating total journey time for the worst convoy on the line, divide this time by the number of convoys, pace convoy departures (only from the first stop to avoid too much processing). Big drawback: does not take delays into account (can be fixed by saying instead that convoys must wait a certain time after the previous convoy's departure to go).
_ Simulating total journey time [...] but instead of clocking, set a checkpoint on the schedule so that when convoy n passes this point, convoy n+1 can go. Problem of checkpoint: if the convoy has to change his route and does not pass the checkpoint ... can be fixed by measuring distance travelled since the first stop instead.

I think the second solution is the best, space between convoys is more to-the-point than time windows which can vary a lot according to convoys performance, delays, etc ...

I also never got into Simutrans code so I don't know exactly how it works, anyway, my word about performance is that:
_ The checkpoint/space vary only if the line changes, if the convoys on it change (addition/deletion/change of convoy), if the infrastructure used by the line change. This doesn't happen so frequently. So the space can be calculated only when: line schedule change, convoy addition/deletion/change on the line, if a convoy had to recalculate his route (that indicates that the infrastructure changed). There is still a problem: if infrastructure change but no convoy was using it at the moment, recalculation does not happen: this is still to think about.
_ The spacing can happen only at the first stop (considered at the terminus stop), not necessarily at all stops, it would by okay.
Seeing performance: that would not hurt so bad, would it ?

(And anyway, if performance is a problem, it is also possible to add a setting whether to use spacing or not).

It is also possible to determine total journey time by stats instead of simulation (at least use simulation for the first measures), that has the advantage to take global traffic into account (although more performance demanding).

I would gladly code it myself, as I know a bit C++, but coding is already the main subject of my studies, so no more coding-energy-motivation during free time  ;D
Title: Re: Just testing
Post by: Ters on May 27, 2015, 03:22:34 PM
Doing long term planning is pointless if there is no one that's committed to following it up. There's an entire board full of requests for things to be implemented, and all of us that are developers knows it's there. But so far, developers have been following their own ideas and plans. That's what motivates us. Then we share what we've done with the world as a gift.

It is a bit strange, though, and perhaps worrying (for the project), that all major developers all but disappeared at virtually the same time. I can see that they are still lurking recently, so that haven't fully abandoned ship. Maybe they just want to enjoy the latest efforts they've put into the game. Or maybe most of them just happened to be progressing into a new phase in life at the same time.
Title: Re: Just testing
Post by: sdog on May 27, 2015, 10:21:19 PM
Following Simutrans development for a few years now, I predict that something will come up when the coders, who are mostly on the northern hemisphere, are forced inside due to rainy weather, cold winds, and short days.


Were there indeed a lack of viable projects (which I doubt) I should like to encourage a review of some of the wonderful features present in experimental, with the intention of implementation in standard.
Title: Re: Just testing
Post by: IgorEliezer on May 27, 2015, 11:36:07 PM
Quote from: sdog on May 27, 2015, 10:21:19 PM
(snip) the coders, who are mostly on the northern hemisphere, (snip)
Or, we need more coders from the "other" hemisphere... :)

j/k
Title: Re: Just testing
Post by: DrSuperGood on May 28, 2015, 12:39:13 AM
QuoteWere there indeed a lack of viable projects (which I doubt) I should like to encourage a review of some of the wonderful features present in experimental, with the intention of implementation in standard.
Problematic because Experimental has a different target user than Standard. Specifically Experimental has considerably higher minimum system requirements with a similar sized map consuming both more memory as well as more CPU to run. Additionally a lot of the features are not in the direction some people want Simutrans to be which is why it is a parallel project in the first place.

Standard -> low requirements, easy to use/play
Experimental -> high requirements, very difficult to use/play
Title: Re: Just testing
Post by: Ters on May 28, 2015, 04:56:29 AM
Quote from: sdog on May 27, 2015, 10:21:19 PM
Following Simutrans development for a few years now, I predict that something will come up when the coders, who are mostly on the northern hemisphere, are forced inside due to rainy weather, cold winds, and short days.

Personally, short days just drain me of energy. It's still technically night when I go to work, and it's night again when I go home. But then I'm further north than most, although not so far north that I don't have daytime at all part of the year.
Title: Re: Just testing
Post by: isidoro on May 28, 2015, 10:49:27 PM
Some projects are just much simpler than the ones suggested by DrSuperGood and I think they could boost the game up: for instance, a format to automatically include real city world coordinates and populations in maps.

That could lead to realistic maps and could fancy some people...
Title: Re: Just testing
Post by: DrSuperGood on May 28, 2015, 11:15:30 PM
QuoteSome projects are just much simpler than the ones suggested by DrSuperGood and I think they could boost the game up: for instance, a format to automatically include real city world coordinates and populations in maps.
And how is that simple? Unfortunately the world is not flat and rectangular so does not map very well into Simutrans.

I do admit that a tool to found cities from a text file (name, x, y) would be useful for people setting up maps or scenarios. However trying to translate "real city world coordinates" into Simutrans does not sound like an easy to implement feature.

The real world is not flat so already distortion correction is required. It is not even a sphere so more advanced corrections are required. How does one translate real latitude and longitude into Simutrans coordinates in a meaningful way? According to Simutrans units (1km/tile) London is well under 100 tiles squared with Paris being nearly 1,000 tiles away. If anything manually placing cities will still be more accurate as any input data would likely not be suitable for the Simutrans map it is intended for.

Title: Re: Just testing
Post by: prissi on May 29, 2015, 12:00:09 AM
About bunching: A gated signal (i.e. a traffic light with long delays (255/1 for isntance) can releive some short term bunching. More can relieved by stops with nothing to load but 100% load and wait timer, with a traffic light before.
Title: Re: Just testing
Post by: gauthier on May 29, 2015, 04:15:00 AM
What's a gated signal ?

I already use 100% loading with timer, but timer is a hassle to use as it can only waits 2^(-n), so you can only double or half waiting time, it lacks precision. The biggest problem here is that you have to micro-mannage things all the time (when population increase, you have to adapt your offer before stations get completely overcrowded, screwing up all the network for the next two years).

Anyway I know the tricks to limit bunching problems. The idea of automatic spacing would just make things much more convenient for the players.
Title: Re: Just testing
Post by: DrSuperGood on May 29, 2015, 05:28:50 AM
QuoteAnyway I know the tricks to limit bunching problems. The idea of automatic spacing would just make things much more convenient for the players.
Trying to think of a "fool-proof" way to implement automatic spacing is very difficult.

One way could be to promote stops on a schedule to a "buffers". Buffers automatically space convoys using some form of control algorithm. They operate by timing how long between convoys passing through the buffer stop.

The logic behind a buffer stop would be that convoys arriving sooner than the current spacing time get held back until the current spacing time and slightly decrease the current spacing time. Convoys arriving later than the current spacing time depart immediately and slightly increase the current spacing time. The input to the algorithm is the delay between convoys. The output is the current spacing time. Feedback comes in the form of delaying convoys.

This approach is likely not optimal. Like most control algorithms it would be prone to oscillations or latency. These might be adjustable by special settings in the schedule panel and are given a reasonable default value.

Example how it would work.


Release 3 convoys onto a schedule that takes 300 units of time to complete in worst case. Optimal spacing would be 100 units of time. However when they are released from depot they are next to each other, only 2 units of time apart. When the first convoy hits the buffer stop on the schedule it activates, starting to take the time between convoy arrivals at that stop on the schedule. When the second convoy arrives 2 units of time later it assumes the spacing to be 2 units of time (as it is the first time value). This value holds for the third convoy when it first enters as it was also 2 units of time later (so no correction needed).

When the first convoy arrives at the buffer stop after running through the schedule the time measured was 296 units of time since the last convoy of that schedule passed. Since this is much larger than the current spacing time the convoy is ordered to immediately depart and the current spacing time is altered by the control algorithm to 50 (a made up example). The second convoy is still only 2 units of time later than the first since it was "clustered" from leaving the depot so it arrives sooner than the current spacing time (50). Since it is 48 units of time too early it is forced to wait 48 units of time and the current spacing time is modified downwards to 40 (another made up example). The third convoy arrives 38 units too soon so has to wait 38 units and the current spacing time is lowered to 35 (another made up example).

On the second full loop the first convoy arrives 210 units of time after the last convoy which is better than the previous loop, departs immediately and raises current spacing time to 60. Second convoy arrives 50 units later which is less than the expected 60 so it waits 10 and lowers current to 58. Third convoy arrives 40 units later, lower than 58 so waits and decreases current to 52.

Eventually after enough loops (loops -> infinity) the current spacing time settles at 100.


Obviously real life is never as perfect as the example, but the system does not need to be perfect, just good enough that clustering is mostly removed (convoys do not need to be perfectly spaced, just not in bunches).

The main advantage of this implementation would be a minimal memory footprint (last convoy time, current spacing time, some control settings and that's it) and computations run only every time a convoy on that schedule stops at that stop.
Title: Re: Just testing
Post by: Vladki on May 29, 2015, 06:35:18 AM
I like that spacing algorithm proposal.
Title: Re: Just testing
Post by: Isaac Eiland-Hall on May 29, 2015, 07:02:16 AM
I've used traffic signals to sort of simulate border controls - if you create a three-way intersection, then delete the "third" way, it leaves you with a traffic signal that is red/green for the two remaining directions. It can then be used to space out convois. Or slow down traffic "crossing" a "border". :)
Title: Re: Just testing
Post by: Ters on May 29, 2015, 08:16:46 AM
I still believe that the solution lies at the cause of the problem: Emptier vehicles catch up with fuller vehicles because they are lighter, which makes them even more empty and more light. If passenger weight wasn't an issue for bus acceleration, the problem wouldn't be as common. Other causes (crossings and busy junctions) should even out over time.
Title: Re: Just testing
Post by: DrSuperGood on May 29, 2015, 03:12:14 PM
QuoteI still believe that the solution lies at the cause of the problem: Emptier vehicles catch up with fuller vehicles because they are lighter, which makes them even more empty and more light. If passenger weight wasn't an issue for bus acceleration, the problem wouldn't be as common. Other causes (crossings and busy junctions) should even out over time.
Until some newbie parks 100 trucks in the middle of the road while you are away causing all convoys on the line to collect together messing up the spacing you spent hours to get right.

Hence the need for an automatic spacing system which will just work. No need to spend hours manually spacing lines when you can just turn it on and it does all that for you. Slight changes to the route will also automatically correct over time so you do not need to worry about that detour or shortcut messing up your spacing either.

Theoretically a simple filter should work for the algorithm. If the filter was perfect 0 frequency pass (>0 frequency removed) then it would automatically produce the needed spacing. Perfect filters are of course impossible. To keep resource usage low an IIR (http://en.wikipedia.org/wiki/Infinite_impulse_response) filter would be a good solution if a suitable one can be devised. A FIR (http://en.wikipedia.org/wiki/Finite_impulse_response) filter might also be possible to use and might be more reliable in this case (finite response nature) however it would need more memory (buffer of last N measured times where N gets bigger the larger the required frequency filter range).
Title: Re: Just testing
Post by: Ters on May 29, 2015, 03:50:22 PM
Quote from: DrSuperGood on May 29, 2015, 03:12:14 PM
Until some newbie parks 100 trucks in the middle of the road while you are away causing all convoys on the line to collect together messing up the spacing you spent hours to get right.

And then your vehicles will block other vehicles while hanging around for the proper spacing. I don't like any solution that involves vehicles standing still except on explicit orders from me.
Title: Re: Just testing
Post by: DrSuperGood on May 29, 2015, 05:42:14 PM
QuoteAnd then your vehicles will block other vehicles while hanging around for the proper spacing. I don't like any solution that involves vehicles standing still except on explicit orders from me.
Which it is "on explicit order from" you. Since it will only use the stop buffering system if you turn it on at that stop on the schedule.

If you want to use the feature you use it at terminals or sidings where there is space for convoys to wait. If the system works properly it should at most have a backlog of 1 (unless a blockage occurred somewhere else).
Title: Re: Just testing
Post by: Ters on May 29, 2015, 07:34:28 PM
Quote from: DrSuperGood on May 29, 2015, 05:42:14 PM
Which it is "on explicit order from" you. Since it will only use the stop buffering system if you turn it on at that stop on the schedule.

If you want to use the feature you use it at terminals or sidings where there is space for convoys to wait. If the system works properly it should at most have a backlog of 1 (unless a blockage occurred somewhere else).

But I want neither of those. I want vehicles to not bunch up by themselves (because full vehicles at the front are slower than the less full vehicles behind it), and if they bunch up because of a traffic jam, once it's cleared, they should keep moving as fast as they can (there might be a huge backlog of passengers to handle, can't waste capacity) until I find it appropriate to space them out again.
Title: Re: Just testing
Post by: isidoro on May 29, 2015, 10:26:58 PM
Quote from: DrSuperGood on May 28, 2015, 11:15:30 PM
[...talking about a file format to allow placing cities in ST from their geographical coordinates...]
And how is that simple? Unfortunately the world is not flat and rectangular so does not map very well into Simutrans.
[...]

Much on the contrary.  Realistic maps in ST are usually based on DEM files.  Those files have an easy map from (latitude, longitude) to (x,y) coordinates in the map.  One can get world coordinates of the relevant cities and give (x,y) coordinates very easily.  If some cities aren't placed correctly, minor manual adjustments can be made...
Title: Re: Just testing
Post by: DrSuperGood on May 29, 2015, 11:17:39 PM
QuoteBut I want neither of those. I want vehicles to not bunch up by themselves (because full vehicles at the front are slower than the less full vehicles behind it), and if they bunch up because of a traffic jam, once it's cleared, they should keep moving as fast as they can (there might be a huge backlog of passengers to handle, can't waste capacity) until I find it appropriate to space them out again.
What you want can be achieved by giving passengers 0 weight. Although unrealistic, good's weight is only used to alter acceleration and maximum speed. Since you always want optimum acceleration then having the goods weigh nothing (0 weight) will give exactly what you want. That falls under pak balance more than anything.

The system most people want is automatic spacing.
Title: Re: Just testing
Post by: Ters on May 30, 2015, 09:18:23 AM
Quote from: DrSuperGood on May 29, 2015, 11:17:39 PM
What you want can be achieved by giving passengers 0 weight.

As I have written before. Perhaps not so directly in this discussion, but in the discussion about automatic spacing.

Quote from: DrSuperGood on May 29, 2015, 11:17:39 PM
The system most people want is automatic spacing.

It could be useful for me to have a system that would space vehicles automatically out of the depot, but having vehicles automatically stand still out on the roads at random times later could be as disruptive to me over time as that one newbie with the 100 vehicles is to you.
Title: Re: Just testing
Post by: DrSuperGood on May 30, 2015, 12:02:44 PM
QuoteIt could be useful for me to have a system that would space vehicles automatically out of the depot, but having vehicles automatically stand still out on the roads at random times later could be as disruptive to me over time as that one newbie with the 100 vehicles is to you.
They would stand at stops, not random times. Also it should only be used at terminals with some space to spare so any delays do not disrupt busy ways or at through stops which do not have much traffic through them.
Title: Re: Just testing
Post by: Ters on May 30, 2015, 01:59:25 PM
Quote from: DrSuperGood on May 30, 2015, 12:02:44 PM
They would stand at stops, not random times. Also it should only be used at terminals with some space to spare so any delays do not disrupt busy ways or at through stops which do not have much traffic through them.

I meant at stops, but it would be random whether they wait at a stop or not, depending on whether the vehicles is ahead or not. Even if my buses stop at terminals, they will still block other buses visiting that terminal. (My terminals also usually have the bus stops along a normal road. In reality, the buses would stop in pockets at the side of the road, but Simutrans lacks that detail.)

While both of us seems to have problems with buses bunching up, it seems like there are two different problems (related to different styles of playing) requiring two different solutions. (A typical situation in Simutrans, where every player seems to play the game differently.)
Title: Re: Just testing
Post by: DrSuperGood on May 30, 2015, 05:17:50 PM
Quotebut it would be random whether they wait at a stop or not
No it would be based on the control algorithm for the timing to try and keep them evenly spaced. Nothing random at all.

QuoteEven if my buses stop at terminals, they will still block other buses visiting that terminal. (My terminals also usually have the bus stops along a normal road. In reality, the buses would stop in pockets at the side of the road, but Simutrans lacks that detail.)
Depends on how used the terminals are. In theory they will only wait as long as needed to keep evenly spaced. You can always do what is recommended and make dedicated terminals or terminals with spare stops.

Your solution is a simple pak modification. The paksets are open source so you can fix it yourself. Maybe an option could be added called "weightless cargo" which would satisfy some.

The solution I am suggesting is a feature for automatic spacing while using weight mechanics. I see no reason why both cannot be done.
Title: Re: Just testing
Post by: Ters on May 30, 2015, 05:43:27 PM
Quote from: DrSuperGood on May 30, 2015, 05:17:50 PM
No it would be based on the control algorithm for the timing to try and keep them evenly spaced. Nothing random at all.

But the input to the control algorithm is random, in the sense that anything in Simutrans is random at all. If the wait time isn't the same every single time a vehicle arrives at a stop, I call it random. I can't think of no other word for it, that is more precise.

Quote from: DrSuperGood on May 30, 2015, 05:17:50 PM
You can always do what is recommended and make dedicated terminals or terminals with spare stops.

There seems to never be enough room. Sometimes, I have problems putting two stops right after each other for long trams. And it's not always because I hate demolishing buildings that aren't mine.
Title: Re: Just testing
Post by: kierongreen on June 03, 2015, 09:59:01 PM
Regarding lack of development - I for one just have had a fair bit on the last few months (or years even). Yes it may be that come the winter months I might have more time for Simutrans, then again, I might not. I'm someone who is naturally drawn to improving the visual aspects of the gameplay - things that stand out at the moment for me are: bridges/elevated ways, viewports, cliffs dependent on climate, realistic climate generation on maps and industry and city placement linked to resources. I could even dig out an old patch I had to have slope views for vehicles which was rejected about 10 years ago... I couldn't tell you whether any of these would be before the end of the year even though.

It should be said that Simutrans is a mature game - we've had a playable game for years now so the incentive for changing it for changes sake is low, fixing bugs should be the priority.
Title: Re: Just testing
Post by: gauthier on June 04, 2015, 08:49:07 AM
QuoteI'm someone who is naturally drawn to improving the visual aspects of the gameplay
Some months ago I posted a report about glitches when attempting to make stations taller than one tile. I was told my source image should take into account some specifications of the display algorithm ... after several tries (and hours wasted) I was still unable to do so. In my opinion this glitch was caused by a fundamental inconsistency (it's inconsistent only in my opinion, it's a good choice in the coder's opinion) of the display code, which basically, in a local point of view, draws frontimage of tile A before backimage of tile B even if A is north and/or west to B. It's also fairly easy to find other glitches resulting of that inconsistency.

I assume this was done so to avoid other difficulties with displaying vehicles which are on two tiles simultaneously.

Maybe you could take a look ? :D