KING.TXT - What does it do?

[krille]

I was fiddling around just now with CivDOS in a MemoryEditor (was playing around with offsets, mainly changing my Civilization in-game) but I soon managed to mess the game up very bad (the GUI got psychedelic television snow all over, a lot of weird messages got spammed all over, weird terrain features, terrain got visible that should've been, the Shift+56 cheat got enabled (YES, it's true! Shift-56 got enabled at V05), etc), so I quickly terminated the process avoid any permanent harm to the game files.

To my horror I quickly noticed that CivDOS had managed to modify the KING.TXT file the very moment CivDOS turned into madness. I do have a backup of all the original game files, but I'm wondering what possibly could've been changed in KING.TXT and whether reverting it back to the original will cause any side effects (may it cause old savegames to bug out or something)?

What does KING.TXT do?

I doubt it's a "read-only" containing only the obvious text strings, as there would be no reason to have program code changing the file in that case.

 

[Urtica dioica]

The timestamp on my KING.TXT is 2003-03-08 15:20, years before I started playing. It should never be written to under normal circumstances it appears. Since the contents are just a bunch of text strings with parameters marked to be replaced, sort of like C's printf, I can't imagine why it would be edited anyway.

If you're in a unix derivative, you can diff the file and its backup. On another OS you may find something similar. Maybe take a checksum to see if anything changed at all?

 

[krille]

I did CRC32 check the file, it was changed. Nothing was noticeable, however, when differentiated by my eyes in NotePad. (However, there's a lot of nontext data in it too.)

My original KING.TXT is from after applying the v05 patch (although iirc the patch only meant a new executable) and the timestamp says it was last changed 1991-12-02 13:56. So obviously something must've happened to yours? (Maybe just a copy with a new date?) What's your checksum?

My checksums:

Original CRC32
KING.TXT: D8CF22F9

Corrupt(?) CRC32
KING.TXT: 1632F814

I guess a "Read" instruction could've been accidentally corrupted into a "Write" one or something.

 

[Dack]

I've seen this over the years don't know what it is. That group of Hex33 was written.
I once tried changing all civ files to read only. I think that king.txt is the only one that CIV updates. Except for this section of the file the rest remains the same.

File: KING.TXT
Original file

Offset hex. 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 
000000000:  30 30 30 30 DA 07 30 30 30 30 30 30 30 30 30 30 0000Ú.0000000000
000000010:  30 30 30 30 30 30 30 30 30 30 C2 20 30 30 30 30 0000000000Â 0000
000000020:  A5 04 35 15 33 20 30 30 30 30 3B 09 42 0D 30 30 ¥.5.3 0000;.B.00
000000030:  30 30 30 30 30 30 45 16 30 30 30 30 30 30 30 30 000000E.00000000
000000040:  0D 0A 30 30 30 30 30 30 30 30 30 30 30 30 30 30 ..00000000000000
000000050:  30 30 30 30 30 30 0A 07 68 0A 30 30 30 30 30 30 000000..h.000000
000000060:  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
000000070:  30 30 AF 13 30 30 30 30 30 30 30 30 30 30 2C 13 00¯.0000000000,.
000000080:  30 30 0D 0A 30 30 30 30 F7 0A 30 30 30 30 30 30 00..0000÷.000000
000000090:  30 30 3C 18 30 30 6D 0F 30 30 30 30 30 30 30 30 00<.00m.00000000


Modified
Tuesday, October 30, 2007, 2:58:30 PM

Offset hex. 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 
000000000:  30 30 30 30 DA 07 30 30 30 30 30 30 30 30 30 30 0000Ú.0000000000
000000010:  30 30 30 30 30 30 30 30 30 30 C2 20 30 30 30 30 0000000000Â 0000
000000020:  A5 04 35 15 33 20 33 20 33 20 3B 09 42 0D 33 20 ¥.5.3 3 3 ;.B.3 
000000030:  33 20 33 20 33 20 45 16 33 20 33 20 33 20 33 20 3 3 3 E.3 3 3 3 
000000040:  0D 0A 33 20 33 20 33 20 33 20 33 20 33 20 33 20 ..3 3 3 3 3 3 3 
000000050:  33 20 33 20 33 20 0A 07 68 0A 33 20 33 20 33 20 3 3 3 ..h.3 3 3 
000000060:  33 20 33 20 33 20 33 20 33 20 33 20 33 20 33 20 3 3 3 3 3 3 3 3 
000000070:  33 20 AF 13 33 20 33 20 33 20 33 20 33 20 2C 13 3 ¯.3 3 3 3 3 ,.
000000080:  33 20 0D 0A 33 20 33 20 F7 0A 30 30 30 30 30 30 3 ..3 3 ÷.000000
000000090:  30 30 3C 18 30 30 6D 0F 30 30 30 30 30 30 30 30 00<.00m.00000000

 

[Urtica dioica]

It took a while to find a way to get a CRC32 on Linux, since no one would bother with such a weak checksum. But I found it, and mine matches your original.

Having a read corrupted to a write wouldn't do it, unless the file was opened in the wrong mode to begin with (DOS does it that way, right?). I'm curious how you could manage to corrupt memory that badly. Of course, being DOS, you could have modified kernel code as well.

As I said, if you really want to know what happened, you need a diff tool. Manually poking around in Notepad doesn't count. (You use Notepad?!) If you know even a little programming, you could have written your own tool already. If you use unix, you could have solved it in under 30 seconds.

 

[krille]

I could've (and should've) made an MD5, but CRC32 is enough in most cases and is the default checksum in the program I use (by the time I made my post here I had already replaced my changed file). The biggest problem, I guess, with CRC32 is not it's weakness, but that it isn't standardized. Thus it was very poor judgment on my part to use it, especially for cross-system comparisons. Let's all agree on MD5 for future comparisons as it's not only much better and safer but also standardized.

Another file, that was changed today after a similar 'accident' is: ERROR.TXT
I replaced it with a backup without bothering to check it.

MD5 checksums of the original files.

;         1823  10:39.30 1991-12-02 ERROR.TXT
;         8535  13:56.14 1991-12-02 KING.TXT
303339faa64ef5f23b6f9b788dca1713 *ERROR.TXT
5b410d6e0f10f96e642615848151898c *KING.TXT

edit: Urtica dioica > I wasn't that interested in the changes really, I was mostly interested in what it does/why it was changed if anyone knows. Like I said, I had already replaced the file upon posting here (bad practice but whatever). I used notepad because it was a .TXT (it was the first time I bothered to open the actual file) and if something had gotten really messed up I'd spot it very quickly (which I didn't, thus the CRC32 to see if they're at all different, they were...).