JGR's Patch Pack

[aberro]

The map size unfortunately has to stay as it is because of a project i am working on which needs the smaller scale

Oh, btw, you can set openttd process affinity to one core - in some way it boost game speed drastically, while lowering fps and increasing lag spikes.

[JGR]

I have some strange bug - I barely can scroll map in cargo flow mode. It's like it's returning to same point it was a frame before. And the more stations there is the harder becomes to scroll map. Sadly, I don't have time to debug now.

I can't reproduce any problem here. Any more info might be helpful.

The map size unfortunately has to stay as it is because of a project i am working on which needs the smaller scale

Increasing the day length may help with this.

Oh, btw, you can set openttd process affinity to one core - in some way it boost game speed drastically, while lowering fps and increasing lag spikes.

I'm not sure about this. A few things, in particular link graph update jobs, are run in separate threads.

[aberro]

I can't reproduce any problem here. Any more info might be helpful.

Well, I just open map, scroll it somewhere into any area with a dense traffic, switch it to cargo flow mode and try to scroll it, but it's only jitters and almost not moving.

I'm not sure about this. A few things, in particular link graph update jobs, are run in separate threads.

Maybe, but nonetheless, when I set affinity to single core, game runs in fast-forward, like, two times faster, all vehicles just flashes through the screen, but fps drops by two-three times (or it's not really fps drops, but lag spike increases).

[eshield]

Hello,

I wonder if JGR can fix panning issue on Windows RS3? Here is a copy-paste from related thread:

The patch working for me is:
file win32_v.cpp, line 750:
if (_cursor.UpdateCursorPosition(x, y, false)) {

I've only changed true to false in the mentioned line to avoid queued mouse events processing inside CursorVars::UpdateCursorPosition. When building with SDL video driver (not my case), you'll find similar line in sdl_v.cpp (line 535).

Note: It seems to be the workaround only. As fas as I understand the code, queued mouse event processing was introduced to improve cursor behaviour "esp. when OpenTTD lags a bit" (quote from source code comment). My observation is: on modern PCs processing the queue is not required. That's why I disabled it, not trying to find the bug in processing (I don't know the sources well, spent 2 hours on the whole process).

I think it will take years for openttd devs to fix this so the only hope is JGR

Much appreciated!

[Gliptal]

Hello,

I wonder if JGR can fix panning issue on Windows RS3? Here is a copy-paste from related thread:

The patch working for me is:
file win32_v.cpp, line 750:
if (_cursor.UpdateCursorPosition(x, y, false)) {

I've only changed true to false in the mentioned line to avoid queued mouse events processing inside CursorVars::UpdateCursorPosition. When building with SDL video driver (not my case), you'll find similar line in sdl_v.cpp (line 535).

Note: It seems to be the workaround only. As fas as I understand the code, queued mouse event processing was introduced to improve cursor behaviour "esp. when OpenTTD lags a bit" (quote from source code comment). My observation is: on modern PCs processing the queue is not required. That's why I disabled it, not trying to find the bug in processing (I don't know the sources well, spent 2 hours on the whole process).

I think it will take years for openttd devs to fix this so the only hope is JGR

Much appreciated!

Was just about to post this. Any chance you could slip this in your upcoming update JGR?

[JGR]

Hello,

I wonder if JGR can fix panning issue on Windows RS3? Here is a copy-paste from related thread:

The patch working for me is:
file win32_v.cpp, line 750:
if (_cursor.UpdateCursorPosition(x, y, false)) {

I've only changed true to false in the mentioned line to avoid queued mouse events processing inside CursorVars::UpdateCursorPosition. When building with SDL video driver (not my case), you'll find similar line in sdl_v.cpp (line 535).

Note: It seems to be the workaround only. As fas as I understand the code, queued mouse event processing was introduced to improve cursor behaviour "esp. when OpenTTD lags a bit" (quote from source code comment). My observation is: on modern PCs processing the queue is not required. That's why I disabled it, not trying to find the bug in processing (I don't know the sources well, spent 2 hours on the whole process).

I think it will take years for openttd devs to fix this so the only hope is JGR

Much appreciated!

Was just about to post this. Any chance you could slip this in your upcoming update JGR?

In the thread it looks to be a more complicated problem than is solved by the workaround above.
I don't have a Windows system to test on, which makes testing more complicated.
I'm inclined to wait until a more complete/permanent solution is available.

[pelya]

Hey JGR, could you please add a link to Github release page RSS feed to the first post? It's easier to get notified about new releases using RSS feed than watching the forum activity (the last version did not get any announcement, I've noticed it only when servers with version 0.22.0 started appearing).

For some reason Android version crashes very often on user devices, and stack traces are not very usable - it's usually inside main loop in HandleMouseEvents(), when iterating through window list, it looks like a memory corruption or use-after-delete. Considering the amount of Android-specific patches, I don't think it will be easy to reproduce on PC. If anyone is able to reproduce this crash on Android via specific steps, please tell me.

[Gliptal]

In the thread it looks to be a more complicated problem than is solved by the workaround above.
I don't have a Windows system to test on, which makes testing more complicated.
I'm inclined to wait until a more complete/permanent solution is available.

I understand, given the latest info I support your decision of waiting it out. Not that my support means anything that is.

On another note, savegames are fully compatible between updates, correct?

[cmhbob]

Object placement, specifically fenced land. Is that part of this patch, or part of the official/trunk game? I've found a bug with it.

When you buy land with sign placement, you can only buy it once. If you try to buy it again, you get a message that you already own it. If you try to place fenced land on top of fenced land, it allows it to happen, with the accompanying charge. It should give the same "You already own it" message.

On a related note, are we ever going to get draggable sign placement? I hate having to click 30 individual tiles around an airport. I'd rather be able to click-and-drag to do it.

[JGR]

Hey JGR, could you please add a link to Github release page RSS feed to the first post? It's easier to get notified about new releases using RSS feed than watching the forum activity (the last version did not get any announcement, I've noticed it only when servers with version 0.22.0 started appearing).

That is done now.

On another note, savegames are fully compatible between updates, correct?

Yes there should be full backwards compatibility for loading savegames from previous patchpack versions and trunk, and limited compatibility for loading from other versions as listed in the first post.

Object placement, specifically fenced land. Is that part of this patch, or part of the official/trunk game? I've found a bug with it.

I'm not aware of any changes to NewGRF objects in this patchpack. It's not a feature that I use or test.
You may want to check the trunk behaviour and/or raise it with the NewGRF author.

On a related note, are we ever going to get draggable sign placement? I hate having to click 30 individual tiles around an airport. I'd rather be able to click-and-drag to do it.

It's not something that there seems to much demand or need for. Why is there a need to purchase tiles around an airport?

[cmhbob]

On a related note, are we ever going to get draggable sign placement? I hate having to click 30 individual tiles around an airport. I'd rather be able to click-and-drag to do it.

It's not something that there seems to much demand or need for. Why is there a need to purchase tiles around an airport?

I do that to secure land for airport expansion so I don't have to bulldoze a bunch of stuff in the future. I've also done it around train stations for the same reason.

Now the hard part is figuring out which newgrf that is. Actually, it looks like it's OpenGFX+Landscape.

Thanks for the reply.

[Wahazar]

May I ask for a small but important fix:
force New orders are 'non-stop' by default to true if any infrastructure settings are enabled.
Implicit orders should not be available in case of infrastructure sharing.
Many inexperienced users keep this option off as it is default in original openttd, which make terrible mess if somebody put two station in shared town and buses start unattended to go to competitors stations.
This mess is even quadrupled when cargodist is enabled...

[wallyweb]

Object placement, specifically fenced land. Is that part of this patch, or part of the official/trunk game? I've found a bug with it.

I'm not aware of any changes to NewGRF objects in this patchpack. It's not a feature that I use or test.
You may want to check the trunk behaviour and/or raise it with the NewGRF author.

Objects have been around for many years and any trunk bugs should have been worked out by now. Take this bug to the object author and let him/her deal with it.

[Wahazar]

Unfortunately there is still bug related to "disallow removing water tiles" option. It is not possible to fund water industries, for example FIRS fishing grounds or ports, this include game generation - no such industry appears.

[JGR]

May I ask for a small but important fix:
force New orders are 'non-stop' by default to true if any infrastructure settings are enabled.
Implicit orders should not be available in case of infrastructure sharing.
Many inexperienced users keep this option off as it is default in original openttd, which make terrible mess if somebody put two station in shared town and buses start unattended to go to competitors stations.
This mess is even quadrupled when cargodist is enabled...

Really 'non-stop' should be the default anyway.
However, ignoring the user setting may generate additional bug reports due to user confusion.
Some users seem to be averse to non-stop orders.
I will look into/consider this.

Unfortunately there is still bug related to "disallow removing water tiles" option. It is not possible to fund water industries, for example FIRS fishing grounds or ports, this include game generation - no such industry appears.

This should be fixed now, thanks for the bug report.

[Wahazar]

Really 'non-stop' should be the default anyway.

Yes, this is a long term fix related to the trunk, but forcing option if infrastructure sharing is enabled can be a short term fix, I doubt anybody would complain, because intentionally used "random walking" play style is rather uncommon, especially on servers using shared infrastructure.

[Redirect Left]

Fall update for Windows 10 breaks RMB panning of the map, it's described here; viewtopic.php?f=31&t=77042 - i just got the fall update and this has now caused issues for me, in patchpack and trunk

Would be ace if you could figure out how to fix it and put it into the patchpack!

[wicket-303]

Hello
JGR's Patch Pack is very wonderful. However, the time and day will inevitably deviate ...
Is it impossible to fit "Tick per minute" and "Day lengch factor" perfectly?

[aberro]

Hello
JGR's Patch Pack is very wonderful. However, the time and day will inevitably deviate ...
Is it impossible to fit "Tick per minute" and "Day lengch factor" perfectly?

I'd say more - is it impossible to make "Tick per minute" floating point? Because I'm using "Day length factor" times 10 and trying to align 24 hours with year, but it's definitely impossible, target value is 187.69791(6) (74 ticks per day * 10 daytime factor * 365.25 days in year = 270285, divided by 1440 minutes in day)

[dasy2k1]

Just discovered this and wow,

playing around with the signal routing and its so useful when you have a mix of platform lengths in a station and a mix of through and bay platforms,

the only thing i have not yet got my head around is slot operations,
is there any link which describes how to use them?