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).
 
darkpanda said:
During my journey inside the map generation code, I figured out this code was also setting up the values of the data block unknown25, which is apparently some kind of high-level path-finding data, i.e. data meant to help the Civ AI moving units around the map in an optimal way.

The funny thing is that the Civ code setting up this data seems to wrong - although it may not matter in the end...
[...]

5. Can it be fixed? Should it be fixed?

I am actually very interested in discovering what Civ would do if accessing the data properly...

But then I am also wondering: if this bug has always been here, in all versions of Civ (to be confirmed) is this data actually used at all by the Civ's AI code? In oterh words, even if it is corrected, is it going to change anything in the game?

I guess answers to those questions will come in the next episode...
Click to expand...

Sorry to activate this old thread ;) But, working on OpenCiv1 gave me insight into internals of Civ that was not possible before.
The code that actually uses Land Pathfinding values is only in UnitGoTo segment (0x2e31, version .05).

Further investigation into GoTo code revealed that GoTo code is full of errors (doesn't work properly, and, to make things worse overwrites data at random locations) and that actual Land Pathfinding table is not important for Civ to function properly.

By Sid's own admission (I read it in one of his interviews, citation needed) "The Go To function was one of the last features added to Civ"

I guess bunch of testing code remained behind (not actually doing anything!)
 
GoTo command as cosmetics for the human player may indeed have been added at the last minute. But AI uses the same pathfinding for its movement and some pathfinding is necessary for AI so I think it was added early.
 
tupi said:
GoTo command as cosmetics for the human player may indeed have been added at the last minute. But AI uses the same pathfinding for its movement and some pathfinding is necessary for AI so I think it was added early.
Click to expand...
Yes, but as @darkpanda mentioned before that this table is generated with wrong data anyway, so, it serves no purpose for any kind of movement. The AI movement is basically: I want to move from point A to point B and that's it. Will need to rewrite the entire GoTo code to make things behave correctly and stable!
 
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
744
Lord_Hill
L
I
Map Analysis and Optimization with Image Processing and Linear/Binary Programming
Replies
6
Views
814
dom111
dom111
rhaul
Edit avanced Trade
Replies
4
Views
984
rhaul
rhaul
Top Bottom