Difference between revisions of "Item Definition"
m |
m (→Format and syntax description) |
||
Line 14: | Line 14: | ||
Comments are usually indicated by the character '#'. It is possible to add comments to the end of an line, but breaking the line format for the current section using comments may cause hard to find game crashes during loading stage. This is why a comment should always be placed on an seperate line. Comments can also be placed outside of sections. | Comments are usually indicated by the character '#'. It is possible to add comments to the end of an line, but breaking the line format for the current section using comments may cause hard to find game crashes during loading stage. This is why a comment should always be placed on an seperate line. Comments can also be placed outside of sections. | ||
− | The line format itself is always the same. It only differs in the number of parameters. Parameters are the semantical content of the line. Parameters are usually seperated by a comma character. Starting and ending [[wikipedia:Whitespace_character|whitespace characters]] get trimmed. However using whitespaces inside a parameter is not possible in almost every case so that they are simply used to structure the file more clearly. Strings can be encased by the character '"', but this is optional and rarely used by default. | + | The line format itself is always the same. It only differs in the number of parameters. Parameters are the semantical content of the line. Parameters are usually seperated by a comma character. Starting and ending [[wikipedia:Whitespace_character|whitespace characters]] get trimmed. However using whitespaces inside a parameter is not possible in almost every case so that they are simply used to structure the file more clearly. Strings can be encased by the character '"', but this is optional and rarely used by default. Also the games parser uses an invariant culture to parse numerical values and strings. Which means strings are [[Wikipedia:ASCII|ASCII]] encrypted and the decimal seperator is '.'. |
==== Section example ==== | ==== Section example ==== |
Revision as of 08:00, 27 July 2010
This article may need to be rewritten. Please help improve this article. The discussion page may contain suggestions. |
IDE Sections:
|
Item definition files, usually identicated by the file extension .ide
, are used to declare many different aspects for the map system or to specify special behaviour rules for one of the aspects. They are stored in plain text format, so that they can be opened by any text editing program (like Notepad), but there are also some tools to simplify editing.
Contents
Overview
The item definition files are split up into several sections. Each section itself is optional which means there is no rule descriping in which order you use the sections. Also there is no need for using all sections inside your file.
Format and syntax description
The basic structure of the different sections is pretty simple. Each section starts with an 4 character identifier indicating how the content of the section gets interpreted by the game. The identifier is followed by the definition entries. Every entry takes one line and every line follows certain rules which get descriped in the articles handling the sections in detail (see below). However lines can also be empty or commented. If so they get ignored by the games parser. The end of every section gets indicated by the string "end". Both (section identifier and terminating string) are not case sensitive, but by default they are written in lower case.
Comments are usually indicated by the character '#'. It is possible to add comments to the end of an line, but breaking the line format for the current section using comments may cause hard to find game crashes during loading stage. This is why a comment should always be placed on an seperate line. Comments can also be placed outside of sections.
The line format itself is always the same. It only differs in the number of parameters. Parameters are the semantical content of the line. Parameters are usually seperated by a comma character. Starting and ending whitespace characters get trimmed. However using whitespaces inside a parameter is not possible in almost every case so that they are simply used to structure the file more clearly. Strings can be encased by the character '"', but this is optional and rarely used by default. Also the games parser uses an invariant culture to parse numerical values and strings. Which means strings are ASCII encrypted and the decimal seperator is '.'.
Section example
objs ... end
Sections
The following table contains basic information about all known sections. For additional information read the articles itself.
Identifier | Supported games | Description |
---|---|---|
Most important section: defines objects for the map. | ||
Basicly does the same as OBJS, but it has two additional parameters defining the ingame time range the object can get rendered. | ||
Basicly does the same as OBJS, but it has one additional parameter identicating an IFP or WAD animation file to assign an animation to the object. | ||
Used to define "pedestrians" (Random NPC's). | ||
Used to define weapons. | ||
Used to define vehicles. | ||
Partly unknown. Used to define objects for interactions with actors for example in cutscenes. | ||
Used to virtually extent texture dictionarys. | ||
Used to add particles to objects, defined in one of the sections above (except TXDP). | ||
Used to create waypoints for random NPC spawns (Paths). | ||
– | ||
Used to combine TOBJ and ANIM sections. | ||
– | ||
– |
IDE Flags
Flags are used in order to specify the behaviour of objects. They are interpreted as signed 32-bit integer values where each bit descripes a boolean value of an different aspect. The following table shows the standart flags used for objects defined in OBJS, TOBJ and ANIM section.
Flag | Supported games | Binary | Description |
---|---|---|---|
1111 1111 1111 1111 1111 1111 |
Enables all flags. [1] Never used by default. | ||
0000 0000 0000 0000 0000 0001 |
Wet effect (objects appear darker). | ||
0000 0000 0000 0000 0000 0010 |
Indicates that the object gets rendered at night for objects defined in TOBJ. | ||
0000 0000 0000 0000 0000 0100 |
Alpha transparency 1 | ||
0000 0000 0000 0000 0000 1000 |
Alpha transparency 2 | ||
0000 0000 0000 0000 0001 0000 |
Opposite to flag 2 | ||
0000 0000 0000 0000 0010 0000 |
Indicates an object to be used inside an interior. | ||
0000 0000 0000 0000 0100 0000 |
Disables the shadow mesh to project a shadow. | ||
0000 0000 0000 0000 1000 0000 |
Object surface will not be culled. | ||
0000 0000 0000 0001 0000 0000 |
Disables draw distance (Only used for LOD objects with an LOD value greater than 299). | ||
0000 0000 0000 0010 0000 0000 |
Object is breakable (like glass – additional parameters defined inside the object.dat file, otherwise there is no effect). | ||
0000 0000 0000 0100 0000 0000 |
Similar to flag 512: object first cracks on a strong collision, then it breaks (does also require object.dat registration). | ||
0000 0000 0000 1000 0000 0000 |
Indicates an object as an garage door (for more information see GRGE – requires object.dat registration). | ||
0000 0000 0001 0000 0000 0000 |
Indicates an multiclump object (Object switches from clump 2 to clump 1 after collision – requires object.dat registration). | ||
0000 0000 1000 0000 0000 0000 |
Uses object brightness from the current weather definition (See timecyc.dat – PoleShd). | ||
0000 0001 0000 0000 0000 0000 |
Object explodes after getting hit (requires object.dat registration). | ||
0000 0010 0000 0000 0000 0000 |
Unknown – apparently some flag for the Script. | ||
0000 0100 0000 0000 0000 0000 |
Unknown – only used 1 time in San Andreas. | ||
0000 1000 0000 0000 0000 0000 |
Object will switch from clump 2 to clump 1 after getting sprayed by the player (graffity flag). | ||
0001 0000 0000 0000 0000 0000 |
Disables backface culling – as an result the texture will be drawed on both sides of the model (Always enabled for GTA III and Vice City) | ||
0010 0000 0000 0000 0000 0000 |
Unknown – apparently related into physics. |
For flags defining different aspects of different definitions read the articles about their sections.
Difference between GTA III and GTA IV engines
GTA IV not only uses different formats to the previous games, it also does not use ID's any longer in order to identify objects. While GTA III era games are using an ID as an index inside an array of definitions GTA IV uses the hashes of the model name as an key inside an hashtable. For more information about this see Map System.
Tools
- GTAGarage: IDEditor - By Xmen
- GTAForums: IDE-IV in GTA-IV script centre - by Gforce
- FlagValue Calculator - By Aschratt - Calculates all flagvalues (even those unknown).
See also
References
External Links
- GTAForums: GTAVC IDE Definitions - topic by ODIE covering specific details of IDE files in GTA VC
- GTAForums: GTA3/VC Map File Documentation and Troubleshooting - topic by Opius covering general features of IDE files in GTA3 and GTA VC
- ID Flagvalue Decoding Project - project to decode all missing flag values
Grand Theft Auto IV | |
---|---|
File Formats | .dat • .gxt • .ide • .img • .ipl • .nod • .sco • .rpf • .rrr • .wad • .wbd/.wbn • .wdd • .wdr • .wft • .whm • .wpl • .wtd |
Documentation | Audio • Bink Video • Cryptography • Cutscenes • GXT Text • Image listing • Keycodes • Map Listing • Native functions • Paths • Radar Blips • Radio Stations • Saves • Scenarios • VTable • Weapons |
Tools | ASI Loader • ENBSeries • G-Texture • GIMS IV • Ingame WPL Editor • IV Needle • OpenIV • SparkIV • XLiveLess • WPL Manager • X Mod Installer Alice • C++ Script Hook • .NET Script Hook • Scocl |
Tutorials | Importing Textures with OpenIV • Importing Textures with SparkIV |
Modifications | GTA Connected • Gostown IV • Four Multiplayer • IV Multiplayer • CitizenMP:IV Reloaded |
Useful links | Community portal • Discussion forums • Modding forums • Mods on GTAGarage.com |