PlutonianEmpire said:
How's my knowledge? All i know about it is that eight bits make up a byte or something like that. Sorry.
OK,
this webpage should help you familiarise yourself with those terms and concepts. After scanning that tutorial you should be able to recognise that a byte has the following range of values:
Binary (base 2): 00000000 11111111
Decimal (base 10): 0 255
Hexadecimal (base 16): 0 FF
Below is a screenshot of AXE showing the beginning of a Civ2 .sav file. In the
Bytes column, raw bytes are displayed as 2-digit hexadecimal numbers (00 FF). Bytes are identified by their offsets (the position number in the file). The offset for the first byte in each row is displayed in the
Offset column, the first byte in the file being zero. By default these are also displayed in hexadecimal. Clicking the column heading changes them to decimal. In this example the number of bytes per row has been set at 15 (it's adjustable) to keep the screenshot down to an acceptable size. Notice that the current selection is indicated in the status bar; in this case byte 10. The
ANSI Text column can be useful for editing strings, eg, "CIVILIZE".
So how do I know which bytes to edit? The complete structure of the .sav/.scn file is not known, but a good proportion of it has been documented. For information on the Civ2 .sav file format, read Allard Höfelt's hex-editing article (the Scenario League's Hints, Tips and Guides threads are down, so I'll attach it here). It covers vanilla Civ2, FW and MGE. It doesn't include ToT, but the basic format is very similar. I began to compile a file format document for ToT (in HTML) at the beginning of the year, but guess what? I'm a lazy bugger and didn't finish.
Once you have the byte offsets, you're set to go. In the case of the Leaders2 table, I've already supplied that information (in the
Restricting Technologies article). Anyway, before you start editing anything, make sure you backup the original file first, especially if you're unsure as to what you're doing.
Hex editing the Leaders2 table is a good place to start because it's very easy. This is because each digit in the @LEADERS2 table from rules.txt represents a single byte with a value ranging from 0 to 2. Open your .sav/.scn file in your hex editor. The first byte in the Leaders2 table is located at offset 29728. This value is a constant for all ToT scenarios. In AXE, click the
Goto button (or Ctrl+G), check the Decimal Offset option and type in 29728. Other hex-editors should have a similar 'Go to' function.
This will present you with the Leaders2 table in the game file, an 8 x 21 byte matrix. After resizing the
Bytes column to 8 bytes per row, it compares very easily to the @LEADERS2 table in rules.txt. This is the Leaders2 table for a Fantasy game:
Here's the same table in rules.txt:
Code:
@LEADERS2
02012220
02212220
02012202
02212022
02210220
02212220
02212220
02012220
02212220
02012202
02212022
02210220
02212220
02212220
02012220
02212220
02012202
02212022
02210220
02212220
02212220
Making changes to this table in the .sav/.scn file should be a piece of cake. No further explanation is really required. Change the byte values to reflect your new technology settings and then save. It's much simpler than using EnableTechnology events.
PlutonianEmpire said:
Also, when i converted just the .scn file to ToT, i had this problem where the entire ToT program crashed whenever the PE's turn came up when loading the scenario (the game starts with the barbarians' turn. it is a modern-day-earth scenario). I started out as the russians, and the game started fine. but when i switched human players to USA, i did see the PE beat up USA for a while, but once the PE'ian turn ended, the game crashed, and had to be shut down and restarted.
The problem can't be identified from that information. Often labels.txt will cause crashes, but that normally occurs as soon as the scenario is loaded, so that's not likely. For some scenarios CivConverter produces errors in the .scn file which cause it to crash. Fortunately these scenarios are few and far between. If you're unlucky, yours maybe one of them. There's no known fix. Then again it's possible that the problem is completely unrelated to CivConverter there could be an error in the original scenario for instance.