News:

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

Load long distance passengers patch

Started by Markohs, September 25, 2014, 10:22:07 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Markohs

#35
New version, implemented following TurfIt suggestions, and without the bug Vladki commented, and without warnings (no C+11 scoped enum).

In my tests it's working ok, if anyone finds something not working, or has any suggestion, just post it, thanks!!!

https://dl.dropboxusercontent.com/u/30024783/longdistance-6.patch

It's still not saving the info in the savegame, I don't want to corrupt the savegames of nobody, yet. :)

EDIT: I've copiled a version for windows using mingw. It should work, but I'm not responsable of if some weird **** happens to your computer. :) https://dl.dropboxusercontent.com/u/30024783/sim-longdistance.exe

Ters

Quote from: DrSuperGood on September 29, 2014, 11:38:37 AM
"I will not take your tram because this is total rubbish that I must pay for 30 stops to reach one 5 tiles away".

There is a setting for that in Simutrans already, but I don't remember the name at the moment. Passengers will then only pay for 5 tiles, but if the pak set isn't balanced with that in mind, traffic through obstructed terrain will be unprofitable.

Vladki

#37
Markohs - thanks, now the patch seems to behave correctly.

Circular routes (though off-topic here) in simutrans are profitable and effective, but they are not so common in real world. Yes there are some circular routes in bigger cities, but most lines are linear (from the center to the suburbs). And I have never seen a circular intercity line.

UPDATE:
There's one cosmetic thing - the gui option for shor/long distance overlaps with replicate backwards button (see on bus/truck lines)

sdog

Quote from: Markohs on September 29, 2014, 07:11:09 AM
Ok turfit, got it know. You are right, it's a simple solution and easy to understand/read. No additional mem structures. It will perform poorly in schedules I'd say wuth more than 50 stops but that's not a common situation.

It's a long distance loading option. Only local trains would have so many stops. You can just check the number of stops in a schedule and default to the old loading algorithm if it is too large.

Is the STL gcc4 discussion not a bit too fundamental for the thread of a smaller patch project?

Have you tested the behaviour with counter rotating circular lines, serving exactly the same stops?

Quote
Quote"I will not take your tram because this is total rubbish that I must pay for 30 stops to reach one 5 tiles away".

There is a setting for that in Simutrans already, but I don't remember the name at the moment. Passengers will then only pay for 5 tiles, but if the pak set isn't balanced with that in mind, traffic through obstructed terrain will be unprofitable.
I'm surprised that's not turned on by default, I've not played without that option. It would make moving goods around in big loops an artificial mlik cow. But since that is available, such is a balancing problem on the paksets' side, not loading algorithm.


Markohs

Quote from: sdog on September 30, 2014, 12:16:04 AM
It's a long distance loading option. Only local trains would have so many stops. You can just check the number of stops in a schedule and default to the old loading algorithm if it is too large.

That can be done, but I doubt it's really necessary.

Quote from: sdog on September 30, 2014, 12:16:04 AM
Is the STL gcc4 discussion not a bit too fundamental for the thread of a smaller patch project?

Yes it was sightly off-topic (my original patch had C++11 requisites). Anyway it's just a topic I wanted to talk about, just as a rant, because I have already accepted we'll never use STL. I guess it's just a personal point of view from most developers. I just get pissed when I can't even use a stack, a fifo, a set or a simple hash table, and can't understand why I can't.

I just can't understand why we can't use simple tools available to all programmers, because the resulting code is often, without doubt, poor quality code, resulting from not having enough simple tools to use.

Quote from: sdog on September 30, 2014, 12:16:04 AM
Have you tested the behaviour with counter rotating circular lines, serving exactly the same stops?

Well, it's intended for long distance lines, linear ones, where circular lines, don't really make sense building. No player should build them if they want to keep a minimum of similarity with the real world. It's an exploit, imho.

sdog


Quote from: Markohs on September 30, 2014, 01:28:37 AM
I just can't understand why we can't use simple tools available to all programmers, because the resulting code is often, without doubt, poor quality code, resulting from not having enough simple tools to use.
It was recently discussed in this topic:
http://forum.simutrans.com/index.php?topic=4838.0
The reason was not incompatibility with Haiku, that already had a fairly recent gcc (BeOS was stuck at 2.9 or so) but rather consistency within the code. Since I'm not a dev it perhaps not prudent to comment on this, on the other hand it makes me impartial: It is perhaps not the best way to start this as a rant, it is a convention within a scattered group working for more than a decade on this after all. Perhaps it would be a good idea to re-evaluate the arguments of the last debate in the light fo new developments and discuss it there.

ps: It might be enough if there is one Haiku user, when that user happens to be the dev with the longest and deepest commitment to this project.

Quote
Well, it's intended for long distance lines, linear ones, where circular lines, don't really make sense building. No player should build them if they want to keep a minimum of similarity with the real world. It's an exploit, imho.
I wasn't thinking so much about using the new option for that, but on whether it changes its behaviour without it. For bi-directional circular lines boarding the train line that has the shorter distance would be intended behaviour (unless exploiting with aforementioned legacy settings).

DrSuperGood

QuoteThere is a setting for that in Simutrans already, but I don't remember the name at the moment. Passengers will then only pay for 5 tiles, but if the pak set isn't balanced with that in mind, traffic through obstructed terrain will be unprofitable.
QuoteI'm surprised that's not turned on by default, I've not played without that option. It would make moving goods around in big loops an artificial mlik cow. But since that is available, such is a balancing problem on the paksets' side, not loading algorithm.
The result of it being turned on is that taking any form of detour becomes highly unprofitable. All stops have to be direct lines from each other with goods mostly moving positively to make money. Destructive transfers (that move goods away from their destination for convenience) become mostly impossible.

It also results in highly unfair payments as times. That person will still take your trains to ride 20 stops to a station 5 tiles away except now you are footing the bill for his stupidity.

Experimental solves it by allowing passengers to "walk" between stops. In the above case the person will not take the service but instead walk to the other stop as it is "faster". Both the ability to walk between stops and transit time are not in standard.

One solution would be to introduce a variant of "walking" into standard that is different from experimental. On top of a pickup range, stations have a "shortcut" range, probably about 6-8 tiles in size. If a passenger is picked up at a stop and wants to go to a stop within the shortcut range then he will "walk" to that stop (well more like teleport but still) if that stop is more than 1-2 hops down the line. The result is that people will still use your service between stops however if you have any sort of folded loop circuit people will shortcut long distances. However this is for another topic.

prissi

pay_form_distance is 0 in most paks, but 1 for some. With any setting different from 0 the long distance setting will incur a bigger loss than the other. As soon as overcrowding of intermediate stops occurs, even with pay_form_distance=0 will be less profitable since the total number of people to transport is reduced.

If you have a line A-B-C-B, and you want to transport mostly from A to C and back and only when there is something left also for B. The you should stop loading when you encouter the same stop on the schedule, just as it is done now. Otherwise you are just reducing capacity.

But then for long distance, why no go A-C and local A-B-C-B? If you have enough capacity, the old and reverse loading give the same result, if you have not enough either passengers for C or A a A resp. C or with this scheme at B will pile up. But pile up will occur anyway, so the best option moneywise is adding capacity or splitting the line.

As such this feature is imho nothing that should find its way into standard, because it is misleading and will easily lead to more overcrowding (because with the name "long distance" 99% of all user will enable such a switch). And then I read on some sites that simutrans routing is stupid ...

(About Haiku: The problem is rather getting SDL or Allegro to compile on Haiku. GCC4 is working on Haiku, I could run a server quite well.)

Markohs

Quote from: prissi on September 30, 2014, 09:22:40 PM
But then for long distance, why no go A-C and local A-B-C-B? If you have enough capacity, the old and reverse loading give the same result, if you have not enough either passengers for C or A a A resp. C or with this scheme at B will pile up. But pile up will occur anyway, so the best option moneywise is adding capacity or splitting the line.

No, because A-B-C-B and A-C *BOTH* are long distance routes. With A-B and A-B-C-B, you got one of the lines that transverse half the distance.

Quote from: prissi on September 30, 2014, 09:22:40 PM
As such this feature is imho nothing that should find its way into standard, because it is misleading and will easily lead to more overcrowding.

I disagree. Anyway saw this coming.

Quote from: prissi on September 30, 2014, 09:22:40 PM
(because with the name "long distance" 99% of all user will enable such a switch).

I don't think so, our players don't work that way, or shoudn't be able to play a game so confusing to learn like this one, with such a weird and exotic GUI.

Quote from: prissi on September 30, 2014, 09:22:40 PM
And then I read on some sites that simutrans routing is stupid ...

Yet you don't want to change anything.

Quote from: prissi on September 30, 2014, 09:22:40 PM
(About Haiku: The problem is rather getting SDL or Allegro to compile on Haiku. GCC4 is working on Haiku, I could run a server quite well.)

If Haiku can't even properly compile SDL gives us a lot of hints of how inteligent is keep giving support to it.

Now I remember why I stopped contributing to simutrans months ago. This is exhausting, I'm out of here. See you!

Vladki

Quote from: prissi on September 30, 2014, 09:22:40 PM
As such this feature is imho nothing that should find its way into standard, because it is misleading and will easily lead to more overcrowding (because with the name "long distance" 99% of all user will enable such a switch). And then I read on some sites that simutrans routing is stupid ...

If the name "long distance" is misleading, then propose something better. Confusing name is not a good reason to deny a useful improvement.


sdog

Quote from: prissi on September 30, 2014, 09:22:40 PM
But then for long distance, why no go A-C and local A-B-C-B? If you have enough capacity, the old and reverse loading give the same result, if you have not enough either passengers for C or A a A resp. C or with this scheme at B will pile up. But pile up will occur anyway, so the best option moneywise is adding capacity or splitting the line.
This would indeed be useless for a long distance A-B-C and back line that runs along another local A-B-C line. It is rather a local line stopping at A-K-N while a local line runs throug all intermediate stops A-...-K-...-N. I.e. a fast line connecting medium cities and having major cities at its end points, while local lines run mostly parallel and connect with the long distance line at the intermediate cities.

The dilemma comes from the local line loading mostly short haul passengers, and is mostly empty when it arrives at K, thus it has enough free capacity to pick up most pax at K. The express train loads the shortest distance pax first, to K, when it arrives there, the pax to N are already removed by the local train and it continues below full capacity. In large passenger networks there seem often not much ways around this or similar problems. Especially with the small margin between overcrowding stations and running trains below a profitable utilization.

Quote
As such this feature is imho nothing that should find its way into standard, because it is misleading and will easily lead to more overcrowding (because with the name "long distance" 99% of all user will enable such a switch). And then I read on some sites that simutrans routing is stupid ...
While I find the patch quite useful, I think this is a point that can't be dismissed with a shrug, it ought to be considered. SImply naming it differently might not be enough. Maybe a more abstract word, that sounds less attractive? "inverted loading order"
(@Markohs, he would read that when people confuse the settings of that patch.)

Btw, why not fifo loading? That seems to  be by far the most realistic loading pattern. Who's first at the station, has the best position to get on an overcrowded train.

Oh dear, sometimes i think simutrans needs a middle ground between experimental and a more pro version. Not that it is very desirable, especially as people always seem to activate 'pro' settings the first thing.


while this is remotely on topic, it might not be helpful, but delightful:
Les Vacances de monsieur Hulot (boarding a train)
http://www.youtube.com/watch?v=0n0g8S3aA0o

Ters

Quote from: prissi on September 30, 2014, 09:22:40 PM
But then for long distance, why no go A-C and local A-B-C-B?

Because A-B-C-B wouldn't be local. The lines might also be something like A-B-C-D-E-F-G (local) and D-E-X-Y (intercity). Another issue, is that most of the traffic might be between A and B. Alternative solutions for this is to have the lines A-B and B-C, or A-B and A-C, but that may look strange. The latter one might even run into capacity problems at A.

Quote from: sdog on October 01, 2014, 01:06:27 AM
Btw, why not fifo loading? That seems to  be by far the most realistic loading pattern. Who's first at the station, has the best position to get on an overcrowded train.

We've discussed that. It doesn't work sensibly without an complete redoing of how Simutrans tracks freight, which would also require more memory (we might be talking orders of magnitude, including save game size) and processing power.

prissi

Experimental does this even much worse (i.e. does not merge pakets).

It would add at least 4 bytes per packet (since the freelist does chunks of 4) to 16 bytes. I saw games with 10 millions packets, meaning 40 MB more meory. That is not so bad, also 16 is probably close to a cahceline read anyway.

Markohs

Move this to denied patches, please, admins. Thank you!

DrSuperGood

QuoteIt would add at least 4 bytes per packet (since the freelist does chunks of 4) to 16 bytes. I saw games with 10 millions packets, meaning 40 MB more meory. That is not so bad, also 16 is probably close to a cahceline read anyway.
As it is, I recall goods packets utilize bit fields to try and save space. Many modern compilers completely ignore these (unless some specific options or macros are used) due to their poorly defined and difficult memory model. As such you may already find that the structure is bigger than intended!

The bigger packet size/more packets should be of little concern if transport restrictions are in place. The big problem currently is that it is very easy to end up with a transfer with >1 million passengers waiting, especially in multiplayer where you often do not spot it for several game years.

sdog

Quote from: DrSuperGood on October 02, 2014, 01:37:02 PM
The bigger packet size/more packets should be of little concern if transport restrictions are in place. The big problem currently is that it is very easy to end up with a transfer with >1 million passengers waiting, especially in multiplayer where you often do not spot it for several game years.

Perhaps goods/pax ought to decay, ie having an upper limit of travel time.

Ters

Quote from: sdog on October 03, 2014, 05:04:02 PM
Perhaps goods/pax ought to decay, ie having an upper limit of travel time.

But then the packets get even bigger and more processing is required, although depending on how it's done, it might be less than that required by very many packets. Unless players want to have huge waiting queues.

prissi

1 Million passengers waiting to 100 destinations are only 100 packets. Merging packets is very efficient. You can still age waiting times when merging by averaging with the pasengers number. (Same system used by old pocket calulators to do statistics with only two memory cells).

Ters

Were we not discussing a situation where packets are not merged?

isidoro

I guess that what Prissi intends to say is that you can have an intermediate solution.  FIFO schedule is a priority based algorithm, being priority the waiting time in this case.  So, if we have six passengers waiting:
Passenger (1) wants to go to A and have waited 12 minutes
Passenger (2) wants to go to B and have waited 10 minutes
Passenger (3) wants to go to B and have waited  8 minutes
Passenger (4) wants to go to A and have waited  7 minutes
Passenger (5) wants to go to A and have waited  5 minutes
Passenger (6) wants to go to C and have waited  2 minutes

Passengers are loaded based on waiting time: (1), (2), (3), (4), (5), and (6), stopping when the vehicle is full.

If we merge packets, we have three of them:
First packet: (1),(4),(5) want to go to A and have waited 8 minutes each in average
Second packet: (2),(3) want to go to B and have waited 9 minutes each in average
Third packet: (6) want to go to C and have waited 2 minutes each in average

The load order is, therefore, second packet, first packet and third packet.

It is evident that if you merge packets you save a lot of resources (memory, for instance).  And, besides, Simucitizens aren't individuals with name.  So, it doesn't matter if we load (1), (4) or (5).  It only matters the number of them and the destination...

It is not FIFO, but maybe it is better that always loading in the same order, isn't it?


Ters

Quote from: isidoro on October 03, 2014, 11:20:15 PM
It is not FIFO
Exactly. What I was writing about was however FIFO, plain and true.

Quote from: isidoro on October 03, 2014, 11:20:15 PM
but maybe it is better that always loading in the same order, isn't it?
Maybe, just like the long distance priority option. I do however think the latter will behave (much) better when used right, while the former will look somewhat better (although passenger 1 might still be stuck waiting for a long time) and doesn't require intervention. Reality is probably somewhere in between.

sdog

I thought of discarding goods/pax as a way of limiting the number of packets.
But i haven't thought it through. James had to go through all the hoops of the refunds, to facilitate discarding of goods/pax packets. Without it would open the gates for blatant cheating transport almost to the consumer, get payed and let it rot there. I don't think that would be desired very much for standard simutrans.


With isidoro's fifo the same thing happens as happens now, vehicles often get loaded with pax for one destination only.

Could packets be instead randomly broken up? For example when a vehicle is loaded a chunk of its capacity is (pseudo)-randomly assigned as the maximum for the next packet. If the next packet, perhaps choses as isidoro suggest is larger, it will be split in one that is transported and one that remains. That would increase the number of packets not terribly much (what would it matter if there are thousands or ten-thousands?).

Perhaps pseudo-random is good enough for loading, and very realistic: A Chinese bus stop rather than one in London. The position in the queue is irrelevant, as there are always old ladies with very bony ellbows.

DrSuperGood

A refund mechanic would be very useful for my JIT2 implementation. I decided to enforce maximum input storage of industries (only in JIT2 mode, classic modes not affected). The current mechanic I use is to discard excess goods and apply a demand buffer penalty of the amount discarded. However I noticed that the function that is called to receive goods returns the amount consumed (or -1 if nothing was accepted) so I made the return amount reflect the amount actually consumed hopefully allowing for some kind of refund mechanic later.

Also expiring cargo and such would be very useful to stop the current infinite send issue with JIT2 (since it cannot detect overfull transfers).

A simple expiration method could be based on stop storage capacity and current amount. When a stop becomes more than a certain fraction full (like 125%) then cargo starts to be discarded periodically. If you have FIFO tracking of cargo packets then you discard part of the oldest packets that are of the type overfilling the stop. When cargo is discarded then some penalty is incurred, be it financial, order logic or even preference (who they choose to use in the case of multiple paths).

However, another approach which does not need discarding mechanics at all is simply to use transfer restrictions like "no route over crowded" with possibly some enhancements. With JIT2 mechanics it is easy to have complex industry networks while maintaining a low and steady in-transit amount so overfilling stops is not an issue. The only issue is from dealing with >50k passengers per month in some transfer stops which can fluctuate heavily with time (as there is no time-tabling in standard...). Currently there is no way to get a reasonable storage amount for them outside of paving a large part of the map with storage structures. However if cheaper and larger storage structures were made available in paksets (possibly removing the hard-coded storage amount to cost ratio) then one could have a higher storage density per tile to compensate. Under these conditions transfer restrictions could be used which mostly remove the need for discarding as no more will be generated in the case of transfer crowding.

Markohs

I know I use to steal some discussion threads and derail them, but aren't you guys getting a bit off-topic here? Just move this thread to denied patches and open a new thread to discuss that, there. :)

Ters

Quote from: sdog on October 04, 2014, 03:15:14 AM
Could packets be instead randomly broken up? For example when a vehicle is loaded a chunk of its capacity is (pseudo)-randomly assigned as the maximum for the next packet.

That would primarily be a cosmetic improvement. It would have some effect on the A-B & A-B-C problem, but I think the random factor would both improve and degrade the situation in equal amount. The A-B & A-B-C problem is itself random, based on arrival of passengers and arrival of vehicles serving the two lines.

Quote from: sdog on October 04, 2014, 03:15:14 AM
I thought of discarding goods/pax as a way of limiting the number of packets.
But i haven't thought it through. James had to go through all the hoops of the refunds, to facilitate discarding of goods/pax packets. Without it would open the gates for blatant cheating transport almost to the consumer, get payed and let it rot there. I don't think that would be desired very much for standard simutrans.
Quote from: DrSuperGood on October 04, 2014, 04:29:49 AM
A refund mechanic would be very useful for my JIT2 implementation. I decided to enforce maximum input storage of industries (only in JIT2 mode, classic modes not affected). The current mechanic I use is to discard excess goods and apply a demand buffer penalty of the amount discarded. However I noticed that the function that is called to receive goods returns the amount consumed (or -1 if nothing was accepted) so I made the return amount reflect the amount actually consumed hopefully allowing for some kind of refund mechanic later.

If there is goods to pick up, you should get payed for delivering it, no matter what. If consumer is full, that's it's problem, not the carrier's. For goods and mail, it doesn't make as much sense to get payed for getting it half way there, but not further. No routing over overcrowded will pretty much eliminate the cheat of getting payed for only transporting things half way there. If speed bonuses also included waiting at intermediate stations, and possibly also the initiall station, one wouldn't really be allowed to let things just lie waiting at stations unless the goods explicitly allow it (virtually no speed bonus). It would make it a lot more risky to let the game run without paying attention all the time, though. Tracking waiting time at stations properly also means less merging of packets.

Quote from: Markohs on October 04, 2014, 04:51:39 AM
I know I use to steal some discussion threads and derail them, but aren't you guys getting a bit off-topic here? Just move this thread to denied patches and open a new thread to discuss that, there. :)

This discussion spun out of a help request before you started on your patch, which was only one of several possible solutions. To avoid having to start another discussion, and having to repeat all the arguments a third time, since nobody bothers going back to the parent discussion(s), it might be better to just rename this one. And I haven't given up on a long distance option, even though I haven't had the time to actually look at it yet.

DrSuperGood

QuoteIf there is goods to pick up, you should get payed for delivering it, no matter what. If consumer is full, that's it's problem, not the carrier's
Not if a small fast food outlet orders fresh meat in units of 5 with a storage of 40 units to find that you sent a 700 unit train filled with all their orders. I am pretty sure in real life there would be complaints and refunds, or at least a change in transport provider.

Currently the behaviour is to just discard the excess goods with no financial penalty (they were thrown away). The amount discarded is then subtracted from the demand buffer to act as a penalty. It appears to work alright but more people need to test it (only 2 have downloaded the patch).
Quote
If speed bonuses also included waiting at intermediate stations, and possibly also the initiall station, one wouldn't really be allowed to let things just lie waiting at stations unless the goods explicitly allow it (virtually no speed bonus).
Problem is no standard pakset is balanced for this. The lack of financial controls for convoy income with the current speed bonus model would make balancing basically impossible. For example, a high speed train would literally need to push passengers at full speed most of the time to break even as the average speed will be nowhere near the convoy maximum speed (you can see this in experimental). It would also need timetabling to minimize wait time as otherwise the bus clump problem would cause a huge variance in wait times. It would also up the games difficulty considerably which might not be a good thing.

Ters

Quote from: DrSuperGood on October 04, 2014, 11:31:51 AM
Not if a small fast food outlet orders fresh meat in units of 5 with a storage of 40 units to find that you sent a 700 unit train filled with all their orders.

The thing is that the producer should never have loaded more than 40 units on the train to begin with. This becomes a bit more complicated when the goods is reloaded along the way, but that's the basic premise. I thought this was part of what your JIT2 thing was about.

Quote from: DrSuperGood on October 04, 2014, 11:31:51 AM
Problem is no standard pakset is balanced for this. The lack of financial controls for convoy income with the current speed bonus model would make balancing basically impossible. For example, a high speed train would literally need to push passengers at full speed most of the time to break even as the average speed will be nowhere near the convoy maximum speed (you can see this in experimental). It would also need timetabling to minimize wait time as otherwise the bus clump problem would cause a huge variance in wait times. It would also up the games difficulty considerably which might not be a good thing.

The way speed bonus works would have to be changed somewhat. But if you didn't notice, I wasn't exactly arguing for the idea myself. It was just a stray thought.

DrSuperGood

QuoteThe thing is that the producer should never have loaded more than 40 units on the train to begin with. This becomes a bit more complicated when the goods is reloaded along the way, but that's the basic premise. I thought this was part of what your JIT2 thing was about.
It orders at the rate at which it consumes down to the smallest ordering granularity possible (it will order for at least 1 full distribution cycle). However nothing stops Mr. Bad Transport Manager from ordering a 700 unit train to "load to 100%" and shipping directly to the consumer. Nothing stops one from doing this in real life as well except that it makes no economic sense and that someone at the consumer will complain that their shop has just been buried under 700 tons of goods. As such I represent it as an inefficiency in the supply line that will cause imperfect consumption.

However with JIT2 you could also send out appropriately sized trucks to carry the food and "load to 100%". They will evenly space out and the consumer will never overflow. This currently is not easily done requiring a large amount of fine tuning and cannot scale. Basically in JIT2 consumer ordering pattern becomes a high frequency pulse width modulation behaviour insuring a constant flow of goods unlike the current order mechanic which is a very low frequency pulse width modulated behaviour. JIT2 never over orders where as JIT classic has nothing to stop you from maxing out as much in transit as you can. Neither deal with the fact that you can use an inappropiatly sized convoy to ship to end consumer. It might also be the case that the pakset just has the end consumer set to accept too little (pak64 food marketplace has less canned food storage than the smallest end game convoy can deliver).

Ters

Quote from: DrSuperGood on October 04, 2014, 06:01:07 PM
However nothing stops Mr. Bad Transport Manager from ordering a 700 unit train to "load to 100%" and shipping directly to the consumer. Nothing stops one from doing this in real life as well except that it makes no economic sense and that someone at the consumer will complain that their shop has just been buried under 700 tons of goods.

No, in real life, the producer simply won't fill the train and it will just end up sitting there. If the consumer is buried, it will complain to the supplier. The carrier has only transported what the supplier has ordered it to transport, and won't be held responsible. (The transporter might be held responsible for late delivery, though, which is what speed bonues tries to deal with.)

But this is something completely different from what this discussion is about, which is passenger loading priorities.

DrSuperGood

There needs to be some form of upper limit to concurrent passengers on a map. I have had the crazy situation where 1 transfer has more passengers waiting than there are people living on the entire map. I then clicked another 5 transfers to see that they also had similar numbers! Yes I was not a good transport manager (well people advanced the server a lot when I was not there) however there still needs to be some kind of logical limit.

Maybe each building could only send at most X passengers at a time? What I am talking about is a token system where by each passenger generated from a building consumes a token. When the passenger arrives at its destination (or is discarded via some form of expiry mechanic or due to a line closure) then the token is refunded. The number of tokens depends on the population the building represents to some degree. Not all tokens have to be sent at any given time (traditional passenger spawn mechanics still apply) just they are there to limit the number created from a single structure to provide a more realistic limit.

ronnie89b

Hi!
I want to try this patch, but i don't know how. I tried compile the game for myself, but it's not working(I'm very inexperienced in this case).
Won't this patch include into a nightly version?

Ters

Quote from: ronnie89b on October 08, 2014, 08:12:22 PM
Hi!
I want to try this patch, but i don't know how. I tried compile the game for myself, but it's not working(I'm very inexperienced in this case).
Won't this patch include into a nightly version?

Since development continues on trunk, it is possible that this patch won't apply to the current code without some manual work.

If what you're asking for is whether this will be available in a nightly build, you should notice that the patch has been abandoned, possibly in an unfinished state, by it's author for apparent lack of support from the other developers. The option might be more confusing than useful. I might try to pick it up one day, if only to see if it really solves the problem it's supposed to, but I'm very unpredictable in what I do.

Markohs

You got a binary here: https://dl.dropboxusercontent.com/u/30024783/sim-longdistance.exe .

Anyway this change it's not going to be incorporated ever on the game (it's been rejected by the project leader), so just use it for your personal tests.

Quote from: Ters on October 08, 2014, 09:30:49 PM
...by it's author for apparent lack of support from the other developers. ...

Not really, it's just about prissi is against this change and as you know, nothing can be changed if he doesn't agree. Anyway if you decide to investigate this further in the future, I wish you good luck.

Ters

Quote from: Markohs on October 09, 2014, 01:16:58 AM
Not really, it's just about prissi is against this change and as you know, nothing can be changed if he doesn't agree. Anyway if you decide to investigate this further in the future, I wish you good luck.

As far as I can see, there seems to be about two developers for and two against, although they may not actually have decided on a final vote. At least two major developers haven't stated their opinion. (They have been rather absent from the forum lately.) So it's blocked democratically, not through some dictatorship.

ronnie89b

I downloaded the binary by Markohs, then put it in the simutrans folder. I got a "missing dll" message.(libbz2-2.dll)
What should i do?