Chill's patchpack v14_7

[ChillCore]

any idea when that fixed .diff will be ready ?

Yesterday?
Nothing stops you from taking the previous one and applying the change I mentioned manually ...

I did not bump to make sure no additional (read new) bugs get introduced for the moment. My bumped version seems to work but I am busy doing other things first so I did not get to test it enough with recent trunk changes.
If somebody posts a new binary ... please do not bump unless you feel like bughunting. Thank you for understanding.

[WDSnav]

Here is the new fixed binary. I did not bump it to a new revision.

OpenTTD chipp v9_9_9_1.zip

(3.97 MiB) Downloaded 128 times

chipp_v9_9_9_1_compatible_v9_9_4_r20768.diff

(1.09 MiB) Downloaded 71 times

[Wasila]

Hey,
Excellent patchpack!

I just wanted to report a bug: when clicking to centre the smallmap on current location, it appears to move to close to the top left corner of the game (using the binary just posted).

I also can’t figure out how to use programmable signals. I pressed the cog button and laid a signal down but nothing happens (not even the signal is placed). Am I doing something wrong?

Also, is there supposed to not be an option to change the regularity of simulated signals on tunnels/bridges? It's currently set too high for me...

Thanks,
Wasila

[ChillCore]

Here is the new fixed binary. I did not bump it to a new revision.

Thank you for the binary and the previous one also.

I just wanted to report a bug: when clicking to centre the smallmap on current location, it appears to move to close to the top left corner of the game (using the binary just posted).

http://www.tt-forums.net/viewtopic.php? ... &start=371
I have not yet merged the code corectly between CargoDist and the More height levels patch ...
Each patch in itself works correctly though so do not go reporting in those threads please.
If I can not make it work correctly by the next version I will revert to the previous smallmap code which was almost correct.

I also can’t figure out how to use programmable signals. I pressed the cog button and laid a signal down but nothing happens (not even the signal is placed). Am I doing something wrong?

http://www.tt-forums.net/viewtopic.php? ... 2&start=47

Also, is there supposed to not be an option to change the regularity of simulated signals on tunnels/bridges? It's currently set too high for me...

Someone asked the same question here ...
http://www.tt-forums.net/viewtopic.php? ... &start=171
To modify it in te patchpack is the same procedure.
Little warning though. A long time ago, when the gap was configurable, I could make trains crash in tunnels when he gap was two tiles and the front one reversed.
Also if you modify it, please do not post your binary ...

[Wasila]

I also can’t figure out how to use programmable signals. I pressed the cog button and laid a signal down but nothing happens (not even the signal is placed). Am I doing something wrong?
viewtopic.php?f=33&t=47622&start=47

I tried this - I lay a signal down, hit the cog and click the signal, but nothing happens?

Someone asked the same question here ...
viewtopic.php?f=33&t=41260&start=171
To modify it in te patchpack is the same procedure.

Mmm... I was just checking if it was the same - I wasn't sure if this version of the patch was the same as the separate version.

[ChillCore]

Programmable signals:
Can you please be more specific? It works over here.
You mean that the window does not open or you mean that you do not know how to program the signal?

Tunnel signals:
Yes it is the version as found in the first post but the syntax is modified to work with the programmable signals patch.
In the patchpack however you will be searching for 4 instead of 6. (Just search for "100 tiles" to find the sweet spot )

[Wasila]

Programmable signals:

I open the Signal Selection window.
I then lay down a signal.
I press the 'cog' (program signal) button.
I click the signal.

Is there something wrong there?

Also I am afraid to report a crash. According to my own investigations (I had the same problem in my own custom build), I believe that it is a result of the extra-large-maps patch. .log and .png attached.

[ChillCore]

Programmable signals:
Are you sure you are clicking a programmable signal? If you click a pbs signal after the program button noting will happen indeed.
You can not program other signals types and the signals to depend upon can only be exit signals. (combo signals are exit signals too.)

Crash:
Please tell me how to reproduce. I can remove tramtracks without problems.
As you modified the source it would be helpful if I knew what exactly you changed.
If you PM me the patch from your source I can more easily compare it to mine to see if you have maybe forgotten to do something while modifying/bumping. No promises that I can fix it though and please make sure that the new files are included also.

There is a reason I do not always post my patch pack against the current trunk or ask not to bump. Read: if there are codechanges in trunk those changes have to be made in the patches also to keep them working correctly, if they are affected by the codechange that is.
Sometimes the change is simple, sometimes I need to go and dig the logfiles if I missed it when the change was made to trunk.

[Wasila]

Programmable signals:
Are you sure you are clicking a programmable signal? If you click a pbs signal after the program button noting will happen indeed.
You can not program other signals types and the signals to depend upon can only be exit signals. (combo signals are exit signals too.)

Ooohhhh! I just noticed that there was a 'programmable signal'.

Please tell me how to reproduce. I can remove tramtracks without problems.
As you modified the source it would be helpful if I knew what exactly you changed.
If you PM me the patch from your source I can more easily compare it to mine to see if you have maybe forgotten to do something while modifying/bumping. No promises that I can fix it though and please make sure that the new files are included also.

There is a reason I do not always post my patch pack against the current trunk or ask not to bump. Read: if there are codechanges in trunk those changes have to be made in the patches also to keep them working correctly, if they are affected by the codechange that is.
Sometimes the change is simple, sometimes I need to go and dig the logfiles if I missed it when the change was made to trunk.

I believe that the problem only occurs with a large map - starting one and then messing around with trams a bit (two trams with orders usually) seems do the trick, although it has crashed at other times. The patch is compiled with the same revision as is stated in the .diff's file name.

Changed:

Code: Select all

+/* Maximum bridge size is 100 tiles, 16 bit available for signals in m2 =>
+ * 50 blocks of 2 tiles available between ramps */
+static const uint8 bridge_signal_block_size = TILE_SIZE * 2;

Code: Select all

+	while (bridge_signal_position <= bridge_section) {
+		bridge_signal_position += 2; // 2 tiles is block size, max 48 signals, 50 blocks * 2 = 102 on bridge of max length e.g. 100 tiles 

I'll PM the diff to you.

There was, while I was testing the game for the previous crash, another crash! Attached is the usual. Again, this was caused when setting up a few trams and after giving them orders to a station.

[ChillCore]

I still can not reproduce the two crashes you had Wasila.
Can you post savegames please if it happens again so I can run them through a debug build. (Maybe you still have them?)
The tunnel signal gap difference between your code and mine should not be a problem if there are no vehicles in them in your savegame.

ps: do not post 8k *8k savegames as my pc can not handle them because of the memory usage with such big maps.

[Rubidium]

ps: do not post 8k *8k savegames as my pc can not handle them because of the memory usage with such big maps.

Then you can't reproduce at least the first of the two crashes. Well, with any map having 16 777 216 or more tiles would allow you to reproduce it; so 4k*8k should make it possible as well. Also make sure that you've got the NewGRF debugging tools enabled and you're using the land query tool on a tile with index >= 16 777 216.

[Wasila]

The map is 4k*8k so it should be alright. I've just noticed (speaking of the first crash) that the crash always takes place on the 12th of January - it appears to have nothing to do with trams.

http://rapidshare.com/files/418292630/GlobalTrans.sav

Attached are the newGRFs I'm using, in case it's something to do with that.

[ChillCore]

Also make sure that you've got the NewGRF debugging tools enabled and you're using the land query tool on a tile with index >= 16 777 216.

That did the trick. Thank you very much. Some (down)tuning is to be done it seems.
I will also change the patch I posted in the larger maps thread once I have the correct maximum numbers to insert.

The map is 4k*8k so it should be alright. I've just noticed (speaking of the first crash) that the crash always takes place on the 12th of January - it appears to have nothing to do with trams.

http://rapidshare.com/files/418292630/GlobalTrans.sav

Attached are the newGRFs I'm using, in case it's something to do with that.

Thank you for the savegame, that will make testing easier.
I will have a looksie to see if the issue is not caused also because of too many tiles. I am not sure if I can or should fix handling such big maps.
Also, talking about GRFs, making a habit of selecting them BEFORE you start the game will save you a lot of potential problems.

[Wasila]

I will have a looksie to see if the issue is not caused also because of too many tiles.

I should hope not, that's the point of the patch!

Thanks for having a look at this - it would be great if you could PM me if/when you figure it out .

[ChillCore]

Man that Rapidshare is rapid ... Yes It took until now to download those 20MB.

For testing I changed newgrf_debug_gui.cpp. 24 to 26 5 times.
Your savegame was still running up to februari. Also I was able to query the last tiles.
Would you mind recompiling with these changes and doing some more testing Wasila before I post a new patch.


As for the "official" bigger maps patch I'm not sure what to do, downsize the maximum mapsize (in number of tiles) or make the same adjustments as mentioned above?

[Wasila]

Man that Rapidshare is rapid ... Yes It took until now to download those 20MB.

Was it really that slow? Perhaps I should use a new hoster... any suggestions?

For testing I changed newgrf_debug_gui.cpp. 24 to 26 5 times.

I'm not entirely sure what you mean. Could you please post exactly which bit of code was changed?

[ChillCore]

Perhaps I should use a new hoster... any suggestions?

I was able to download it that is the most important.
No suggestions sorry.

Could you please post exactly which bit of code was changed?

Change line 47 in newgrf_debug_gui.cpp
from

Code: Select all

	return GB(window_number, 0, 24);

to

Code: Select all

	return GB(window_number, 0, 26);

and do the same for line 56, 60, 215 and 419. (read: replacing "24" by "26")
I'm not sure if that fixes the crash you had in rail_map.h also though. I guess not. Feel free to post a savegame if it happens again.

[Wasila]

Oh, I understand now. I quickly ran the newly compiled game and it hasn't crashed yet; I'll test it properly tomorrow. Thanks .

I don't know if you know this, but there were a few other things that looked like error messages which popped up while compiling.

Wasila

[ChillCore]

I did not know about the compiling errors in terraform_cmd.cpp, the file compiles cleanly on my pc.
A quick look shows that all of them refer to debugging messages, they should not affect gameplay.
Thank you for mentioning them.

If it is not too much trouble and you find some time, would you mind compiling the more height levels patch alone to see if they show up in there also ... that would be much appreciated.
If they are there also I could report them to ic111.

[Wasila]

Very curious... I compiled the moreheightlevels patch in the thread's OP with the corrent version (r20761) and not a single hunk succeeded...