PUD File Format StuffQuote from: easycompany on 2017-02-26, 03:50:18
hex(h)
80 (00) value =01 bnet 00= custom map<--- very important this is
Ok. Not really sure, but I'm assuming the "80" at the start of this line is a file offset, i.e. the position in the PUD file where this value should be set ya??
Not sure, but i should give a quick description of how PUD files are formatted - perhaps you already know this IDK.
PUD FILE FORMAT
The PUD file format is like a simplified RIFF format (which, incidentally is what an AVI file is). It consists of sections. each section is formatted like this:
Code: [Select]
DWORD 4CC
DWORD Size
(Size bytes) Data
A '4CC' is a "four character code". It's just used like a name for the section, but it always contains exactly 4 characters ('DIVX' is a 4CC). 4CCs are kind of cool because they are easily readable by a human, and usually kind of describe what they denote, but also because they are exactly 4 bytes, and 4 bytes is a DWORD (32bit value) they can be handled by the processor as a single number and don't need to be processed as a string.... anyway, its a name that has 4 characters (letters).
i.e. the section that contains the starting gold for each player is called 'SGLD', and the section that contains the list of all the units on the map is called 'UNIT', while the section that contains the unit data (specs for each unit type... HP damage etc.) is called 'UDTA'
Most of the sections appear in all PUDs, some don't. i.e. the restriction section that allows a player to train certian units/upgrades but not others is called 'ALOW'. A 'normal' PUD that does not have any restrictions (you can have all the unit types) does not have an 'ALOW' section at all, however if this section is present WC2 will look at it and only allow the specified units/upgrades as per this section.
If you run my GrimEdit editor, and select Edit->Clipboard from the menu, you will see a list of common PUD sections. You can select the 4CC for each and it will display a (very) short description of what it is. You can then go to Modules->Player Properties, select a player, click one of the the "Units Allowed" etc. buttons and deselect a few things then click [Ok]. If you then go back to the "clipboard" you will see that an 'ALOW' section has been created and added to the PUD.
Many of the common sections that can appear towards the start of a PUD have a fixed length (i.e. 'SGLD' is always 32 bytes) which can make it appear that certain values occur at certain file offsets, because the sections are commonly written in the same order, however this is an illusion as the sections can be written in a different order or entirely new sections inserted into a PUD. ( this is how it is possible to create a file that is both a playable .PUD file and an executable .EXE file).
Also there are certianly sections whose length will vary from PUD to PUD... i.e. the size of 'UNIT' will depend on how many units are placed on the map.
It is by changing the sections that a PUD file is edited. If you look at the map description module in the ASM source you will see it loads/saves the 'DESC' section, while the Starting Resources module edits 'SGLD', 'SLBR' and 'SOIL'. There are (or used to be) descriptions of the common PUD sections floating around on the web.
==
==
==
==
==
==
==
==
Oh Hey, here ya go, found the section definitions. I downloaded this from somewhere in like 2002 or something
PUD Format (Download)So your offset 0x80 is the very start of the data for the 'UDTA' section.
You can see it here - random cusom PUD is Mini BGH (SS of my trusty Hex Editor - I wrote that golden oldie in '97 - been using it ever since
).
So the red box shows the section 4CC 'UDTA' the blue box contains the dword length of the data for that section - in this case 0x1640 bytes (5696 in ape numbers), and following that inthe green box is the value you are setting, which is actually a 2-byte 'WORD' value, but as it is either 0 or 1, the high byte (which comes second) is always 0, so only the first byte is modified.
As you can see from the included file:
------------------------------------------------------------
6: Section 'UDTA', Unit Data
word use default data (0 no, 1 yes) 110 words overlap frames
508 words obselete data (ignore it) was .....
-------------------------------------------------------------
... it's that first WORD value "use default data"
and just to illustrate the issue with using file offsets for this type of file, here's the same information from an earlier description of PUD internals, which is entitled "PUD Maximum File Format"
-------------------------------------------------------------------------
00:006A-00:006B W Era number
0=Forest,1=Icelands,2=Wastelands,3=Swamps
*4-255=forest
00:006C-00:006F $ Header description "ERAX"
00:0070-00:0073 L Expansion era data length ( 2 B)
00:0074-00:0075 W Expansion Era number
0=Forest,1=Icelands,2=Wastelands,3=Swamps
*4-255=forest
00:0076-00:0079 $ Header description "DIM "
00:007A-00:007D L Dimensions data length ( 4 B)
00:007E-00:0081 W Map X and Y dimensions (0 ?? .. 128max)
*Map is always loaded only by Y size
*i.e. Y*Y map size
00:0082-00:0085 $ Header description "UDTA"
00:0086-00:0089 L Unit data length ( 5950 B )
00:008A-00:008B W Set if Should be used default data
0=no,1=yes00:008C-00:0167 W Overlap frames for each unit (0..109)
* group to belong number
* see "UNIT" section for units order
00:0168-00:0265 W Obsolete General grafix frames
-------------------------------------------------------------------
However as you can see here the value is denoted as being at offset 0x8A because the PUD file being described also contains the optional 'ERAX' section.
The only thing that can be guaranteed is that it is the first WORD in the data for the 'UDTA' section.The data lengths in each section header construct the file i.e. as the 'UDTA' section in the Mini BGH PUD here is 0x1640 bytes long and starts at 0x80 then the next section header will be at 0x1640 + 0x0080 = 0x16C0, and indeed if you go to offset 0x16C0 in this PUD you will find 'UGRD' the "Upgrades" section 4CC followed by the DWORD 0x0000030E because the data for this section is 0x30E bytes long...
