SAT & EAT Tool 2018

Tools created by Son of Persia

Tutorial prepared by Mr.Curious

Introduction
Another interesting chapter in our tutorial series will be dealing with the long awaited collision tool (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 Resiedent Evil 4. Thanks to Son of Persia’s dedication &
persistence, we now have this tool at our disposal.

To start, let us look at the RE4 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. Both file types are collision maps, one being for the player (SAT) and the other for projectiles
(EAT).

We 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 'Universal Concepts Guide' , the first thing we want to do when opening any kind of room in
3ds Max is to open the collision data (SAT) file to use as a refference for scale, as many of hte rooms in RE4
use different scales (x1,x10, x100) etc.

Extracting the SAT data gives us a reference to the scale at which we are working, and can be used as a
reference with other files, such as the AEV, LIT, and other files that create OBJ files that we can import into
the 3d program. If we are using other tools like the CRSZOK ELS enemy tool, it is important to have SAT
data to reference where the enemies will be placed on the map.

If we are simply using the SAT data for reference, I suggest to use the 'FREEZE' layer option in 3dsMaxfor
the SAT data layers so that they do not accidentally get shifted while editing other elements. We can also
make these layers wireframe or transperant so they are easy to see though while editing other objects.
WORKING WITH THE SAT FILE
IMPORTING SAT DATA
1 - To start, extract any of the UDAS files that you want to use using the UDAS tool. We see a whole list of
files, and the SAT file is usually near the top. Copy this SAT file and place it in a workign directory along with
the RE4UHD_SAT_EAT_Tool.exe and the .bat files. After extracting the SAT file from the UDAS archive we
can then extract an .obj file from the SAT file.

1 - To generate the .obj data simply double click the SAT_EAT_Extract.bat file that is in our working
direcotry. Once the extraction is complete will see that a new folder has been created in our working
directory with the name of the file. We see inside this new folder a newly generated .OBJ file (sometimes
there are multiple OBJ files that are created but there is always a main OBJ file). This .OBJ file contains all
the data we need to create functional collision maps.

2 - We are now ready to import this newly generated .obj file into 3dsMax; once imported into 3dsMax we
can edit the polygons, edit their positions and sizes, and edit the names of the object layers to determine
what types of collision data they will be.

The next step is to import the newly generated .OBJ file into 3dsMAx (or whatever 3d app you are using).
After import we see that the .OBJ file is divided into several object layers that have names that look
something like this:

object_0_0x0_0x0_0x0_0x40_0x0_0x0
object_1_0x0_0x0_0x0_0x20_0x0_0x0
object_2_0x0_0x0_0x0_0x80_0x0_0x0
object_3_0x0_0x0_0x0_0xC0_0x0_0x0
object_4_0x0_0x0_0x0_0x60_0x0_0x0
object_5_0x0_0x0_0x0_0xA0_0x0_0x0

These 6 numerical offesets (0x0) in the object layer name serve as metadata for the collision map which
determine the type of collision data that is used. By changing these values we are able to change the type
of collision data. It is important to maintain proper naming conventions while editing this data, as the tool is
case sensitive and requires that the name be precise in order to create properly functinoing collision data.

EDITING SAT COLLISION DATA

There are 2 types of SAT data edits; Position & Type

EDITING POSITION
The first part of editing SAT data is fairly straight forward. We actually determine the position & angle of
collision data by editing the OBJ layer’s vertex positions in 3dsMax. So it’s as simple as moving those faces
around where you want them. There are some things that are recommended though as suggestions for
creating functional geometry.

DO'S & DONT'S OF FUNTIONAL GEOMETRY

An important thing to note is that our polys (or walls, floors etc) should not penetrate each other. When
dealing with vertex positions, is it easy to get lazy and try to simply eyeball where a vertex should go but we
can often get unpredictable results if have vertices 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.

While sloppy collision data might ‘work’ in game, its best to take the time to be precise in our measurements
for several reasons. One reason is that sometimes enemies will try to ‘b-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.
Improperly named or misplaced vertices can make enemies very confused and can leave 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. If vertices 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 example, if we don’t have floor collision data we can still
walk normally in the game, but enemies will eventually jump down into nothing. If we don’t align vertices
properly when trying to make a ‘jump over’ event it may not work properly or may not work at all. It can be a
very 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 vertices are correctly joined is to use the SNAP (vertex) feature
in 3dsmax.

Try to experiment to get a feel how this works. Copy some of the different types of faces and paste them to
what result you get. It will not always be successful, but if you experiment with the groups you may come to
understand what makes them work. (I myself am still experimenting, and do not know all of the types)!

An easy way to experiment with collision data is to simply copy these layers and then arrange them in any
shape you wish by editing the vertex positions... just make sure the faces are pointing in the right direction!
A sample OBJ file has been provided with this toolset hat contains most functional SAT types which you can
simply compy and paste into your own scene in 3dsMAX for editing.

NOTE * Another thing to note about the planes we create for collision data is that it is very important the
faces of the polys are facing the right way. If they are facing the wrong way they will still allow a player to
walk through them or will not function as intended.

When we observe an extraced obj file from a SAT file we see that usually the walls are made up of 2 (or
more) faces. Tehse are combined to make a square or rectangle with active faces of the polygons facing the
direction the player walks into them. In 3ds Max we can use the 'Default Shading' opton in the display port to
ensure we are seeing the faces properly (the inactive side of the faces will be darker when highlited).

It is important to understand that walls are usually made up of two (or more) faces in order to function. An
example of this can be seen below:

These two faces above are combined to make up one active peice of collision data. If separated (or used
alone), neither of these faces can be used as reliable collision data. I have seen single rectangluar planes
used in game by the develoopers, so you can try out different polys to see what works. I often use square
polyhedrons to blcok out smaller items like furntiure or ornate corners as it is easier than creating these
planes descibed above, but it is important to understand how collision data works before we start cutting
corners, litterally and figuratively =)

About Non-conventional polyhedons

Please note that if we are to use non-conventional polyhedrons to block out the walls (meaning that we use
objects without proper names) they may work to prevent the player form walking somewhere but other
functions of collision data will not be present.

One example of this is how the CAM behaves when we are right next to a wall. If we use a plane that is not
properly named it may work to restrict player movement, but it does not tell the camera that there is a wall
there so the camera may clip the wall. You can try to use whatever polyhedrons you wish to try to create
functional SAT data, but your results may vary.
EDITING SAT COLLISION TYPES
There are several types of SAT collision data that serve different functions besides simply restricting player
movement. There are numerous interactive elements of the game that are handled by the SAT file like
Jump Over and Jump Down. As noted above, the type of collision data is determined by the values in the 6
different offsets in the object layer name.

I have only listed a few of the known types as I have not yet explored all the known types. Here are the basic
essentials to start with:

NORMAL (restrictive):

As we can see in the screenshot above only the 4th offset is used to input values in the object layer names
and the rest of the offset values are left with a value of 0. This 4th offset is reserved for NORMAL
(restrictive) collision data. Other types with use different offsets for their values (see below). When making
walls we do not always have to use all the different values seen above. We can simply use combinations of
them when making a wall (like using a 40 & 20, or using 80 & C0). Why there are so many variants of this
offset is still a mystery to me.

NOTE** Object layers that are not given a type (or not properly named) will be assigned the type 0x0 by
default for all offsets and will act as NORMAL Restrictive collision data as 0 is a recognized value for the
4th offset. This applies to non-conventional and non-named polyhedrons as well.

JUMP DOWN:

As you can see in this screenshot, there are several object layers that are used in the 'JUMP DOWN'
collision type, all of which use the 3rd offset with a value of either 90 or 10. We should observe also that the
values in the 4th offset are still present (as seen in the first example), and act as NORMAL restrictive
collision data which prevents us from passing. This is an example of collision data that serves 2 functions:
One, to restrict movement, and the second, to prompt the JUMP DOWN function. So now we understand
that collision data can have different combinations of functions when we use the offsets in the object layer
names.
JUMP OVER:

Again, as seen in the sreenshot above we can see that now there is still data in the 4th offset (used for
NORMAL Restrictive), but we also see new values in the 5th offset, all of which are either a value of 60 or
20. If you observe the screenshot you will see that there are 2 walls for each side of this event. This is
created this way because we know the player will need to access this event from either side. Each of these
walls must have their faces pointing outward (opposite directions). In this example we see the collision data
for the small fence we can hop over in r101.

JUMP OVER 2 (JUMP ACROSS)

Much like the previous 'Jump Over' collisiontype, we see in theis example that there is still data in the 4th
offset (used for NORMAL Restrictive), but also see new values in the 3rd offset all of which are set to a
value of 8. This type of collision data will create an area where the player is promted to jump over, the kind
where we see the player jump across something like a gap. This type of jump over acts differently than the
previously mentioned type of jump over, which is usually used for small ledges or fences that the player
hops over.

Special note about this type of collision data: This will not work unless there is normal restrictive
collision data within a certain range/height of the Jump 2 collision object. Essentially there must be
something for the player to land on. We simply can not make Jump Over 2 data next to nothing or it will not
work.

OTHER TYPES
There are other rooms in the game that use other types of collision data that are not covered in this tutorial,
but the same principles will apply. Simply look at the object layer name offsets and see which are used
commonly and experiement by isolating these events and moving them around.

NOTES ABOUT MULTIPLE OBJ FILES

There are some rooms, like r222 that use multiple obj files to create collision data. These rooms are often
ones that need temporary collision data, or collision data that changes. (in r222 it is becuase there are
moving models that the player walks across).

It is important to know that the first .obj file in a bunch of files is the main one, with the ones that follow
being used for the temporary or changing events. It is best to keep these while we repack. If we do not wish
to use the extra .obj files we can simply import them and change thier positions. In some instances I was
able to get away with removing the extra obj files and updating the .idx file for the SAT_EAT Tool, but in
some rooms this did not work and the game kept crashing.

EXPORTING & REPACKING SAT DATA

EXPORTING
To export SAT data simply select all the layers that you wish to include in the final export in 3dsMAX and
use the EXPORT fucntion of 3dsMax. Files must be exported in OBJ format, with the name of the target
file being the same as the original exported OBJ file. Example: r400_01_0.obj.

The next part is repacking. What the repacking function of the SAT_EAT Tool does at this point is to merge
all the known object layer types of the individual layers and then writes the data to the SAT file that is
located in the working folder. We do not need to merge these layers manually as the tool does this for us.

To expalin further let us take a depper look at what happens during repacking. We can export our final OBJ
file for repacking without merging all the same layer types, but do take note that if we were to re-extract an
OBJ file from a newly generated SAT file with our custom collision data the layers types would be
merged with similar layers types:

Example:
If we have a wall that is made up of these 4 object layers:
object_27_0x0_0x0_0x0_0x40_0x0_0x0
object_28_0x0_0x0_0x0_0x20_0x0_0x0
object_29_0x0_0x0_0x0_0x80_0x0_0x0
object_30_0x0_0x0_0x0_0xC0_0x0_0x0

and we copy/paste this wall, and then rename their numerical prefixes
(we dont really need to rename the prefix but for this example I will):

object_31_0x0_0x0_0x0_0x40_0x0_0x0
object_32_0x0_0x0_0x0_0x20_0x0_0x0
object_33_0x0_0x0_0x0_0x80_0x0_0x0
object_34_0x0_0x0_0x0_0xC0_0x0_0x0

we now have:
object_31_0x0_0x0_0x0_0x40_0x0_0x0
object_32_0x0_0x0_0x0_0x20_0x0_0x0
object_33_0x0_0x0_0x0_0x80_0x0_0x0
object_34_0x0_0x0_0x0_0xC0_0x0_0x0
object_31_0x0_0x0_0x0_0x40_0x0_0x0
object_32_0x0_0x0_0x0_0x20_0x0_0x0
object_33_0x0_0x0_0x0_0x80_0x0_0x0
object_34_0x0_0x0_0x0_0xC0_0x0_0x0

Exporting this as shown above (with all the similar layer types separated) is fine, but just remember that all
the simlar types will get merged when we export & repack.
Example: object_27 would be merged with object_31 as they are both type 40, and object_28 would be
merged with object_32 and so on. This really does not matter if we are not extracting the file again, but if we
want to keep our layers intact we need to do so in the 3d application. Just keep your 3d application project
file saved with the layers separated if you wish to have these layers separate for future editing.
REPACKING
Repacking is as simple as placing our newly generated OBJ file into the egenrated OBJ folder (the one with
the obj file in it) with the name of the original file and then clicking the SAT_EAT_Repack.bat file. After we
have done this the SAT file has been re-writen with our new collision data. The next step is then to copy this
newly created SAT file to our working UDAS directory and repack the UDAS file with the UDAS Tool.

PROBLEMS WITH EDITING EXISTING COLLISION DATA

While creating custom collision data from scratch has proven to yield stable results, editing exisitng data in
some rooms can be a nightmare. For whatever reason there are certain rooms that when we even move 1
vertice the stability of the collision data is comprimised.

This often happens in scenarios where we wish to remove only part of existing collision data. I have found
this a VERY TRICKY undertaking, so please do not complain when you are editing existing collision data
because the collision tools are not perfect.

In the scenario where we wish to remove some part of the wall but it makes everything else not work
perfectly, try removing only 1 triangle at a time to see what happens. We can also try removing one vertice,
repack and test. Adding new collision data with existing collision is fine; its only when we remove some of
the original that things can get crazy. There are times I have had to remake entire sections of rooms, so be
patient with this undertaking!

EAT TOOL
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 developers created separate file types (although identical in structure) was
because there are often times that we want our projectiles to have different boundaries than the player
movement. Having separated boundaries for each file type gives us more options and a more realistic feel
of how objects and characters interact in the 3D environment.

UNDERSTANDING THE EAT FILE

Amongst the many files located inside the UDAS archive is the EAT file. This file is responsible for the
collision data of discharged rounds and other projectiles thrown from the character. Since the SAT file is
responsible for blocking player movement and does not block bullets or other projectiles we have another
file that is solely responsible for this; the EAT file.

Basically the EAT file determines the boundaries of where bullets, grenades, and other projectiles like
arrows hit. Also the EAT file determines where falling objects 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
environment to the projectiles. 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.

If 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. Usually EAT
data follows the same positions as SAT data with some slight variations depending on the scenario.

For example if there's SAT data that is ‘Normal Restrictive’ type used for walls in room it should follow
that bullets and projectiles would use the same areas with some added (and perhaps a few removed) but
for the most part they will appear in the same places.

To understand this concept a little better let us observe the subtle differences between the SAT and EAT
files of r101:
EAT

SAT

By comparing the images of the extracted files above we can see subtle differences in their appearance,
most notably those circled in the top left corner. As we can see in the EAT example, the circles area defines
the uneven terrain we see as we enter r101, whereas in this same area in the SAT example we simply see
a wall. We can now see how each file operates independently while still using the same format.

WORKING WITH THE EAT FILE

The concepts of working with the EAT file is the same as the SAT file desribed above:

1 - After extracting the EAT file from the UDAS archive we can then extract an .obj file from the EAT file
data using the SAT_EAT_Extract.bat file.

2 - We import this newly generated .obj file into 3dsMax and edit the polygons, remembering that the active
side of the polygon is what serves as the active surface. It should be noted that each barrier (or wall) should
be comprised of two of the following .obj name types:

object0_0x0_0x0_0x0_0x0_0x0_0x40
object1_0x0_0x0_0x0_0x0_0x0_0x80

3 - Once we have finished editing the polygons to our liking we simply export the .obj file to our working
directory using the same method as described above in the SAT section of this tutorial. Simply replace the
existing .obj file and then use the SAT_EAT_Repack.bat file to repack the EAT file.

4 - After this copy the new EAT file to your work of UDAS directory and repack.
EAT FILE DATA TYPES
While there are many diffrent SAT file types to work with there only seem to be 1 or 2 different EAT types
(more research is required on types fo the EAT file). Here is another data type used for making an EAT
polygon react other than normal restrictive:

Water Surface
object8_0x0_0x0_0x0_0x80_0x0_0x40
object9_0x0_0x0_0x0_0x80_0x0_0x80

There is one modification we can make to EAT files to change the way our bullets affect the environment to
make appear as though the porjectiles are hitting a water surface. Using a value in the 6th offset set to 80
will make a water effect when bullets hit these areas.

This concludes the SAT EAT Tool tutorial. A special THANK YOU goes out to Son of Persia for his
determined efforts to make this speical tool possible for us to use.

Happy Modding!

Mr.Curious
12 - 2018
https://www.youtube.com/user/kalamalkakid/
http://residentevilmodding.boards.net/user/5592