JGR's Patch Pack

[Ricard]

Many thanks for the good job you are doing.

Lately I'm having one problem. I'm not sure which version started happening but now I'm using 72.1

Some trains get stuck in stations for a while when reach 100% loading or 0% unloading. They stay stuck while other trains arrive, load or download and go on. After a variable time any stuck train come to live again and continue with their work. I've made some tests but I could not discover why one train gets stuck and when they go back to work.

I attach a couple of examples when you download the game, the focus is on one station with some stuck trains.

[JGR]

Many thanks for the good job you are doing.

Lately I'm having one problem. I'm not sure which version started happening but now I'm using 72.1

Some trains get stuck in stations for a while when reach 100% loading or 0% unloading. They stay stuck while other trains arrive, load or download and go on. After a variable time any stuck train come to live again and continue with their work. I've made some tests but I could not discover why one train gets stuck and when they go back to work.

I attach a couple of examples when you download the game, the focus is on one station with some stuck trains.

It does not make sense to use timetable auto-separation for this group. I suggest you turn it off.
Your trains are waiting because they are running early. However the lateness state should probably just be ignored because the timetable is not in a started/valid state anyway.

[Ricard]

My fault. I never use auto separation in non passenger trains. Now I have realised that there is a configuration option to put auto separation by default in all trains.

Thanks for your help

[gravelpit]

Many thanks for the good job you are doing.

Lately I'm having one problem. I'm not sure which version started happening but now I'm using 72.1

Some trains get stuck in stations for a while when reach 100% loading or 0% unloading. They stay stuck while other trains arrive, load or download and go on. After a variable time any stuck train come to live again and continue with their work. I've made some tests but I could not discover why one train gets stuck and when they go back to work.

I attach a couple of examples when you download the game, the focus is on one station with some stuck trains.

Automatic separation should be turned off

[Auge]

Hello

It does not make sense to use timetable auto-separation for this group. I suggest you turn it off.

Now I have realised that there is a configuration option to put auto separation by default in all trains.

Automatic separation should be turned off

Automatic separation turned on or off, both approaches have their drawbacks. Is it turned off, freight line vehicles which typically should start when fully loaded will do this but for passenger lines where one wants to have automatic separation one has to remember to manually turn it on. If turned on, one has to remember to turn it off again for freight line timetables. In my experience, I tend to forget this quite often (in my case to disable it for freight line timetables), and I reckon I’m by no means the only one.

Ideally the setting would have an option to set it on for passenger vehicles and to disable it for all other vehicles. But I haven’t the faintest idea whether something like that is even feasible.

Tschö, Auge

[xarick]

I have received a bug report regarding AIList instances during save and load. See viewtopic.php?p=1279485#p1279485

I found out the reason the script crashes on load is due to a problem with saving in JGRPP.

https://github.com/JGRennison/OpenTTD-p ... #L454-L455
Between these two lines, adding the following fixes the save issue.

Code: Select all

SlWriteByte(SQSL_INSTANCE);

[JGR]

I have received a bug report regarding AIList instances during save and load. See viewtopic.php?p=1279485#p1279485

I found out the reason the script crashes on load is due to a problem with saving in JGRPP.

https://github.com/JGRennison/OpenTTD-p ... #L454-L455
Between these two lines, adding the following fixes the save issue.

Code: Select all

SlWriteByte(SQSL_INSTANCE);

Thanks, this will be fixed in the next release.

[gravelpit]

I have an ongoing observation: could it be possible to count a vehicle's delivery cycles in a given year? Instead of checking how much it earned, we would instead check the cycles traveled from station to station. This way, we could easily compare which transport option would be best for a given route?

[eekee]

I have an ongoing observation: could it be possible to count a vehicle's delivery cycles in a given year? Instead of checking how much it earned, we would instead check the cycles traveled from station to station. This way, we could easily compare which transport option would be best for a given route?

Ow! Do you have to shout? If you find all the text too small, your web browser and operating system both likely provide multiple ways to increase its size. The simplest to use is just to press Ctrl-+

[eekee]

I have a bug: the station build window -- >30% of my screen area -- is inconsistently placed in the middle of the screen. It's because the station build window is aligned to the left edge of the rail toolbar which itself is now placed inconsistently. I see 2 issues.

The really big serious issue is that this gigantic window may be opened in the middle of the screen because it's related to the position of the rail toolbar. Opening it at the right edge of the screen would solve the issue for me.

The other thing is the inconsistency of the position of the rail build bar itself. It used to be consistent. When Link landscape toolbar to rail/road/water/airport toolbars was off, it would always be at the right edge of the screen. When the option was on, the landscape toolbar would always be between the infrastructure toolbar and the right edge. Now, the off behaviour varies. If you open the landscape toolbar before an infrastructure toolbar, the landscape toolbar will be positioned as if the option were on, and the infrastructure will be positioned to the left of it as if the option were on. My feeling at present is that I can probably just get used to this, but I don't know if I'd feel the same if I ever get into a long hyperfocused play session again.

The station build window was always a bit of trouble. In 640x480 it was overly intrusive even before NewGRFs were invented. I remember the frustration more clearly than the details this many years later, but perhaps it was never a good idea to align it with the left side of the rather long rail toolbar.

----------------------------

Another minor issue is the severely reduced space for NewGRF station element names. These have been moved under the element selection list which is fine, but it's also been reduced to one line which totally spoils the fun! To fit, many names would have to be abbreviated brutally! lol But all exaggeration aside, even if the limited space were reasonable and it were reasonable to tell GRF creators to update their GRFs, I have many GRFs which haven't been updated for many years and likely never will be. Expanding the space for element names to 3 lines might be enough, but it might not. I'm working from memory here and my memory is terrible. Names fit better in the other column near the orientation and station size buttons, there was more width and 2 lines were enough. The more width you have, the less space is wasted by word-wrapping, so perhaps 4 lines might be more reasonable in its new location.


I suspect all these are upstream issues, but as I recently learned, I have all the symptoms of dementia and have had all my life. It wasn't easy to write this. If I post on the official bug-tracker, I'd have to work twice as hard and that has always been a bit too much.

[JGR]

I have a bug: the station build window -- >30% of my screen area -- is inconsistently placed in the middle of the screen. It's because the station build window is aligned to the left edge of the rail toolbar which itself is now placed inconsistently. I see 2 issues.

The really big serious issue is that this gigantic window may be opened in the middle of the screen because it's related to the position of the rail toolbar. Opening it at the right edge of the screen would solve the issue for me.

The other thing is the inconsistency of the position of the rail build bar itself. It used to be consistent. When Link landscape toolbar to rail/road/water/airport toolbars was off, it would always be at the right edge of the screen. When the option was on, the landscape toolbar would always be between the infrastructure toolbar and the right edge. Now, the off behaviour varies. If you open the landscape toolbar before an infrastructure toolbar, the landscape toolbar will be positioned as if the option were on, and the infrastructure will be positioned to the left of it as if the option were on. My feeling at present is that I can probably just get used to this, but I don't know if I'd feel the same if I ever get into a long hyperfocused play session again.

The station build window was always a bit of trouble. In 640x480 it was overly intrusive even before NewGRFs were invented. I remember the frustration more clearly than the details this many years later, but perhaps it was never a good idea to align it with the left side of the rather long rail toolbar.

----------------------------

Another minor issue is the severely reduced space for NewGRF station element names. These have been moved under the element selection list which is fine, but it's also been reduced to one line which totally spoils the fun! To fit, many names would have to be abbreviated brutally! lol But all exaggeration aside, even if the limited space were reasonable and it were reasonable to tell GRF creators to update their GRFs, I have many GRFs which haven't been updated for many years and likely never will be. Expanding the space for element names to 3 lines might be enough, but it might not. I'm working from memory here and my memory is terrible. Names fit better in the other column near the orientation and station size buttons, there was more width and 2 lines were enough. The more width you have, the less space is wasted by word-wrapping, so perhaps 4 lines might be more reasonable in its new location.


I suspect all these are upstream issues, but as I recently learned, I have all the symptoms of dementia and have had all my life. It wasn't easy to write this. If I post on the official bug-tracker, I'd have to work twice as hard and that has always been a bit too much.

I am guessing that the change that is affecting you is this one: https://github.com/OpenTTD/OpenTTD/pull/14725 ?
There could potentially be a setting for the traditional behaviour but it isn't all that clear how that would be articulated.

640x480 is very small. I understand that you don't want to change your workflow but this does limit what is practically achievable.

For the name field, you can horizontally resize the station build window if you need to see a very long name.
I gather that a lot of players don't actually use the individual station names for anything and in many GRFs these don't have useful values.

If there's an earlier version of the game that you're more happy with or got more complete muscle-memory for, another option is to carry on using that, as it sounds like consistency would outweigh any benefit from new functionality.
Some level of UI and workflow changes is unavoidable with upgrading.

[masonma71]

Using this patch has really made the game fun for me, and I do appreciate the work you put in. I like to play with a larger map and many towns. I notice there is a minimum distance between towns setting, and I find this really useful, as it stops towns from being right next door to each other. I was wondering if it was possible to have a setting for a maximum distance. as on larger maps you'll sometimes get a cluster of towns, and then a long distance between the next nearest

[Chaserchris]

I have a problem with releases after 68.2. I use the Toal Bridge Replacement Set 1.12 . Bridges are not shown as graphics but with ( ? ) Icons. Last version which is ok was 0.68.2 Same with some Road waypoints but that does not matter so much.

Various bridge sets are coded incorrectly and will not display correctly in vanilla OpenTTD or this branch. You may want to look into a newer version or a different bridge set,

Question to all users: Is there any good compatible Bridge Newgrf you can recommend?

[eekee]

I am guessing that the change that is affecting you is this one: https://github.com/OpenTTD/OpenTTD/pull/14725 ?
There could potentially be a setting for the traditional behaviour but it isn't all that clear how that would be articulated.

It looks like it is. If I read that right and if I rightly remember a setting I don't use, the author of that change would have been satisfied merely by changing the Link landscape toolbar setting. I'll have to get an older version and verify.

640x480 is very small. I understand that you don't want to change your workflow but this does limit what is practically achievable.

640x480 was a reference to the original games. My screen is admittedly small by modern standards, but not quite so... dramatically. It's 1440x900.

For the name field, you can horizontally resize the station build window if you need to see a very long name.
I gather that a lot of players don't actually use the individual station names for anything and in many GRFs these don't have useful values.

They're not strictly useful, just nice. Moving the station build window so I can resize it, then resizing and moving it back so I can see where I'm building is much too much for something that's merely nice. This is a game, why can't we have nice things? lol

If there's an earlier version of the game that you're more happy with or got more complete muscle-memory for, another option is to carry on using that, as it sounds like consistency would outweigh any benefit from new functionality.
Some level of UI and workflow changes is unavoidable with upgrading.

That is a good idea. I've only played one save since upgrading, and it wouldn't be bad to redo the changes I made to it with the knowledge I gained making the changes the first time.

[Valdez]

If I may have a question with regards to signal restrictions:

could "long reserve unless stopping" be also available without "realistic braking" turned on? Or is there a technical reason why it's impossible?

[BlueEagle_nl]

Hi JGR,

I notice the 0.73.0 release is not opening on Mac OS X 26.5.2 / 26.6.
I do get the "You downloaded this app from the Interwebs" popup. This then allows you to open the app via Settings > Privacy, adding the app to a whitelist of allowed apps. But, that requires the password and that prompt is not opening, where it would for the latest 0.72...
Copilot points me to check the signing;

Code: Select all

codesign --verify --deep --verbose OpenTTD.app

tells me the app is not signed at all; did something in the build process for Mac OSX fail?

[JGR]

If I may have a question with regards to signal restrictions:

could "long reserve unless stopping" be also available without "realistic braking" turned on? Or is there a technical reason why it's impossible?

This functionality makes use of the realistic braking driving model machinery, and would be unreliable without it. In any case it is not likely to be very useful when running in the standard braking model.

Hi JGR,

I notice the 0.73.0 release is not opening on Mac OS X 26.5.2 / 26.6.
I do get the "You downloaded this app from the Interwebs" popup. This then allows you to open the app via Settings > Privacy, adding the app to a whitelist of allowed apps. But, that requires the password and that prompt is not opening, where it would for the latest 0.72...
Copilot points me to check the signing;

Code: Select all

codesign --verify --deep --verbose OpenTTD.app

tells me the app is not signed at all; did something in the build process for Mac OSX fail?

I'm not very interested in paying a bunch of money to Apple or jumping through their hoops. The build process is the same as for previous releases, I don't have any control of anything different that might be happening on the Apple side though.

[piratescooby]

If I may have a question with regards to signal restrictions:

could "long reserve unless stopping" be also available without "realistic braking" turned on? Or is there a technical reason why it's impossible?

This functionality makes use of the realistic braking driving model machinery, and would be unreliable without it. In any case it is not likely to be very useful when running in the standard braking model.

Hi JGR,

I notice the 0.73.0 release is not opening on Mac OS X 26.5.2 / 26.6.
I do get the "You downloaded this app from the Interwebs" popup. This then allows you to open the app via Settings > Privacy, adding the app to a whitelist of allowed apps. But, that requires the password and that prompt is not opening, where it would for the latest 0.72...
Copilot points me to check the signing;

Code: Select all

codesign --verify --deep --verbose OpenTTD.app

tells me the app is not signed at all; did something in the build process for Mac OSX fail?

I'm not very interested in paying a bunch of money to Apple or jumping through their hoops. The build process is the same as for previous releases, I don't have any control of anything different that might be happening on the Apple side though.

0.73.0 works on my Mac , May I say In my senior years I prefer to play the game on my Mac Laptop .

[BlueEagle_nl]

Hi JGR,

I notice the 0.73.0 release is not opening on Mac OS X 26.5.2 / 26.6.
I do get the "You downloaded this app from the Interwebs" popup. This then allows you to open the app via Settings > Privacy, adding the app to a whitelist of allowed apps. But, that requires the password and that prompt is not opening, where it would for the latest 0.72...
Copilot points me to check the signing;

Code: Select all

codesign --verify --deep --verbose OpenTTD.app

tells me the app is not signed at all; did something in the build process for Mac OSX fail?

I have re-downloaded the app via an Administrator-account instead of a standard user account, and now the app is able to run. Seems to have been a misconfiguration on my side