Reply to Re: freedinkedit is stuffed
If you don't have an account, just leave the password field blank.
I suspect there may be an issue in DINK.DAT
I haven't checked your new version, but I know exactly what the problem is: When creating a new map, the size of map.dat is used to determine how many maps are currently in use, so it gets the new map number from that. Then it writes that ID to dink.dat.
The problem is that it uses the size of a clean struct for this computation, as opposed to the thing that is actually saved which contains a lot of unused junk. So when there are 10 maps in map.dat, the actual size of it (if it works well) is 10*N, with N the large size of a single map screen. But it then computes the id of the next map using (10*N)/n, with n the small size of the junkless single map screen. That's a pretty big number, much bigger than it should be. And it gets bigger when the map gets bigger. So the map number explodes, and when writing a map screen with a very high id, it will seek to its position in map.dat, thereby expanding it to whatever size it needs for that.
So my original explanation was wrong: this is not a 64 bit issue; in fact, it's worse on 32 bit, because the packed struct is even smaller there.
Anyway, you have replaced the code with something new, so unless you introduced the same error in the new code, which is unlikely, it will be fixed by that.
I haven't checked your new version, but I know exactly what the problem is: When creating a new map, the size of map.dat is used to determine how many maps are currently in use, so it gets the new map number from that. Then it writes that ID to dink.dat.
The problem is that it uses the size of a clean struct for this computation, as opposed to the thing that is actually saved which contains a lot of unused junk. So when there are 10 maps in map.dat, the actual size of it (if it works well) is 10*N, with N the large size of a single map screen. But it then computes the id of the next map using (10*N)/n, with n the small size of the junkless single map screen. That's a pretty big number, much bigger than it should be. And it gets bigger when the map gets bigger. So the map number explodes, and when writing a map screen with a very high id, it will seek to its position in map.dat, thereby expanding it to whatever size it needs for that.
So my original explanation was wrong: this is not a 64 bit issue; in fact, it's worse on 32 bit, because the packed struct is even smaller there.
Anyway, you have replaced the code with something new, so unless you introduced the same error in the new code, which is unlikely, it will be fixed by that.
