Surface types and collision.
+diff --git a/Game_8cpp.html b/Game_8cpp.html index 7e492f116..a735ab4db 100644 --- a/Game_8cpp.html +++ b/Game_8cpp.html @@ -2657,7 +2657,7 @@ Here is the caller graph for this function:
Reimplemented from OObject.
Make shadow size bigger if thwomp is scaled up
+Make shadow size bigger if thwomp is scaled up
make adjustable properties for squishSize and boundingBoxSize
Thwomp OObject
diff --git a/contpfs_8c.html b/contpfs_8c.html index d5670d7e7..44135498f 100644 --- a/contpfs_8c.html +++ b/contpfs_8c.html @@ -210,8 +210,8 @@ Here is the caller graph for this function:yoshi_valley vs yoshis_valley)When using the migration script (migrations.py), a mods.toml file can be automatically generated for your migrated mod. See Migration Guide for details.
On input skip logo screen
-|
+ SpaghettiKart
+
+ |
+

The kind of driving surface the player is on. Dirt and sand will slow you down. Asphalt is driving on a road, etc.
+This sets if the object can be driven through or not. And if objects in the environment collide with it. Generally, this value only needs to be changed under certain circumstances
No collision. Players can drive through this object.
A normal wall collision presuming the player can never access the other side of the wall. If they do, they will drive through the object.
+Not necessary to be set. But if for some reason you need to force a mesh to be a surface, this is here for that.
+Required if making a fence where the player can access both sides of the wall. The collision generator is not good at recognizing that you want a double-sided wall and for performance reasons will not provide collision for the other side. This means the player can drive through one side, but not the other. Double-sided wall fixes this so no matter what side the wall is approached from, the player cannot drive through the wall.
+Object draw order matters for transparent objects. Thus, transparent objects must be drawn after opaque objects.
+Pretty self-explanatory. The draw phase gets completely cut from the object. This is useful for invisible walls
+A normal object. It is not transparent.
+A transparent object. If you do not set this for transparent objects, the order of drawn objects will be wrong.
+Objects set to this ignore the ZBuffer. This means they are always visible on the screen, no matter the distance. The HM64 Labs Gizmo grab handles for instance are set to this (used for translating objects).
+|
+ SpaghettiKart
+
+ |
+
The game uses multiple types of track paths
Used by courses
-Used by the train
-Pathing for the camera during end of race scene, podium ceremony, and credits.
+Allows CPUs to follow the track and for the game to track player progress

This allows the user to select which path is which. Path 1 is required and must be the main path.
+The other paths must circle the entire track, splitting off wherever, and are optional.
+The vehicle path is for trains, boats, cars, etc.
+
See the overview guide for more details
Important details without the steps
Path Points: ~800 (any number is fine) Triangle Count: Original tracks average ~6000 triangles
Path Points: ~800 (any number is fine)
Starting Line Width: 1.75 units
Track Boundaries: +-32767.0 in Blender units this is +-1310.68 (32767 / 25)
Track Widths:
is it possible to remove them somehow?
-is it possible to remove them somehow?
+Make shadow size bigger if thwomp is scaled up
+Make shadow size bigger if thwomp is scaled up
make adjustable properties for squishSize and boundingBoxSize
Apply TransformationsApply Transformations