JGR's Patch Pack

[SirVictor]

I'm playing the patch through WINE and it worked perfectly well, except from the music. The general sound effects play normally but the music doesn't. I have separated files, one for JGRpatch and one for the default OpenTTD (up to date) where the music plays normally. I had this same problem in the base game before but followed the troubleshooting (download Timidity) and it worked well. There is a fix for that? As I said, the game works perfectly well but I miss some music action sometimes, so it is not a problem if there isn't a fix.

And sorry if this is a stupid question but the patch is "separated" from the game? I run JGRPatch on a different file so I have a launcher for it and one for the base OpenTTD. Is the patch "updated" to 1.9.3 or it works like a different stance or something like that?

[Auge]

Hello

I'm playing the patch through WINE and it worked perfectly well, except from the music. The general sound effects play normally but the music doesn't. I have separated files, one for JGRpatch and one for the default OpenTTD (up to date) where the music plays normally. I had this same problem in the base game before but followed the troubleshooting (download Timidity) and it worked well. There is a fix for that? As I said, the game works perfectly well but I miss some music action sometimes, so it is not a problem if there isn't a fix.

If you run your computer with Linux, compile the patchpack directly in Linux without using the detour over Wine (with the Windows-version of JGRPP). If the configure script finds timidity, it tells the compiler to compile the program with music support.

And sorry if this is a stupid question but the patch is "separated" from the game? I run JGRPatch on a different file so I have a launcher for it and one for the base OpenTTD. Is the patch "updated" to 1.9.3 or it works like a different stance or something like that?

The patchpack is a separate version and instance one can run separately or beside a "normal" OpenTTD installation.

Tschö, Auge

[MagicBuzz]

Hello,

I have two small suggestions about the feature "template replacement".

Firstly : better integration with subgroups
Currently you can set a template replacement for a group that contains subgroups.
But the template replacement will replace only the vehicles directly contained in the group, not the subgroups.
=> I think it should be better if the template was applied to any vehicle in subgroups (recursive) unless there is actually another template affected to the subgroup.
This is the way the trunk feature "vehicle replacement" works.

Secondly : better coherence between "vehicle replacement" and "template replacement"
I always play with breakdown disabled, so there are never depots in my orders.
If I set a vehicle replacement, then all my vehicle will try "as soon as possible" to upgrade in the nearest depot along their current route.
But if I set a template replacement, I need to send them manually to the depot in order to upgrade them.
=> I think it should be better to have the same behavior with the two features. IMO the behavior itself for the two features should be configurable (replace old only, replace as soon as possible, replace only when sent to depot) but eh... Christmas is in 350 days now...

[Diesel Power]

Would it be possible to add another conditional order option? "Jump to order # if loaded with cargo X is true/false." Would make multi cargo trains skip visiting unnecessary stations. If seem this in the route restrictions on signals and think it would be more useful as a conditional order.

Thanks!

[mrjack2]

Hi, I have a few thoughts with regards to automatic timetabling, particularly with how it interacts with either auto-separation or scheduled dispatch under conditions of strain (high frequencies / conflicting traffic / long routes).

Firstly, I strongly see the logic of it favouring negative adjustments (shorter times) for time between stations, because I've seen how positive feedback loops of travel times and delays can lead to a station getting completely gummed up. However, for waiting time at stations, I think the reverse should occur, with positive adjustments strongly favoured. The reason for this is that the automatically generated waiting times are always un-useably low, and I have to set them manually. Essentially, waiting times need to be long enough such that a late train (which will run fuller than an on-time train, and therefore has to wait longer) can catch up to its timetable. Unlike travel times, positive bias for waiting times isn't going to cause feedback loops, as far as I can make out. The extent of the positive feedback could be decided by a setting (ideally per train group rather than a game setting), e.g. I might want to set my waiting times to the 90th percentile, so 10% of trains stop for longer and 90% shorter.

Secondly, for my purposes the most useful time between the stations is the shortest possible one, to the extent that I would have the travel times *never* increase (and simply represent the shortest time which has been achieved over a section of track since it was untimetabled). At present I still have to be extremely careful when upgrading trains / adding more, because positive feedback loops still occur and gum up a whole line. My trains run on physically separated tracks with essentially no alternate routes, so it would be a pile worse for more complex running patterns or trying to mix freight traffic onto the same line. For situations like those where trains are much more likely to get interrupted, I wonder if the scheduled time could be the minimum time plus a slack time, e.g. 10%, configurable? E.g. with minorly mixed traffic I might attempt to run at 110% travel times, in heavier traffic I might attempt 125%? That way the positive feedback loop could be avoided while still giving space for varied travel times.

These suggestions are from wanting it to be even more set-up-and-forget -- at present when I get new trains and need a new timetable, I have to come back to the same trains several times when frequencies are close to the limit, e.g. to turn timetable automation off once I have a good timetable running well, or to increase station waiting times if late trains aren't catching up.

[JGR]

Hello,

I have two small suggestions about the feature "template replacement".

Firstly : better integration with subgroups
Currently you can set a template replacement for a group that contains subgroups.
But the template replacement will replace only the vehicles directly contained in the group, not the subgroups.
=> I think it should be better if the template was applied to any vehicle in subgroups (recursive) unless there is actually another template affected to the subgroup.
This is the way the trunk feature "vehicle replacement" works.

Quite possibly you are the first person who has ever wanted to do that.
Recursive behaviour seems reasonable enough.

Secondly : better coherence between "vehicle replacement" and "template replacement"
I always play with breakdown disabled, so there are never depots in my orders.
If I set a vehicle replacement, then all my vehicle will try "as soon as possible" to upgrade in the nearest depot along their current route.
But if I set a template replacement, I need to send them manually to the depot in order to upgrade them.
=> I think it should be better to have the same behavior with the two features. IMO the behavior itself for the two features should be configurable (replace old only, replace as soon as possible, replace only when sent to depot) but eh... Christmas is in 350 days now...

Seems sensible enough. I for one always have at least one depot order for every vehicle, so this hasn't been an issue for me.
It is simple enough to implement the behaviour, the main difficulty is finding a sensible way to put it in the UI.

Would it be possible to add another conditional order option? "Jump to order # if loaded with cargo X is true/false." Would make multi cargo trains skip visiting unnecessary stations. If seem this in the route restrictions on signals and think it would be more useful as a conditional order.

Thanks!

It would seem better to me if it was extended to: "Jump to order # when Load percentage of cargo X operator value", to match the existing load percentage conditional.

Hi, I have a few thoughts with regards to automatic timetabling, particularly with how it interacts with either auto-separation or scheduled dispatch under conditions of strain (high frequencies / conflicting traffic / long routes).

Firstly, I strongly see the logic of it favouring negative adjustments (shorter times) for time between stations, because I've seen how positive feedback loops of travel times and delays can lead to a station getting completely gummed up. However, for waiting time at stations, I think the reverse should occur, with positive adjustments strongly favoured. The reason for this is that the automatically generated waiting times are always un-useably low, and I have to set them manually. Essentially, waiting times need to be long enough such that a late train (which will run fuller than an on-time train, and therefore has to wait longer) can catch up to its timetable. Unlike travel times, positive bias for waiting times isn't going to cause feedback loops, as far as I can make out. The extent of the positive feedback could be decided by a setting (ideally per train group rather than a game setting), e.g. I might want to set my waiting times to the 90th percentile, so 10% of trains stop for longer and 90% shorter.

Secondly, for my purposes the most useful time between the stations is the shortest possible one, to the extent that I would have the travel times *never* increase (and simply represent the shortest time which has been achieved over a section of track since it was untimetabled). At present I still have to be extremely careful when upgrading trains / adding more, because positive feedback loops still occur and gum up a whole line. My trains run on physically separated tracks with essentially no alternate routes, so it would be a pile worse for more complex running patterns or trying to mix freight traffic onto the same line. For situations like those where trains are much more likely to get interrupted, I wonder if the scheduled time could be the minimum time plus a slack time, e.g. 10%, configurable? E.g. with minorly mixed traffic I might attempt to run at 110% travel times, in heavier traffic I might attempt 125%? That way the positive feedback loop could be avoided while still giving space for varied travel times.

These suggestions are from wanting it to be even more set-up-and-forget -- at present when I get new trains and need a new timetable, I have to come back to the same trains several times when frequencies are close to the limit, e.g. to turn timetable automation off once I have a good timetable running well, or to increase station waiting times if late trains aren't catching up.

I can see the logic of using a different bias for waiting times than for travel times. I'll look into that.

Percentile based settings are a bit problematic as this effectively requires storage of the history of previous values, which so far has been avoided.

I think that where possible it'd be better to try to calculate something sensible than expect the user to have to tune too many settings or per-vehicle knobs, though this is not always practical.
The timetable window is already a bit problematic due to the plethora of buttons. Adding more per vehicle/order list settings/modes would likely require a UI rethink.
Padding wait times would not be technically difficult.

Not increasing travel times at all is potentially problematic as this can lead to the case where trains are perpetually late-running.

From a gameplay point of view, timetables can only do so much. It is worth having a little slack in platform capacity and/or track layout to handle disruption.

[Pascal]

Code: Select all

Add setting for alternative transfer payment mode.

It's not completely clear to me how this new system works. I'm looking into setting up a server with a few people with the highest daylength, and to work with infrasharing. Ideally, every trip would be paid fully for that trip, like it would be in real life. After all, the bus company asks me the same amount of money no matter how long I've been waiting in the train and how far I've traveled before that time. Is the new behaviour like this, or not? If not, is it possible such a payment behaviour could be added as an option in the future?

[ino]

The default game payment is that the cargo get paid depend on the distance between origin and destination station and the time taken (not counting transfer time), no matter the route it takes.

This creates problem in feeder system and multileg passenger system, because only the final vehicle got the payment, so other vehicle in the chain got negative balance.

That's where the transfer system come in. If the vehicle is ordered to transfer, that vehicle get credited for the cargo payment calculate using the origin and destination of that vehicle, multiply by the transfer percent (default 75%). Note the word credited. No money is actually being paid, it just get credited to the vehicle so the vehicle balance would look better (i.e. not negative). The credit is attached to the cargo, and when the final payment is made when the cargo arrive at the destination, the actual payment minus the transfer credit is added to that vehicle profit.

This can easily make the final vehicle seems to be in deep debt, especially if it's bus or truck. So the "alternative payment" is will calculate the transfer credit using cargo origin instead of that leg origin. It helps somewhat, but not all.

What you are asking for might be possible, but I believe that would create overblown profit interaction in feeder system or in ICE passenger where passenger transfer between high speed and local train. Not to mention easily exploit.

I am not sure how cross company transfer work in infrastructure sharing.

At least, this is my understanding of how the profit is calculated in the game. Correct me if I am wrong.

[JGR]

Code: Select all

Add setting for alternative transfer payment mode.

It's not completely clear to me how this new system works. I'm looking into setting up a server with a few people with the highest daylength, and to work with infrasharing. Ideally, every trip would be paid fully for that trip, like it would be in real life. After all, the bus company asks me the same amount of money no matter how long I've been waiting in the train and how far I've traveled before that time. Is the new behaviour like this, or not? If not, is it possible such a payment behaviour could be added as an option in the future?

The default game payment is that the cargo get paid depend on the distance between origin and destination station and the time taken (not counting transfer time), no matter the route it takes.

This creates problem in feeder system and multileg passenger system, because only the final vehicle got the payment, so other vehicle in the chain got negative balance.

That's where the transfer system come in. If the vehicle is ordered to transfer, that vehicle get credited for the cargo payment calculate using the origin and destination of that vehicle, multiply by the transfer percent (default 75%). Note the word credited. No money is actually being paid, it just get credited to the vehicle so the vehicle balance would look better (i.e. not negative). The credit is attached to the cargo, and when the final payment is made when the cargo arrive at the destination, the actual payment minus the transfer credit is added to that vehicle profit.

This can easily make the final vehicle seems to be in deep debt, especially if it's bus or truck. So the "alternative payment" is will calculate the transfer credit using cargo origin instead of that leg origin. It helps somewhat, but not all.

What you are asking for might be possible, but I believe that would create overblown profit interaction in feeder system or in ICE passenger where passenger transfer between high speed and local train. Not to mention easily exploit.

I am not sure how cross company transfer work in infrastructure sharing.

At least, this is my understanding of how the profit is calculated in the game. Correct me if I am wrong.

The alternative transfer payment mode setting is to control how exactly the transfer setting is calculated. The new algorithm, when enabled, (in my observations and opinion) tends to produce better results than the original algorithm in that the distribution of income between vehicles is better and the final vehicles does not tend to unfairly receive large negative payments. I did recently submit it upstream as a PR, where the feedback so far is that if it is better it should be on all the time, and not have a setting, which in retrospect is probably the way to go.

The transfer credit system already works with infrastructure sharing. This is not controlled by a setting and so is "on" all the time.
When a transfer payment is made to a vehicle, the value of that payment is added to a record associated to the cargo itself, on a per owner company and per vehicle type basis. (In the code this is the cargo packet deferred payments map).

When the cargo reaches its destination, "actual money" is generated as income for the delivery of cargo. In trunk this is paid to the company which owns the final vehicle with the income category of the final vehicle (i.e. which line in the company finance window).
In this patchpack, payments are made to the companies and vehicle type income categories previously recorded when the transfers took place, and the remainder is paid to the company which owns the final vehicle with the income category of the final vehicle.
No actual money is paid to transfer companies until the cargo reaches its destination and is paid for, and it is not possible to receive more money in total than the final delivery income of the cargo, this avoids all the simple exploits.
If cargo is lost before reaching its destination for whatever reason the associated deferred payments are also lost, and no payment is made to any company.
It is however possible for a company owning a transfer vehicle to receive a negative real payment when the cargo reaches its final destination. I suppose this is in theory exploitable by use of throwaway companies but you'd have a hard time in practice.
If a company owning a transfer vehicle is bought out or goes bankrupt, the deferred payments are reallocated to the buyer company or the final vehicle respectively.

To clarify: the alternative transfer payment mode setting and the feeder share percentage setting do affect the distribution of actual money between companies in the infrastructure sharing case of multi-company transfers.

[JGR]

Hello,

I have two small suggestions about the feature "template replacement".

Firstly : better integration with subgroups
Currently you can set a template replacement for a group that contains subgroups.
But the template replacement will replace only the vehicles directly contained in the group, not the subgroups.
=> I think it should be better if the template was applied to any vehicle in subgroups (recursive) unless there is actually another template affected to the subgroup.
This is the way the trunk feature "vehicle replacement" works.

Secondly : better coherence between "vehicle replacement" and "template replacement"
I always play with breakdown disabled, so there are never depots in my orders.
If I set a vehicle replacement, then all my vehicle will try "as soon as possible" to upgrade in the nearest depot along their current route.
But if I set a template replacement, I need to send them manually to the depot in order to upgrade them.
=> I think it should be better to have the same behavior with the two features. IMO the behavior itself for the two features should be configurable (replace old only, replace as soon as possible, replace only when sent to depot) but eh... Christmas is in 350 days now...

These are both implemented now.
I didn't add a setting/mode for whether to replace as soon as possible or when only when sent to depot, as these are only different when breakdowns are off and servicing is disabled (which is not a configuration I would normally play or test).
A mode where setting a template replacement requires further manual intervention to get the trains in to a depot does not seem useful, matching the trunk auto-replace behaviour seems more sensible.
The replace old only mode still works as previously.

[MagicBuzz]

Thank you JGR

I'll test those ASAP

[MagicBuzz]

Hello,

I very quickly tested the new behavior about automatically sending to depot vehicles that are different from their template.
It looks like there is an inverted test : the only trains that continuously visit depots are the one that already fit the template.

[JGR]

Hello,

I very quickly tested the new behavior about automatically sending to depot vehicles that are different from their template.
It looks like there is an inverted test : the only trains that continuously visit depots are the one that already fit the template.

How embarrassing.
Yes, you are right. It appears that I got the train refit state matches template refit state test the wrong way round, this has been corrected now.

[MagicBuzz]

I think there is still something wrong with the template replacement.

I just got this error :

jgr crash.png (6.48 KiB) Viewed 6298 times

It occurred a few second after I modified template by replacing the engine with a better one...

Attached the crash files.

[JGR]

I think there is still something wrong with the template replacement.

I just got this error :

jgr crash.png

It occurred a few second after I modified template by replacing the engine with a better one...

Attached the crash files.

Oh dear.
This oversight should be fixed now.

Would it be possible to add another conditional order option? "Jump to order # if loaded with cargo X is true/false." Would make multi cargo trains skip visiting unnecessary stations. If seem this in the route restrictions on signals and think it would be more useful as a conditional order.

Thanks!

It would seem better to me if it was extended to: "Jump to order # when Load percentage of cargo X operator value", to match the existing load percentage conditional.

This is added.

Hi, I have a few thoughts with regards to automatic timetabling, particularly with how it interacts with either auto-separation or scheduled dispatch under conditions of strain (high frequencies / conflicting traffic / long routes).

Firstly, I strongly see the logic of it favouring negative adjustments (shorter times) for time between stations, because I've seen how positive feedback loops of travel times and delays can lead to a station getting completely gummed up. However, for waiting time at stations, I think the reverse should occur, with positive adjustments strongly favoured. The reason for this is that the automatically generated waiting times are always un-useably low, and I have to set them manually. Essentially, waiting times need to be long enough such that a late train (which will run fuller than an on-time train, and therefore has to wait longer) can catch up to its timetable. Unlike travel times, positive bias for waiting times isn't going to cause feedback loops, as far as I can make out. The extent of the positive feedback could be decided by a setting (ideally per train group rather than a game setting), e.g. I might want to set my waiting times to the 90th percentile, so 10% of trains stop for longer and 90% shorter.

Secondly, for my purposes the most useful time between the stations is the shortest possible one, to the extent that I would have the travel times *never* increase (and simply represent the shortest time which has been achieved over a section of track since it was untimetabled). At present I still have to be extremely careful when upgrading trains / adding more, because positive feedback loops still occur and gum up a whole line. My trains run on physically separated tracks with essentially no alternate routes, so it would be a pile worse for more complex running patterns or trying to mix freight traffic onto the same line. For situations like those where trains are much more likely to get interrupted, I wonder if the scheduled time could be the minimum time plus a slack time, e.g. 10%, configurable? E.g. with minorly mixed traffic I might attempt to run at 110% travel times, in heavier traffic I might attempt 125%? That way the positive feedback loop could be avoided while still giving space for varied travel times.

These suggestions are from wanting it to be even more set-up-and-forget -- at present when I get new trains and need a new timetable, I have to come back to the same trains several times when frequencies are close to the limit, e.g. to turn timetable automation off once I have a good timetable running well, or to increase station waiting times if late trains aren't catching up.

I can see the logic of using a different bias for waiting times than for travel times. I'll look into that.
...

I've adjusted the algorithm for waiting times to favour positive adjustments, and removed a case which should only really have been applied for travel times which could be a cause of the unexpectedly low wait times that you observed.

[xxxvinniexxx]

Been playing OTTD a long time and been with this pack for a while now. But SOmething i really miss is an option to let a train load on a station until it has x units or until another train comes in. If there is a way in the current game please let me know

[MagicBuzz]

Been playing OTTD a long time and been with this pack for a while now. But SOmething i really miss is an option to let a train load on a station until it has x units or until another train comes in. If there is a way in the current game please let me know

That's almost the same thing as I was thinking : it should be nice if we could give orders like "wait for full loading or until X ticks".

Anyway, I notice a strange behavior with my road vehicles.

I still run with no breakdowns and no depots in orders.
When my vehicles gets old, they try to autorenew.

And there is a problem : they target the nearest depot, whoever is their owner. As a result, I get spammed with messages "autoreplace failed because the depot you can't purchase vehicles in a depot you're not the owner" (sorry, that's not the real message).

I found a setting "allow competitors to purchase vehicles in competitors depots" but this setting doesn't change the behavior : the trucks always try to autoreplace in competitors depots, and they still can't.

IMO when this setting is "true", then trucks should be able to autoreplace in competitors depots, and when it's "false", they should not try to enter competitors depots.

[JGR]

Been playing OTTD a long time and been with this pack for a while now. But SOmething i really miss is an option to let a train load on a station until it has x units or until another train comes in. If there is a way in the current game please let me know

There isn't a way to do this at present, I'll see about looking into it.

Anyway, I notice a strange behavior with my road vehicles.

I still run with no breakdowns and no depots in orders.
When my vehicles gets old, they try to autorenew.

And there is a problem : they target the nearest depot, whoever is their owner. As a result, I get spammed with messages "autoreplace failed because the depot you can't purchase vehicles in a depot you're not the owner" (sorry, that's not the real message).

I found a setting "allow competitors to purchase vehicles in competitors depots" but this setting doesn't change the behavior : the trucks always try to autoreplace in competitors depots, and they still can't.

IMO when this setting is "true", then trucks should be able to autoreplace in competitors depots, and when it's "false", they should not try to enter competitors depots.

This company setting applies to other company's vehicles in your depots.
You would need to request that the other company change the value of the setting if you want to purchase vehicles in their depot.

In general it is advisable to include at least one service at depot order in each vehicles orders. This prevents the behaviour where vehicles abandon their orders and head to an unspecified depot for servicing, as this usually has various negative side-effects in all but the smallest/simplest networks.
There is a news/advice setting to warn when this has been forgotten.

[Level Crossing]

Hi JGR,

Thanks for the great patch pack! Bug report: sometimes when I force a train to bypass a red path signal (Train 14, in the attached screenie), it doesn't reserve the track under itself as it moves down the line so a later-arriving train will think the track is clear and reserve it, causing a collision. Image and savegame attached.

[Redirect Left]

ran across an interesting something or other this evening.

decided to check the departures board for one of my stations. And lo and behold, delays! I've checked, all of these entries will direct you to the same vehicle, which is no where near the station, there's lots of other trains arriving long before this train will get there. So two glitches here, all these refer to the same train when clicked on, and there are lots of trains due before this, so i don't know why its listing this before them. I use 0.33.0
A save game is attached. Unfortunately window state isn't saved, so click on the station infront of you when the game loads, and then view that stations departures.

bug.sav

(6.37 MiB) Downloaded 165 times