Daylength hack

[mtwist]

Hi,

due to the fact that the gamespeed is too high for enjoying all of the nice features offered by the patch I developed a hack to modify the daylength. It is currently a bad exe hack but I am working on the code to include this into the patch. I hope I will fully understand the patch coding soon .

I am not sure if I break the board rules with this description, so please moderators delete this topic if I do so. And sorry for that.

The hack is currently only available for the windows version. It modifies GameGFX.exe file, so you better copy the file before.


Open the GameGFX.exe with a hex editor.

Search for the string 67 E2 C1. The daylength value is 14 bytes after the occurence of this string. (In german version of GameGFX.exe it is address 0x151c9f). You will find the bytes 75 03 there. This is the default value 0x375 for daylength delay (be careful, the bytes are swapped).

Now decrease this hex value. A small value means a long daylenth. The smallest possible value is 0x1, which results in a daylenght of around 25 minutes!

Save GameGFX.exe.

If you are useing TTDpatch delete the TTDLOADW.OVL file.


Note: There are no calculation adaptions at the moment. When the daylength is very high, the running costs will get negligible, because they are calculated on daybase. On the other hand you will earn more money per day. So the balance between costs and income is not longer the same. I will clarify the impact and try to fix this for the switch in TTDpatch.

[m3henry]

sounds interesting, longer games

[Patchman]

Go to address 0x151c9f. You will find the bytes 75 03 there. This is the default value 0x375 for daylength delay (be careful, the bytes are swapped).

That will only work with one specific language version of gamegfx.exe, the offsets are different in each version...

[mtwist]

Oh, thanks for that hint. I used the german version. Instead of useing the address 0x151c9f one should search for the unique string 67 E2 C1. The daylength value is 14 bytes after the occurence of this string. I really must get into the patch coding

[uzurpator]

This... is... ubercool!!!

EDIT:

Hehe - checked that value of 0x22 gives a nice 30 second day. However this does not multiply the running costs accordingly - so with 30 second day (which is about 10 times longer) the train will not cost 10 times more to run.

Nonetheless - this is very cool

[Dave]

Hmm is there any chance of this becoming part of the Patch, patchman?

With proper changes of course

I can't do these hacks.

[m3henry]

if it does, it will be near the middle of the list meaning patchman is doing something more important (fun/great )

[mtwist]

Hehe - checked that value of 0x22 gives a nice 30 second day. However this does not multiply the running costs accordingly - so with 30 second day (which is about 10 times longer) the train will not cost 10 times more to run.

This is exactly what I meant with disturbed balance...I will try to integrate the hack into the patch as fast as possible - including an adapted calculation of running costs. But I am not sure yet, if it is that easy. A possible workaround would be a general multiplier for the running costs.

[stevenh]

mtwist: congratulations, you've done something I half-promised to look into a while back.
Integrating this into the patch would be quite simple (if you chose to hardcode the changed timespan) until it came to the actual ability of changing the parameter.
Josef will be able to help you with that.

As far as running costs are concerned; I don't see that they really need to be modified?

This is quite a welcomed addition actually, finally my trains can arrive at their destination in the same day (especially since they only have to travel very short distances).

[mtwist]

Josef will be able to help you with that.

I am already in contact with Josef .

As far as running costs are concerned; I don't see that they really need to be modified?

For me that's the same, but it would be nice to have an option for adapting the calculation. Currently TTD increases a DayPart variable every twelve ticks (or clock cycles, I am not sure with that) with the delay value of 0x375. When this addition causes an overflow (bigger than 0xFFFF) the day is over and another Date variable is increased. In addition all necessary claculations are done. A possible adaption for the running costs would be the following:
- Increase the DayPart variable as it is.
- Include a new variable, let's say DayLength which is increased, when DayPart causes the overflow.
- All calulations are done now, but the Date variable won't be increased. This will be done, when the new DayLength variable reaches the given delay value.

I haven't clarified yet how the running costs are calculated and if it is date depended or only triggerd by the overflow mentioned above.

[jacke]

Very interesting, this feature in the patch would be really great! Good luck mtwist!

[Hyronymus]

Can we welcome you to the Patch Dev team yet, mtwist? I assume you have a throrough knowledge of assembly if you found this stuff out . Looking forward to testing this feature, although it might get boring somewhere down the line.

[ISA]

you've done something I half-promised to look into a while back.

Yay my sugsesion what I offer wile back is in progress. Keep up the good work

[mtwist]

Can we welcome you to the Patch Dev team yet, mtwist? I assume you have a throrough knowledge of assembly if you found this stuff out .

I started to check out the required work for getting into the patch coding. Assembly coding should not be the problem, because I have some experience, currently it is only the stuff to get the changes into the patch that causes some problems. But I am sure I will solve them

[ISA]

OK I wanna make days longer but im doing something wrong i found that string 67 E2 C1 there i read 14 bytes.... and there is

Code: Select all

75 03 OF etc

SO I changed this 03 to 22 and day is going faster. Hmmm explain me please that part. What "code" I must add to have 30 sec days.

[Dave]

Now decrease this hex value. A small value means a long daylenth. The smallest possible value is 0x1, which results in a daylenght of around 25 minutes!

LOWER numbers mean longer days. 22 is NOT lower than 3.

[DaleStan]

Actually, thats "0x2275 is not lower than 0x0375". Remember what m3henry said about the bytes being reversed.

[Aegir]

That was mtwist, Dalestan. Not m3henry.

[mtwist]

DaleStan is absolutly right. The bytes are swapped in the exe file. A few examples:

Value 0x0375 would be 75 03 in the file
Value 0x0001 would be 01 00 in the file
Value 0x0022 would be 22 00 in the file
...

It is also possible to set the value to zero, but then the current day won't end at all...Who does not remind of "Groundhog Day"

[ISA]

Value 0x0375 would be 75 03 in the file
Value 0x0001 would be 01 00 in the file
Value 0x0022 would be 22 00 in the file

Ty I knew I forgot something. Damn zeros
Edit: /me try it and it worked