The International Simutrans Forum

 

Author Topic: Just testing  (Read 11526 times)

0 Members and 1 Guest are viewing this topic.

Offline Isaac.Eiland-Hall us

  • Benevolent Dictator
  • Administrator
  • *
  • Posts: 3649
  • PanamaCityPC.com/support/
    • Facebook Profile
  • Languages: EN
Just testing
« 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.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #1 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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Just testing
« Reply #2 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.

Offline IgorEliezer br

  • Devotee
  • Administrator
  • *
  • Posts: 4083
  • Cake recipes are cool... REALLY!
    • Igor Eliezer Architect and Urban Planner/Arquiteto e Urbanista
  • Languages: PT, EN, AutoLISP, Python
Re: Just testing
« Reply #3 on: May 24, 2015, 02:31:49 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.

Offline AK

  • *
  • Posts: 14
  • Languages: EN,PL
Re: Just testing
« Reply #4 on: May 26, 2015, 07:47:06 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 ?

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #5 on: May 26, 2015, 08:57:05 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.)

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Just testing
« Reply #6 on: May 27, 2015, 12:54:44 AM »
Quote
Who wants to play offline (single) these days ?
Me.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #7 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.
  • Minimum runway length for land/take off of aircraft. Default is 3 (same as current). Allows pakset authors to force more realistic airport sizes.
  • Take off/Landing fees for aircraft. Default is free (same as current). Allows pakset authors to force a minimum viable distance between airports (eg, only usable on very large maps).
  • Improved build logic consistency between elevated ways and bridges. Both have similar placement restrictions with regard to buildings and other elevated structures underneath. Someone needs to define if buildings with a second vertical image are treated as twice the height or not (currently they are treated as infinite height for elevated way and 1 height for bridge).
  • Improved city building logic consistency with regard to elevated ways and bridges. Free tiles underneath bridges should be considered suitable for city buildings (currently such tiles are ignored). If decided that buildings should have a height larger than 1 then it should respect height restrictions due to elevated ways and bridges when upgrading buildings(currently it ignores height restrictions and so upgrades buildings underneath elevated ways in a way that violates the elevated way placement restrictions).
  • Add "shipping to nowhere" protection for JIT2. This could be done by refusing to send goods if the decided path-finder route contains a stop that is over capacity with the same good type as wanting to be sent. This is different from existing overcrowded protection in that it has a settable threshold for overcrowding (eg >150% of the stop maximum capacity, to allow for some tolerances at transfers) and will not attempt to re-route goods (it will appear as no-route so no more will depart until the overcrowding is fixed). This feature is needed for improved usability of JIT2 in multiplayer settings to stop inexperienced players from limiting industry efficiency.
  • Add population conservation for cities. It is not nice that bulldozing buildings "kills" people. Should be implemented as a setting defaulting to on (so people can play with classic rules if they want to still).
  • Add population dispersion support. Once "homeless" count exceeds a certain threshold (a lot of bulldozing or no more space to build) defined by a setting then the population gets re-allocated to nearby cities. A minor feature that would make the game feel more polished.
  • Improve city growth logic. Building more cities should not allow for more growth but instead reduce per-city growth. If transport metrics are good growth should be faster. If transport metrics are bad (eg as a result of too much growth and not enough player reaction to it) then growth should be slow, if not stop. If transport metrics become really bad (eg a company exclusively servicing the area is removed) then negative growth might be possible. Some form of "population limit" should exist limiting the extent to which growth can occur. All this should be controllable by settings an metrics like growth rate and maximum population should roughly scale with map area (a semi-realistic model).
  • Make growth ignore "impossible" industries. City goods metric should only count inputs that are serviceable (have one or more supplier). Slight polish feature as it is not the player's fault that the city is under supplied if he cannot supply it.
  • Improve industry construction logic. Instead of based on the population of cities (and hence city number) use global population. Assign all industries a "cost" which can be adjusted by pakset authors based on the potential value of the industry chain. Conversion of population into "value" for industries could be linear or decaying. Settings should exist to allow configuration of this model.
  • Add some form industry "obsolescence" support. Industries that become obsolete destroyed. The date they obsolete and the period over which they get destroyed are separate from the "appears until" field for backwards compatibility with existing pakset balance. Factories that will obsolete show a date they will close which is computed at the time of construction. The date of a specific industry can be modified by public service for sandbox use of industries (eg a historic village). When a factory obsoletes its cost gets refunded and re-allocated with logic in place trying to assure sufficient non-obsolete factories to keep the chain usable. The idea of this feature is to fix the "useless small factory" problem that currently occurs, especially in Pak128 britain.
  • Add a "pay for distance travelled" payment mode. This is basically an easy mode that removes the need for re-direction stops on a line. Might be useful for server games where straight line tracks are not always possible or sandbox games where efficiency is not a concern. Defaults remain un-changed.
  • Add some form of inter-server communication support. Specifically two servers can be made to roughly synchronize (not perfectly, just approximately) with each other. Some form of cross-server features could be added such as out-of-map routes. Exact details would need to be better defied.
  • Improve netcode to take advantage of multi-threading more and so keep the client more responsive. Might force the use of threads and so could raise system requirements. Specifically when querying a dead server it should not make the game process unresponsive.
  • Add support for peer-to-peer map file transfers. Since all clients in a server game have the same save at the time someone else joins then they could be used to help the new player download faster. This feature would be completely optional and default to off for clients.
  • Add support for "no pause during transfer" servers. All actions that occur are buffered and sent to the new client after the save transfer completes. His client then runs as fast as possible (not fast forwards, but instead no delay between loops) to catch up. Very useful feature for servers which are very busy with people constantly joining and leaving.
  • Add "region" support. Companies can be restricted where they build and what they can service. A feature several server administrators would like.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Just testing
« Reply #8 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

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #9 on: May 27, 2015, 02:21:09 PM »
Quote
Am 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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Just testing
« Reply #10 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

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #11 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.

Offline sdog

  • Devotee
  • *
  • Posts: 2039
Re: Just testing
« Reply #12 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.

Offline IgorEliezer br

  • Devotee
  • Administrator
  • *
  • Posts: 4083
  • Cake recipes are cool... REALLY!
    • Igor Eliezer Architect and Urban Planner/Arquiteto e Urbanista
  • Languages: PT, EN, AutoLISP, Python
Re: Just testing
« Reply #13 on: May 27, 2015, 11:36:07 PM »
(snip) the coders, who are mostly on the northern hemisphere, (snip)
Or, we need more coders from the "other" hemisphere... :)

j/k
« Last Edit: May 28, 2015, 04:15:56 AM by IgorEliezer »

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #14 on: May 28, 2015, 12:39:13 AM »
Quote
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.
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
« Last Edit: May 28, 2015, 12:54:08 PM by DrSuperGood »

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #15 on: May 28, 2015, 04:56:29 AM »
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.

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Just testing
« Reply #16 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...

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #17 on: May 28, 2015, 11:15:30 PM »
Quote
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.
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.


Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9460
  • Languages: De,EN,JP
Re: Just testing
« Reply #18 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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Just testing
« Reply #19 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.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #20 on: May 29, 2015, 05:28:50 AM »
Quote
Anyway 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.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2629
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Just testing
« Reply #21 on: May 29, 2015, 06:35:18 AM »
I like that spacing algorithm proposal.

Offline Isaac.Eiland-Hall us

  • Benevolent Dictator
  • Administrator
  • *
  • Posts: 3649
  • PanamaCityPC.com/support/
    • Facebook Profile
  • Languages: EN
Re: Just testing
« Reply #22 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". :)

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #23 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.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #24 on: May 29, 2015, 03:12:14 PM »
Quote
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.
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 filter would be a good solution if a suitable one can be devised. A FIR 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).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #25 on: May 29, 2015, 03:50:22 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.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #26 on: May 29, 2015, 05:42:14 PM »
Quote
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.
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).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #27 on: May 29, 2015, 07:34:28 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.

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Just testing
« Reply #28 on: May 29, 2015, 10:26:58 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...

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #29 on: May 29, 2015, 11:17:39 PM »
Quote
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.
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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #30 on: May 30, 2015, 09:18:23 AM »
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.

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.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #31 on: May 30, 2015, 12:02:44 PM »
Quote
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.
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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #32 on: May 30, 2015, 01:59:25 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.)

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2642
  • Languages: EN
Re: Just testing
« Reply #33 on: May 30, 2015, 05:17:50 PM »
Quote
but 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.

Quote
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.)
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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: Just testing
« Reply #34 on: May 30, 2015, 05:43:27 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.

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.