https://pzwiki.net/w/api.php?action=feedcontributions&user=Fuebar&feedformat=atomPZwiki - User contributions [en]2024-03-29T09:16:23ZUser contributionsMediaWiki 1.39.6https://pzwiki.net/w/index.php?title=File_formats&diff=14900File formats2013-11-20T01:52:38Z<p>Fuebar: -- added that the functionality of integers in the entries in texturepacks is merely guesswork and might not be reality</p>
<hr />
<div>===map_sand.bin===<br />
<br />
[https://gist.github.com/Fuebar/7495914 Simple big-endian BinaryReader override written in C#.]<br />
<br />
A simple contiguous array of big-endian 32-bit integers. On loading, each integer is stored in a specific global option variable used to control things like zombie attributes and game speed, when the power will go out, etc. All the options you can set at the creation of a Sandbox game. Useful for tweaking options after you've already created your game.<br />
<br />
Note: If the world version is < 5 (world version is read in as a big-endian 32-bit integer from '''map_ver.bin''' the same way these are), you have to leave out Temperature and Rain when reading in variables.<br />
<br />
<code><br />
<font color="blue">int</font> Zombies, Distribution, Survivors, Speed, DayLength, StartMonth, StartTime, WaterShut, ElecShut, Loot, Temperature, Rain;<br />
<font color="blue">static class ZombieStats</font><br />
{<br />
<font color="blue">static int</font> Speed, Strength, Toughness, Transmission, Mortality, Reanimate, Cognition, Memory, Decomposition, Sight, Hearing, Smell;<br />
}<br><br />
BigEndianBinaryReader br; <font color="#008000">// implementation left out for brevity. anything that can read four bytes in big-endian order from a file works.</font><br><br />
Zombies = br.ReadInt32();<br />
Distribution = br.ReadInt32();<br />
. . .<br />
Rain = br.ReadInt32();<br><br />
ZombieStats.Speed = br.ReadInt32();<br />
. . .<br />
ZombieStats.Smell = br.ReadInt32();<br />
<font color="#008000">// order is essential, exactly as listed above in the int declarations</font><br />
</code><br />
<br />
If any new Sandbox options are added in you'll have to check /zombie/SandboxOptions.class (decompile it with Java Decompiler) and look at the load() function.<br />
<br />
Example file contents:<br />
<code><br />
00 00 00 03 | 00 00 00 01 | 00 00 00 01 | 00 00 00 03<br />
00 00 00 05 | 00 00 00 07 | 00 00 00 01 | 00 00 00 05<br />
etc., total of six lines of this length<br />
</code><br />
<br />
===TexturePacks (.pack files)===<br />
These are the files located in /media/texturepacks/, Characters.pack, Tiles.pack, and UI.pack. Reading them is simple, the implementation will probably be 20 or 30 lines long.<br />
<br />
Each file contains a number of 'pages' which are basically PNG images with an associated array of offset coordinates, widths, heights, and names, that are specify smaller rectangles on the PNG file that are to be copied into their own individual images. This is called a [https://en.wikipedia.org/wiki/Texture_atlas texture atlas] and is a common practice in game development.<br />
<br />
The integers in this file are little-endian, i.e. the least significant bytes come first. This is the default on my system, so no special stream reader was required, but you may have to use/write a little-endian reader if your system defaults to big-endian.<br />
<br />
The first four bytes of the file specify a 32-bit integer, which tells you how many pages (atlas images) are located within. Every byte after this belongs to a page, and follows the structure outlined below.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this texture page<br />
int32, number of entries in the page<br />
int32, represents a boolean value, true if non-zero. Titled 'mask' in the code, honestly not sure what it does. Not necessary for extraction purposes.<br><br />
[entries - outlined below]<br><br />
byte[], PNG data, byte[] { 49, 45, 4E, 44, AE, 42, 60, 82, EF, BE, AD, DE } marks the end of the file, they don't have to be included in the PNG's byte array.<br />
The next page starts immediately after the byte pattern specified above.<br />
</code><br />
<br />
The first entry comes immediately after the <code>mask</code> int32, there are as many entries as determined by the int preceding <code>mask</code>. You'll probably want to create a struct/class to hold the info contained in each entry, though you could do with indexed arrays as well. Each entry contains the info you need to copy the subimages out of the PNG data, and some information irrelevant to that as well.<br />
The format is most easily demonstrated with code.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this specific subtexture<br />
int32, x-coord of the upper left corner of this subimage on the subtexture<br />
int32, y-coord of the upper left corner of this subimage on the subtexture<br />
int32, width of the subtexture<br />
int32, height of the subtexture<br />
int32, number of pixels of transparent padding to the left of the image (i.e., x offset) note: This is merely a guess, this could be used for something else.<br />
int32, number of pixels of transparent padding on top of the image (i.e., y offset) note: This is a guess.<br />
int32, actual width of the subtexture, after including padding. Sometimes width + x-offset is less than this value, in which case padding is required on the right as well. note: This is a guess.<br />
int32, actual height of the subtexture, after including padding. Sometimes height + y-offset is less than this value, in which case padding is required at the bottom as well. note: This is a guess.<br />
</code><br />
<br />
In simpler terms, the first int32 of the entry contains the length of the char array defining its name that follows it. The next eight int32s fill the values { x, y, w, h, ox, oy, fx, fy }. After the last int32 of the subtexture's entry, if we're not on the last subtexture, the following int32 will define the length of the char array defining that subtexture's name and so on.<br />
<br />
(x, y) = offset within the entire PNG the image begins at<br><br />
(w, h) = size of the image ''on the atlas''<br><br />
(ox, oy) = offset within the (fx, fy) bounds to put the upper left corner of the image we got from (x, y)<br><br />
(fx, fy) = full desired size of the images, for most inventory images this is 32x32<br><br />
<br />
For example, the Apple inventory item entry on the page 'ninventory0' has the following values: <code>x = 184, y = 274, w = 28, h = 32, ox = 3, oy = 0, fx = 32, fy = 32;</code><br />
<br />
So to get this image, we'd load the PNG data following these entries into memory, use some method to cut a 28x32 subtexture out of the PNG at (184, 274), and then write those pixels into a 32x32 image beginning at (3, 0).<br />
<br />
===.lotheader files===<br />
These files contain information relevant to each .lotpack file in /media/maps/[map name]/. They are found in the same directory at .lotpack files and have the same naming format as well. Each <code>world_[int]_[int].lotpack</code> file has a corresponding <code>[int]_[int].lotheader</code> file that goes with it. The variables <code>wX</code> and <code>wY</code> denote world coordinates and represent the [int]_[int] part of the file name. They will be used as such to represent these in the format code below. All integers are little-endian.<br />
<br />
I feel these aren't very practical explanations of the formats, and so I'm linking to a GitHub gist that contains some classes and methods, written in C#, that can read .lotheader files. They don't actually ''do'' anything with the data, however.<br />
<br />
[https://gist.github.com/Fuebar/7494753 GitHub gist displaying .lotheader reading.]<br />
<br />
<code><br />
int32, .lotheader format version, zero as of build 12.<br />
int32, number of tiles cached, following this.<br />
string[], delimited by 0x0A, variable length and no length specifying prefixes, so you'll have to read byte by byte for each one<br />
byte, empty space, has no purpose other than to be skipped. The seek position of the stream must advance one byte after reading all the strings before this.<br />
int32, width of this lot<br />
int32, height of this lot<br />
int32, number of (vertical) levels on this lot<br />
int32, number of rooms on this lot<br />
[room array here, outlined in following code segment]<br />
int32, number of buildings on this lot<br />
[building format, iterate over it the number of times specified above:]<br />
int32, number of rooms<br />
int32[], room indexes, corresponds with each room read above from 0 to the total number of rooms - 1. As long as the int32 before this indicates.<br />
[end of building format]<br />
byte[30][30], this reads until the end of the file. It is a 30x30 two-dimensional jagged array of bytes, each indicating the density of zombies within the specific area they denote<br />
</code><br />
<br />
Room format, iterate over it the number of times indicated by the <code>int32</code> representing the number of rooms:<br />
<code><br />
string, name of the room, same as in the above code segment. 0x0A delimited and must be read byte by byte until you reach 0x0A.<br />
int32, level the room is on, i.e floor<br />
int32, count of the rectangles in the room<br />
[rectangle format, iterate over it:]<br />
int32, x value of this rectangle, (wX * 300) is added to the value during assignment<br />
int32, y value of this rectangle, (wY * 300) is added to the value during assignment<br />
int32, width of the rectangle<br />
int32, height of the rectangle<br />
[end of rectangle format]<br />
int32, number of objects in this room<br />
[object format, iterate:]<br />
int32, type of object<br />
int32, x value of object, (wX * 300) added during assignment<br />
int32, y value of object, (wY * 300) added during assignment<br />
[end of object format]<br />
</code><br />
<br />
[[Category:Modding]]</div>Fuebarhttps://pzwiki.net/w/index.php?title=File_formats&diff=14387File formats2013-11-16T04:25:41Z<p>Fuebar: -- whoops</p>
<hr />
<div>===map_sand.bin===<br />
<br />
[https://gist.github.com/Fuebar/7495914 Simple big-endian BinaryReader override written in C#.]<br />
<br />
A simple contiguous array of big-endian 32-bit integers. On loading, each integer is stored in a specific global option variable used to control things like zombie attributes and game speed, when the power will go out, etc. All the options you can set at the creation of a Sandbox game. Useful for tweaking options after you've already created your game.<br />
<br />
Note: If the world version is < 5 (world version is read in as a big-endian 32-bit integer from '''map_ver.bin''' the same way these are), you have to leave out Temperature and Rain when reading in variables.<br />
<br />
<code><br />
<font color="blue">int</font> Zombies, Distribution, Survivors, Speed, DayLength, StartMonth, StartTime, WaterShut, ElecShut, Loot, Temperature, Rain;<br />
<font color="blue">static class ZombieStats</font><br />
{<br />
<font color="blue">static int</font> Speed, Strength, Toughness, Transmission, Mortality, Reanimate, Cognition, Memory, Decomposition, Sight, Hearing, Smell;<br />
}<br><br />
BigEndianBinaryReader br; <font color="#008000">// implementation left out for brevity. anything that can read four bytes in big-endian order from a file works.</font><br><br />
Zombies = br.ReadInt32();<br />
Distribution = br.ReadInt32();<br />
. . .<br />
Rain = br.ReadInt32();<br><br />
ZombieStats.Speed = br.ReadInt32();<br />
. . .<br />
ZombieStats.Smell = br.ReadInt32();<br />
<font color="#008000">// order is essential, exactly as listed above in the int declarations</font><br />
</code><br />
<br />
If any new Sandbox options are added in you'll have to check /zombie/SandboxOptions.class (decompile it with Java Decompiler) and look at the load() function.<br />
<br />
Example file contents:<br />
<code><br />
00 00 00 03 | 00 00 00 01 | 00 00 00 01 | 00 00 00 03<br />
00 00 00 05 | 00 00 00 07 | 00 00 00 01 | 00 00 00 05<br />
etc., total of six lines of this length<br />
</code><br />
<br />
===TexturePacks (.pack files)===<br />
These are the files located in /media/texturepacks/, Characters.pack, Tiles.pack, and UI.pack. Reading them is simple, the implementation will probably be 20 or 30 lines long.<br />
<br />
Each file contains a number of 'pages' which are basically PNG images with an associated array of offset coordinates, widths, heights, and names, that are specify smaller rectangles on the PNG file that are to be copied into their own individual images. This is called a [https://en.wikipedia.org/wiki/Texture_atlas texture atlas] and is a common practice in game development.<br />
<br />
The integers in this file are little-endian, i.e. the least significant bytes come first. This is the default on my system, so no special stream reader was required, but you may have to use/write a little-endian reader if your system defaults to big-endian.<br />
<br />
The first four bytes of the file specify a 32-bit integer, which tells you how many pages (atlas images) are located within. Every byte after this belongs to a page, and follows the structure outlined below.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this texture page<br />
int32, number of entries in the page<br />
int32, represents a boolean value, true if non-zero. Titled 'mask' in the code, honestly not sure what it does. Not necessary for extraction purposes.<br><br />
[entries - outlined below]<br><br />
byte[], PNG data, byte[] { 49, 45, 4E, 44, AE, 42, 60, 82, EF, BE, AD, DE } marks the end of the file, they don't have to be included in the PNG's byte array.<br />
The next page starts immediately after the byte pattern specified above.<br />
</code><br />
<br />
The first entry comes immediately after the <code>mask</code> int32, there are as many entries as determined by the int preceding <code>mask</code>. You'll probably want to create a struct/class to hold the info contained in each entry, though you could do with indexed arrays as well. Each entry contains the info you need to copy the subimages out of the PNG data, and some information irrelevant to that as well.<br />
The format is most easily demonstrated with code.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this specific subtexture<br />
int32, x-coord of the upper left corner of this subimage on the subtexture<br />
int32, y-coord of the upper left corner of this subimage on the subtexture<br />
int32, width of the subtexture<br />
int32, height of the subtexture<br />
int32, number of pixels of transparent padding to the left of the image (i.e., x offset)<br />
int32, number of pixels of transparent padding on top of the image (i.e., y offset)<br />
int32, actual width of the subtexture, after including padding. Sometimes width + x-offset is less than this value, in which case padding is required on the right as well.<br />
int32, actual height of the subtexture, after including padding. Sometimes height + y-offset is less than this value, in which case padding is required at the bottom as well.<br />
</code><br />
<br />
In simpler terms, the first int32 of the entry contains the length of the char array defining its name that follows it. The next eight int32s fill the values { x, y, w, h, ox, oy, fx, fy }. After the last int32 of the subtexture's entry, if we're not on the last subtexture, the following int32 will define the length of the char array defining that subtexture's name and so on.<br />
<br />
(x, y) = offset within the entire PNG the image begins at<br><br />
(w, h) = size of the image ''on the atlas''<br><br />
(ox, oy) = offset within the (fx, fy) bounds to put the upper left corner of the image we got from (x, y)<br><br />
(fx, fy) = full desired size of the images, for most inventory images this is 32x32<br><br />
<br />
For example, the Apple inventory item entry on the page 'ninventory0' has the following values: <code>x = 184, y = 274, w = 28, h = 32, ox = 3, oy = 0, fx = 32, fy = 32;</code><br />
<br />
So to get this image, we'd load the PNG data following these entries into memory, use some method to cut a 28x32 subtexture out of the PNG at (184, 274), and then write those pixels into a 32x32 image beginning at (3, 0).<br />
<br />
===.lotheader files===<br />
These files contain information relevant to each .lotpack file in /media/maps/[map name]/. They are found in the same directory at .lotpack files and have the same naming format as well. Each <code>world_[int]_[int].lotpack</code> file has a corresponding <code>[int]_[int].lotheader</code> file that goes with it. The variables <code>wX</code> and <code>wY</code> denote world coordinates and represent the [int]_[int] part of the file name. They will be used as such to represent these in the format code below. All integers are little-endian.<br />
<br />
I feel these aren't very practical explanations of the formats, and so I'm linking to a GitHub gist that contains some classes and methods, written in C#, that can read .lotheader files. They don't actually ''do'' anything with the data, however.<br />
<br />
[https://gist.github.com/Fuebar/7494753 GitHub gist displaying .lotheader reading.]<br />
<br />
<code><br />
int32, .lotheader format version, zero as of build 12.<br />
int32, number of tiles cached, following this.<br />
string[], delimited by 0x0A, variable length and no length specifying prefixes, so you'll have to read byte by byte for each one<br />
byte, empty space, has no purpose other than to be skipped. The seek position of the stream must advance one byte after reading all the strings before this.<br />
int32, width of this lot<br />
int32, height of this lot<br />
int32, number of (vertical) levels on this lot<br />
int32, number of rooms on this lot<br />
[room array here, outlined in following code segment]<br />
int32, number of buildings on this lot<br />
[building format, iterate over it the number of times specified above:]<br />
int32, number of rooms<br />
int32[], room indexes, corresponds with each room read above from 0 to the total number of rooms - 1. As long as the int32 before this indicates.<br />
[end of building format]<br />
byte[30][30], this reads until the end of the file. It is a 30x30 two-dimensional jagged array of bytes, each indicating the density of zombies within the specific area they denote<br />
</code><br />
<br />
Room format, iterate over it the number of times indicated by the <code>int32</code> representing the number of rooms:<br />
<code><br />
string, name of the room, same as in the above code segment. 0x0A delimited and must be read byte by byte until you reach 0x0A.<br />
int32, level the room is on, i.e floor<br />
int32, count of the rectangles in the room<br />
[rectangle format, iterate over it:]<br />
int32, x value of this rectangle, (wX * 300) is added to the value during assignment<br />
int32, y value of this rectangle, (wY * 300) is added to the value during assignment<br />
int32, width of the rectangle<br />
int32, height of the rectangle<br />
[end of rectangle format]<br />
int32, number of objects in this room<br />
[object format, iterate:]<br />
int32, type of object<br />
int32, x value of object, (wX * 300) added during assignment<br />
int32, y value of object, (wY * 300) added during assignment<br />
[end of object format]<br />
</code><br />
<br />
[[Category:Modding]]</div>Fuebarhttps://pzwiki.net/w/index.php?title=File_formats&diff=14386File formats2013-11-16T04:21:04Z<p>Fuebar: -- added gist link to a big-endian BinaryReader implementation as an example</p>
<hr />
<div>===map_sand.bin===<br />
<br />
[https://gist.github.com/Fuebar/7495879 Simple big-endian BinaryReader override written in C#.]<br />
<br />
A simple contiguous array of big-endian 32-bit integers. On loading, each integer is stored in a specific global option variable used to control things like zombie attributes and game speed, when the power will go out, etc. All the options you can set at the creation of a Sandbox game. Useful for tweaking options after you've already created your game.<br />
<br />
Note: If the world version is < 5 (world version is read in as a big-endian 32-bit integer from '''map_ver.bin''' the same way these are), you have to leave out Temperature and Rain when reading in variables.<br />
<br />
<code><br />
<font color="blue">int</font> Zombies, Distribution, Survivors, Speed, DayLength, StartMonth, StartTime, WaterShut, ElecShut, Loot, Temperature, Rain;<br />
<font color="blue">static class ZombieStats</font><br />
{<br />
<font color="blue">static int</font> Speed, Strength, Toughness, Transmission, Mortality, Reanimate, Cognition, Memory, Decomposition, Sight, Hearing, Smell;<br />
}<br><br />
BigEndianBinaryReader br; <font color="#008000">// implementation left out for brevity. anything that can read four bytes in big-endian order from a file works.</font><br><br />
Zombies = br.ReadInt32();<br />
Distribution = br.ReadInt32();<br />
. . .<br />
Rain = br.ReadInt32();<br><br />
ZombieStats.Speed = br.ReadInt32();<br />
. . .<br />
ZombieStats.Smell = br.ReadInt32();<br />
<font color="#008000">// order is essential, exactly as listed above in the int declarations</font><br />
</code><br />
<br />
If any new Sandbox options are added in you'll have to check /zombie/SandboxOptions.class (decompile it with Java Decompiler) and look at the load() function.<br />
<br />
Example file contents:<br />
<code><br />
00 00 00 03 | 00 00 00 01 | 00 00 00 01 | 00 00 00 03<br />
00 00 00 05 | 00 00 00 07 | 00 00 00 01 | 00 00 00 05<br />
etc., total of six lines of this length<br />
</code><br />
<br />
===TexturePacks (.pack files)===<br />
These are the files located in /media/texturepacks/, Characters.pack, Tiles.pack, and UI.pack. Reading them is simple, the implementation will probably be 20 or 30 lines long.<br />
<br />
Each file contains a number of 'pages' which are basically PNG images with an associated array of offset coordinates, widths, heights, and names, that are specify smaller rectangles on the PNG file that are to be copied into their own individual images. This is called a [https://en.wikipedia.org/wiki/Texture_atlas texture atlas] and is a common practice in game development.<br />
<br />
The integers in this file are little-endian, i.e. the least significant bytes come first. This is the default on my system, so no special stream reader was required, but you may have to use/write a little-endian reader if your system defaults to big-endian.<br />
<br />
The first four bytes of the file specify a 32-bit integer, which tells you how many pages (atlas images) are located within. Every byte after this belongs to a page, and follows the structure outlined below.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this texture page<br />
int32, number of entries in the page<br />
int32, represents a boolean value, true if non-zero. Titled 'mask' in the code, honestly not sure what it does. Not necessary for extraction purposes.<br><br />
[entries - outlined below]<br><br />
byte[], PNG data, byte[] { 49, 45, 4E, 44, AE, 42, 60, 82, EF, BE, AD, DE } marks the end of the file, they don't have to be included in the PNG's byte array.<br />
The next page starts immediately after the byte pattern specified above.<br />
</code><br />
<br />
The first entry comes immediately after the <code>mask</code> int32, there are as many entries as determined by the int preceding <code>mask</code>. You'll probably want to create a struct/class to hold the info contained in each entry, though you could do with indexed arrays as well. Each entry contains the info you need to copy the subimages out of the PNG data, and some information irrelevant to that as well.<br />
The format is most easily demonstrated with code.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this specific subtexture<br />
int32, x-coord of the upper left corner of this subimage on the subtexture<br />
int32, y-coord of the upper left corner of this subimage on the subtexture<br />
int32, width of the subtexture<br />
int32, height of the subtexture<br />
int32, number of pixels of transparent padding to the left of the image (i.e., x offset)<br />
int32, number of pixels of transparent padding on top of the image (i.e., y offset)<br />
int32, actual width of the subtexture, after including padding. Sometimes width + x-offset is less than this value, in which case padding is required on the right as well.<br />
int32, actual height of the subtexture, after including padding. Sometimes height + y-offset is less than this value, in which case padding is required at the bottom as well.<br />
</code><br />
<br />
In simpler terms, the first int32 of the entry contains the length of the char array defining its name that follows it. The next eight int32s fill the values { x, y, w, h, ox, oy, fx, fy }. After the last int32 of the subtexture's entry, if we're not on the last subtexture, the following int32 will define the length of the char array defining that subtexture's name and so on.<br />
<br />
(x, y) = offset within the entire PNG the image begins at<br><br />
(w, h) = size of the image ''on the atlas''<br><br />
(ox, oy) = offset within the (fx, fy) bounds to put the upper left corner of the image we got from (x, y)<br><br />
(fx, fy) = full desired size of the images, for most inventory images this is 32x32<br><br />
<br />
For example, the Apple inventory item entry on the page 'ninventory0' has the following values: <code>x = 184, y = 274, w = 28, h = 32, ox = 3, oy = 0, fx = 32, fy = 32;</code><br />
<br />
So to get this image, we'd load the PNG data following these entries into memory, use some method to cut a 28x32 subtexture out of the PNG at (184, 274), and then write those pixels into a 32x32 image beginning at (3, 0).<br />
<br />
===.lotheader files===<br />
These files contain information relevant to each .lotpack file in /media/maps/[map name]/. They are found in the same directory at .lotpack files and have the same naming format as well. Each <code>world_[int]_[int].lotpack</code> file has a corresponding <code>[int]_[int].lotheader</code> file that goes with it. The variables <code>wX</code> and <code>wY</code> denote world coordinates and represent the [int]_[int] part of the file name. They will be used as such to represent these in the format code below. All integers are little-endian.<br />
<br />
I feel these aren't very practical explanations of the formats, and so I'm linking to a GitHub gist that contains some classes and methods, written in C#, that can read .lotheader files. They don't actually ''do'' anything with the data, however.<br />
<br />
[https://gist.github.com/Fuebar/7494753 GitHub gist displaying .lotheader reading.]<br />
<br />
<code><br />
int32, .lotheader format version, zero as of build 12.<br />
int32, number of tiles cached, following this.<br />
string[], delimited by 0x0A, variable length and no length specifying prefixes, so you'll have to read byte by byte for each one<br />
byte, empty space, has no purpose other than to be skipped. The seek position of the stream must advance one byte after reading all the strings before this.<br />
int32, width of this lot<br />
int32, height of this lot<br />
int32, number of (vertical) levels on this lot<br />
int32, number of rooms on this lot<br />
[room array here, outlined in following code segment]<br />
int32, number of buildings on this lot<br />
[building format, iterate over it the number of times specified above:]<br />
int32, number of rooms<br />
int32[], room indexes, corresponds with each room read above from 0 to the total number of rooms - 1. As long as the int32 before this indicates.<br />
[end of building format]<br />
byte[30][30], this reads until the end of the file. It is a 30x30 two-dimensional jagged array of bytes, each indicating the density of zombies within the specific area they denote<br />
</code><br />
<br />
Room format, iterate over it the number of times indicated by the <code>int32</code> representing the number of rooms:<br />
<code><br />
string, name of the room, same as in the above code segment. 0x0A delimited and must be read byte by byte until you reach 0x0A.<br />
int32, level the room is on, i.e floor<br />
int32, count of the rectangles in the room<br />
[rectangle format, iterate over it:]<br />
int32, x value of this rectangle, (wX * 300) is added to the value during assignment<br />
int32, y value of this rectangle, (wY * 300) is added to the value during assignment<br />
int32, width of the rectangle<br />
int32, height of the rectangle<br />
[end of rectangle format]<br />
int32, number of objects in this room<br />
[object format, iterate:]<br />
int32, type of object<br />
int32, x value of object, (wX * 300) added during assignment<br />
int32, y value of object, (wY * 300) added during assignment<br />
[end of object format]<br />
</code><br />
<br />
[[Category:Modding]]</div>Fuebarhttps://pzwiki.net/w/index.php?title=File_formats&diff=14385File formats2013-11-16T03:12:15Z<p>Fuebar: -- +Category:Modding</p>
<hr />
<div>===map_sand.bin===<br />
<br />
A simple contiguous array of big-endian 32-bit integers. On loading, each integer is stored in a specific global option variable used to control things like zombie attributes and game speed, when the power will go out, etc. All the options you can set at the creation of a Sandbox game. Useful for tweaking options after you've already created your game.<br />
<br />
Note: If the world version is < 5 (world version is read in as a big-endian 32-bit integer from '''map_ver.bin''' the same way these are), you have to leave out Temperature and Rain when reading in variables.<br />
<br />
<code><br />
<font color="blue">int</font> Zombies, Distribution, Survivors, Speed, DayLength, StartMonth, StartTime, WaterShut, ElecShut, Loot, Temperature, Rain;<br />
<font color="blue">static class ZombieStats</font><br />
{<br />
<font color="blue">static int</font> Speed, Strength, Toughness, Transmission, Mortality, Reanimate, Cognition, Memory, Decomposition, Sight, Hearing, Smell;<br />
}<br><br />
BigEndianBinaryReader br; <font color="#008000">// implementation left out for brevity. anything that can read four bytes in big-endian order from a file works.</font><br><br />
Zombies = br.ReadInt32();<br />
Distribution = br.ReadInt32();<br />
. . .<br />
Rain = br.ReadInt32();<br><br />
ZombieStats.Speed = br.ReadInt32();<br />
. . .<br />
ZombieStats.Smell = br.ReadInt32();<br />
<font color="#008000">// order is essential, exactly as listed above in the int declarations</font><br />
</code><br />
<br />
If any new Sandbox options are added in you'll have to check /zombie/SandboxOptions.class (decompile it with Java Decompiler) and look at the load() function.<br />
<br />
Example file contents:<br />
<code><br />
00 00 00 03 | 00 00 00 01 | 00 00 00 01 | 00 00 00 03<br />
00 00 00 05 | 00 00 00 07 | 00 00 00 01 | 00 00 00 05<br />
etc., total of six lines of this length<br />
</code><br />
<br />
===TexturePacks (.pack files)===<br />
These are the files located in /media/texturepacks/, Characters.pack, Tiles.pack, and UI.pack. Reading them is simple, the implementation will probably be 20 or 30 lines long.<br />
<br />
Each file contains a number of 'pages' which are basically PNG images with an associated array of offset coordinates, widths, heights, and names, that are specify smaller rectangles on the PNG file that are to be copied into their own individual images. This is called a [https://en.wikipedia.org/wiki/Texture_atlas texture atlas] and is a common practice in game development.<br />
<br />
The integers in this file are little-endian, i.e. the least significant bytes come first. This is the default on my system, so no special stream reader was required, but you may have to use/write a little-endian reader if your system defaults to big-endian.<br />
<br />
The first four bytes of the file specify a 32-bit integer, which tells you how many pages (atlas images) are located within. Every byte after this belongs to a page, and follows the structure outlined below.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this texture page<br />
int32, number of entries in the page<br />
int32, represents a boolean value, true if non-zero. Titled 'mask' in the code, honestly not sure what it does. Not necessary for extraction purposes.<br><br />
[entries - outlined below]<br><br />
byte[], PNG data, byte[] { 49, 45, 4E, 44, AE, 42, 60, 82, EF, BE, AD, DE } marks the end of the file, they don't have to be included in the PNG's byte array.<br />
The next page starts immediately after the byte pattern specified above.<br />
</code><br />
<br />
The first entry comes immediately after the <code>mask</code> int32, there are as many entries as determined by the int preceding <code>mask</code>. You'll probably want to create a struct/class to hold the info contained in each entry, though you could do with indexed arrays as well. Each entry contains the info you need to copy the subimages out of the PNG data, and some information irrelevant to that as well.<br />
The format is most easily demonstrated with code.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this specific subtexture<br />
int32, x-coord of the upper left corner of this subimage on the subtexture<br />
int32, y-coord of the upper left corner of this subimage on the subtexture<br />
int32, width of the subtexture<br />
int32, height of the subtexture<br />
int32, number of pixels of transparent padding to the left of the image (i.e., x offset)<br />
int32, number of pixels of transparent padding on top of the image (i.e., y offset)<br />
int32, actual width of the subtexture, after including padding. Sometimes width + x-offset is less than this value, in which case padding is required on the right as well.<br />
int32, actual height of the subtexture, after including padding. Sometimes height + y-offset is less than this value, in which case padding is required at the bottom as well.<br />
</code><br />
<br />
In simpler terms, the first int32 of the entry contains the length of the char array defining its name that follows it. The next eight int32s fill the values { x, y, w, h, ox, oy, fx, fy }. After the last int32 of the subtexture's entry, if we're not on the last subtexture, the following int32 will define the length of the char array defining that subtexture's name and so on.<br />
<br />
(x, y) = offset within the entire PNG the image begins at<br><br />
(w, h) = size of the image ''on the atlas''<br><br />
(ox, oy) = offset within the (fx, fy) bounds to put the upper left corner of the image we got from (x, y)<br><br />
(fx, fy) = full desired size of the images, for most inventory images this is 32x32<br><br />
<br />
For example, the Apple inventory item entry on the page 'ninventory0' has the following values: <code>x = 184, y = 274, w = 28, h = 32, ox = 3, oy = 0, fx = 32, fy = 32;</code><br />
<br />
So to get this image, we'd load the PNG data following these entries into memory, use some method to cut a 28x32 subtexture out of the PNG at (184, 274), and then write those pixels into a 32x32 image beginning at (3, 0).<br />
<br />
===.lotheader files===<br />
These files contain information relevant to each .lotpack file in /media/maps/[map name]/. They are found in the same directory at .lotpack files and have the same naming format as well. Each <code>world_[int]_[int].lotpack</code> file has a corresponding <code>[int]_[int].lotheader</code> file that goes with it. The variables <code>wX</code> and <code>wY</code> denote world coordinates and represent the [int]_[int] part of the file name. They will be used as such to represent these in the format code below. All integers are little-endian.<br />
<br />
I feel these aren't very practical explanations of the formats, and so I'm linking to a GitHub gist that contains some classes and methods, written in C#, that can read .lotheader files. They don't actually ''do'' anything with the data, however.<br />
<br />
[https://gist.github.com/Fuebar/7494753 GitHub gist displaying .lotheader reading.]<br />
<br />
<code><br />
int32, .lotheader format version, zero as of build 12.<br />
int32, number of tiles cached, following this.<br />
string[], delimited by 0x0A, variable length and no length specifying prefixes, so you'll have to read byte by byte for each one<br />
byte, empty space, has no purpose other than to be skipped. The seek position of the stream must advance one byte after reading all the strings before this.<br />
int32, width of this lot<br />
int32, height of this lot<br />
int32, number of (vertical) levels on this lot<br />
int32, number of rooms on this lot<br />
[room array here, outlined in following code segment]<br />
int32, number of buildings on this lot<br />
[building format, iterate over it the number of times specified above:]<br />
int32, number of rooms<br />
int32[], room indexes, corresponds with each room read above from 0 to the total number of rooms - 1. As long as the int32 before this indicates.<br />
[end of building format]<br />
byte[30][30], this reads until the end of the file. It is a 30x30 two-dimensional jagged array of bytes, each indicating the density of zombies within the specific area they denote<br />
</code><br />
<br />
Room format, iterate over it the number of times indicated by the <code>int32</code> representing the number of rooms:<br />
<code><br />
string, name of the room, same as in the above code segment. 0x0A delimited and must be read byte by byte until you reach 0x0A.<br />
int32, level the room is on, i.e floor<br />
int32, count of the rectangles in the room<br />
[rectangle format, iterate over it:]<br />
int32, x value of this rectangle, (wX * 300) is added to the value during assignment<br />
int32, y value of this rectangle, (wY * 300) is added to the value during assignment<br />
int32, width of the rectangle<br />
int32, height of the rectangle<br />
[end of rectangle format]<br />
int32, number of objects in this room<br />
[object format, iterate:]<br />
int32, type of object<br />
int32, x value of object, (wX * 300) added during assignment<br />
int32, y value of object, (wY * 300) added during assignment<br />
[end of object format]<br />
</code><br />
<br />
[[Category:Modding]]</div>Fuebarhttps://pzwiki.net/w/index.php?title=File_formats&diff=14381File formats2013-11-16T01:42:50Z<p>Fuebar: -- added .lotheader file format documentation and linked to a gist displaying how these can be read programmatically</p>
<hr />
<div>===map_sand.bin===<br />
<br />
A simple contiguous array of big-endian 32-bit integers. On loading, each integer is stored in a specific global option variable used to control things like zombie attributes and game speed, when the power will go out, etc. All the options you can set at the creation of a Sandbox game. Useful for tweaking options after you've already created your game.<br />
<br />
Note: If the world version is < 5 (world version is read in as a big-endian 32-bit integer from '''map_ver.bin''' the same way these are), you have to leave out Temperature and Rain when reading in variables.<br />
<br />
<code><br />
<font color="blue">int</font> Zombies, Distribution, Survivors, Speed, DayLength, StartMonth, StartTime, WaterShut, ElecShut, Loot, Temperature, Rain;<br />
<font color="blue">static class ZombieStats</font><br />
{<br />
<font color="blue">static int</font> Speed, Strength, Toughness, Transmission, Mortality, Reanimate, Cognition, Memory, Decomposition, Sight, Hearing, Smell;<br />
}<br><br />
BigEndianBinaryReader br; <font color="#008000">// implementation left out for brevity. anything that can read four bytes in big-endian order from a file works.</font><br><br />
Zombies = br.ReadInt32();<br />
Distribution = br.ReadInt32();<br />
. . .<br />
Rain = br.ReadInt32();<br><br />
ZombieStats.Speed = br.ReadInt32();<br />
. . .<br />
ZombieStats.Smell = br.ReadInt32();<br />
<font color="#008000">// order is essential, exactly as listed above in the int declarations</font><br />
</code><br />
<br />
If any new Sandbox options are added in you'll have to check /zombie/SandboxOptions.class (decompile it with Java Decompiler) and look at the load() function.<br />
<br />
Example file contents:<br />
<code><br />
00 00 00 03 | 00 00 00 01 | 00 00 00 01 | 00 00 00 03<br />
00 00 00 05 | 00 00 00 07 | 00 00 00 01 | 00 00 00 05<br />
etc., total of six lines of this length<br />
</code><br />
<br />
===TexturePacks (.pack files)===<br />
These are the files located in /media/texturepacks/, Characters.pack, Tiles.pack, and UI.pack. Reading them is simple, the implementation will probably be 20 or 30 lines long.<br />
<br />
Each file contains a number of 'pages' which are basically PNG images with an associated array of offset coordinates, widths, heights, and names, that are specify smaller rectangles on the PNG file that are to be copied into their own individual images. This is called a [https://en.wikipedia.org/wiki/Texture_atlas texture atlas] and is a common practice in game development.<br />
<br />
The integers in this file are little-endian, i.e. the least significant bytes come first. This is the default on my system, so no special stream reader was required, but you may have to use/write a little-endian reader if your system defaults to big-endian.<br />
<br />
The first four bytes of the file specify a 32-bit integer, which tells you how many pages (atlas images) are located within. Every byte after this belongs to a page, and follows the structure outlined below.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this texture page<br />
int32, number of entries in the page<br />
int32, represents a boolean value, true if non-zero. Titled 'mask' in the code, honestly not sure what it does. Not necessary for extraction purposes.<br><br />
[entries - outlined below]<br><br />
byte[], PNG data, byte[] { 49, 45, 4E, 44, AE, 42, 60, 82, EF, BE, AD, DE } marks the end of the file, they don't have to be included in the PNG's byte array.<br />
The next page starts immediately after the byte pattern specified above.<br />
</code><br />
<br />
The first entry comes immediately after the <code>mask</code> int32, there are as many entries as determined by the int preceding <code>mask</code>. You'll probably want to create a struct/class to hold the info contained in each entry, though you could do with indexed arrays as well. Each entry contains the info you need to copy the subimages out of the PNG data, and some information irrelevant to that as well.<br />
The format is most easily demonstrated with code.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this specific subtexture<br />
int32, x-coord of the upper left corner of this subimage on the subtexture<br />
int32, y-coord of the upper left corner of this subimage on the subtexture<br />
int32, width of the subtexture<br />
int32, height of the subtexture<br />
int32, number of pixels of transparent padding to the left of the image (i.e., x offset)<br />
int32, number of pixels of transparent padding on top of the image (i.e., y offset)<br />
int32, actual width of the subtexture, after including padding. Sometimes width + x-offset is less than this value, in which case padding is required on the right as well.<br />
int32, actual height of the subtexture, after including padding. Sometimes height + y-offset is less than this value, in which case padding is required at the bottom as well.<br />
</code><br />
<br />
In simpler terms, the first int32 of the entry contains the length of the char array defining its name that follows it. The next eight int32s fill the values { x, y, w, h, ox, oy, fx, fy }. After the last int32 of the subtexture's entry, if we're not on the last subtexture, the following int32 will define the length of the char array defining that subtexture's name and so on.<br />
<br />
(x, y) = offset within the entire PNG the image begins at<br><br />
(w, h) = size of the image ''on the atlas''<br><br />
(ox, oy) = offset within the (fx, fy) bounds to put the upper left corner of the image we got from (x, y)<br><br />
(fx, fy) = full desired size of the images, for most inventory images this is 32x32<br><br />
<br />
For example, the Apple inventory item entry on the page 'ninventory0' has the following values: <code>x = 184, y = 274, w = 28, h = 32, ox = 3, oy = 0, fx = 32, fy = 32;</code><br />
<br />
So to get this image, we'd load the PNG data following these entries into memory, use some method to cut a 28x32 subtexture out of the PNG at (184, 274), and then write those pixels into a 32x32 image beginning at (3, 0).<br />
<br />
===.lotheader files===<br />
These files contain information relevant to each .lotpack file in /media/maps/[map name]/. They are found in the same directory at .lotpack files and have the same naming format as well. Each <code>world_[int]_[int].lotpack</code> file has a corresponding <code>[int]_[int].lotheader</code> file that goes with it. The variables <code>wX</code> and <code>wY</code> denote world coordinates and represent the [int]_[int] part of the file name. They will be used as such to represent these in the format code below. All integers are little-endian.<br />
<br />
I feel these aren't very practical explanations of the formats, and so I'm linking to a GitHub gist that contains some classes and methods, written in C#, that can read .lotheader files. They don't actually ''do'' anything with the data, however.<br />
<br />
[https://gist.github.com/Fuebar/7494753 GitHub gist displaying .lotheader reading.]<br />
<br />
<code><br />
int32, .lotheader format version, zero as of build 12.<br />
int32, number of tiles cached, following this.<br />
string[], delimited by 0x0A, variable length and no length specifying prefixes, so you'll have to read byte by byte for each one<br />
byte, empty space, has no purpose other than to be skipped. The seek position of the stream must advance one byte after reading all the strings before this.<br />
int32, width of this lot<br />
int32, height of this lot<br />
int32, number of (vertical) levels on this lot<br />
int32, number of rooms on this lot<br />
[room array here, outlined in following code segment]<br />
int32, number of buildings on this lot<br />
[building format, iterate over it the number of times specified above:]<br />
int32, number of rooms<br />
int32[], room indexes, corresponds with each room read above from 0 to the total number of rooms - 1. As long as the int32 before this indicates.<br />
[end of building format]<br />
byte[30][30], this reads until the end of the file. It is a 30x30 two-dimensional jagged array of bytes, each indicating the density of zombies within the specific area they denote<br />
</code><br />
<br />
Room format, iterate over it the number of times indicated by the <code>int32</code> representing the number of rooms:<br />
<code><br />
string, name of the room, same as in the above code segment. 0x0A delimited and must be read byte by byte until you reach 0x0A.<br />
int32, level the room is on, i.e floor<br />
int32, count of the rectangles in the room<br />
[rectangle format, iterate over it:]<br />
int32, x value of this rectangle, (wX * 300) is added to the value during assignment<br />
int32, y value of this rectangle, (wY * 300) is added to the value during assignment<br />
int32, width of the rectangle<br />
int32, height of the rectangle<br />
[end of rectangle format]<br />
int32, number of objects in this room<br />
[object format, iterate:]<br />
int32, type of object<br />
int32, x value of object, (wX * 300) added during assignment<br />
int32, y value of object, (wY * 300) added during assignment<br />
[end of object format]<br />
</code></div>Fuebarhttps://pzwiki.net/w/index.php?title=User:Fuebar&diff=14337User:Fuebar2013-11-14T06:33:04Z<p>Fuebar: -- clear the documentation from my user page</p>
<hr />
<div>[[Modding/File Formats|File format documentation]].</div>Fuebarhttps://pzwiki.net/w/index.php?title=File_formats&diff=14336File formats2013-11-14T06:32:24Z<p>Fuebar: -- documentation on game file formats</p>
<hr />
<div>===map_sand.bin===<br />
<br />
A simple contiguous array of big-endian 32-bit integers. On loading, each integer is stored in a specific global option variable used to control things like zombie attributes and game speed, when the power will go out, etc. All the options you can set at the creation of a Sandbox game. Useful for tweaking options after you've already created your game.<br />
<br />
Note: If the world version is < 5 (world version is read in as a big-endian 32-bit integer from '''map_ver.bin''' the same way these are), you have to leave out Temperature and Rain when reading in variables.<br />
<br />
<code><br />
<font color="blue">int</font> Zombies, Distribution, Survivors, Speed, DayLength, StartMonth, StartTime, WaterShut, ElecShut, Loot, Temperature, Rain;<br />
<font color="blue">static class ZombieStats</font><br />
{<br />
<font color="blue">static int</font> Speed, Strength, Toughness, Transmission, Mortality, Reanimate, Cognition, Memory, Decomposition, Sight, Hearing, Smell;<br />
}<br><br />
BigEndianBinaryReader br; <font color="#008000">// implementation left out for brevity. anything that can read four bytes in big-endian order from a file works.</font><br><br />
Zombies = br.ReadInt32();<br />
Distribution = br.ReadInt32();<br />
. . .<br />
Rain = br.ReadInt32();<br><br />
ZombieStats.Speed = br.ReadInt32();<br />
. . .<br />
ZombieStats.Smell = br.ReadInt32();<br />
<font color="#008000">// order is essential, exactly as listed above in the int declarations</font><br />
</code><br />
<br />
If any new Sandbox options are added in you'll have to check /zombie/SandboxOptions.class (decompile it with Java Decompiler) and look at the load() function.<br />
<br />
Example file contents:<br />
<code><br />
00 00 00 03 | 00 00 00 01 | 00 00 00 01 | 00 00 00 03<br />
00 00 00 05 | 00 00 00 07 | 00 00 00 01 | 00 00 00 05<br />
etc., total of six lines of this length<br />
</code><br />
<br />
===TexturePacks (.pack files)===<br />
These are the files located in /media/texturepacks/, Characters.pack, Tiles.pack, and UI.pack. Reading them is simple, the implementation will probably be 20 or 30 lines long.<br />
<br />
Each file contains a number of 'pages' which are basically PNG images with an associated array of offset coordinates, widths, heights, and names, that are specify smaller rectangles on the PNG file that are to be copied into their own individual images. This is called a [https://en.wikipedia.org/wiki/Texture_atlas texture atlas] and is a common practice in game development.<br />
<br />
The integers in this file are little-endian, i.e. the least significant bytes come first. This is the default on my system, so no special stream reader was required, but you may have to use/write a little-endian reader if your system defaults to big-endian.<br />
<br />
The first four bytes of the file specify a 32-bit integer, which tells you how many pages (atlas images) are located within. Every byte after this belongs to a page, and follows the structure outlined below.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this texture page<br />
int32, number of entries in the page<br />
int32, represents a boolean value, true if non-zero. Titled 'mask' in the code, honestly not sure what it does. Not necessary for extraction purposes.<br><br />
[entries - outlined below]<br><br />
byte[], PNG data, byte[] { 49, 45, 4E, 44, AE, 42, 60, 82, EF, BE, AD, DE } marks the end of the file, they don't have to be included in the PNG's byte array.<br />
The next page starts immediately after the byte pattern specified above.<br />
</code><br />
<br />
The first entry comes immediately after the <code>mask</code> int32, there are as many entries as determined by the int preceding <code>mask</code>. You'll probably want to create a struct/class to hold the info contained in each entry, though you could do with indexed arrays as well. Each entry contains the info you need to copy the subimages out of the PNG data, and some information irrelevant to that as well.<br />
The format is most easily demonstrated with code.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this specific subtexture<br />
int32, x-coord of the upper left corner of this subimage on the subtexture<br />
int32, y-coord of the upper left corner of this subimage on the subtexture<br />
int32, width of the subtexture<br />
int32, height of the subtexture<br />
int32, number of pixels of transparent padding to the left of the image (i.e., x offset)<br />
int32, number of pixels of transparent padding on top of the image (i.e., y offset)<br />
int32, actual width of the subtexture, after including padding. Sometimes width + x-offset is less than this value, in which case padding is required on the right as well.<br />
int32, actual height of the subtexture, after including padding. Sometimes height + y-offset is less than this value, in which case padding is required at the bottom as well.<br />
</code><br />
<br />
In simpler terms, the first int32 of the entry contains the length of the char array defining its name that follows it. The next eight int32s fill the values { x, y, w, h, ox, oy, fx, fy }. After the last int32 of the subtexture's entry, if we're not on the last subtexture, the following int32 will define the length of the char array defining that subtexture's name and so on.<br />
<br />
(x, y) = offset within the entire PNG the image begins at<br><br />
(w, h) = size of the image ''on the atlas''<br><br />
(ox, oy) = offset within the (fx, fy) bounds to put the upper left corner of the image we got from (x, y)<br><br />
(fx, fy) = full desired size of the images, for most inventory images this is 32x32<br><br />
<br />
For example, the Apple inventory item entry on the page 'ninventory0' has the following values: <code>x = 184, y = 274, w = 28, h = 32, ox = 3, oy = 0, fx = 32, fy = 32;</code><br />
<br />
So to get this image, we'd load the PNG data following these entries into memory, use some method to cut a 28x32 subtexture out of the PNG at (184, 274), and then write those pixels into a 32x32 image beginning at (3, 0).</div>Fuebarhttps://pzwiki.net/w/index.php?title=Modding&diff=14335Modding2013-11-14T06:31:52Z<p>Fuebar: /* Modding tools for 2.9 versions */ -- hope this is the right place to put this?</p>
<hr />
<div>{{languages}}<br />
<br />
== '''License Info''' ==<br />
<br />
'''By purchasing Project Zomboid, you are permitted to:'''<br />
<br />
*Change the base files in any way you like, provided that those changes do not result in the game being playable without purchasing.<br />
*Distribute the files in any way as you like, providing the files you distribute are not useable by themselves, or accompanied with freely available downloadable files, to play the game without purchasing.<br />
*Use art, music, video footage or intellectual property of Project Zomboid for creative purposes in any way you like, providing the end result is related in some way to Project Zomboid, states Project Zomboid as its influence and origin, and is for non-commercial use only.<br />
<br />
'''You are not permitted to:'''<br />
<br />
*Modify the demo in any way beyond cosmetic graphical/sound/musical changes.<br />
*Modify the base files to include malicious code.<br />
<br />
== Scripting tutorials for 2.9 versions ==<br />
*[http://pz-mods.net/guide/event-reference/ Event References]<br />
*[http://www.theindiestone.com/community/viewtopic.php%3ff=34&t=14783.html Making a Rain Collector]<br />
*[http://www.theindiestone.com/community/viewtopic.php%3ff=34&t=13811.html Adding Professions (outdated)]<br />
<br />
== Current Mods ==<br />
*[http://theindiestone.com/forums/index.php/forum/47-completed-mods/ Completed Mods]<br />
*[http://theindiestone.com/forums/index.php/forum/52-wip-mods/ Work in Progress Mods]<br />
*[http://xeno-mods.com/ Unofficial PZ Mod Repository]<br />
*[http://pz-mods.net/ Another mod repository]<br />
<br />
==Modding tools for 2.9 versions==<br />
No tools have been released yet. As character graphics and map file formats have changed significantly, none of the old tools can be used to mod the current version.<br />
<br />
===File Format Documentation===<br />
For developers or the curious, the new file formats are documented [[Modding/File Formats|here]].<br />
<br />
==Legacy modding tools for old 0.2.0 versions==<br />
<br />
;Costume-Ed v1.0 "Released July 28 2011"<br />
:Costume Editor<br />
:http://theindiestone.com/community/viewtopic.php%3ff=34&t=3036.html<br />
<br />
;Iso-Ed v0.9ish<br />
:Floor Tile Modding Tool<br />
:http://theindiestone.com/community/viewtopic.php%3ff=34&t=6454.html<br />
<br />
====Mapping Tools====<br />
<br />
Please refer to [[Mapping]] for more a more detailed explanation of the processes involved in editing and creating maps in Project Zomboid.<br />
<br />
;Mapping Tools<br />
:Link Also contains 300x300 blank map.<br />
:http://theindiestone.com/community/viewtopic.php%3ff=27&t=7406.html"<br />
<br />
;TileZed Map Editor fantastic version of Tiled "Created by EasyPickins"<br />
:Map Editor<br />
:http://theindiestone.com/community/viewtopic.php%3ff=34&t=7521.html<br />
<br />
====Modding Tools (PZ 0.1.5)====<br />
<br />
;PZ Mod Tools 0.1.5d + character pieces<br />
:Slightly updated mod tools<br />
:Comes with some other nifty tools<br />
:http://theindiestone.com/community/viewtopic.php%3ff=34&t=4200.html<br />
<br />
==Mapping Tutorials==<br />
<br />
;Badgerflaps - Mapping Tutorial (0.1.5 specific)<br />
:http://theindiestone.com/community/viewtopic.php%3ff=34&t=3961.html<br />
<br />
;[[New_Tiles|Creating New Tiles for use in PZ 0.2.0 +]]<br />
<br />
;matsydoodles - Custom Textures (Floors/Walls/Furniture etc) (0.1.5 specific)<br />
:http://theindiestone.com/community/viewtopic.php%3ff=34&t=4608.html<br />
<br />
==Java Scripting==<br />
Java scripting refers to the modding tools originally used to create item and story mods.<br />
<br />
;Lemmy101's Modding Guide<br />
:http://www.projectzomboid.com/modtools/ModdingGuide2.rtf<br />
<br />
;Lemmy101's Java object inheritance and you<br />
:http://theindiestone.com/community/viewtopic.php%3ff=27&t=6593.html<br />
<br />
; Ontogenesis - My First Story Mod <br />
:http://theindiestone.com/community/viewtopic.php%3ff=34&t=4459.html<br />
<br />
==Lua Tutorials==<br />
<br />
'''Basic Lua Language:''' <br />
<br />
;[[Lua_Intro|An Introduction to Lua]]<br />
;[[Variables_Assignments_Datatypes|Variables, Assignments and Datatypes]]<br />
:::[[Task_One_Solutions|'''Test Yourself Solutions''']]<br />
;[[Arithmetic_Operators|Arithmetic Operators]]<br />
;[[Relational_and_Boolean_Operators|Relational and Boolean Operators]]<br />
;[[Concatenation_and_Length_Operators|Concatentation and Length Operators]]<br />
;[[If_Statements_and_Functions|If Statements and Functions]]<br />
;[[Loops|Loops]]<br />
;[[Local_and_Global_Variables|Local and Global Variables]]<br />
;[[Tables|Tables]]<br />
;[[Looping_Through_Tables|Looping Through Tables]]<br />
<br />
<br />
;Javadoc reference to Project Zomboid codebase<br />
:http://theindiestone.com/community/viewtopic.php%3Ff=34&t=5639.html‎<br />
<br />
;Ontogenesis - My First Lua Mod<br />
:http://xeno-mods.com/post/12/my-first-lua-mod-part-one<br />
:http://xeno-mods.com/post/13/my-first-lua-mod-part-two<br />
:http://xeno-mods.com/post/14/my-first-lua-mod-part-three<br />
<br />
== Specifics ==<br />
<br />
=== List of Item Parameters === <br />
Much of this information was supplied by forum member InnocentSam.<ref> http://theindiestone.com/community/viewtopic.php%3ff=27&t=3654.html </ref><br />
{| class="wikitable"<br />
!style="background:#dbdbdb;"|Parameter Name<br />
!style="background:#dbdbdb;"|Effect / Description<br />
!style="background:#dbdbdb;"|Example<br />
|-<br />
!colspan=3|General<br />
|-<br />
|Type<br />
|Item-type, describes how the item behaves. Includes 'Food', 'Weapon', 'Drainable', 'Literature', 'Clothing' and 'Normal'.<br />
|Food ([[steak]])<br />
|-<br />
|Display Name<br />
|The item's name as it appears displayed to the player.<br />
|Axe ([[axe]])<br />
|-<br />
|Icon<br />
|The item's icon as it appears displayed to the player. This parameter looks inside "media/texturepacks/ui.txt" and will call any sprite with the prefix "Item_".<br />
|Molotov ([[molotov cocktail]])<br />
|-<br />
|Weight<br />
|Item's weight, used for encumbrance.<br />
|0.1 ([[painkillers]])<br />
|-<br />
|OtherHandRequire<br />
|Requires a specified item to be held by the player in their second quick-slot before the item may be used.<br />
|Lighter ([[molotov cocktail]])<br />
|-<br />
|CanBarricade<br />
|Whether the item may be used like the hammer to barricade doors and windows.<br />
|Boolean (false or true)<br />
|-<br />
|Count<br />
|The number of items which may ever be used in the game world.<br />
|8 ([[Ripped Sheet]])<br />
|-<br />
|UseWhileEquipped<br />
|Whether the item is used over time while it is equipped.<br />
|Boolean (false or true)<br />
|-<br />
|UseDelta<br />
|Numerical value associated with how quickly the item drains.<br />
|0.0009 ([[torch]])<br />
|-<br />
|ReplaceOnUse<br />
|Name of the item which replaces the current item after use.<br />
|Pot ([[pot of soup]])<br />
|-<br />
!colspan=3|Consumables<br />
|-<br />
|IsCookable<br />
|Whether the item can be cooked.<br />
|Boolean (false or true)<br />
|-<br />
|MinutesToCook<br />
|How many in-game minutes the item must be in an oven for it to cook.<br />
|50 ([[pot of soup]])<br />
|-<br />
|MinutesToBurn<br />
|Length of time the item must be in an oven for it to be burnt. Usually double the value of 'MinutesToCook'.<br />
|150 ([[steak]])<br />
|-<br />
|HungerChange<br />
|Value applied to player's current hunger points. Positive increases hunger.<br />
|<nowiki>-</nowiki>20 ([[crisps]])<br />
|-<br />
|DaysFresh<br />
|How many days it takes for a food item to begin rotting.<br />
|2 ([[steak]])<br />
|-<br />
|DaysTotallyRotten<br />
|How many days it takes for a food item to become entirely rotten.<br />
|7 ([[carrots]])<br />
|-<br />
|DangerousUncooked<br />
|Whether the food item will negatively affect the player in an uncooked state.<br />
|Boolean (false or true)<br />
|-<br />
|RequireInHandOrInventory<br />
|Requires a specified item to be inside the player's inventory before the item may be used.<br />
|CanOpener ([[canned soup]])<br />
|-<br />
|Alcoholic<br />
|Whether the item effects the player in a similar way to [[Whiskey]].<br />
|Boolean (false or true)<br />
|-<br />
|UseSelf<br />
|Whether the item is consumed after use.<br />
|Boolean (false or true)<br />
|-<br />
!colspan=3|Weapons<br />
|-<br />
|MinAngle<br />
|The angle that the weapon attacks, a value aprox. to 1 is going to need more accuracy with mouse than one nearer to -1.<br />
|0.88 ([[shotgun]])<br />
|-<br />
|MinDamage<br />
|Minimum damage the weapon will inflict.<br />
|0.7 ([[baseball bat]])<br />
|-<br />
|MaxDamage<br />
|Maximum damage the weapon may ever inflict.<br />
|1.0 ([[baseball bat]])<br />
|-<br />
|MaxRange<br />
|Maximum range the weapon is effective.<br />
|1.5 ([[spiked baseball bat]])<br />
|-<br />
|MaxHitCount<br />
|Maximum amount of enemies the weapon will hit at one time.<br />
|1 ([[hammer]])<br />
|-<br />
|PhysicsObject<br />
|Physics object used as a projectile.<br />
|MolotovCocktail ([[molotov cocktail]])<br />
|-<br />
|SwingAnim<br />
|Name of animation which is ran when the weapon is fired/swung.<br />
|Bat ([[baseball bat]])<br />
|-<br />
|WeaponSprite<br />
|Name of sprite, the image used to display the weapon.<br />
|axe ([[axe]])<br />
|-<br />
|DoorDamage<br />
|Damage inflicted by the item on doors.<br />
|10 ([[spiked baseball bat]])<br />
|-<br />
|MinimumSwingTime<br />
|The time that takes between each swing.<br />
|15 ([[baseball bat]])<br />
|-<br />
|SwingAmountBeforeImpact<br />
|Requires more research.<br />
|0.2 ([[spiked baseball bat]])<br />
|-<br />
|PushBackMod<br />
|Distance that enemies are pushed back.<br />
|4.5 ([[Wooden Plank|wood planks]])<br />
|-<br />
|KnockBackOnNoDeath<br />
|Whether enemies are pushed back if they are not killed.<br />
|Boolean (false or true)<br />
|-<br />
|SplatNumber<br />
|Blood effects used when an enemy is injured by the weapon.<br />
|5 ([[shotgun]])<br />
|-<br />
|SplatBloodOnNoDeath<br />
|Whether an enemy injured by the weapon will bleed if they are not killed<br />
|Boolean (false or true)<br />
|-<br />
|ImpactSound<br />
|Name of sound used on impact.<br />
|splat1 ([[axe]])<br />
|-<br />
|SwingSound<br />
|Name of sound used when firing/swinging weapon.<br />
|shotgun ([[shotgun]])<br />
|-<br />
|SoundVolume<br />
|Defines the volume of a chosen sound.<br />
|40 ([[shotgun]])<br />
|-<br />
|SoundRadius<br />
|Radius in which the sound may be heard in the game world from it's point of origin.<br />
|50 ([[shotgun]])<br />
|-<br />
|ToHitModifier<br />
|Requires more research.<br />
|1.5 ([[shotgun]])<br />
|-<br />
|NPCSoundBoost<br />
|Amount that a sound is boosted when the weapon is fired by an NPC (Not player).<br />
|1.5 ([[shotgun]])<br />
|-<br />
|RangeFalloff<br />
|Requires more research.<br />
|Boolean (false or true)<br />
|-<br />
|UseEndurance<br />
|Whether the weapon causes exhaustion.<br />
|Boolean (false or true)<br />
|-<br />
|ShareDamage<br />
|Requires more research.<br />
|Boolean (false or true)<br />
|-<br />
|AmmoType<br />
|Item required to fire the weapon.<br />
|ShotgunShells ([[shotgun]])<br />
|-<br />
!colspan=3|Clothing<br />
|-<br />
|Palettes<br />
|Defines the clothing item's colors.<br />
|Trousers_Blue/Trousers_Brown/Trousers_Grey/Trousers_White ([[trousers]])<br />
|-<br />
|PalettesStart<br />
|Defines the clothing item's palette prefix.<br />
|Shirt_ ([[sweater]])<br />
|-<br />
|BodyLocation<br />
|Where the clothing item is worn.<br />
|Bottoms ([[trousers]])<br />
|-<br />
|SpriteName<br />
|Defines the sprite displayed on the player.<br />
|Shoes1 ([[shoes]])<br />
|-<br />
!colspan=3|Literature<br />
|-<br />
|StressChange<br />
|Value applied to player's current stress points. Positive makes the player become more stressed.<br />
|<nowiki>-</nowiki>10 ([[newspaper]])<br />
|-<br />
|BoredomChange<br />
|Value applied to player's current boredom points. Positive increases player's boredom.<br />
|<nowiki>-</nowiki>50 ([[book]])<br />
|}<br />
<br />
==References==<br />
<br />
<references/><br />
<br />
[[Category:Modding]]</div>Fuebarhttps://pzwiki.net/w/index.php?title=User:Fuebar&diff=14267User:Fuebar2013-11-13T20:36:30Z<p>Fuebar: -- /* File Formats */ for modding or whatever.</p>
<hr />
<div>==File Formats==<br />
<br />
Since I'm not sure where to put this for now, or if it's warranted, here it is, for nobody to read or use and for me to procrastinate. Up-to-date as of build 12 (2013-11-12).<br />
<br />
===map_sand.bin===<br />
<br />
A simple contiguous array of big-endian 32-bit integers. On loading, each integer is stored in a specific global option variable used to control things like zombie attributes and game speed, when the power will go out, etc. All the options you can set at the creation of a Sandbox game. Useful for tweaking options after you've already created your game.<br />
<br />
Note: If the world version is < 5 (world version is read in as a big-endian 32-bit integer from '''map_ver.bin''' the same way these are), you have to leave out Temperature and Rain when reading in variables.<br />
<br />
<code><br />
<font color="blue">int</font> Zombies, Distribution, Survivors, Speed, DayLength, StartMonth, StartTime, WaterShut, ElecShut, Loot, Temperature, Rain;<br />
<font color="blue">static class ZombieStats</font><br />
{<br />
<font color="blue">static int</font> Speed, Strength, Toughness, Transmission, Mortality, Reanimate, Cognition, Memory, Decomposition, Sight, Hearing, Smell;<br />
}<br><br />
BigEndianBinaryReader br; <font color="#008000">// implementation left out for brevity. anything that can read four bytes in big-endian order from a file works.</font><br><br />
Zombies = br.ReadInt32();<br />
Distribution = br.ReadInt32();<br />
. . .<br />
Rain = br.ReadInt32();<br><br />
ZombieStats.Speed = br.ReadInt32();<br />
. . .<br />
ZombieStats.Smell = br.ReadInt32();<br />
<font color="#008000">// order is essential, exactly as listed above in the int declarations</font><br />
</code><br />
<br />
If any new Sandbox options are added in you'll have to check /zombie/SandboxOptions.class (decompile it with Java Decompiler) and look at the load() function.<br />
<br />
Example file contents:<br />
<code><br />
00 00 00 03 | 00 00 00 01 | 00 00 00 01 | 00 00 00 03<br />
00 00 00 05 | 00 00 00 07 | 00 00 00 01 | 00 00 00 05<br />
etc., total of six lines of this length<br />
</code><br />
<br />
===TexturePacks (.pack files)===<br />
These are the files located in /media/texturepacks/, Characters.pack, Tiles.pack, and UI.pack. Reading them is simple, the implementation will probably be 20 or 30 lines long.<br />
<br />
Each file contains a number of 'pages' which are basically PNG images with an associated array of offset coordinates, widths, heights, and names, that are specify smaller rectangles on the PNG file that are to be copied into their own individual images. This is called a [https://en.wikipedia.org/wiki/Texture_atlas texture atlas] and is a common practice in game development.<br />
<br />
The integers in this file are little-endian, i.e. the least significant bytes come first. This is the default on my system, so no special stream reader was required, but you may have to use/write a little-endian reader if your system defaults to big-endian.<br />
<br />
The first four bytes of the file specify a 32-bit integer, which tells you how many pages (atlas images) are located within. Every byte after this belongs to a page, and follows the structure outlined below.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this texture page<br />
int32, number of entries in the page<br />
int32, represents a boolean value, true if non-zero. Titled 'mask' in the code, honestly not sure what it does. Not necessary for extraction purposes.<br><br />
[entries - outlined below]<br><br />
byte[], PNG data, byte[] { 49, 45, 4E, 44, AE, 42, 60, 82, EF, BE, AD, DE } marks the end of the file, they don't have to be included in the PNG's byte array.<br />
The next page starts immediately after the byte pattern specified above.<br />
</code><br />
<br />
The first entry comes immediately after the <code>mask</code> int32, there are as many entries as determined by the int preceding <code>mask</code>. You'll probably want to create a struct/class to hold the info contained in each entry, though you could do with indexed arrays as well. Each entry contains the info you need to copy the subimages out of the PNG data, and some information irrelevant to that as well.<br />
The format is most easily demonstrated with code.<br />
<code><br />
int32, length of the char[] to follow<br />
char[], name of this specific subtexture<br />
int32, x-coord of the upper left corner of this subimage on the subtexture<br />
int32, y-coord of the upper left corner of this subimage on the subtexture<br />
int32, width of the subtexture<br />
int32, height of the subtexture<br />
int32, number of pixels of transparent padding to the left of the image (i.e., x offset)<br />
int32, number of pixels of transparent padding on top of the image (i.e., y offset)<br />
int32, actual width of the subtexture, after including padding. Sometimes width + x-offset is less than this value, in which case padding is required on the right as well.<br />
int32, actual height of the subtexture, after including padding. Sometimes height + y-offset is less than this value, in which case padding is required at the bottom as well.<br />
</code><br />
<br />
In simpler terms, the first int32 of the entry contains the length of the char array defining its name that follows it. The next eight int32s fill the values { x, y, w, h, ox, oy, fx, fy }. After the last int32 of the subtexture's entry, if we're not on the last subtexture, the following int32 will define the length of the char array defining that subtexture's name and so on.<br />
<br />
(x, y) = offset within the entire PNG the image begins at<br><br />
(w, h) = size of the image ''on the atlas''<br><br />
(ox, oy) = offset within the (fx, fy) bounds to put the upper left corner of the image we got from (x, y)<br><br />
(fx, fy) = full desired size of the images, for most inventory images this is 32x32<br><br />
<br />
For example, the Apple inventory item entry on the page 'ninventory0' has the following values: <code>x = 184, y = 274, w = 28, h = 32, ox = 3, oy = 0, fx = 32, fy = 32;</code><br />
<br />
So to get this image, we'd load the PNG data following these entries into memory, use some method to cut a 28x32 subtexture out of the PNG at (184, 274), and then write those pixels into a 32x32 image beginning at (3, 0).</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Yoyo.png&diff=14224File:Yoyo.png2013-11-13T01:55:07Z<p>Fuebar: uploaded a new version of &quot;File:Yoyo.png&quot;: -- compressed</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Watermelon_Slice.png&diff=14223File:Watermelon Slice.png2013-11-13T01:54:23Z<p>Fuebar: uploaded a new version of &quot;File:Watermelon Slice.png&quot;: -- transparent background</p>
<hr />
<div>Slice of watermelon</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Watermelon_slices.png&diff=14220File:Watermelon slices.png2013-11-13T01:53:25Z<p>Fuebar: uploaded a new version of &quot;File:Watermelon slices.png&quot;: -- compressed</p>
<hr />
<div>Watermelon pieces or slices.</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Watermelon.png&diff=14219File:Watermelon.png2013-11-13T01:52:55Z<p>Fuebar: uploaded a new version of &quot;File:Watermelon.png&quot;: -- transparent background</p>
<hr />
<div>A watermelon</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Wallet.png&diff=14217File:Wallet.png2013-11-13T01:51:47Z<p>Fuebar: uploaded a new version of &quot;File:Wallet.png&quot;: -- transparent background</p>
<hr />
<div>Wallet icon</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:DoorFrame.png&diff=14216File:DoorFrame.png2013-11-13T01:51:26Z<p>Fuebar: uploaded a new version of &quot;File:DoorFrame.png&quot;: -- compressed</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Wall.png&diff=14215File:Wall.png2013-11-13T01:50:51Z<p>Fuebar: uploaded a new version of &quot;File:Wall.png&quot;: -- transparent background</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Vitamins.png&diff=14214File:Vitamins.png2013-11-13T01:50:32Z<p>Fuebar: uploaded a new version of &quot;File:Vitamins.png&quot;: -- transparent background</p>
<hr />
<div>Vitamins icon</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Tuna.png&diff=14213File:Tuna.png2013-11-13T01:50:06Z<p>Fuebar: uploaded a new version of &quot;File:Tuna.png&quot;: -- transparent background</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Tomato_Rotten.png&diff=14212File:Tomato Rotten.png2013-11-13T01:49:15Z<p>Fuebar: uploaded a new version of &quot;File:Tomato Rotten.png&quot;: -- new image</p>
<hr />
<div>a rotten tomato</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Tomato.png&diff=14211File:Tomato.png2013-11-13T01:49:01Z<p>Fuebar: uploaded a new version of &quot;File:Tomato.png&quot;: -- new image</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Tissues.png&diff=14210File:Tissues.png2013-11-13T01:48:35Z<p>Fuebar: uploaded a new version of &quot;File:Tissues.png&quot;: -- compressed</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:SmallTeaBag.png&diff=14209File:SmallTeaBag.png2013-11-13T01:47:37Z<p>Fuebar: uploaded a new version of &quot;File:SmallTeaBag.png&quot;: -- compressed</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Steakburned.png&diff=14207File:Steakburned.png2013-11-13T01:46:43Z<p>Fuebar: uploaded a new version of &quot;File:Steakburned.png&quot;: -- normal size</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Steakcooked.png&diff=14206File:Steakcooked.png2013-11-13T01:46:27Z<p>Fuebar: uploaded a new version of &quot;File:Steakcooked.png&quot;: -- normal size</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Steakmoldy.png&diff=14205File:Steakmoldy.png2013-11-13T01:46:13Z<p>Fuebar: uploaded a new version of &quot;File:Steakmoldy.png&quot;: -- normal size</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Steak.png&diff=14204File:Steak.png2013-11-13T01:45:59Z<p>Fuebar: uploaded a new version of &quot;File:Steak.png&quot;: -- normal size</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Spoon.png&diff=14203File:Spoon.png2013-11-13T01:45:31Z<p>Fuebar: uploaded a new version of &quot;File:Spoon.png&quot;: -- transparent background</p>
<hr />
<div>The spoon icon</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Sledgehammer.png&diff=14202File:Sledgehammer.png2013-11-13T01:44:21Z<p>Fuebar: uploaded a new version of &quot;File:Sledgehammer.png&quot;: -- transparent background</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=Skirt&diff=14201Skirt2013-11-13T01:43:33Z<p>Fuebar: -- added weight, put Languages on top</p>
<hr />
<div>{{Languages}}<br />
{{Items<br />
|image = Skirt.png<br />
|weight = 0.0<br />
}}<br />
<br />
The skirt is an article of clothing wearable on the legs. The skirt gives less warmth than the trouser. They can be used to make bandages.<br />
<br />
However, skirts are only wearable by female characters.<br />
<br />
==Code==<br />
<nowiki>item Shoes<br />
{<br />
Type = Clothing,<br />
Type = Clothing,<br />
BodyLocation = Bottoms,<br />
DisplayName = Skirt,<br />
Icon = Skirt,<br />
Palettes = Skirt_Brown/Skirt_Grey/Skirt_White/Skirt_Blue/Skirt_Purple,<br />
PalettesStart = Skirt_,<br />
SpriteName = Skirt,<br />
Temperature = 5<br />
}</nowiki><br />
<br />
== History ==<br />
{| class="wikitable" width="550" style="text-align:center;"<br />
|-<br />
! Alpha || <br />
|-<br />
| RC 2.9 || Added to the game. <br />
|}<br />
<br />
==See Also==<br />
* [[Vest]]<br />
<br />
{{Navbox/Clothing}}<br />
<br />
[[Category:Clothing]]<br />
[[Category:Items]]<br />
[[Category:Version 0.2.0r]]</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Skirt.png&diff=14200File:Skirt.png2013-11-13T01:43:00Z<p>Fuebar: Blue variant of the Skirt.</p>
<hr />
<div>Blue variant of the Skirt.</div>Fuebarhttps://pzwiki.net/w/index.php?title=Skirt&diff=14199Skirt2013-11-13T01:42:36Z<p>Fuebar: -- added Items template</p>
<hr />
<div>{{Items<br />
|image = Skirt.png<br />
}}<br />
<br />
{{Languages}}<br />
<br />
The skirt is an article of clothing wearable on the legs. The skirt gives less warmth than the trouser. They can be used to make bandages.<br />
<br />
However, skirts are only wearable by female characters.<br />
<br />
==Code==<br />
<nowiki>item Shoes<br />
{<br />
Type = Clothing,<br />
Type = Clothing,<br />
BodyLocation = Bottoms,<br />
DisplayName = Skirt,<br />
Icon = Skirt,<br />
Palettes = Skirt_Brown/Skirt_Grey/Skirt_White/Skirt_Blue/Skirt_Purple,<br />
PalettesStart = Skirt_,<br />
SpriteName = Skirt,<br />
Temperature = 5<br />
}</nowiki><br />
<br />
== History ==<br />
{| class="wikitable" width="550" style="text-align:center;"<br />
|-<br />
! Alpha || <br />
|-<br />
| RC 2.9 || Added to the game. <br />
|}<br />
<br />
==See Also==<br />
* [[Vest]]<br />
<br />
{{Navbox/Clothing}}<br />
<br />
[[Category:Clothing]]<br />
[[Category:Items]]<br />
[[Category:Version 0.2.0r]]</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:SmallSawnOffShotgun.png&diff=14198File:SmallSawnOffShotgun.png2013-11-13T01:41:03Z<p>Fuebar: uploaded a new version of &quot;File:SmallSawnOffShotgun.png&quot;: -- compressed</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:SheetRope.png&diff=14196File:SheetRope.png2013-11-13T01:35:59Z<p>Fuebar: uploaded a new version of &quot;File:SheetRope.png&quot;: -- compressed</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Rotten_Salmon.png&diff=14194File:Rotten Salmon.png2013-11-13T01:34:20Z<p>Fuebar: uploaded a new version of &quot;File:Rotten Salmon.png&quot;: -- transparent background</p>
<hr />
<div>Rotten Salmon</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Salmon.png&diff=14192File:Salmon.png2013-11-13T01:33:48Z<p>Fuebar: uploaded a new version of &quot;File:Salmon.png&quot;: -- actual Raw Salmon</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Roasting_Pan.png&diff=14190File:Roasting Pan.png2013-11-13T01:31:23Z<p>Fuebar: uploaded a new version of &quot;File:Roasting Pan.png&quot;: -- transparent background</p>
<hr />
<div>Roasting Pan (empty)</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Razor.png&diff=14189File:Razor.png2013-11-13T01:31:06Z<p>Fuebar: uploaded a new version of &quot;File:Razor.png&quot;: -- transparent background</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Potato.png&diff=14186File:Potato.png2013-11-13T01:28:51Z<p>Fuebar: uploaded a new version of &quot;File:Potato.png&quot;: -- transparent background</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Popcorn.png&diff=14185File:Popcorn.png2013-11-13T01:28:06Z<p>Fuebar: uploaded a new version of &quot;File:Popcorn.png&quot;: -- transparent background</p>
<hr />
<div>Popcorn (cooked)</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Pool_cue.png&diff=14184File:Pool cue.png2013-11-13T01:27:28Z<p>Fuebar: uploaded a new version of &quot;File:Pool cue.png&quot;: -- transparent background</p>
<hr />
<div>Pool cue picture</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Sleepingtablets.png&diff=14182File:Sleepingtablets.png2013-11-13T01:25:39Z<p>Fuebar: uploaded a new version of &quot;File:Sleepingtablets.png&quot;: -- better image</p>
<hr />
<div>Sleeping tablets. (pre-alpha)</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Painkillers.png&diff=14181File:Painkillers.png2013-11-13T01:24:35Z<p>Fuebar: uploaded a new version of &quot;File:Painkillers.png&quot;: -- transparent background</p>
<hr />
<div>Painkillers icon</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Pie.png&diff=14178File:Pie.png2013-11-13T01:22:43Z<p>Fuebar: uploaded a new version of &quot;File:Pie.png&quot;: -- transparent background</p>
<hr />
<div>Pie</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Pencil.png&diff=14177File:Pencil.png2013-11-13T01:22:05Z<p>Fuebar: uploaded a new version of &quot;File:Pencil.png&quot;: -- transparent background</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Pen.png&diff=14176File:Pen.png2013-11-13T01:21:50Z<p>Fuebar: uploaded a new version of &quot;File:Pen.png&quot;: -- transparent background</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Peas.png&diff=14175File:Peas.png2013-11-13T01:21:31Z<p>Fuebar: uploaded a new version of &quot;File:Peas.png&quot;: -- compressed</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Peanut_butter.png&diff=14174File:Peanut butter.png2013-11-13T01:21:11Z<p>Fuebar: uploaded a new version of &quot;File:Peanut butter.png&quot;: -- transparent background</p>
<hr />
<div></div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Pan.png&diff=14173File:Pan.png2013-11-13T01:20:33Z<p>Fuebar: uploaded a new version of &quot;File:Pan.png&quot;: -- transparent background</p>
<hr />
<div>Pan (empty)</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Orange.png&diff=14171File:Orange.png2013-11-13T01:19:13Z<p>Fuebar: uploaded a new version of &quot;File:Orange.png&quot;: -- transparent background</p>
<hr />
<div>Orange</div>Fuebarhttps://pzwiki.net/w/index.php?title=File:Onion_rotten.png&diff=14170File:Onion rotten.png2013-11-13T01:18:58Z<p>Fuebar: uploaded a new version of &quot;File:Onion rotten.png&quot;: -- transparent background</p>
<hr />
<div>rotten onion</div>Fuebar