Chill's patchpack v14_7

[ChillCore]

I do not know what patch dkarn has used, there have been quite a few town growth patches and maybe he wrote it himself.
I do not doubt that it is fun to use, if you like suuch challenges, but if you want me to include it I will need the patch first.

I don't know which patch is included there either.

I found the patch on page 225 of the thread where you got the patch.
There is at least one (outcommented) line in it from the daylength patch and maybe there are a few more errors (against current trunk) besides not bumping the savegame version ...

But it seems not to work properly anyway. It works fine with food. But when it comes to goods there has to be a bug. Since I don't know if a thread exists for that patch... I can't report it anywhere

Report the error in the HFR thread, where you got the binary, or PM dkarn here maybe if your french is no good?
I still do not know where he got it and who's it is, the patch is posted there and there is no link to the original.

Also do you not find that the towns grow to fast? When I glanced through the code dkarn removed the adjustments according to daylength in the patchpack ...

I don't think the towns are growing to fast with this patch (I assume we talk about the same one because dkarn is mentioned in the French forums)... We play with daylength factor 4 and sometimes I wish they could grow a little bit faster

Yes we are talking about the same patch ... HFR_2.0 is what you mentioned before, right?
For faster towngrowth see "Advanced Settings -> Economy -> Towns -> Town growth speed" and ofcourse deliver what needs to be delivered in sufficient quantities as you are playing with a town growth patch. Also you may want to try to tweak the settings dkarn added there, they should be above "Allow bribing of the local authority".

I will have a looksie later on if you want me to add the patch.
If you add it yourself you need to use the same savegame numbers for the towngrowth patch and the IS patch as you find them in the HFR version (*) to keep compatiblity with the game you started in HRF 2.0. It is not compatible with my version and it will never be. Even not after I add the patch in my version, sorry. Please do not post it here if you do.

(*)
For IS change the number of IS_SL in saveload.h to "143" (I have already added IS while bumping it in my version ... you just need to "un-bump")
For the towngrowth patch keep "94" while adding it.
If you do both you should be able to continue your game.

So here's a windows binary including the build log (in German though)

Thank you for the binary and the build log.



Also,
I am still looking at the vehicle income. Funny things are happening. Now the cargo payment is correct for high daylength setting but it is too low for low settings. Moehahaha.
I'll get it right eventually, I hope. I think something else still needs adjustment to the daylength settings besides the profits ...

[Dwight_K._Schrute]

Report the error in the HFR thread, where you got the binary, or PM dkarn here maybe if your french is no good?
I still do not know where he got it and who's it is, the patch is posted there and there is no link to the original.

I think I have to PM him... my French is not existent

I will have a looksie later on if you want me to add the patch.
If you add it yourself you need to use the same savegame numbers for the towngrowth patch and the IS patch as you find them in the HFR version (*) to keep compatiblity with the game you started in HRF 2.0. It is not compatible with my version and it will never be. Even not after I add the patch in my version, sorry. Please do not post it here if you do.

It would be nice to have it in CPP but it's not that important to me. So don't put too much effort in it Especially if it doesn't work properly...

I did not hope that it will be compatible.. so it is no problem for me ...

[JGR]

Trying to build a bus or lorry stations using the adjacent station build GUI (control-click) seems to trigger the assertion on line 545 of station_cmd.cpp
assert(w > 0) in GetAcceptanceAroundTiles

Other station types and not using the adjacent station build tool do not seem to be an issue.
I compiled and tested r21667 and that's fine.

I've not looked through the code yet, as it's late and I need sleep, might do tomorrow.

I'll attach a crash log for completeness, but it seems to be trivially reproducible enough.

Edit: Further testing revealed that some of what I had said was not strictly correct, now removed.

Edit 2: Docks seem to be fubared as well.

[ChillCore]

Thank you for the report JGR.

The problem is with the copypaste path and the tilehighlighting, I have not fixed it properly it seems.

If you want you can do this in the meantime around line 30 in tilehighlight_type.h ... untill I decide what to do with the copypaste patch.

Code: Select all

-	HT_PREVIEW   = 0x100, ///< used for CopyPaste Preview
-	HT_VEHICLE   = 0x200, ///< vehicle is accepted as target as well (bitmask)
-	HT_DIAGONAL  = 0x210, ///< Also allow 'diagonal rectangles'. Only usable in combination with #HT_RECT or #HT_POINT.
-	HT_DRAG_MASK = 0x1F8, ///< Mask for the tile drag-type modes.
+	HT_VEHICLE   = 0x100, ///< vehicle is accepted as target as well (bitmask)
+	HT_DIAGONAL  = 0x200, ///< Also allow 'diagonal rectangles'. Only usable in combination with #HT_RECT or #HT_POINT.
+	HT_PREVIEW   = 0x210, ///< used for CopyPaste Preview
+	HT_DRAG_MASK = 0x0F8, ///< Mask for the tile drag-type modes.

That will fix the crashes while disabling the tilehighlighting when pasting templates. Copypaste will still be functional.
I have tried a few other solutions but they each break something else ... The problem is with the numbers above and not being allowed to set HT_DRAG_MASK higher. Normally I would do HT_PREVIEW = 0x300 and HT_DRAG_MASK = 0x3F8, but as soon as HT_DRAG_MASK is higher then standard, which was not a problem until recent trunk changes, all sorts of problems emerge.

[JGR]

Thanks for the quick fix Chill. I've recompiled and all seems to be well.
I don't use the copy&paste patch myself so hadn't really been following what's going on with that.

[Alberth]

Thank you for the report JGR.

The problem is with the copypaste path and the tilehighlighting, I have not fixed it properly it seems.

If you want you can do this in the meantime around line 30 in tilehighlight_type.h ... untill I decide what to do with the copypaste patch.

Code: Select all

-	HT_PREVIEW   = 0x100, ///< used for CopyPaste Preview
-	HT_VEHICLE   = 0x200, ///< vehicle is accepted as target as well (bitmask)
-	HT_DIAGONAL  = 0x210, ///< Also allow 'diagonal rectangles'. Only usable in combination with #HT_RECT or #HT_POINT.
-	HT_DRAG_MASK = 0x1F8, ///< Mask for the tile drag-type modes.
+	HT_VEHICLE   = 0x100, ///< vehicle is accepted as target as well (bitmask)
+	HT_DIAGONAL  = 0x200, ///< Also allow 'diagonal rectangles'. Only usable in combination with #HT_RECT or #HT_POINT.
+	HT_PREVIEW   = 0x210, ///< used for CopyPaste Preview
+	HT_DRAG_MASK = 0x0F8, ///< Mask for the tile drag-type modes.

The problem is with the numbers above and not being allowed to set HT_DRAG_MASK higher. Normally I would do HT_PREVIEW = 0x300 and HT_DRAG_MASK = 0x3F8, but as soon as HT_DRAG_MASK is higher then standard, which was not a problem until recent trunk changes, all sorts of problems emerge.

huh?
As long as you make both HT_VEHICLE and HT_DIAGONAL a single bit, and not part of HT_DRAG_MASK, it should work w.r.t. trunk.

[ChillCore]

As long as you make both HT_VEHICLE and HT_DIAGONAL a single bit, and not part of HT_DRAG_MASK, it should work w.r.t. trunk.

I just tested different things untill it worked, untill JGR came along that is

I adjusted the code above to what is below. Thank you Alberth.
If someone could be so kind to test.
I have tested all kind of things, including distant joining all kinds of stations and diagonal highlighting of tiles, but I might have missed some cornercase again ...

Code: Select all

	HT_VEHICLE   = 0x100, ///< vehicle is accepted as target as well (bitmask)
	HT_DIAGONAL  = 0x100, ///< Also allow 'diagonal rectangles'. Only usable in combination with #HT_RECT or #HT_POINT.
	HT_PREVIEW   = 0x200, ///< used for CopyPaste Preview
	HT_DRAG_MASK = 0x2F8, ///< Mask for the tile drag-type modes.

These numbers seem to work while fixing the tilehighlighting for the copypaste patch ... but I wonder ... if HT_VEHICLE and HT_DIAGONAL can use the same bit, why is this not like this in trunk (to save space) and can others be joined maybe?

[Alberth]

As long as you make both HT_VEHICLE and HT_DIAGONAL a single bit, and not part of HT_DRAG_MASK, it should work w.r.t. trunk.

I was not clear here, I meant both a single bit && HT_VEHICLE != HT_DIAGONAL. Sorry for the confusion.

I have tested all kind of things, including distant joining all kinds of stations and diagonal highlighting of tiles, but I might have missed some cornercase again ...

Code: Select all

	HT_VEHICLE   = 0x100, ///< vehicle is accepted as target as well (bitmask)
	HT_DIAGONAL  = 0x100, ///< Also allow 'diagonal rectangles'. Only usable in combination with #HT_RECT or #HT_POINT.
	HT_PREVIEW   = 0x200, ///< used for CopyPaste Preview
	HT_DRAG_MASK = 0x2F8, ///< Mask for the tile drag-type modes.

These numbers seem to work while fixing the tilehighlighting for the copypaste patch ... but I wonder ... if HT_VEHICLE and HT_DIAGONAL can use the same bit, why is this not like this in trunk (to save space) and can others be joined maybe?

I'd use HT_DIAGONAL=0x200; HT_PREVIEW=0x400; HT_DRAG_MASK=0x4F8. In that way you can at least identify each case uniquely.

Yes there is room for improvement in the enum (and I have a patch for it somewhere). However, there are more things wrong with the code. In particular, I don't understand some parts of it (where it computes what to do next, and later use that (sorry, I have no source here so I cannot give you more details)).
I am considering to break it all up in smaller parts, but how is a topic not yet decided.

[ChillCore]

As long as you make both HT_VEHICLE and HT_DIAGONAL a single bit, and not part of HT_DRAG_MASK, it should work w.r.t. trunk.
I was not clear here, I meant both a single bit && HT_VEHICLE != HT_DIAGONAL. Sorry for the confusion.

... snip codeblock ...

I'd use HT_DIAGONAL=0x200; HT_PREVIEW=0x400; HT_DRAG_MASK=0x4F8. In that way you can at least identify each case uniquely.

Ok, that works also ... I figured it would not as I tried 0x300 and 0x3F8 and that crashed the game ... seems I was wrong.
So if /when something else gets added to tilehighlighting that uses 0x400 I need to change HT_PREVEW to 0x800 to keep it working?

Yes there is room for improvement in the enum (and I have a patch for it somewhere). However, there are more things wrong with the code. In particular, I don't understand some parts of it (where it computes what to do next, and later use that (sorry, I have no source here so I cannot give you more details)).
I am considering to break it all up in smaller parts, but how is a topic not yet decided.

Looking forward to that Alberth. No need to hurry though, I have plenty of stuff to fix already.




I will first update my source to current trunk, which may take some time with the codechanges in smallmap_gui.cpp and post a new version with the above fix so non-selfcomiling players can have a (somewhat) non crashing version again to continue their games.
Then I will test some more to fix the vehicle profit in combination with the daylength patch and restoring the savegame compatibility with current trunk.
Update coming soon(TM).

[clarklawson]

Thanks for the pack, I'll be looking to use it for the first time this week.

It took me a while to get it working on windows but downloaded the win32 binary that was on a few pages previous.

[clarklawson]

Thanks for the pack, I'll be looking to use it for the first time this week.

It took me a while to get it working on windows but downloaded the win32 binary that was on a few pages previous.

Is there any reason why I can't apply GRFs during a game but they're listed on the 'New GRF' window on the start-up screen?

As I want to apply my usual prefix to a scenario that I use - and I can't apply them to the scenario either.

Any ideas?

[Arie-]

It's a feature from trunk: people screwed up their savegames by adding or removing newgrfs or changing their parameters. Then come in and complain about a bug they introduced themselves as newgrfs are a part of the game, not simple plugins one can turn on or off at any given moment.

[ChillCore]

Is there any reason why I can't apply GRFs during a game but they're listed on the 'New GRF' window on the start-up screen?

As I want to apply my usual prefix to a scenario that I use - and I can't apply them to the scenario either.

Any ideas?

As Arie- explained.

When you make a new scenario the GRF preset from the main menu is used.
Adjusting that afterwards for an existing scenario in the scenario editor is the same as adjusting that ingame and will give errors in most cases afterwards.

If you must edit a scenario (because of no available vehicles or whatever)... try the "scenario_developer" setting in the config file but be warned that in most cases you will not get (much) support if things go wrong.
Devs (-> clean OpenTTD) will not bother and I will not search for long neither as those errors are buggers to find and can not be solved in most cases other than restarting a game/scenario and not modifying GRFs.

Also,
If you are playing with the windows binary for v11_6 do not try to distant join stations. The game will crash.
Instead do it like before it was possible to distant join stations. (-> Build connected stations and use the bulldozer tool to seperate them afterwards.)
In the next version this will be fixed.



@ everybody:
I have found a way to use "waypoints" in combination with autoseparation.
Replace waypoints with station tiles and use the non-stop via order.

[dimon22_g]

Chill, here is my question from another post.
I am playing now another game with 2cc trainset (version 2.0.0 beta 4.1) and nutracks (version r112 downloaded from online content) and I have a question - how can I find on the smallmap where I have what type of rails? All of them just seems to appear as black rails, regardless of their maximum allowed speed. After I did updrage to next level, I am not really sure if I missed some parts or not and maybe took even more then was actually needed.
Thanks for the help.

[ChillCore]

I would have to re-read my discussion with Eddi (see link in the second post) about that to be absolutely sure but IIRC his choice was to have all rails black because it was more clear when the signal states are drawn also on the rails with his patch. (Green to red depending on how long a train is waiting there)
For the moment there is no option to see the different railtypes in the smallmap with the patchpack so you will have to check using the main gui.

I have to dig in the smallmap_gui code anyway to bump to trunk, I'll have a looksie if I can fix it while I am there.
To fix it there are three options:
- Draw the rails a different color as in trunk.
- Make the stuck trains option a seperate view. (eg. like for the CargoDist linkgraphs) and draw them black there.
- Make a switch that allows to select the track colouring in that view.

What is your opinion on what would be the best option?

Feel free to discuss this issue here or in the stuck train thread. (I have not changed anything in that patch to fit the patchpack, yet)

[Melfice]

Looking way back at the beginning of the thread, whatever happened to the idea of adding the "Grass on Tracks" patch?

Interference with some (all?) of the other patches, or did you never get round to adding it?
'Cause it's a fairly fun eye-candy patch, in my opinion...

[dimon22_g]

Well, in my opinion, stuck train is useful functionality, so it has to be properly shown. So, definitely first one is not an option at all. Best (most intuitive) if you do it as a separate view. However, when you dig into the gui, check what is easier to implement, if anything possible.

p. s. I will also have to check how this is working in the trunk.

[ChillCore]

Looking way back at the beginning of the thread, whatever happened to the idea of adding the "Grass on Tracks" patch?

Interference with some (all?) of the other patches, or did you never get round to adding it?
'Cause it's a fairly fun eye-candy patch, in my opinion...

Funny you ask now.
It conflicts with the stuck train patch as both use the m7 bit ... see link in second post.

I had it in one of my first patchpacks and I like also but it is rather CPU intensive ... as is routemarkers.
If you want I can send you my old patchpack but it is rather old (+- r14600) and quite buggy.
My old patchpack had:
- company info v2 patch
- copy_paste_r14589.patch
- r14239-daypatch.diff
- filter_by_cargo_r14564.patch
- improved-breakdowns-v2.4-r14563.patch
- less_clicks_r14400.diff
- map-M1-13664-fixed.patch
- more_cond_orders+stop_in_depot-r14503.patch
- MMS_v1_081005_r14339.patch
- opengl_r14405.diff
- poldtracks[1].14450.diff
- routemarkers-r14545.patch
- timetable-management-v230-rimproved14647M.patch
- Town_funding_network_safer.patch
(Do a forum search for the filenames if you do not know what the patches above refer to.)

In a later (test) version I added some early versions of the more heightlevels patch and the edges patch(just before it hit trunk) in it also. I have backups of different versions and might have to search a bit for the newest version ...

Also kgat had it, of which there should still be an extended version in the more height levels thread with 1024 heightlevels for testing. (including, at that time still excisting, bugs.)

There are a few more patches that I would like to add myself and I have a requested patches folder .... but first I should get the current version somewhat stablish befor adding new problems, IMHO.

Well, in my opinion, stuck train is useful functionality, so it has to be properly shown. So, definitely first one is not an option at all. Best (most intuitive) if you do it as a separate view. However, when you dig into the gui, check what is easier to implement, if anything possible.

I think the easiest (and least amount of code to add) would be a switch in the advanced settings.
If that would be the best option is another matter.

[Melfice]

Oh, I'm quite happy with the current patches, so no need to send me that old one.
And if it doesn't work... it doesn't work. Simple as that.

[Alberth]

Ok, that works also ... I figured it would not as I tried 0x300 and 0x3F8 and that crashed the game ... seems I was wrong.

0x300 = 0x100 + 0x200 (in terms of single bits[1]), thus you made HT_PREVIEW = (HT_VEHICLE | HT_DIAGONAL). I am pretty sure that causes chaos. If it doesn't, then the drag mask of 0x3F8 will, as HT_VEHICLE and HT_DIAGONAL must stay outside that mask. (Tile highlighting enum has plenty of room to mess up )

[1] Due to the binary nature of computer systems, a 'single bit' means a value that is a power of 2 (1, 2, 4, 8, 16, 32, ...). In hexadecimal notation it is an easy pattern, since 1 hex digit represents 4 bits. (0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80, 0x100, 0x200, ...). The trick of using hexadecimal numbers is to read it as a bit pattern rather than as a number.

So if /when something else gets added to tilehighlighting that uses 0x400 I need to change HT_PREVEW to 0x800 to keep it working?

I would assume so yeah.