I tried using m8 before but that does not exist ...Melfice wrote: 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.
It might work if/when "stealing" some free bits somewhere else, but I have not invested time in trying to do so.
Feel free to try and merge the two patches to get them to work if you want. If you are succesful I'll add it.
The system load caused by the grass on tracks patch can be disabled by disabling the "show all details setting".
I understand now what I did wrong.Alberth wrote: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 )ChillCore wrote: Ok, that works also ... I figured it would not as I tried 0x300 and 0x3F8 and that crashed the game ... seems I was wrong.
[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.
It works in the same way as you would set the parameters for the ECS vectors, just add bits together to get the result you want.
But when writing such GRF (or code) make sure that you can never get to the same result by adding different bits together.