News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

[patch] Semi-automaitc spacing for lines.

Started by inkelyad, November 24, 2010, 11:54:57 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

inkelyad

By popular demand.

Open demo save.
Open line management dialog.
Set Spacing to 20-25.
Look at convoys tooltips.

EDIT(2010-11-27): new upload, indentation fix.

inkelyad


Dwachs

I quickly looked through the patch (I did not apply nor test it). As far as I understand, the spacing is applied to the whole schedule. The spacing number is equivalent to number of convois that are allowed to stop at each halt in the schedule per month.

Tbh I find this quite counterintuitive. Imho it would be more intuitive to set spacing as the minimum time between convois.

The code that determines the waiting-time (convoi_t::laden) does not take into account when the previous convoi left. For example, if weltt->ticks_per_month() / fpl->spacing is equal to 1000, current time is 2001, previous convoi left at 1000, the current convoi will wait till 3000, although it could leave without waiting.
Maybe one could save the time, when a convoi leaves a station, in the schedule of the line?

The tooltip-stuff seems to be completely independent of the rest of the patch. Showing the waiting time in tooltip is a very good idea. But it may look strange if waiting time is longer than one day. Maybe show number of days then?

Further remarks:
-- spacing should be written/read in schedule_t::rdwr to, but check for right savegame version (file->version() ...)
-- very minor: you do indentation with spaces, the simutrans code does it with tabs

This post is meant as constructive criticism. Thank you :)

Edit: We (as developers) currently are heading for a release, so this patch has to wait a little bit.
Parsley, sage, rosemary, and maggikraut.

inkelyad

Quote from: Dwachs on November 26, 2010, 11:40:21 AM
Tbh I find this quite counterintuitive. Imho it would be more intuitive to set spacing as the minimum time between convois.
Then we need to put internal timescale in gui. And it will depends on welt->ticks_per_month setting. Not good.

Again, when we have industry with 100t/month productivity, and 10t convoy => we well use 10conv/month schedule for it. Easy calculations.

Quote
Maybe one could save the time, when a convoi leaves a station, in the schedule of the line?
Yes, in Experimental we have such field, I use it. But Standard have not, and I don't want to add it.

In another hand, in this implementation, we can synchronize lines. (set 10 cnv/month for rail and 20 cnv/month for bus and see.)

Quote
-- very minor: you do indentation with spaces, the simutrans code does it with tabs
Wrong editor settings. I will fix it.

prissi

I personally am not keen on including such a patch, since a) the same functionality can be achieved by other means and b) it solves not problem. The problem I found was rather that it was too hard to transport all passengers. Giving them a predefined spacing make it even harder to transport.

Also bunching will usually only occur, if you have too much or too few busses availabe; and then it can be cured but a waiting sign and wait for 100% load with a waiting time. Having 100% full buses waiting additionally defies a little the prupose of a transport simulator.

inkelyad

100% full bus will not wait in my patch too. It works like more structured version of  'Max waiting time'.

There was 10 downloads. Can somebody write about actual experience?

VS

I've had this opened in a tab for a week now, and I still can't bring myself to do anything... :(

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

wlindley

#7
Hmm... The main problem I have seen with "spacing" or waiting periods, is with ships.  

I have two "continents" each with a main port, and a single passenger ship line between these two points ("A" and "B").

If I build ten ships and set the Waiting time to, let's say 1/2 month, and start all those ships at "A", then all the ships will wait the "same" 1/2 month, and sail in one massive fleet to "B"; meanwhile "A" stacks up unhappy passengers.  No amount of fiddling with waiting times will prevent this situation from starting, nor is there a way to break it up once started.

Inkelyad, I looked at the code; is your patch designed to resolve that situation?  

It seems, instead, what I want is neither the current, standard, "Each vehicle [convoi?] wait until load-factor, or until fraction of month after arriving, whichever comes first, regardless of other vehicles" nor exactly what this patch does, but rather that a vehicle should:


  • When arriving at a station, its departure timeout should be zeroed, and starts to count up.
  • Always depart when load-factor, if given, is filled.
  • Always depart when its timeout value increases to the set value.
  • When departing the station, zero the timeout of all other vehicles in the same Line, waiting at the same station.

Indeed, for bus stations with a single halt square, and for train stations where trains in a line do not use a choose signal, i.e., where vehicles "queue," the behavior of such a patch would be identical to the current codebase.  For ships, and where choose signals are used, such a patch would result in a far more intuitive behavior. 

Thus, such a patch would not require any additional interface items, just a change of algorithm.

Thoughts?

inkelyad

#8
Quote from: wlindley on December 02, 2010, 01:27:28 AM
Inkelyad, I looked at the code; is your patch designed to resolve that situation?  
Yes.

Quote
Thus, such a patch would not require any additional interface items, just a change of algorithm.
Current 'power of 2' waiting time is too rough. More, sometimes current behaviour can be useful. And there is backward compatibility issue -- changing current algorithm will break old well-balanced games.

prissi

In current nightlies, only the convoi of a line is loaded that arrived first. The situation, that all ships depart at once, will now only occur when you have way to few capacity on a line, so that the ships will never ever wait. Or when you set waiting time too short.

Please try your scenario with ships with a recent nightly. (Same goes for multiple trains on only line at multi-platform loading queues or airplanes ... ) I found it to work rather well in some test games, especially on planes and ships.

inkelyad

Quote from: prissi on December 02, 2010, 09:31:39 AM
In current nightlies, only the convoi of a line is loaded that arrived first. The situation, that all ships depart at once,
Ships arrived at once (from depot, for example) => they depart at once unless infinite waiting time is used. Once group of chips formed(passengers peak from big train, for example), it will stay that way.

prissi

Yes, but then it is needed by transportation demand and will still happen with the above suggestion. Anything else will cripple the capacity of said line, or?

inkelyad

It needed only in peak hour. (arrival of big train to port). Then we want ships spread again. it is impossible to do using just wait time.

wlindley

Quote from: inkelyad on December 02, 2010, 10:42:19 AM
Ships arrived at once (from depot, for example) => they depart at once unless infinite waiting time is used. Once {a} group of ships {is} formed (passengers peak from big train, for example), it will stay that way... {The group is} needed only in peak hour (arrival of big train to port). Then we want ships spread again. It is impossible to do using just wait time.

Indeed.

OK, prissi, I tried openpak128 and sim-gcc4 r3998.  Built a ship line between two cities.  Five passenger ships built at once, assigned to a single line with 1-month wait time.  Started all five ships.  All five ships sail to first port, wait one month, and all depart at once. 

Prissi, based on what you said, should not "only the first ship" try to board passengers, and the other four sit idly by until the first leaves?  That is the desired behavior.  Then the one-month wait time would work more intuitively.

Quote from: inkelyad on December 02, 2010, 05:22:40 AM
Current 'power of 2' waiting time is too rough.

Hmm... Currently we have these approximate wait times:

30 days {1 month}, 15, 7, 4, 2, 1 day {1/32 month}, 12 hours, 6, 3, 1.5 hours {1/512 month}

How about changing that to more exact day and hour intervals?

30, 25, 20, 15, 10, 5, 2 days, 1 day; 12 hours, 6, 4, 2, 1 hour...

Spike

I'd expect that Prissi's change works with "% load" until allowed to depart, not "fixed waiting time".

prissi

First, the time you see in simutrans is different dependent on your setting. A month can be either three days or 28-31 days long. (The first option make sense when you have small number of bit_per_month).

If you left ships sail to an empty harbour, indeed, they will all leave at the same time. But what is the point of letting 5 ships sail, when there are not enough passengers for one ship? If there are enough passengers, to have the first ship part before the others, then gradually a more uniform spacing will occur. I often used that technique and, with the current nightly and waiting queue it works fine.

On a different note: Especially with multiple ships on the same line, a loading limit without waiting time would make much more sense. Like 85% one the more crowded and 50% on the more empty stop. This is also much more meaningful economiywise.

Finally, the waiting time is not a line enforced behaviour, but operates schedule wise. You can have vehicles on the same line with different waiting settings. How would one handle a wiating time in those circumstances? Or if vehicles do not run on lines but individual schedules serving the same destination?

wlindley

The line of five ships, I originally set to minimum 10% load and 1 month wait time.  That is the behavior I reported on.

I tried Hajo's suggestion;  it is true that with a 10% (or 1%) load, and unlimited wait time, that only one ship boards passengers, and the ships then become spaced.

However the reasonable action when both minimum load and maximum wait time, would be as I described: That vehicles not currently boarding should have infinite wait time, and only a vehicle currently boarding would timeout and leave on the maximum wait time setting.

No?