M****ively negative "distance" and corresponding costs July 01, 2010, 07:54:07 pm I've been playing a map (pak64) for a few (in-game) years, and have noticed an odd pattern in some of my lines. Some of my lines (mostly bus lines, but some trains too) fluctuate wildly in the profit they deliver, despite the fact that their p****enger numbers, revenue and running costs stay constant. We're talking some months a profit of -5,000 for a city bus route which runs vehicles with cheap maintenance costs. And this despite the fact that each individual convoy on the line shows a profit.I was baffled for a while, until I noticed that the readings in the "Distance" graph in the line management box showed very odd figures which correlated with the profit and loss of these vehicles. Specifically, the "distance" value is often very, very far below zero -- in one case, -1,639,241. This seems confusing to me -- doesn't the "distance" value record how far convoys on that line have travelled? If not, how does "distance" end up negative, and how can I prevent this from happening?Thanks in advance! Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #1 – July 01, 2010, 08:03:05 pm Those extremely high costs are likely refunds for money spent at a long distance line. This is an effect of too high travel times. The p****engers time out in your buses and then incur the cost at that line. This is a bit in-transparent at the moment. As soon as the refund plot for convois is functional this will be easier to spot. (btw James, i think a global refunds diagram, would be necessary)The way to cure it is to streamline your local transport and create some overcapacity. Second step create fast long range links. Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #2 – July 01, 2010, 08:05:46 pm Ok, thanks. On the lines in question, "refunds" are always at zero, so that seems rather strange. Also, how does this explain the odd values in "distance"?Also -- what makes a travel time "too high"? Is it set by the limits in simuconf.tab? Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #3 – July 01, 2010, 09:44:31 pm maximum travel times are limited in experimental, the values are in simuconfig indeed.i don't know how recent the files is in your install, you can compare and perhaps try it with the one from the development branch for example: http://github.com/jamespetts/simutrans-experimental/tree/devel. Alternatively you can play around with the values. The 8.2 file should be ok already. 8.0 had way too low values.With 8.2 it's challenging, but it is doable with pak britain. I'm constantly fighting with delays all of the time, a single stuck side line can bring down my profits from +50k$ to -50k$Code: [Select]# P****engers have a maximum tolerance level for how long that they will# spend travelling. The further that the p****engers want to go, the more# time that they will be prepared to spend travelling. The number is # expressed in minutes. For each packet of p****engers, the number of # minutes travelling time (including waiting time) that they are prepared# to tolerate is randomised between the minimum and maximum amount. The# local, mid-range and long-distance p****enger groups correspond to those# above. min_local_tolerance = 35max_local_tolerance = 90min_midrange_tolerance = 60max_midrange_tolerance = 240min_longdistance_tolerance = 150max_longdistance_tolerance = 2160 Quote Selected Last Edit: July 01, 2010, 09:47:41 pm by sdog
Re: M****ively negative "distance" and corresponding costs Reply #4 – July 01, 2010, 10:20:53 pm Thanks! So am I to understand that, if someone arrives at a destination and it's taken too long, that they receive a refund for their whole journey (all legs)? This would explain why the loss levels of some lines are so much higher than the revenues of those lines taken by themselves. However, if this is the case, then the data in "Line Management" appears to be broken, since my charts display no refunds and instead seem to record this data in the "Distance" chart -- and even then, it's not clear what the metric is. Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #5 – July 01, 2010, 11:28:36 pm As i understood, yes. I think the refund graph is not functional yet.The negative way traveled, is striking indeed. It could very well be an artifact from the refund system though. This would happen if the route to the p****engers origin is checked when it is deleted after timeout. The refund would be based on this route then, and the negative distance would be visible at the line. This is just a guess however, i don't know how james implemented the refund system. Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #6 – July 02, 2010, 10:20:07 pm Jha4ceb,thank you for your post. This seems to me like a bug (integer overflow), not an artefact of the refund system. The refund system and graph is indeed fully functional in 8.x. Do you think that you could upload your saved game so that I could try to reproduce and fix the bug? Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #7 – July 02, 2010, 11:29:32 pm Looking at the symptoms, there might be a refund display related problem: Firstly the refunds are always for any line 0 for me, even when i artificially cause m****ive delays and witness p****engers disappear.The m****ive negative distance happens mostly at slow lines, at the fringes. I never have this at the efficient tram lines inside the directly linked large cities.The losses in the balance would fit well to the refunds, they correspond directly to the profit of my network, and get more severe if some parts are stuck.I can try to play with the refunds factor (now 1.5, earlier 2, to see if it influences the loss or the distance chart.)The values in the negative distance chart are way to high to be the distance back to the origin, the refund is based on. Perhaps the values are overwritten by refunds? Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #8 – July 03, 2010, 09:44:03 am Sdog,thank you for the analysis. It is possible, I suppose, that there is a bug whereby, as you suggest, distance values are over-written with refund values. Does this occur only after saving/loading, or all the time? Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #9 – July 03, 2010, 09:51:36 am Here's my saved game:http://www.mediafire.com/file/njmiiezyly2/Third.sveYou should be able to observe the phenomenon on any of the lines that aren't making a profit. Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #10 – October 14, 2010, 02:59:39 pm Hi guys,I'm a newbie and I have noticed exactely the same phenomenon occurring in my game (SimutransEx8.2 with PakGermanExp), as described by jha4ceb in this thread. Now the discussion abruptly ended...Has it moved to somewhere else?What could be done to make the game playable? sorry, in developing and solution finding i'm not gonna be of great help, as i'm not into informatics or design... i just love to play with trains and buses and stuff =)Thanks and cheers!ps. in my first post i also want to notice that i had terrible fun playing simutrans standard with different paksets... and simutrans experimental from the idea promises so much! jamespetts did an amazing job and implemented exactly the changes i had wished for, when i was still unaware of the experimental brach... and generally thanks for your work! Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #11 – October 14, 2010, 04:31:11 pm I've solved this problem by simply serving the lines with more frequent vehicles. Once the service is frequent enough, the distance will return to positive figures. Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #12 – October 16, 2010, 09:43:01 am Hi, thanks for the advice. I tried out just having more vehicles for the routes that show such tremendous negative distance and profit values, however I'm not happy with it: Often the lines that show this behaviour are very small train or smaller bus lines (with up to -6000 monthly profit). At the point where values of distance turn to positive when I buy more vehicles for that line, the vehicles are sometimes less than 5% filled, in average, and the resulting deficit is quite impressive for that reason (up to -2000 monthly with 7 buses on a small line). Also, this behaviour seeems very difficult to anticipate, as profit changes drastically from month to month even without changes in game. Secondly, to alleviate the problem with the idea of making p****engers more tolerant to fine me for delays, I changed the following code in simuconf tab:min_local_tolerance = 35max_local_tolerance = 90min_midrange_tolerance = 60max_midrange_tolerance = 240min_longdistance_tolerance = 150max_longdistance_tolerance = 2160to min_local_tolerance = 35max_local_tolerance = 200min_midrange_tolerance = 60max_midrange_tolerance = 500min_longdistance_tolerance = 150max_longdistance_tolerance = 4000so doubling the maximal tolerance.It did however only have an effect on some lines with negative distance and profit. On the other hand, profits and revenue of my (more or less fast but quite profitable) main lines dropped considerably down to ca. 50% which in turn is quite an unexpected and problematic behaviour to me.So in the end, I wish just to turn down the level of fines. In previous posts in other threads I red that the value is set to 1.5 currently and I want to set it down, to see the behaviour of this change. Probably with Value=1 the fining shouldn't work, so I'll try that out first.But: Where can I find and change this value? I didn't find it in simuconf.tab...Probably others have already tried that out... did it work?Thanks again and cheers!grainwatsky Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #13 – October 16, 2010, 02:31:50 pm That's interesting. I've found a similar effect as you describe -- if I saturate lines with buses, then it's difficult to make the line break even. But the loss is usually small and far less than the previous fines, and I usually chalk it up to the philosophy that almost every transport system will have a few loss-making lines which exist for the purpose of feeding the profit-making ones.However, I think that this feature reflects two problems with the game:1) In Experimental, p****engers are very intolerant of lines that are not *very* frequent. I find that on almost every train line I am forced to run a "subway"-style service -- a train every few minutes (or the equivalent of) -- or my p****engers will start to become unhappy and fine me. But this often results in running almost empty trains on some routes. This seems unrealistic: many real-life minor lines have a less-than-hourly service. It seems to me that such a service would be impossible to run profitably on Simutrans Experimental. To my mind, p****engers need to be more tolerant of waits. I know that this can be adjusted to a certain degree in simuconf -- but it seems to me that there is a more fundamental problem here than simply tampering with the variables.2) As you note, the fines are very extravagant by default, resulting in huge losses for very small lines. One more note on your use of the "tolerance" parameters to alter this. I was under the impression that those lines control whether a p****enger will embark on a journey at all -- i.e. if a local journey will take more than 90 mins then they won't even bother. Have I got this wrong? Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #14 – October 16, 2010, 03:32:56 pm Quote from: jha4ceb – on October 16, 2010, 02:31:50 pmbut it seems to me that there is a more fundamental problem here than simply tampering with the variables.Well, simutrans p****engers can't predict 'there will be fast train in 30min, let's go to bus', they want travel 'right now'. As I understand, it can't be easily fixed. Quote Selected
Re: M****ively negative "distance" and corresponding costs Reply #15 – October 16, 2010, 03:35:59 pm Exactly. What I should have said, then, is that the way the game is set up means it will necessarily be unrealistic in this way. I guess that in playing we just have to work around it. Quote Selected