SAT & EAT Tool 2018 Tools created by Son of Persia Tutorial prepared by Mr.Curious
Introduction Another Another interesting interesting chapter chapter in our our tutorial tutorial series will will be dealing dealing with with the long awaited awaited collision tool (aka (aka the SAT EAT tool). For many years this piece of the puzzle was a mystery and remained the last barrier for creating fully functional custom stages in esiedent E!il ". Thanks to Son of #ersia$s dedication % persistence& we now ha!e this tool at our disposal. To start& let us look at the E" file types we will be dealing with using the SAT EAT tool. This tool actually allows us to deal with both SAT % EAT files& which are essentially the same thing but used for different purposes. 'oth file types are collision maps& one being for the player (SAT) and the other for proectiles (EAT). e may wish to use the SAT collision data for different purposes. Some of us may only wish to use it as a reference when editing other aspects of a room& while others may wish to actually edit the collision data. As descirbed in teh *+ni!ersal ,oncepts -uide* & the first thing we want to do when opening any kind of room in ds /a0 is to open the collision data (SAT) file to use as a refference for scale& as many of hte rooms in E" use different scales (01&012& 0122) etc. E0tracting the SAT data gi!es us a reference to the scale at which we are working& and can be used as a reference with other files& such as the AE3& 45T& and other files that create 6'7 files that we can import into the d program. 5f we are using other tools like the ,S869 E4S enemy tool& it is important to ha!e SAT data to reference where the enemies will be placed on the map. 5f we are simply using the SAT data for reference& 5 suggest to use the *FEE8E* layer option in ds/a0for the SAT data layers so that they do not accidentally get shifted while editing other elements. e can also make these layers wireframe or transperant so they are easy to see though while editing other obects.
!"#I$% IT TE SAT 'I(E IMP!"TI$% SAT )ATA 1 : To start& e0tract any of the +;AS files that you want to use using the +;AS tool. e see a whole list of files& and the SAT file is usually near the top. ,opy this SAT file and place it in a workign directory along with the "E*+),SAT,EAT,Tool.e-e and the .bat files. After files. After e0tracting e0tracting the SAT file from the +;AS +;AS archi!e archi!e we can then e0tract an .ob file from the SAT file. 1 / To generate the .ob data simply double click the SAT,EAT,E-tract.bat file that is in our working direcotry. 6nce the e0traction is complete will see that a new folder has been created in our working directory with the name of the file. e see inside this new folder a newly generated .! file (sometimes there are multiple 6'7 files that are created but there is always a main 6'7 file). This .! file contains all the data we need to create functional collision maps. 2 / e are now ready to import this newly generated .ob file into ds/a0< once imported into ds/a0 we can edit the polygons& edit their positions and sizes& and edit the names of the obect layers to determine what types of collision data they will be.
The ne0t step is to import the newly generated .! file into ds/A0 (or whate!er d app you are using). After import import we see see that the the .6'7 file is di!ided di!ided into se!eral obect layers layers that ha!e ha!e names that look something like this= obect>2>202>202>202>20"2>202>202 obect>1>202>202>202>20?2>202>202 obect>?>202>202>202>[email protected]
>202>202 obect>>202>202>202>20,2>202>202 obect>">202>202>202>202>202>202 obect>B>202>202>202>20A2>202>202 These numerical offesets (202) in the obect layer name ser!e as metadata for the collision map which determine the type of collision data that is used. 'y changing these !alues we are able to change the type of collision data. 5t is important to maintain proper naming con!entions while editing this data& as the tool is case sensiti!e and reCuires that the name be precise in order to create properly functinoing collision data.
E)ITI$% SAT C!((ISI!$ )ATA There are ? types of SAT data edits< Position % Type E)ITI$% P!SITI!$ The first part of editing SAT data is fairly straight forward. e actually determine the position % angle of collision data by editing the 6'7 layer$s !erte0 positions in ds/a0. So it$s as simple as mo!ing those faces around where you want them. There are some things that are recommended though as suggestions for creating functional geometry. )!S & )!$TS !' '+$TI!$A( %E!MET"3 An important important thing thing to note note is that our polys polys (or walls& walls& floors etc) etc) should should not penetrate penetrate each other. other. hen dealing with !erte0 positions& is it easy to get lazy and try to simply eyeball where a !erte0 should go but we can often get unpredictable results if ha!e !ertices that are improperly connected& or that make planes cross through each other. This is not the golden rule though& as penetrating face still work& but not always& so be careful.
hile sloppy collision data might Dwork$ in game& its best to take the time to be precise in our measurements for se!eral reasons. 6ne reason is that sometimes enemies will try to Db:line$ through these sloppy collisions
(that is to say they will try to walk as though there are no walls at all)& instead of walking around them. 5mproperly named or misplaced !ertices can make enemies !ery confused and can lea!e them stuck trying to walk through walls. Another reason to create precise collision data is that there are problems that arise when dealing with ramps or stairs. 5f !ertices are misplaced or faces are crossing into each other& ramps often do not work& or work only partially. These suggestions go for all collision types. For e0ample& if we don$t ha!e floor collision data we can still walk normally in the game& but enemies will e!entually ump down into nothing. 5f we don$t align !ertices properly when trying to make a Dump o!er$ e!ent it may not work properly or may not work at all. 5t can be a !ery delicate procedure when dealing with collision data so its best that we manipulate the data as precisely as possible. The best way to make sure our !ertices are correctly oined is to use the SA# (!erte0) feature in dsma0. Try to e0periment to get a feel how this works. ,opy some of the different types of faces and paste them to what result you get. 5t will not always be successful& but if you e0periment with the groups you may come to understand what makes them work. (5 myself am still e0perimenting& and do not know all of the types) An easy way to e0periment e0periment with with collision collision data is to simply copy these these layers layers and then then arrange arrange them in in any shape you wish wish by editing the !erte0 positions... ust make sure the faces are pointing in the right direction A sample 6'7 file has been been pro!ided pro!ided with this toolset toolset hat contains contains most most functional functional SAT SAT types types which you you can simply compy and paste into your own scene in ds/AG for editing. note about the planes planes we create create for collision collision data is that that it is !ery !ery important important the $!TE 4 Another thing to note faces of the polys are facin5 t6e ri56t 7ay. 5f they are facing the wrong way they will still allow a player to walk through them or will not function as intended. hen we obser!e an e0traced ob file from a SAT file we see that usually the walls are made up of ? (or more) faces. Tehse are combined to make a sCuare or rectangle with acti!e faces of the polygons facing the direction the player walks into them. 5n ds /a0 we can use the *;efault Shading* opton in the display port to ensure we are seeing the faces properly (the inacti!e side of the faces will be darker when highlited). 5t is important to understand that walls are usually made up of t7o or 9ore: faces in order to function. An e0ample of this can be seen below=
These t7o faces abo!e are combined to make up one acti!e peice of collision data. 5f separated (or used alone)& neither of these faces can be used as reliable collision data. 5 ha!e seen single rectangluar planes used in game by the de!eloopers& so you can try out different polys to see what works. 5 often use sCuare polyhedrons to blcok out smaller items like furntiure or ornate corners as it is easier than creating these planes descibed abo!e& but it is important to understand how collision data works before we start cutting corners& litterally and figurati!ely H) About $on/con;entional poly6edons #lease note that if we are to use non:con!entional polyhedrons to block out the walls (meaning that we use obects without proper names) they may work to pre!ent the player form walking somewhere but other functions of collision data will not be present.
6ne e0ample of this is how the ,A/ beha!es when we are right ne0t to a wall. 5f we use a plane that is not properly named it may work to restrict player mo!ement& but it does not tell the camera that there is a wall there so the camera may clip the wall. Iou can try to use whate!er polyhedrons you wish to try to create functional SAT data& but your results may !ary.
E)ITI$% SAT C!((ISI!$ T3PES There are se!eral types of SAT collision data that ser!e different functions besides simply restricting player mo!ement. There are numerous interacti!e elements of the game that are handled by the SAT file like and Jump Down . As noted abo!e& the type of collision data is determined by the !alues in the Jump Over and different offsets in the object layer name . 5 ha!e only listed a few of the known types as 5 ha!e not yet e0plored all the known types. Jere are the basic essentials to start with= $!"MA( restricti;e:<
As we can can see in in the screensho screenshott abo!e only only the *t6 offset is used to input !alues in the obect layer names and the rest of the offset !alues are left with a !alue of 0. This "th offset is reser!ed for $!"MA( restricti;e: collision data. 6ther types with use different offsets for their !alues (see below). hen making walls we do not always ha!e to use all the different !alues seen abo!e. e can simply use combinations of them when making a wall (like using a *0 % 20& or using 80 % C0:. hy there are so many !ariants of this offset is still a mystery to me. $!TE44 6bect layers that are not gi!en a type (or not properly named) will be assigned the type 0-0 by default for all offsets and will act as NORMAL Restrictive collision data as 2 is a recognized !alue for the "th offset. This applies to non:con!entional and non:named polyhedrons as well.
As you you can see in this screensh screenshot& ot& there are se!eral se!eral obect obect layers layers that are used in the * +MP )!$ collision type& all of which use the =rd offset with a !alue of either >0 or 10. e should obser!e also that the !alues in the *t6 offset are still present (as seen in the first e0ample)& and act as NORMAL restrictive collision data which pre!ents us from passing. This is an e0ample of collision data that ser!es 2 functions = 6ne& to restrict mo!ement& and the second& to prompt the JUMP DOWN function. So now we understand that collision data can ha!e different combinations of functions when we use the offsets in the obect layer names.
Again& as seen in the sreenshot sreenshot abo!e abo!e we we can see that now there is still data in the "th "th offset (used (used for $!"MA( "estricti;e )& but we also see new !alues in the @t6 offset& all of which are either a !alue of 0 or 20. 5f you obser!e the screenshot you will see that there are ? walls for each side of this e!ent. This is created this way because we know the player will need to access this e!ent from either side. Each of these walls must ha!e their faces pointing outward (opposite directions). 5n this e0ample we see the collision data for the small fence we can hop o!er in r121. +MP !?E" 2 +MP AC"!SS:
/uch like the pre!ious *7ump 6!er* collisiontype& we see in theis e0ample that there is still data in the "th offset (used for 6/A4 estricti!e)& but also see new !alues in the =rd offset all of which are set to a !alue of 8. This type of collision data will create an area where the player is promted to ump o!er& the kind where we see the player ump across something like a gap. This type of ump o!er acts differently than the pre!iously mentioned type of ump o!er& which is usually used for small ledges or fences that the player hops o!er. Special note about t6is type of collision data = This will not work unless there is normal restricti!e collision data within a certain rangeKheight of the 7ump ? collision obect. Essentially there must be something for the player to land on. e simply can not make 7ump 6!er ? data ne0t to nothing or it will not work.
!TE" T3PES There are other rooms in the game that use other types of collision data that are not co!ered in this tutorial& but the same principles will apply. Simply look at the object layer name offsets and see which are used commonly and e0periement by isolating these e!ents and mo!ing them around. $!TES A!+T M+(TIP(E ! 'I(ES There are some rooms& like r??? that use multiple ob files to create collision data. These rooms are often ones that need temporary collision data& or collision data that changes. (in r??? it is becuase there are mo!ing models that the player walks across).
5t is important to know that the first .ob file in a bunch of files is the main one& with the ones that follow
being used for the temporary or changing e!ents. 5t is best to keep these while we repack. 5f we do not wish to use the e0tra .ob files we can simply import them and change thier positions. 5n some instances 5 was able to get away with remo!ing the e0tra ob files and updating the .id0 file for the SAT>EAT Tool& but in some rooms this did not work and the game kept crashing.
EBP!"TI$% & "EPAC#I$% SAT )ATA EBP!"TI$% To e0port SAT data simply select all the layers that you wish to include in the final e0port in ds/AG and use the EG#6T fucntion of ds/a0. Files must be e0ported in ! for9at& with the name of the target file being the same as the original e0ported 6'7 file. E-a9ple< r"22>21>2.ob.
The ne0t part is repacking. hat the repacking function of the SAT>EAT Tool does at this point is to merge all the known obect layer types of the indi!idual layers and then writes the data to the SAT file that is located in the working folder. e do not need to merge these layers manually as the tool does this for us. To e0palin further let us take a depper look at what happens during repacking. e can e0port our final 6'7 file for repacking without merging all the same layer types& but do take note that if we were to re:e0tract an 6'7 file from a newly generated SAT file with our custom collision data t6e layers types 7ould be 9er5ed with similar layers types=
E-a9ple< 5f we ha!e a wall that is made up of these " obect layers= obect>?L>202>202>202>20"2>202>202 obect>[email protected]
>202>202>202>20?2>202>202 obect>?M>202>202>202>[email protected]
>202>202 obect>2>202>202>202>20,2>202>202 and we copyKpaste this wall& and then rename their numerical prefi0es (we dont really need to rename the prefi0 but for this e0ample 5 will)= obect>1>202>202>202>20"2>202>202 obect>?>202>202>202>20?2>202>202 obect>>202>202>202>[email protected]
2>202>202 obect>">202>202>202>20,2>202>202 we now ha!e= obect>1>202>202>202>20"2>202>202 obect>?>202>202>202>20?2>202>202 obect>>202>202>202>[email protected]
>202>202 obect>">202>202>202>20,2>202>202 obect>1>202>202>202>20"2>202>202 obect>?>202>202>202>20?2>202>202 obect>>202>202>202>[email protected]
>202>202 obect>">202>202>202>20,2>202>202 E0porting this as shown abo!e (with all the similar layer types separated) is fine& but ust remember that all the simlar types will get merged when we e0port % repack. obect>?L would would be merged with obect>1 as they are both type "2& and obect>[email protected]
would be E-a9ple< obect>?L merged with obect>? with obect>? and so on. This really does not matter if we are not e0tracting the file again& but if we want to keep our layers intact we need to do so in the d application. 7ust keep your d application proect file sa!ed with the layers separated if you wish to ha!e these layers separate for future editing.
"EPAC#I$% epacking is as simple as placing our newly generated 6'7 file into the egenrated 6'7 folder (the one with the ob file in it) with the name of the original file and then clicking the AT!"AT!Repac#$bat file. After we ha!e done this the SAT file has been re:writen with our new collision data. The ne0t step is then to copy this newly created SAT file to our working +)AS directory and repack the +;AS file with the +;AS Tool.
P"!(EMS IT E)ITI$% EBISTI$% C!((ISI!$ )ATA hile creating custom collision data from scratch has pro!en to yield stable results& editing e0isitng data in some rooms can be a nightmare. For whate!er reason there are certain rooms that when we e!en mo!e 1 !ertice the stability of the collision data is comprimised. This often happens in scenarios where we wish to remo!e only part of e0isting collision data. 5 ha!e found this a ?E"3 T"IC#3 undertaking& so please do not complain when you are editing e0isting collision data because the collision tools are not perfect . 5n the scenario where we wish to remo!e some part of the wall but it makes e!erything else not work perfectly& try remo!ing only 1 triangle at a time to see what happens. e can also try remo!ing one !ertice& repack and test. Adding new collision data with e0isting collision is fine< its only when we remo!e some of the original that things can get crazy. There are times 5 ha!e had to remake entire sections of rooms& so be patient with this undertaking
EAT T!!( Since the SAT and EAT files are identical in structure it was possible to create one tool to edit both these file types. The reason the de!elopers created separate file types (although identical in structure) was because there are often times that we want our proectiles to ha!e different boundaries than the player mo!ement. Ja!ing separated boundaries for each file type gi!es us more options and a more realistic feel of how obects and characters interact in the ; en!ironment.
+$)E"STA$)I$% +$)E"STA$)I$% TE EAT 'I(E Amongst the many files located located inside inside the +;AS +;AS archi!e archi!e is the the EAT file. This file is responsible for the collision data of discharged rounds and other proectiles thrown from the character. Since the SAT file is responsible for blocking player mo!ement and does not block bullets or other proectiles we ha!e another file that is solely responsible for this< the EAT file. 'asically the EAT file determines the boundaries of where bullets& grenades& and other proectiles like arrows hit. Also the EAT file determines where falling obects stop falling& like when we shoot a spinel from up high and it falls down to the ground. Another feature of the EAT file is to change the reaction type of the en!ironment to the proectiles. For instance& we can use the EAT file to make wet looking footsteps for weather or use the EAT file to make the bullets appear as though they are hitting a water surface. 5f we are creating EAT data from scratch (say when we are creating a new room)& sometimes the easiest method is to create teh SAT data first& and then simply copy the SAT data and fine tune it. +sually EAT data follows the same positions as SAT data with some slight !ariations depending on the scenario. For e0ample if there*s SAT data that is $or9al "estricti;eD type used for walls in room it should follow that bullets and proectiles would use the same areas with some added (and perhaps a few remo!ed) but for the most part they will appear in the same places. To understand this concept a little better let us obser!e the subtle differences between the SAT and EAT files of r121=
'y comparing the images of the e0tracted files abo!e we can see subtle differences in their appearance& most notably those circled in the top left corner. As we can see in the EAT e0ample& the circles area defines the une!en terrain we see as we enter r121& whereas in this same area in the SAT e0ample we simply see a wall. e can now see how each file operates independently while still using the same format.
!"#I$% IT TE EAT 'I(E The concepts of working with the EAT file is the same as the SAT file desribed abo!e= 1 / After e0tracting the EAT file from the +;AS archi!e we can then e0tract an .ob file from the EAT file data using the SAT,EAT,E-tract.bat file. 2 / e import this newly generated .ob file into ds/a0 and edit the polygons& remembering that the acti!e side of the polygon is what ser!es as the acti!e surface. 5t should be noted that each barrier (or wall) should be comprised of two of the following .ob name types=
obect2>202>202>202>202>202> 0-*0 obect1>202>202>202>202>202> 0-80 = / 6nce we ha!e finished editing the polygons to our liking we simply e0port the .ob file to our working directory using the same method as described abo!e in the SAT section of this tutorial. Simply replace the e0isting .ob file and then use the SAT,EAT,"epac.bat file to repack the EAT file. * / After this copy the new EAT file to your work of +;AS directory and repack.
EAT 'I(E )ATA T3PES hile there are many diffrent SAT file types to work with there only seem to be 1 or ? different EAT types (more research is reCuired on types fo the EAT file). Jere is another data type used for making an EAT polygon react other than normal restricti!e= ater Surface ob[email protected]
>202>202>202> 0-80 >202>20 >202>20"2 "2 obectM>202>202>202> 0-80 >202>20 >202>[email protected]
There is one modification we can make to EAT files to change the way our bullets affect the en!ironment to make appear as though the porectiles are hitting a water surface. +sing a !alue in the t6 offset set to 80 will make a water effect when bullets hit these areas. This concludes the SAT EAT Tool tutorial. A special TA$# 3!+ goes out to Son of #ersia for his determined efforts to make this speical tool possible for us to use. Jappy /odding Mr.Curious 12 / 2018 6ttps