Home » SIRTECH CLASSICS » Jagged Alliance: Unfinished Business » Tools and Guides Repository (Archive) » JSD file structure and misc info
JSD file structure and misc info[message #222090]
||Fri, 19 June 2009 23:58 |
||I've decided to save as much info I can recover from the Russian forums, in case they vanish again:
Info is posted my Terapevt and IS translated with Google so so bits might sound funny. Later bits come from Pipetz (the author of that awesome JSD viewer and editor), VM and Black Dragon (which made JSDedit)
Some of this info has already been uploaded at v1.13 wiki, but in not such obvious places. I think it doesnt hurt anyway to have it listed here too.
Ah... and just for the trivia, here's a 2008 post by Chris Camfield, here at Bear's Pit:
Someone in the community emailed me recently about the tool to create JSD files, which, if I remember correctly, were the Jagged Structure Data files, for representation of physical objects in the world. (I don't know why this would be needed to make animated trees. I've forgotten a lot.)
Unfortunately, after checking, I realized that I don't have any of the tools.
But, I can tell you our tool was pretty crappy - a text script converter. You guys have always been bright. With the definition of the structure information in the source code, it should be possible to make a tool better than what we had.
Taking a brief look at Structure Internals.h, it starts to come back to me.
Each object occupied one or more tiles. There'd be some information for each tile. I don't think that the tile for the origin had to come first.
The heart of each tile's info was LOS information stored in 25 bytes, in a 5x5 array. The bits in each byte represented whether the object occupied that sub-cell of the tile. There was stuff for flags and armour values and so on which determined all kinds of stuff like whether you could walk on a particular tile.
The file had a header, TAG_STRUCTURE_FILE_HEADER, which defined the number of structures defined
in the file, and contained a member variable with the # of bytes of the rest of the file in it, so the engine could load the rest of the file in one big chunk and then work with it.
The files could also contain "auxiliary data". And something else (usNumberOfImageTileLocsStored?). Unfortunately I don't remember what these were, and I don't have the complete source code.
Sorry if this isn't very helpful.
[Updated on: Sat, 27 June 2009 03:02] by Moderator
Re: JSD file structure and misc info[message #222098]
||Sat, 20 June 2009 00:40 |
||Values Shape Heights, this bit array. There are 16 ways to fill (from 0 to 15), for the visibility they just presented in a graphical table. Accordingly, the 2-nd and 3 rd differ because in the first case, the bottom has a hole (from the ground up to knee), while the second - a complete filling.
There are three main types of JSD-files (1, 2, 3), its type is specified in the header of the flag at 0Ah. Existing JSD-editor works only with 2-m type, of which, incidentally, a majority. Other types require manual edits and / or fine-tuning in hexa, but this story is too long to describe it in a nutshell.
[Updated on: Sat, 20 June 2009 00:41] by Moderator
Re: JSD file structure and misc info[message #222103]
||Sat, 20 June 2009 00:53 |
||Feature of different types - the value of a flag in the header file to 0Ah. IMHO this flag in the source is undocumented, as I did not find its description. From my research in jsd format, it can take three values: 01, 02, 03.
The unit said that the structure jsd is flat and can contain animation. Such, for example, are all decorative elements, were hanged on the wall or lezhazhie in taylsete in the "trash." For a description of a frame-tion file, in such jsd-structure has not 32 bytes, as usual, and 16. This 16-byte structure and contains a 4 flag. The first byte indicates the structure of its direction, which can be 4. If memory serves, it is: 01 - NE-wall, 02 - NW-wall, 03 - SW-wall 04 - SE-wall. If the flag is equal to 00, the structure is not oriented, ie suitable for any direction. If jsd is animated, the next flag is at the 7 th byte structure. Its value is the number of frames in an animation sequence. Next, 8-th byte structure contains the number of frames in the animation. In the animated jsd, ninth byte is set to 02 - ХЗ what it is
The value 02 is standard, static jsd facility, and works with this version jsd editor. There are some unknows for me, for example in the structures of trees, which I already wrote to you and that should be parsed. But in general, the editor of this type jsd handles.
The value 03 is the sum of the first two, as a rule, this volume animation. Header of this file is entirely the same form as the 02-th type, with the exception of the 7-th byte, which is set to 03. This is followed by 16-byte, and the description of the structures zhsd 01-type, since they are 32-byte description of the standard 02-type. It follows that if you want to view or edit jsd animated object in heks editor must cut out all of the original 16-th byte structure and change in the header value of the 7-th byte to 02, after this jsd editor will open and show you jsd of the object. After editing all the back and insert the correct number and number of frames in the hands heksah. This is how I am now working with nonstandard jsd files.
Re: JSD file structure and misc info[message #222104]
||Sat, 20 June 2009 00:55 |
||JSD (JA2 Structure Data) format.
JSD format used in the game Jagged Alliance 2 for storing information on the physical properties of objects.
Header file (16 bytes, the structure STRUCTURE_FILE_HEADER).
Structure STRUCTURE_FILE_HEADER described in TileEngine \ Structure Internals.h
1-4 bytes - symbols "J2SD" identifier format.
Bytes 5-6 - (usNumberOfStructures) the number of structures \ images associated with the object.
As seems always the same number of images in the same STI-file.
Bytes 7-8 - (usNumberOfStructuresStored) the number of structures described in this file.
It may be less than the number of structures \ images associated with the object. Sometimes
that for each image stored in the same STI-file structure is needed.
For files of type 1 is always 0. On types below.
9-10 bytes - the total amount of structure in bytes. For files of type 1 is always
is 0. On types below.
11 - byte - flags. Identify the type of file.
1 bit - is equal to 1 if the file contains supporting information.
2 bits - is equal to 1 if the file contains information on the structures.
Bits 3-8 - not used.
Thus there are three types of JSD-Files 1 (00000001), 2 (00000010) and 3 (00000011).
3 type, and contains a supportive and structured information.
12-14 bytes - not used
15-16 bytes - (usNumberOfImageTileLocsStored) is not equal to zero only for some
File Type 1. Purpose not clear. As seems always equal to the sum of the values
ubNumberOfTiles field for all records supporting data.
For files of type 1 after the 16-th byte are recording auxiliary data.
The total size - (the number of structures \ images associated with the object) * 16.
For files of type 2, after the 16-th byte are structural data.
For files of type 3 after the 16-th byte first recording auxiliary data
and then the structural data.
Records supporting data are loaded into the structure AuxObjectData. This tazhe structure
that is used to load application data (Application Data) STI-files.
Aux - apparently an abbreviation for "auxiliary" - a subsidiary.
Structure AuxObjectData described in the Standard Gaming Platform \ imgfmt.h.
1 byte - Wall orientation (ubWallOrientation).
2 bytes - number taylov (ubNumberOfTiles). Almost always 0. When greater than zero
is the number taylov occupied by the object. It is not clear what is defined by equality
or inequality to zero of the byte. It is clear that none of the object 0 taylov not
3-4 bytes - the offset in the first taylah tayla object if the number of order all
tayly all objects. To preview an object is equal to 0, the second number taylov
In the first, etc.
5-7 bytes - not used.
8 bytes - the number of frames. There is zero only for animirovanyh structures.
9 bytes - is the number of images.
10 byte - flags.
1 bit - (AUX_FULL_TILE)
2 bit - 1 if the file animiroanny (AUX_ANIMATED_TILE)
3 bit - (AUX_DYNAMIC_TILE)
4 bits - (AUX_INTERACTIVE_TILE)
Bit 5 - (AUX_IGNORES_HEIGHT)
6 bits - (AUX_USES_LAND_Z)
Bits 7-8 - not used.
11-16 bytes - not used.
Structural data provide for each structure is described in the JSD-file information.
- The title of structure (16 bytes)
- Taylovye structure ((number taylov) * 32 bytes)
The title of structure (16 bytes, the structure DB_STRUCTURE).
Structure DB_STRUCTURE described in TileEngine \ Structure Internals.h.
1 byte - (ubArmour) Armor. Accepts values from 0 to 26, all the values mentioned by name in
in the enumeration, which is described in the file TileEngine \ structure.h. It should be noted
that the value of this byte does not determine velechinu rest. ubArmour --
this index in the array gubMaterialArmour  =
(0,25,20,30,3,10,47,10,0,0,0,55,63,70,85,9,40,1,40,0,0,37,57,85,127,127, 57 );
Description of the array in the code accompanying interenye comments that are
cause I will not. Reservations affect the damage strikes the object.
On the slowing down of the bullet passing through the structure. At the sound issued
when hit, struck, opening / closing;
2 bytes - (ubHitPoints) persistence. Damage, which should cause the object to its destruction;
3 bytes - (ubDensity) density. Accepts values from 0 to 100. Influences on the probability
bullet passing through an object, the chance of causing critical damage
(and on the transparency / prosmatrivaemost?);
4 bytes - (ubNumberOfTiles) number taylov occupied structure
5-8 bytes - flags. Identifies the type of structure.
1 bit - STRUCTURE_BASE_TILE.
2 bits - STRUCTURE_OPEN
3 bit - STRUCTURE_OPENABLE / STRUCTURE_CLOSEABLE / STRUCTURE_SEARCHABLE
4 bits - STRUCTURE_HIDDEN
5 bits - STRUCTURE_MOBILE
6 bits - STRUCTURE_PASSABLE
7 bits - STRUCTURE_EXPLOSIVE
8 bit - STRUCTURE_TRANSPARENT
9 bits - STRUCTURE_GENERIC
10 bits - STRUCTURE_TREE
11 bit - STRUCTURE_FENCE
12 bit - STRUCTURE_WIREFENCE
13 bit - STRUCTURE_HASITEMONTOP
14 bit - STRUCTURE_SPECIAL
15 bit - STRUCTURE_LIGHTSOURCE
16 bit - STRUCTURE_VEHICLE
17 bit - STRUCTURE_WALL
18 bit - STRUCTURE_WALLNWINDOW
19 bit - STRUCTURE_SLIDINGDOOR
20 bit - STRUCTURE_DOOR
21 bit - STRUCTURE_MULTI
22 bit - STRUCTURE_CAVEWALL
23 bit - STRUCTURE_DDOOR_LEFT
24 bit - STRUCTURE_DDOOR_RIGHT
25 bit - STRUCTURE_NORMAL_ROOF
26 bit - STRUCTURE_SLANTED_ROOF
27 bit - STRUCTURE_TALL_ROOF
28 bits - STRUCTURE_SWITCH
29 bit - STRUCTURE_ON_LEFT_WALL
30 bit - STRUCTURE_ON_RIGHT_WALL
31 bit - STRUCTURE_CORPSE
32 bits - STRUCTURE_PERSON
9-10 bytes - poryadkovay number of structures.
11 byte - (ubWallOrientation) orientation of the wall.
12 bytes - (bDestructionPartner) Specifies the index of the image object taylsete
after the destruction. How to determine it is not entirely clear. In the code a little
Comment:> 0 = debris number (bDP - 1) <0 = partner graphic
13 byte - (bPartnerDelta) Determines the difference between the indices in the open and taylsete
closed structures (eg doors).
14 byte - (bZTileOffsetX)
15 byte - (bZTileOffsetY) 14, 15 bytes seem to determine the additional
displacement by rendering multiple objects at one tayle. Define
sOffsetX = sOffsetX - pDBStructure-> bZTileOffsetX * (WORLD_TILE_X / 2) +
pDBStructure-> bZTileOffsetY * (WORLD_TILE_X / 2);
sOffsetY = sOffsetY - pDBStructure-> bZTileOffsetY * (WORLD_TILE_Y / 2);
why it is not clear. WORLD_TILE_X = 40 - tayla width in pixels.
WORLD_TILE_Y = 20 - height tayla in pixels.
16 bytes - not used.
Tileset structure (32 bytes, the structure DB_STRUCTURE_TILE).
Structure DB_STRUCTURE_TILE described in TileEngine \ Structure Internals.h.
Bytes 1-2 - (sPosRelToBase) seem to shift the serial number on tayla
serial number of basic (first) tayla object. For some reason, very often
3 bytes - (bXPosRelToBase) Offset tayla relative to the base along the axis X.
4 bytes - (bYPosRelToBase) Offset tayla relative to the base along the axis Y.
5-29 bytes - (Shape) Form tayla. The bytes in this array are the values from 0 (0000)
to 15 (1111). Tayl divided into 25 parts, 5 rows and 5 columns. So
way, each byte of the array corresponds to columns of 4 cubes standing
at one of 25 parts tayla. If any of the 4-bit byte is equal to 1, then
the corresponding cube is considered to be filled structure. In other words
cube with coordinates X, Y, Z will be filled if
(Shape [X * 5 + Y] / 2Z)% 2 = 1.
It seems so.
30 byte - (fFlags) flags.
1 bit - tayl is at the level of the roof.
2 bits - tayl available for passage.
Bits 3-8 - not used.
31 byte - (ubVehicleHitLocation) the location of impact on the vehicle.
Probably never used.
32 bytes of data - do not use.
In the arrangement of the data attache JSD-File Type 3. File Type 1 has no structural data (blue rectangle), the file type 2 no supporting data (green pryamouolnik).
[Updated on: Sat, 20 June 2009 00:58] by Moderator
Current Time: Wed Dec 13 07:19:14 EET 2017
Total time taken to generate the page: 0.01079 seconds