SVE file format

darkpanda said:

Cities

 (back to table)
Data range/length: [5384:8967] / 3584 bytes - (hex: [0x1508:0x2307]/0xE00)
  • each City data is a 28-byte data block, as described below:

    Offset/start||Size|Data
    dec|hex||
    ......
    26|1A|2| unknown

    unknown

    • Bytes whose usage is still unknown yet

Click to expand...


Those 2 "unknown" city bytes must be split into 2 bytes (unknown27 and unknown28), that have a seemingly identical role, yet still quite obscure...

The only thing I discovered so far, is that each byte's 8 bits are used as follows:
Code: 
    unknown27 :  7 6  |  5 4 3 2 1 0
    unknown28 :  7 6  |  5 4 3 2 1 0
        usage : flags | 6-bit-encoded Unit Type
The flags specify whether the unit is fortified (bit 6) and/or veteran (bit 7).
The Unit Type, obviously, specify the type of the unit...

But of course, the big question is: what are those units?

I am currently going through one of the biggest subroutine of CIV (City processing routine) and hope to discover more, but my guesses point somewhere between "units that protect the city", "units that count for happiness or unhappiness" or "units that where just built last turn" ... Although none of them are satisfying.

Another problem is that in most gamesaves I have, those bytes have value 0xFF... I only have a single SVE where only 1 city has the value of unknown27 set to 0x45, which codes for 01000101 = fortified, non-veteran, Riflemen. And indeed the city contains a fortified non-veteran Riflemen, but so do many other cities, and their unknown27 and 28 bytes are still 0xFF.

Well, I'll keep looking...
But if anyone has a gamesave with other values as well, I'm interested!
 
Gowron said:
game.civ0.unit0.unknown_unitbyte9 ubyte 9928 1 0 26C8
Click to expand...

Update about this value:
It's a map direction, coded as a value between 1 and 8. It's set to -1 when there's no direction to save.

However, I still don't know what this direction is used for. It seems to have something to do with the GoTo coordinates. Maybe it's just the current GoTo direction of the unit.
Click to expand...

darkpanda said:
I think the latter is the correct one, it also matches the order in which roads and railroads sprites are stored in SP257.PIC

Maybe it's a "cached" value for AI units in GoTo mode, for example "next move" ?

From my experience, Civ will determine that a unit is in GoTo mode if its "GoToX" attribute is not -1 (0xFF), in which case it uses GoToX and GoToY as the GoTo destination... Some trial and error needed here, I guess.
Click to expand...


While pursuing a clean-up the remaining mysteries of SVE format - including the obscure byte -, I spent the last few days porting the "unit path finding" code from CIV.EXE, and I can now confirm that this byte codes for the next square direction in order to reach the GoTo destination. Its possible value follows the first list proposed by Gowron:
  • 1 = north
  • 2 = north-east
  • 3 = east
  • 4 = south-east
  • 5 = south
  • 6 = south-west
  • 7 = west
  • 8 = north-west

On a side note, I made many discoveries while browsing this code, most notably I found out why GoTo moves ignore the effect of RailRoad... Maybe a patch on the way? ;)
 
I was wondering about that. Also, I noticed in one of my previous threads that railroad is only for ground units, is there a way to allow water units to use them as well?
One more thing, I noticed that if you change the number of moves a unit can move, the goto doesn't use the new value. I don't remember which save I did it on, so I'll go figure that out later.
 
Having a second look at it, the part of the GoTo code that ignores railroad is only the part that selects the next square to move to, not the code that actually decrements the number of remaining moves: when selecting the next square, Civ computes a score (a 'cost' actually) for each neighbour square, based on distance to destination, roads on the square, unit's total moves, change of direction (yes indeed, CIV thinks it is more costly to make a right angle turn that continue straight ahead...), etc. This is where I saw that presence of RailRoad doesn't matter, the neighbour will be considered to consume 1/3 of move even if there is railroad.
 
darkpanda said:

Diplomacy

 (back to table)
Data range/length: [1608:1735] / 128 bytes - (hex: [0x648:0x6C7]/0x80)

  • Diplomatic status of a Civ:
  • this is a series of 8 shorts (8*2 = 16 bytes)
  • each of the 8 short describe the status between the Civ and one of the 8 other Civs (seems to include Barbarians…)
  • each short value is a bitflag whose bits describe a particular diplomatic status
  • currently known bits are as follows:
    Code: 
    bit | meaning of bit value = 1
  0 | at war 
  1 | at peace
  2 | alliance
  3 | vendetta
  4 | ?
  5 | ?
  6 | embassy established
  7 | ?

  8 | ?
  9 | ?
 10 | ?
 11 | ?
 12 | ?
 13 | ?
 14 | ?
 15 | ?
  • this series of 16 bytes is repeated 8 times, once for each Civ (totally 8*16 = 128 bytes)
Click to expand...

It seems that bit 7 is related to nuclear power or nuclear threats: when the Diplomatic screen routine starts, CIV sets this bit value to 1 if the foreign Civ possesses more than 1 active Nuclear.
 
darkpanda said:

Cities

 (back to table)
Data range/length: [5384:8967] / 3584 bytes - (hex: [0x1508:0x2307]/0xE00)

  • Cities
  • there are totally 128 data blocks representing the 128 possible cities supported by CIV
  • each City data is a 28-byte data block, as described below:

    Offset/start||Size|Data
    dec|hex||
    ...
    ...
    26 | 1A | 2 | unknown
Click to expand...

Finally, these 2 unknown bytes, very much look like an additional way to store units... Typically, if a city contains 1 or 2 fortified units whose the city is the Home city, then those units are removed from the Units slots and stored inside those 2 city bytes instead, using up only 1 byte per unit: 2 bits coding for veteran / fortified, and 6 bits for the unit type id.

These 2 unknown bytes are named "unknown 27" and "unknown 28" in JCivED's city screen.

For example, if you change the value from 255 to 5, you get a fortified Riflemen, and 3 gives a fortified Legion, without changing anything to the Units data...
 
Gowron said:
Diplomatic status flags which I've identified so far:

0x01 = War
0x02 = Peace
0x04 = Alliance
0x08 = Vendetta
0x40 = Embassy
Click to expand...

It seems very typical for both the War and Peace flags to be true. What does this translate to? Is it possible that one of these is simply an indicator of having made contact with the other civilization?
 
darkpanda said:


  • Wonders

     (back to table)
    Data range/length: [34418:34461] / 44 bytes - (hex: [0x8672:0x869D]/0x2C)

    • Wonders
    • this data element is a short integer (2 bytes) that occurs 21 times, once for each Wonder
    • it is the ID of the City where the Wonder with the current offset ID (TODO: ref table of Wonders) is built
    • if the wonder is not built yet, this value is 0xFFFF (-1)
    • if this city ID is *not* 0xFFFF and the city corresponding to this ID has size '0' (city destroyed), then the Wonder is marked as Destroyed by CIV
Click to expand...


  • Looks like there might be 2 bytes missing... 21x2 = 42. Are there actually 22 wonders?
 
Question for you guys... Are the continent IDs stored somewhere in the MAP or SVE files? Or are they recalculated after opening the map? I assume it would be something like an 80x50 matrix where each value is a continent ID (or ocean ID).
 
This sort of thing (file format reverse-engineering) has always fascinated me. Awesome work, everyone! I like playing CivNet, though. Has anyone looked at the format for that? I've been poking around some CivNet save-game files a bit and learned some things, but I don't want to reinvent the wheel. Is there a thread discussing that? The content must be very similar, but the format looks different. The biggest change I've noticed is that there is some sort of run-length encoding going on, and variable-length fields.
 
Maybe just I didn't see it but have you discovered tile improvement visibility data bits? Or is that in MAP file?

Or do I remember wrong and and improvements are always visible on seen terrain?
 
darkpanda said:
This is actually the next turn when Civ Rankings will be displayed (when a famous anthologist finishes his epics...).

This value is calculated by Civ as follows:
- At the start of the game, it is a random value between 0 and 50 (exc.)
- Whenever the turn is reached, the next turn is computed as: current turn + 20 + a random value between 0 and 40 (exc.)
Click to expand...
Wow, I finally found this info! (of course I read this thread before but I totally forgot about it!). I used approximate numbers from many tests. It was almost right. Almost.

At the start of the game there's should be additional component, I guess 80. 80+random(50). Values from tests vary from 80 to 127 (from 25 tests).
 
You must log in or register to reply here.

Similar threads

tupi
Civil War in Civ1
Replies
12
Views
2K
tupi
tupi
tupi
Barbarian Great Library bug: investigation
Replies
3
Views
1K
rhaul
rhaul
H
A new challenge of patch ! (as a Christmas gift ...)
Replies
4
Views
739
Lord_Hill
L
I
Map Analysis and Optimization with Image Processing and Linear/Binary Programming
Replies
6
Views
812
dom111
dom111
rhaul
Edit avanced Trade
Replies
4
Views
983
rhaul
rhaul
Top Bottom