 |
|
pdescobar
|
|
Hmm. I'm guessing by the name that's a commercial library and so I'm probably not gonna be able to decompress such files on my own in perl am I?
BTW, for those unfamiliar with it, the way to properly invoke the command Gramphos posted from a DOS shell is:
savexpnd.exe "compressed_filename" "uncompressed_filename"
The quotes are pretty much mandatory and I sometimes have trouble with filenames longer than 8.3; now if only I could figure out the proper syntax to call this from inside my cygwin-bash shell...
|
|
| |
|
|
|
pdescobar
|
|
Grr. Double-post. Sorry 'bout that.
|
|
| |
|
|
|
roudoudou77
|
|
thanks Gramphos for your imput
I have also found a source code somewhere in the Net
to decompress pkware compression format. i have checked some SAV files with SAVExpnd to verify it produce the same output correctly
for those interested, the link is :
http://perso.wanadoo.fr/the-home-of.../civ3/blast.zip
|
|
| |
|
|
|
roudoudou77
|
|
Gramphos,
I have made a simple SAV of a game under CIV3 PTW v1.14f and I have obtained some strange data : there is 3 "GAME" section in the file and the last one of the "GAME" section does even not follow the rule :
- section name
- number of sub-section
- lenght of sub-section
then I see many TILE sections , not just 1 like in BIC files ..
that makes me crazy - and my program too - !!!
( I have uploaded the compressed SAV to :
http://perso.wanadoo.fr/the-home-of.../civ3/julo6.SAV
)
could you help me and explain me the difference there is between the BIC format and the uncompressed SAV format ?
|
|
| |
|
|
|
roudoudou77
|
|
OK, now I understand that there is a BIC file "embedded" inside the SAV file , and that the 2 first GAME section belong to this "embedded" BIC .
Next questions :
1) the GAME section that follow the "embedded" BIC is quite strange : it's length is not correctly indicated ?
2) then there is a repetition of CNSL,LEAD,CULT,ESPN sections, it seems to be like garbage ??? I can't figure what those Fireaxis programmers tried to do with that :-(
3) near the end of the file I found many TILE section (it seems there is 1 section for each tile of the game), each TILE section is 180 bytes ; how should these data be interpreted ?
Last edited by roudoudou77 on 26-06-2003 at 03:54
|
|
| |
|
|
|
pdescobar
|
|
quote:
Originally posted by roudoudou77
I have also found a source code somewhere in the Net to decompress pkware compression format. i ave checked some SAV files with SAVExpnd to verify it produce the same output correctly
for those interested, the link is :
http://perso.wanadoo.fr/the-home-of.../civ3/blast.zip |
Yes, I believe this is the code I actually wound up using myself. After looking at Gramphos' CPT source I located a webpage on the compression format and wound up compiling and using Mark Adler's "Blast" package to do the decompression which looks to be what roudoudou77 used for that executable above.
|
|
| |
|
|
|
Gramphos
|
|
ACS Civ III Files Manager, Prince of Development
|
 |
Chalmers, Sweden
Apr 2001
time: 06:19
|
|
quote:
Originally posted by roudoudou77
1) the GAME section that follow the "embedded" BIC is quite strange : it's length is not correctly indicated ? |
The length indication is the length of the GAME header, and the values in the header, and the rules (number of stuff) makes the game to understand how long the data is. I don't know exactly what controls the length, and am using a search to find the CNSL section (which is only a fixed length thing, that I've no idea of what it controls).
quote:
2) then there is a repetition of CNSL,LEAD,CULT,ESPN sections, it seems to be like garbage ??? I can't figure what those Fireaxis programmers tried to do with that :-( |
LEAD, CULT, ESPN, ESPN is the build up for one player. there shall be 32 sets of them in the save. Again the LEAD starts with a header followed by variable sized data. (If you are to work with this one, it's the section that I know most of.)
quote:
3) near the end of the file I found many TILE section (it seems there is 1 section for each tile of the game), each TILE section is 180 bytes ; how should these data be interpreted ? |
IIRC there are 2xTILE for each tile. one short and one long. The shor stores most of the map data, and are quite similar to the tile sections of the BICs, and the longer stores extra data as FOW and city working on a tile.
|
|
| |
|
|
|
BlueWlvrn
|
|
It looks like in the BIX 11.18 version in the TILE section, there are now 4+29 bytes for each tile.
Can anyone tell me where the extra 6 bytes were added with respect to the BIC format posted here?
It looks like they maybe added in between and not appended to the end.
Thanks for the help.
-BlueWlvrn
|
|
| |
|
|
|
Gramphos
|
|
ACS Civ III Files Manager, Prince of Development
|
|
Chalmers, Sweden
Apr 2001
time: 06:19
|
|
The TILE format in BIX 11.18. I can tell what 2 of the bytes are. I can also tell a little more detailed on the other parts. As I've found out that some of it is incorrect.
4 char "TILE"
4 long number of tiles (= width/2 * height)
For each tile:
4 long length of tile data
1 byte river connection info (binary)
00000000
river in north .......1
river in west ......1.
river in east .....1..
river in south ....1...
1 byte border
4 long resource
1 byte image
1 byte file: 0 = xtgc.pcx, 1 = xgpc.pcx, 2 = xdgc.pcx,
3 = xdpc.pcx, 4 = xdgp.pcx, 5 = xggc.pcx,
6 = wcso.pcx, 7 = wsss.pcx, 8 = wooo.pcx
2 short ??? (0)
1 byte overlays (binary):
00000000
road .......1
railroad ......1.
mine .....1..
irrigation ....1...
fortress ...1....
goody huts ..1.....
pollution .1......
barbarian camp 1.......
1 byte terrain
1 byte bonuses (binary):
00000000
bonus grassland .......1
player start ....1...
snow-capped mts ...1....
pine forest ..1.....
1 byte river crossing data (binarry):
00000000
crossing N .......1
crossing NE ......1.
crossing E .....1..
crossing SE ....1...
crossing S ...1....
crossing SW ..1.....
crossing W .1......
crossing NW 1.......
2 short ??? (-1 = nothing, 75 = barbarian camp)
4 long ??? (-1)
2 short continent
1 byte ???
2 short VictoryLocation (VL if 0 otherwise -1)
4 long ???
|
|
| |
|
|
|
BlueWlvrn
|
|
Thanks Gramphose for the additional information.
Do you know how the image number in the TILE section maps to the terrain PCX files?
For example, image 50 from the xtgc file, should be a solid grassland, but I don't seem to be able to figure out the decode sequence to get it to that image square in the file.
Thanks again for any help.
-BlueWlvrn
|
|
| |
|
|
|
BlueWlvrn
|
|
Ok, I think I figured out the pcx files.
These files are actually a half off of the map grid.
So the TILE section defines the terrain type, but the image applies to the shifted grid square that coveres the upper corner.
code:
/\
/ \
\/\/
/\/\
\ /
\/
The top diamond is the IMAGE and the bottom diamond is the actual terrain type as seen by the map grid
|
|
| |
|
|
|
pdescobar
|
|
Some more on the differences between BIC (4.01) and BIX (11.18) which I have found; confirmations and corrections appreciated:
'DIFF' section:
- There is a 4-byte long value added to the end of the section corresponding to the "Num. citizens quelled by military" setting on the Difficulty Levels tab in the editor.
'RULE' section:
- There is a 4-byte long value added to the end of the section corresponding to the "Flag Unit" setting on the General Settings tab in the editor. (index into unit array)
'PRTO' section:
- They went nuts on this one with an extra 40 bytes of data for each unit as well as changes to some of the existing data. This section is the same as that posted up to and including the 4-byte long index for the 3rd required resource.
- The next entry is still a 4-byte long section of flags for unit abilities. However, the "UNUSED (was mounted)" ability in the second byte is now the "Flag" ability (Princess in standard rules). Additionally, 3 more abilities have been added to the end of the list in byte 4. They are "Lethal Land Bombardment" (bit 3), "Lethal Sea Bombardment" (bit 4) and "King" (bit 5).
- Again, the next entry is the same with some additions. It is still a 4-byte long section of flags for AI strategies. However, 2 more strategies have been added to the end of the list in byte 3. These are "Flag" (bit 2) and "King" (bit 3).
- The availability 4-byte long entry remains essentially the same.
- The next 2 4-byte entries are no longer the conglomeration of orders and actions flags they were in v4.01; I believe they are now essentially garbage values as I couldn't come up with any discernible pattern to them.
- The next 3 4-byte sections (class, "other strategy," and HP bonus) are the same
- A new 4-byte section for "Standard Orders" comes next. These are flags and only the first byte is currently defined:
00000000 (first byte)
.......1 Skip Turn
......1. Wait
.....1.. Fortify
....1... Disband
...1.... Goto
..1..... Explore
.1...... Sentry
1....... (unused)
- Then comes a new 4-byte section for "Special Actions." The first byte and a quarter of the second are all that are currently defined.:
00000000 (first byte)
.......1 Load
......1. Unload
.....1.. Airlift
....1... Pillage
...1.... Bombard
..1..... Airdrop
.1...... Build Army
1....... Finish Improvements
00000000 (second byte)
.......1 Upgrade Unit
......1. Capture
(rest unused)
- Next is a new 4-byte section for "Worker/Engineer Actions." Only the first 2 bytes are currently defined.
00000000 (first byte)
.......1 Build Colony
......1. Build City
.....1.. Build Road
....1... Build Railroad
...1.... Build Fortress
..1..... Build Mine
.1...... Irrigate
1....... Clear Forest
00000000 (second byte)
.......1 Clear Jungle
......1. Plant Forest
.....1.. Clear Pollution
....1... Automate
...1.... Join City
..1..... Build Airfield
.1...... Build Radar Tower
1....... Build Outpost
- Then comes a 4-byte long section for "Air Missions." Only part of the first byte is currently defined.
00000000 (first byte)
.......1 Bombing
......1. Recon
.....1.. Interception
....1... Re-base
...1.... Precision Bombing
(rest unused)
- Next is a strange section I don't fully understand. It seems to be a 4-byte long section full of flags which are duplicates of those covered previously. They cover the first two bytes plus one bit in a third..
00000000 (first byte)
.......1 Sentry (Standard Orders)
......1. Bombard (Special Actions)
.....1.. Build Colony OR Build Road (both Worker Actions)
....1... Build Road (Worker Actions)
...1.... Build Railroad (Worker Actions)
..1..... Build Road (Worker Actions)
.1...... Irrigate (Worker Actions)
1....... Clear Forest (Worker Actions)
(Note how Build Road sets 3 bits on its own and
that bit 2 is set if either Build Road or Build Colony is on.)
00000000 (second byte)
.......1 Clear Jungle (Worker Actions)
......1. Clear Pollution (Worker Actions)
.....1.. Automate (Worker Actions)
....1... Automate (Worker Actions)
...1.... Bombing (Air Missions)
..1..... Precision Bombing (Air Missions)
.1...... Automate (Worker Actions)
1....... Goto (Standard Orders) OR Re-base (Air Missions
(Note how Automate sets 3 bits on its own and
that bit 7 is set if either Goto or Re-base is on.)
00000000 (third byte)
.......1 Always ON (At least, I can't figure out how to turn it off)
(rest unused)
- Next is a 4-byte long value which is 1 if "Bombard Effects" is checked in the "Unit Statistics" section and 0 if it is unchecked.
- The next 12 bytes are essentially flags for the "Ignore Movement Cost" entries. Each byte is 1 if the corresponding terrain type is selected and 0 if it is not.
Byte Terrain
00 Desert
01 Plains
02 Grassland
03 Tundra
04 Flood Plains
05 Hills
06 Mountains
07 Forest
08 Jungle
09 Coast
10 Sea
11 Ocean
- The last entry is a 4-byte long value corresponding to the "Req. Support" checkbox on the "Unit Statistics" section. It is 1 if that box is checked and 0 if not.
|
|
| |
|
|
|
pdescobar
|
|
OK, here's my 3rd installment of "Things that are different in BIX 11.18" I know Gramphos probably doesn't have time to verify any of this, but comments and corrections from anyone else are welcome too 
RACE section:
- A 4-byte long has been added to the end of the section for "King Unit" which is an index into the unit list.
TERR section:
WCHR section:
- These are 13 4-byte long values corresponding to options in the "Generate Map" dialog of the editor. Most options have a "selected" entry which is what was the user chose and an "actual" entry which is the value used on the map. The actual entry is only useful if the selected entry was "Random"; in all other cases it is the same as the selected entry.
4 long Climate - Selected
4 long Climate - Actual
(0-Arid, 1-Normal, 2-Wet, 3-Random)
4 long Barb Activity - Selected
4 long Barb Activity - Actual
(-1 None, 0-Sedentary, 1-Roaming, 2-Restless, 3-Raging, 4-Random)
4 long Land Form - Selected
4 long Land Form - Actual
(0-Archipelago, 1-Continents, 2-Pangaea, 3-Random)
4 long Ocean Coverage - Selected
4 long Ocean Coverage - Actual
(0-80%, 1-70%, 2-60%, 3-Random)
4 long Temperature - Selected
4 long Temperature - Actual
(0-Cool, 1-Temperate, 2-Warm, 3-Random)
4 long Age - Selected
4 long Age - Actual
(0-3 bill yrs, 1-4 bill yrs, 2-5 bill yrs, 3-Random)
4 long World Size
(0-Tiny, 1-Small, 2-Standard, 3-Large, 4-Huge)
WMAP section:
- The ellipsis ("...") on the posted format is 124 bytes of data whose purpose I can't even guess at. In one recent test map the first dozen looked like 4-byte longs with values between 1115 and 6617. I was hoping these would be something like terrain counts since there are 12 terrain types, but I can't make a correlation if they are. The remaining 76 bytes were all "ff" which might by 19 longs of -1 or might be something completely different.
- There is an additional used bit on the flag section at the end. Bit 1 (......1.) corresponds to the "allow y-wrapping" option which is now available; this is the bit between the two previously known flag values.
TILE section:
- Gramphos recently posted an updated version of this after some discussion on save files
UNIT section:
- Is the 32-byte "name" entry simply legacy which is no longer used? I couldn't figure out how to get something to appear there.
- There are 61 bytes added to the end of this section. The first 57 (which seems a strange length) look to be a "custom name" string which gets filled if you put something in the "Name:" field on a unit's properties after you place it on the map.
- The last 4 bytes are a long value corresponding to whether or not the "Use Civ-Specific King Unit" box is checked on the unit properties page. 1 for checked, 0 for unchecked.
CLNY section
- There is an additional 4-byte long value added to the end of the section. I call it the "other structure" value. If the value is zero, this CLNY entry is an actual colony, but if it's non-zero this is a different structure. Defined values are 1 for an airfield, 2 for a radar tower, and 3 for an outpost.
GAME section
- There are more flags defined for the second byte of the victory conditions and rules entry. These are:
accelerated production ......1.
elimination enabled .....1..
regicide enabled ....1...
mass regicide enabled ...1....
victory locations enabled ..1.....
capture the flag enabled .1......
allow cultural conversions 1.......
- Following this, there are 25 new 4-byte long values. These are:
4 long auto-place capture units (checkbox; 1=checked, 0=not)
4 long auto-place king units (checkbox; 1=checked, 0=not)
4 long auto-place victory locations (checkbox; 1=checked, 0=not)
4 long use Debug Mode (checkbox; 1=checked, 0=not)
4 long use Time Limits (checkbox; 1=checked, 0=not)
4 long base time unit (0-Years, 1-Months, 2-Weeks)
4 long starting month (1-January ... 12-December)
4 long starting week (1-52)
4 long starting year (negative if "BC")
4 long time limit in minutes
4 long time limit in turns
4 long time scale entry #1 (turns)
4 long time scale entry #2 (turns)
4 long time scale entry #3 (turns)
4 long time scale entry #4 (turns)
4 long time scale entry #5 (turns)
4 long time scale entry #6 (turns)
4 long time scale entry #7 (turns)
4 long time scale entry #1 (time units)
4 long time scale entry #2 (time units)
4 long time scale entry #3 (time units)
4 long time scale entry #4 (time units)
4 long time scale entry #5 (time units)
4 long time scale entry #6 (time units)
4 long time scale entry #7 (time units)
- Finally, there is a humongous 5,200-byte string for the "Scenario Search Folders" list
Once again, comments and corrections from anyone are appreciated, particularly filling in the holes like in WMAP. I might combine these into a new thread at some point, but I'll probably just start trying to figure out the next set of differences that Conquests introduces and post that whenever it gets released.
|
|
| |
|
| |
|
|
|
AlanH
|
|
I've just spotted a small correction to the TERR data structure as listed here.
The structure begins with a LONG defining the number of possible resources, but the next field is not always 3 bytes. It's a variable length bit field with one bit for each possible resource, and uses N bytes where:
N = (numPossibleResources + 7) % 8 .... i.e enough bytes to store the number of bits required.
In a some games N may be 3, the size quoted in the listing, but it ain't necessarily so.
This applies to the Civ3 BIC format embedded within a .SAV file. I haven't investigated any other file formats.
[edit] Whoops! Just found pdescobar's posts covering this error. I'll go back in my hole.
Last edited by AlanH on 09-08-2003 at 14:24
|
|
| |
|
| |
|
|
|
The Slayer
|
 |
Archmage of Dalaran, Leader of Lordaeron.
Jun 2003
time: 00:19
|
|
English/español post
quote:
tu ingles es mas bueno que mi español. (?!?!?). |
 
Well thanks for your "cheers"??  / Gracias por tus halagos 
But, my real question is to know what is the maximum amount of MB y could be able to upload to Poly?? / Pero mi verdadera pregunta era cual es la canditad maxima de MB que puedo subir a Poly..?
quote:
it's no piracy to use DyP and TeT, because -as far as i know- the creators just ask to be mentioned, if you use their files... |
Yes, I thinked that also, and I'm going to include their names and the names of all the unit creators in the final version of the game. My idea is in the beta version that if somebody recognises his (or another person) unit, setting or graphic mod, e-mail me to add the creator's name in the credits of the mod section / Si, eso creia, y voy a incluir sus nombres y los nombres de todos los creadores de unidades en la version final del mod. La idea es que en la version de prueba del mod, la gente reconozca sus (o de otros) unidades, configuraciones o graficos, me escriba un correo electronico y de ahi yo agrego su nombre en los creditos del mod.
I prefered to join all together the files in one only mod to avoid expressions like "what?.. first I have to download two different mod and later yours??? .. go to h**l!! ". So I think combine the mods would be the best option for them / Preferi juntar los dos mods en uno, para no oir fraces como "que??!, primero me bajo los otros 2 mods y despues el tuyo??.. andate a la M**** . Pienso que juntar los 2 mods pueda ser la mejor opcion para ellos.
Best wishes / Saludos, nos vemos
The Slayer
|
|
| |
All times are GMT. The time now is 05:19.
Apolyton Time is 00:19. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
21-06-2003 01:12
|