Difference between revisions of "Modding:Sonic Forces"
Boilingpot (talk | contribs) (→Stage Objects & Enemies) |
Boilingpot (talk | contribs) |
||
Line 722: | Line 722: | ||
If you want to connect one object to another, you can put the Object & Group ID’s of the parent object (the one that controls the position of the second object) in the ‘ParentID’ and ‘ParentGroupID’ boxes of your object. The childposoffset tab is the distance that your child object is offset from the parent object. Note that any objects that move cannot be parented to other moving objects (under most circumstances, sometimes the game lets it happen but it’s seemingly random.) | If you want to connect one object to another, you can put the Object & Group ID’s of the parent object (the one that controls the position of the second object) in the ‘ParentID’ and ‘ParentGroupID’ boxes of your object. The childposoffset tab is the distance that your child object is offset from the parent object. Note that any objects that move cannot be parented to other moving objects (under most circumstances, sometimes the game lets it happen but it’s seemingly random.) | ||
+ | |||
+ | ==Cameras== | ||
+ | Since the default camera is pretty garbage in Forces, you're going to be reliant on various camera objects to give the player the ability to actually see where they're going. Here's a quick overview of CameraVolumes along with the essential camera types you'll find yourself using the most. | ||
+ | |||
+ | '''CameraVolumes''': | ||
+ | |||
+ | In order to activate camera objects they have to be assigned to CameraVolumes, which are basically invisible boxes that activate the cameras when you go inside them. To assign a camera object to a CameraVolume you simply need to put the ID and GroupID of the object into the volume's Camera parameter. | ||
+ | |||
+ | [Insert Table] | ||
+ | |||
+ | '''CameraSubVolumes''': | ||
+ | |||
+ | If you want to reuse the same camera repeatedly in a stage you can use a CameraSubVolume. Instead of putting in the ID of a camera object you put in the ID and GroupID of another CameraVolume, and the CameraSubVolume will take on all the parameters the CameraVolume uses(aside from it's BasePoint and size). | ||
+ | |||
+ | '''Camera Objects''': | ||
+ | |||
+ | [Insert Table] | ||
+ | |||
+ | '''CameraFollow''': | ||
+ | |||
+ | One of the simplest camera types, as you'd expect it simply just follows the player. | ||
+ | |||
+ | * Yaw: Controls the rotation of the camera on the Y axis. | ||
+ | * Pitch: Controls the rotation of the camera on the X axis. | ||
+ | |||
+ | '''CameraPan''': | ||
+ | |||
+ | Looks at the player from the point the object is placed. | ||
+ | |||
+ | [Insert Table] | ||
+ | |||
+ | '''CameraPoint''': | ||
+ | |||
+ | Stays behind the player while pointing towards wherever the object is placed (essentially the reverse of CameraPan). No unique parameters. | ||
+ | |||
+ | '''CameraRailForwardView''': | ||
+ | |||
+ | Generally something you want to use in 3D running/boosting sections, it moves along a spline path while following behind the player. | ||
+ | |||
+ | [Insert Table] | ||
+ | |||
+ | '''CameraRailSideView''': | ||
+ | |||
+ | Best used for 2D sections (unless you want to do something like that psuedo side-scrolling bit in Spaceport), it moves along a spline path while following the player from more of a side view, hence the name. Also this camera is a bit confusing to work with so there's a couple values I haven't figured out yet. | ||
+ | |||
+ | [Insert Table] | ||
+ | |||
+ | '''DefaultCameraSetting''': | ||
+ | |||
+ | Lets you set the default camera for the entire stage that gets used when no camera volumes are active. '''THIS IS NOT A REPLACEMENT FOR THE DEFAULT CAMERA ITSELF, USE ACTUAL CAMERAS'''. | ||
==SetPaths & Other Path Objects== | ==SetPaths & Other Path Objects== |
Revision as of 20:48, 5 April 2021
Contents
Intro
Hi! I’m gonna keep this simple, but seeing as there’s like a very small number of tutorials for anything relating to modding 3D Sonic games, I’m gonna focus on the Sonic Forces corner of HedgeEdit, a level-editing tool made by Radfordhound. Keep in mind that this only covers editing object layouts, since HedgeEdit can’t edit terrain or anything like that. If there’s enough demand, I’ll make more tutorials. Also, some of the object templates in the base download are either missing or broken, so I’ll also be including a download to some updated templates I made in the HedgeEdit DL link (These may be updated from time to time, so check back here every so often. I’ll have a comment detailing the last update date).
To start level modding in Sonic Forces, you’ll need a couple of other tools.
Tools:
- HedgeEdit [V3 UPDATED 4/3/21, Includes resources and templates!]
- HedgeModManager
- PackCPK
- SFPac OR HedgeArcPack
Using HedgeModManager
HedgeModManager has its own installation instructions, so just follow those, and I’ll just continue with the next tool you need.
Using PackCPK
PackCPK is what you’ll need to unpack the CPK files in Sonic Forces (which contain all of the game’s assets and such). After downloading PackCPK, right click on Sonic Forces in your Steam Library, and hit properties. This will open a menu. On the left, navigate to Local Files and hit the browse button at the top right. This will open the location of Sonic Forces’ files on your PC. Click into the ‘image’ folder, then ‘x64’, then ‘disk’. Inside the ‘disk’ folder, there are several CPK files. Wars_0 contains all of the essential game assets (such as enemies, characters, and UI) as well as all the stage folders for Lost Valley through Aqua Road. Wars_1 contains everything from sunset heights to the final boss. Wars_dlc01 contains all of the episode shadow files, dlc02 contains Super Sonic’s files, and the rest are all of the other avatar costume dlcs and whatnot. There’s also wars_patch, which contains all of the game’s gedit files and other miscellaneous files. For what we’ll be doing, you’ll want to unpack wars_0, wars_1, and wars_patch. Make sure you do these separately, and they may take a while. Keep in mind that often times, PackCPK sometimes misses files, so to be safe, you may want to run the CPKs through a second time after the first attempt.
Creating a mod folder
After the aforementioned CPKs are unpacked, you’re gonna want to open HedgeModManager, and hit ‘Add Mod’ at the bottom left. This will open a dialogue box with several options. You’ll want to hit the last choice (making one), and then hit ‘ok’. This will open *another* dialogue box. For now, you can ignore everything above the ‘description’ tab. For everything in the description tab, you can fill out basically whatever you want, it’s pretty self-explanatory. Once you’re done, you can hit ‘OK’. This will open up a new folder for your mod. Click into the ‘disk’ folder in the new window, and create a folder named ‘wars_patch’ with an underscore between wars and patch.
Putting your stage files in your mod folder
Next, navigate back to your unpacked CPKs. We’ll be starting with Lost Valley. Go into your wars_0 folder, and find the folder labeled ‘w5a01’. This actually brings me to something important: You may be confused by the naming scheme of stages, so here’s something to help you out: ‘w’ refers to the ‘world’ number, where w1 is Death Egg, w2 is Chemical Plant, w3 is City, w4 is Mystic Jungle, w5 is Green Hill, w6 is Metropolis, and w7 is Eggman Empire Fortress. The letter and the 2 numbers after the world number represent the type of act and the character. ‘A’ means it is a stage from the main story. ‘D’ means it is a dlc stage, ‘B’ means it’s a boss stage, and ‘X’ or ‘S’ means it’s an extra or secret stage. For stages from the main story, the number 01 means it is a Sonic stage, 02 is an avatar stage, 03 is a tag team stage, and 04 is a Classic stage. For boss stages or secret/extra stages, the number refers to the act or stage number. (For example, w7b02 is the final boss, since it’s the second boss in that world).
Anyways, back to what i was saying before: click into the w5a01 folder. You’ll see a bunch of pacs. You won’t need to do much with these for now, but just know that these files are opened using ‘SFPac’. Back out of the w5a01 folder, and copy it into the ‘wars_patch’ folder in your mod. While still in your mod’s wars_patch folder, you’ll want to create a folder named ‘gedit’. Next, navigate back to the folder containing the game’s CPKs, and go into *it’s* wars_patch folder (NOT the one in your mod that you just copied files into!). Once inside, you’ll see a ‘gedit’ folder. Go inside it, and copy ‘w5a01_gedit.pac’ into your mod’s gedit folder. Now, you’re ready to start using HedgeEdit. (If you haven’t already downloaded it, do that now). Next, I’m going to teach you how to open stages in HedgeEdit. Simply go into your mod’s wars_patch folder, and copy that directory. Open hedgeedit, click ‘open’ and paste the directory where it says ‘data directory’. Then, enter the ID of the stage you’re looking to edit in the STAGE ID box (w5a01 in our case). If the game is not already set to Sonic Forces, be sure to set it as such.
One more quick thing: Be aware that HedgeEdit copies anything you load or save to it’s own cache folder (to make loading faster) so if you’re running low on space, you might want to check there every now and then to clean out anything you don’t need.
Using SFPac/HedgeArcPack
SFPac: When you need to open a .pac file, simply drag the .pac (NOT the .00s) into SFPac. This will unpack the contents of the pac into a folder of the same name (unless your antivirus registers it as a false positive). To repack, just drag the folder back into SFPac. Be aware that there is a size limit, although you’re not going to hit it unless you’re literally spamming files.
HedgeArcPac: Basically the same thing, but… it has its own instructions so just follow those.
Bugs & Other Issues
DON’T SKIP THIS ONE. I figured I’d put this here since it’s a pretty important one. Since the currently available version of HedgeEdit is unfinished (and basically obsolete as a rewrite is in the works), there are a lot of bugs. Some of these, you’ll be able to get around, but others you’ll have to deal with.
Rotation Bug: The rotation bug is a really fucking horrible bug that makes it so you can’t accurately rotate under 0 degrees (negative values) or over 89.4 degrees. This also affects object parenting, which I will go over later. Keep in mind that once you deselect or save an object, it’s x and z rotation values will swap for no reason. There is no real way around this one, sadly.
Ring bug: When placing or moving Rings using the arrows, their vertical height will be offset by 6 units (this is not reflected visually). If you want to move rings without encountering this issue, you can type the position in manually. This issue has been patched for ObjRing and ObjRedRing as of V3. Other objects that possess this issue will be updated in the future.
Object selection bug: I have no idea what causes this, but in a modified Lost Valley & Imperial Tower, you can’t select objects that don’t have a model set (basically, anything that uses the Default checkerboard cube. You’ll have to go into the scene view to fish the object out.
Not having a gedit file in the mod folder... ...with a name that matches the one you’re editing before you save will cause a crash when attempting to save.
Rendering bugs: Fix in progress.
Collapsing Tabs: Whenever you place an object, the scene view tabs will collapse. Whenever you save, the scene view and assets dialogue will close. This gets very annoying very fast, but uh… Too bad, F in the chat.
Movement arrows disappearing: Movement arrows disappear when you select multiple objects.
Actstgmission issues: If using an edited actstgmission, keep in mind that the dynamic & static sectors will override hedgeedit’s defaults, so you’ll want to remove or edit your actstgmission to include all sectors.
RigidBody parameters: The isEventDriven parameter for Rigid Bodies are backwards. (True = False, False = True).
Crash on Load: Sometimes HedgeEdit will crash when loading a stage, to prevent this, just move the camera around like a maniac until it finishes loading.
There’s no undo button: Yep.
NormalFloor movement types often break: In some cases, NormalFloors use the incorrect movement type no matter what you set them to.
Green Hill Mat Issues: Often times, placing grass platforms in Green Hill stages will make the grass appear red and the platform itself white. You *should* be able to fix this by replacing the materials with the originals but I’m not 100% sure.
Virton object incompatibilities: This isn’t really a bug but I suppose it fits here. The virtron objects from Episode Shadow only work in Guardian Rock, Sunset Heights, or Aqua Road.
Objects carrying over: Hitting new or opening a new gedit while another one is active won’t remove the objects from the previous gedit. Make sure you restart HedgeEdit before changing to a different stage.
Casino Forest Objects do not work with Modern Sonic or the Avatar: This one’s probably obvious, but the game crashes if you try to use casino forest objects with modern sonic or the avatar.
Particle Limit: Sonic Forces has a really small particle limit, so if you hit it, stuff like homing attack and boost particles are gonna start disappearing. This also disables any SFX tied to these particles.
Stage-specific issues:
- Adding objects into Sunset Heights will end up causing camera IDs to conflict (as they have no group IDs of their own). To circumvent this, just add your own group IDs.
- Jumpboard Event Triggers in Metropolitan Highway will always corrupt when loaded, you’ll have to manually replace the object IDs and event types within them by editing the object. Otherwise, this will lead to a crash.
- Final Judgement’s objects are rotated vertically, so the rotation bug fucks all of that up. Final judgement is currently uneditable until HedgeEdit 2 is completed in 10 years.
- Jumpboards break if you try to set their event triggers in some stages. I don't know why. You can’t fix them to my knowledge so… sorry again. Just use switchvolumes.
Set Layers
After you’ve opened and loaded the stage you’re looking to edit in HedgeEdit, hit ‘edit’ at the top and click ‘scene view’. You’ll see a box open up on the right with two groups: ‘Set Layers’ and ‘Terrain Instances’. Terrain instances can be ignored, as it serves no real function currently. What you’ll want to focus on here is the ‘Set Layers’ tab. In each stage, different groups of objects are loaded into their own Set Layers. Whenever you open a stage in HedgeEdit, you’ll need to select one of these layers by clicking on it in order to place objects. The currently selected layer will be shown in parenthesis at the top of the window next to the program’s name. To avoid disorganization, you’ll want to pay attention to whatever set layers you use. If you want to rename or delete a set layer, you can right click a layer and pick an option. Please note that deleting or renaming a set layer does not actually remove or rename it inside your gedit file, so if you need to do that, you’ll want to close HedgeEdit after making that change, open the gedit file in your mod using SFPac, and remove anything you don’t need from there, then repack it by running the folder through SFPac again.
Stage Objects & Enemies
Now that you understand how to open stages and set layers, let’s get to the basics: Object Placement. I’m not gonna be super thorough with this, but I’ll be going over anything that might be confusing in the second half of this video.
Let me start by letting you know that, if there’s a specific object from another stage you want to use, you’re gonna want to copy it’s assets (which may include files from both the object pac AND terrain common) into your mod’s object pac or terrain common. Though, as long as it’s the same in-game location (such as Green Hill) it usually should work without having to add files.
Quick note: You can move the camera in HedgeEdit by holding right click and moving the mouse. You can also press the arrow keys or wasd keys to move, and hold shift to move faster.
Most object descriptions are at the bottom of the object template xmls, unfortunately HedgeEdit doesn’t display object descriptions in-editor and I really don’t want to spend thirty minutes reading all of the object descriptions, so… sorry. You can open up the templates in notepad.
Onto enemies. I’m only going to be focusing on the ones that aren’t self-explanatory.
Valkeen (must be spawned using a trigger):
Name | Function |
---|---|
PathUID | Duh |
AttackDelay | The amount of time before the badnik begins dropping bombs. |
Movespeed | The speed of the badnik when in flight. |
EscapeMoveSpeed | The speed of the badnik when it is disabled and flying away. |
Popspeed | The speed of the badnik before it reaches its pop position. |
PassingAddSpeed | How much to increase this badniks flight speed as it passes by you. |
DropTime | The amount of time the badnik is attacking you for. |
CaptureDistance | Unknown. |
CaptureDistancePassing | Unknown (It may have to do with how it follows the path.) |
TurnRoll | How much the object rotates when steering. |
PopPosition | The position offset where the badnik will spawn in relation to its origin point (ignoring the path). It will begin firing after reaching this position, and despawn once it reaches the path origin. |
PathOffsetPosition | Duh |
AttackType | Normal = It attacks always, Passing = Attacks as it passes you, Reversal = It turns back the other way before dropping bombs. |
CaptureType | Unknown. |
HasGravity | Self-explainatory (but I don't know why you'd ever want to use it.) |
In3D | Duh |
DoesRespawn | If the valkeen can respawn. |
DoesAttack | If the valkeen attacks. |
MoveTime | How long the object moves for |
Eggwalker (i’m just guessing for most of these, this badnik is very inconsistent in its behavior):
Name | Function |
---|---|
PathID | Duh |
MoveSpeed | Its movement speed. |
MaxDistance | The maximum distance this badnik can travel. |
Locaterlist | The list of locators this badnik uses (you only need one, it is the position that it will spawn at BUT make sure you set the badnik’s X and Z coordinates to match its’ locator or it will spawn off-center for some reason. If you want this badnik to jump, though, place the first locator at the position the jump starts and the second at the position the jump ends.) |
JumpSpeed | The speed of the badnik's jump. |
JumpHeight | The height of the badnik's jump. |
JumpType | I don’t think these do anything but I could be wrong. I just don’t care enough to test because Egg Walkers are assholes. |
EndPosObj | The object ID that signifies the location the badnik will stop at (overriding the path.) |
Range | The search range of the Badnik. |
Missileriselength | The amount of height the missiles rise before homing in on you. |
LaunchMissilenum | The amount of missiles this badnik fires. |
FallOffsetHeight | Unsure, might be the offset for the badnik to fall from if isFallStart is set to true. |
PathOffsetPosition | Duh |
IsFV | Whether the badnik is in 3D. |
isFallStart | Whether or not this badnik is in freefall when it is spawned. |
isTreadGrass | Whether or not this badnik kicks up grass when running. |
IsEndTrun | Misspelled parameter for “IsEndTurn,” which means that it will turn to face the direction it came from once it has finished running. |
UpdateMaterial | Whether or not this badnik’s mats will update as it runs into different sectors (should be yes if it starts in a bright area but ends in a dark area). |
EventDriven | Whether or not this badnik is active by default. |
Beeton:
I’m going to keep this one brief since even I don’t really understand some of the parameters, but just to note: SearchDistance is the distance this badnik can move, not the distance it can see like it is for the other badniks. Checkshielding does nothing. IsEscape makes it function like the classic buzzbombers, where it will fire, and then fly away. This Badnik can also be set to respawn by entering along a path, but note that (I believe) the speed of its flight when flying back to its original position is identical to that of its search speed.
Egg Tank:
Name | Function |
---|---|
MoveType | The direction of this Badnik’s movement. |
MoveDistance | Self-explanatory. |
MoveSpeed | Self-explanatory. |
IsRespawn | Whether or not this Badnik respawns. It respawns by materializing in mid air and dropping onto the ground. |
BulletSpeed | The speed of this badnik’s bullets. |
BulletMaxFlyingDistance | The maximum distance the bullets can travel. |
BulletContinuousShellingNum | The amount of bullets this badnik fires during each attack interval. |
BulletShellingInterval | The time between attacks if the ContinuousShellingNum is set to a value above 1. |
BulletCoolDownTime | How long this badnik waits before beginning to fire again. |
Golden Motora:
Name | Function |
---|---|
MoveSpeed | The speed this Badnik moves at. |
MaxMoveDist | The maximum distance this Badnik can travel. |
isFV | Whether or not this badnik is in 3D. |
LocaterList | Each locator correlates to the position the Badnik will land after being hit. Note that the locators must be rotated to face the direction the Badnik is meant to face. |
RingType | The type of ring this badnik will drop. |
RingID | The number of the Red Ring or Number Ring this Badnik drops. |
isBound | Unknown. |
Potos:
Name | Function |
---|---|
StartType | Basically just isEventDriven. |
MoveSpeed | The speed of this badnik’s movement. |
Locatelist | The locator defines where this Badnik will move to after it spawns. These can be used as pathnodes in order to make the Badnik move around. The potos pauses for a brief moment between locators. |
AttackInterval | The time between attacks. |
SearchBox (Width/Height/Depth) | (Width/Height/Depth): Duh. |
RespawnTime | The amount of time after this Badnik is destroyed before it respawns. Set to 0 in order to have it not respawn. |
GalagaBee:
Name | Function |
---|---|
NumBees | The number of bees that appear. |
NumFirstBees | The number of bees that appear during the first interval. |
AppearSpan | The time between spawns. |
Movespeed | The speed the bees travel at. |
SearchBox (Width/Height/Depth) | (Width/Height/Depth): Duh. |
StartPosObj | The locator that defines this badnik’s start position. |
Repat | Supposed to be “repeat”, and it determines if this badnik continuously respawns or if they only appear once. |
Pad values | Unknown. Possibly just padding values. |
Repeatspantime | The time between respawns. |
Homingrebound | Whether you rebound off of the badnik chain? |
HomingDir | The direction you travel at once you homing attack these badniks. |
Egg Pawn:
Name | Function |
---|---|
WeaponType | 0 = Silver Machine Gun Egg Pawns, 1 = Standard Egg Pawns. |
ApproachLimit | How close you can get to this badnik before it can no longer see you (possibly because its gun reaches past you and it has no melee attack like it does in gens in order to avoid this?) |
SearchDistance | The distance this badnik can see. |
SearchAngle | The angle this badnik can see at. |
MoveDistance | How far this badnik can move. |
ShotCoolDown | Whether or not this Badnik stops firing briefly in between attack intervals. |
AttackConst | Whether or not this Badnik is always attacking. |
AttackConstAngle | The angle this badnik fires at if AttackConst is set to true. |
In3D | Self-explanatory. |
IsEventDriven | Self-explanatory. |
HasGravity | Whether or not gravity affects this Badnik. |
IsFallStart | Whether or not this Badnik is in the air when spawning (Note: This sometimes conflicts with IsEventDriven.) |
IsTreadGrass | Whether or not this Badnik emits grass particles when walking. |
UpdateMaterial | See EggWalker. |
IsStatic | Whether or not this Badnik has its AI disabled, basically. |
BehaviorType | I don’t really know if there’s a difference between any of these values, feel free to enlighten me. |
ToSVPathDistance | This Badnik’s distance from a 2D section if it is in 3D. |
Egg Chaser (Fun fact: You can use void on these guys.):
Name | Function |
---|---|
AttackType | 0 = This Badnik’s attacks are based on timing. 1 = This Badnik will attack when the player enters an EggChaserBeginAttackVolume. |
AppearSpeed | The speed of this badnik as it enters its path when spawning. |
EscapeSpeed | Same as above, but when being disabled. |
PlayerDistance | The distance of this Badnik from the player. |
PathHeight | The height offset of this Badnik from its path. |
isEventTurn | Whether or not this badnik is enabled by default. |
SwingSpeed | The speed of this badnik’s hovering. |
SwingPhase | The phase of this badnik’s hovering. |
Lasertime | The amount of time this Badnik is firing for. |
Attackinterval | The interval between attacks. |
Attackphase | The phase of this badnik’s attacks. |
NumAttack | How many time this badnik can fire. |
PathID | Duh. |
UseLaserRayCast | I’m not exactly sure what this one does, I think it’s just related to the particle effect. |
Narl:
The wormlike Badniks from Planet Wisp (in Colors) and Metropolis in Forces.
Name | Function |
---|---|
Type | 0 = Standard (fires lasers in a straight line). 1 = Flame (fires flames.) |
IsFV | If this badnik is in 3D. |
CollisionShape | The shape of this Badnik’s collision range…? |
SearchExtents | The search range of this badnik. |
SearchOffset | The height offset of this Badnik from its path. |
HeadAngle | The angle this Badnik faces. |
IsEventOn | If this badnik is triggered by default or not. |
HeadPitch | The pitch rotation of this badnik’s head. |
Collectibles:
While Red Rings function on their own, the Number Rings and Moon Rings require an object manager to function. These managers are named based on the object they activate (ObjNumberRingManager & ObjYellowMoonRingManager). When placing these managers, make sure its rangein and rangeout are large enough to encapsulate all of the ring objects it controls, otherwise the rings will despawn.
LinkedSprings:
LinkedSprings are pretty much just an alternate version of Springs with a few notable additions: being able to automatically place several springs in a row along with along being able to send the player along a "path" (idk why Sonic Team called it this cause the actual function sends you directly to a given coordinate position and not along a spline).
Unique parameters:
Name | Function |
---|---|
PlaceNum | Places whatever number of springs you define in a row. |
PlaceType | Has two options, Line and Circle. Line places springs in a row and Circle places them in, well, a circle. I'd probably recommend just using Line though cause it's basically impossible to tell what you're doing with Circle until HedgeEdit becomes capable of visualising the spring placement. |
CircleRadius | Determines the radius of the springs if PlaceType is set to Circle. |
Behaviour | Has two options, Normal and Path. Normal just functions like a normal spring (and so i'm not going to go into any of the parameters related to it) while Path sends you to a given set of coordinates. |
Path_TargetPosition | A set of X/Y/Z coordinates that control the position you're sent to if Behaviour is set to Path. |
Path_BeginAngle and Path_EndAngle | Controls the angle of the player upon touching the spring(s) and upon reaching the TargetPosition respectively. |
Path_BeginForce and Path_EndForce | Controls the movement force upon touching the spring and upon reaching the TargetPosition respectively. |
GoalPlate:
The Classic Variant of the goal. It is very basic, in that it simply causes classic to enter an autorun after it is crossed.
GoalTrigger:
The Modern Goal. DO NOT USE PLATE MODEL TYPE 2, IT CRASHES THE GAME. Also, everything past PlateSpeedType is basically just junk, although you can edit it if you like.
WhiteOutTrigger:
WhiteOutTriggers are nice for things like stage transitions; as you might think they pretty much just make the screen fade to white. In order to do a complete transition you always need a trigger at the start of the transition to fade to white and then a trigger at whatever the end point is to fade back to normal colors.
ShapeType:
Determines the shape of the trigger; has box, sphere, cylinder, and capsule options.
BasePoint:
Determines the origin point of the trigger; has center and Z plane options like with most objects that have this setting along with X and Y plane options for some reason.
CollisionFilter:
Filters what types of objects can activate the trigger; why you'd want anything other than the player to activate the trigger is anyone's guess.
Type:
Has two options: White out, which fades the screen to white, and white in, which fades the screen from white back to normal colors.
Sound Triggers:
I’m not going to go into too much depth regarding sound objects, but I’ll go over the basics. You can find the cuenames for the objects by looking in the acb files in the sound folder for the game using a hex editor. The main thing you need to know is that you can’t use sounds that aren’t part of a common acb or are from a different in-game location (for example, w5 sfx won’t work in w2.)
MoveRingBuilder:
These are also really fucky and A LOT OF THIS MAY BE WRONG so I’m basically going to gloss over them, but here’s what I know: These are the objects that get used in Aqua Road that create the moving ring trails you can collect. BuildType Loop means that the rings will keep looping after they reach their end point. BuildNum is the number of chains of rings (as in respawning? I’m not certain on that). BuildInterval is the amount of time between spawns. ItemId is the id of the Red Ring this object uses if the ring type is set to red ring. PathID is self explanatory (or at least I hope it as this point), Movespeed is the speed of the rings as they travel along their path, the meandering parameters are for the wavy movement patterns, limittime is the maximum time the rings can spawn for, overtime is the time they end at(?), columnnum is the amount of rings in a column, rownum is the amount of rings in a row, column offset is the offset, and the rest is self explanatory.
ObjectLayerTrigger/ObjectLayerVolume:
ObjectLayerTriggers allow you to enable/disable Set Layers on the fly. Please note that they do not reset if you restart the stage or restart at a checkpoint, so you should place another trigger to account for that atop the checkpoint/spawn position.
BallMoveTrigger:
A trigger that causes the player to enter a roll based on the speed of the player when crossing through the trigger. The player will decelerate and uncurl in response to the settings in the physics rfls.
BallLaunchTrigger:
Basically the BallMoveTrigger, but it uses set speed parameters and follows a path.
PipeMoveTrigger:
The movement object that controls the movement of the player through the tunnels in Green Hill and Pipes in Chemical Plant.
PipeMoveTrigger Parameters:
Name | Function |
---|---|
SpeedType Fix | The player’s speed is locked at a fixed value. |
SpeedType Min | The player’s speed varies as they travel through the path. |
LaunchSpeed | The speed of the player as they exit the path. |
LaunchAttackTime | How long the player is going to be propelled after launching out of the pipe. |
ShowTimeEffect:
An object that basically functions like the Infinite object in Capital City, but without Infinite. Keep in mind that a second rgb table must be added to the stage’s terrain common in order for this to work.
TerrainBlock/TerrainBlocks:
Placeholder terrain blocks that were used as… placeholders… for terrain during testing. Unfortunately, these only draw in the game’s built-in level editor (presumably). They’re still useful for simple shapes, though.
DebugNote:
Basically just an object that lets you leave notes for other people looking at the gedit you’re working on. Useful when working with a team (then again, you could just tell them directly).
Gravity Objects:
I’m going to gloss over this one too due to them being kind of odd, but basically these objects just control gravity based on the direction and position of the object.
ObjReleaseBox:
The Eggman Capsules used in the blue SOS missions. These usually don’t work in modified stages, but I have had rare occurrences where they do appear.
ObjFan/ObjWaterFan:
The fan objects seen in multiple modern games. I feel like the parameters on these are pretty self-explanatory, so I’m not going to go into them.
ObjGismo:
Gismo Object. This is used for breakable objects like the roadcones in luminous forest and the breakable barricades seen around the game, as well as moving background assets like the signs & cameras in Metropolis. These can be edited using 010 editor & the (unfinished) gismo editor, but they are very very difficult to get working correctly due to their physics behavior being generally unstable.
ObjThornBall:
The Thornballs seen in the extra stages and Casino Forest. I only understand some of these values, so I’m only going to cover those for now.
Name | Function |
---|---|
Type 0 | Just a non-moving thornball. |
Type 1 | A moving thornball. The distance parameter in the object starts from the position of the object itself, so the object should be in the middle of the area you’d like it to move along. |
Type 3 | It’s a thornball that appears when triggered. |
Type 5 | A rolling thornball that follows a path. It will decelerate and eventually fall out of bounds after it reaches the end of its path. Although this object follows a path, gravity still affects it, so be aware of that. |
ObjHintRing:
It’s a hint ring. You can set it to use specific text as defined in the game’s text_hint pacs, but you cannot add new text strings as of right now.
ObjTargetTest:
A placeable homing attack reticle. You can use these to allow the player to homing attack objects they normally wouldn’t be able to.
ObjLaserTurret:
[Insert Table]
ObjWallJumpTest:
A test object that lets you place walljump collision.
GadgetVolume:
Allows you to restrict/enable the use of Wispons when within its range.
OutOfControlVolume:
Lets you disable the player’s controls once they enter the volume. Keep in mind that Classic Sonic kind of ignores this object.
NormalFloor:
The floating platforms used throughout the games.
[Insert Table]
(Custom) scaletest:
A custom object I made that acts as a visualizer for range boxes.
Important/Common Parameters:
- Speed: The speed of the object or it’s function.
- Camera: The ID of the cameravolume the object uses.
- PathID: The ID of the path the object uses.
- IsEventDriven: Whether or not the object is triggered by default or must be triggered by something else.
- phase: It’s basically a time offset. For example, setting the phase to 1 will make the object behave as if it had been activated one second earlier.
Object Parenting:
If you want to connect one object to another, you can put the Object & Group ID’s of the parent object (the one that controls the position of the second object) in the ‘ParentID’ and ‘ParentGroupID’ boxes of your object. The childposoffset tab is the distance that your child object is offset from the parent object. Note that any objects that move cannot be parented to other moving objects (under most circumstances, sometimes the game lets it happen but it’s seemingly random.)
Cameras
Since the default camera is pretty garbage in Forces, you're going to be reliant on various camera objects to give the player the ability to actually see where they're going. Here's a quick overview of CameraVolumes along with the essential camera types you'll find yourself using the most.
CameraVolumes:
In order to activate camera objects they have to be assigned to CameraVolumes, which are basically invisible boxes that activate the cameras when you go inside them. To assign a camera object to a CameraVolume you simply need to put the ID and GroupID of the object into the volume's Camera parameter.
[Insert Table]
CameraSubVolumes:
If you want to reuse the same camera repeatedly in a stage you can use a CameraSubVolume. Instead of putting in the ID of a camera object you put in the ID and GroupID of another CameraVolume, and the CameraSubVolume will take on all the parameters the CameraVolume uses(aside from it's BasePoint and size).
Camera Objects:
[Insert Table]
CameraFollow:
One of the simplest camera types, as you'd expect it simply just follows the player.
- Yaw: Controls the rotation of the camera on the Y axis.
- Pitch: Controls the rotation of the camera on the X axis.
CameraPan:
Looks at the player from the point the object is placed.
[Insert Table]
CameraPoint:
Stays behind the player while pointing towards wherever the object is placed (essentially the reverse of CameraPan). No unique parameters.
CameraRailForwardView:
Generally something you want to use in 3D running/boosting sections, it moves along a spline path while following behind the player.
[Insert Table]
CameraRailSideView:
Best used for 2D sections (unless you want to do something like that psuedo side-scrolling bit in Spaceport), it moves along a spline path while following the player from more of a side view, hence the name. Also this camera is a bit confusing to work with so there's a couple values I haven't figured out yet.
[Insert Table]
DefaultCameraSetting:
Lets you set the default camera for the entire stage that gets used when no camera volumes are active. THIS IS NOT A REPLACEMENT FOR THE DEFAULT CAMERA ITSELF, USE ACTUAL CAMERAS.
SetPaths & Other Path Objects
I’m only going to be going over SetPaths, SetPathNodes, and SetPathLines. As for the others, figure them out yourself.
SetPath
You put a setpath down, and then you put an ID in. This is going to be the path’s ID (obviously). You have 3 pathtypes. The first is Object Path (use this for most cases), 2D path (you can basically just use Object Path it doesn’t really matter), and grind path which-- you guessed it-- is used for grind rails. Theres also a true or false toggle for the path being used for loops, but it’s useless because loops have their own path objects so just pretend that doesn’t exist. StartLineType decides whether or not the path smoothing between nodes will be straight or curved. DivideLength is the distance between the invisible points between each node. Higher values make the path more rigid, whereas lower values make the path smoother. Do NOT use one, it will crash. 10 should be your minimum.
SetPathNode
The nodeID should start at 0 and increase by 1 with each node you add. These should be added into your parent SetPath by their OBJECT ID, NOT their node ID. Linetype is the same as previously described.
SetPathLine
SetPathLines are basically just SetPaths… but they’re a line. Sometimes, you may have to fiddle with the path’s rotation in order to get the desired result.
CorrectPathVolume2
This object basically allows you to force the player along a given path. Useful for tight turns (such as that one part in Metropolitan Highway, except that there is one there, it’s just really weak lol).
Triggers
There are various types of triggers in the game, but in this tutorial I’m going to be focusing on triggers for different objects. Triggers often have 3 event groups with their own individual timers (each timer is independent of one another, they do not stack). Each event group can be set to enable (or disable) any number of objects simply by putting in their object IDs.
Switchvolume
Switchvolumes are invisible boxes that can trigger things such as enemies, particles, and sounds so long as their targets are set to be event driven. They have several condition types which have their own functions. On trigger means that the objects will be triggered as soon as you enter the switchvolume’s range. Pulse means that the target objects will be enabled or disabled each time you enter the switchvolume’s range. Timer & Timer Once seem to be completely useless as there’s no box for a time value. On stay will only trigger the objects as long as you are inside the volume. Once you exit the volume, the objects will turn off.
EventSetter
Basically a switchvolume, but it is triggered by destroying badniks. There’s not much to explain here, just read the object parameter descriptions.
Tips
- To select multiple objects, hold control and click. Keep in mind that this will cause the arrows to disappear, so make sure you know where to click. (The arrows will not move with the objects themselves).
- Having trouble with organization? You can change the name of an object by clicking the name tab in the Custom Data section.
- When placing Egg Chasers on slopes, the initial setpath should be the end point, and all path nodes rotated to face the floor’s orientation.
- The first setpathnode should be behind the main setpath for pulleys & other objects.
- The object limit is 4000, you can’t go over that, fuck Sonic Team. You can view the number of objects at the top left.
- Make sure you change the default ranges when you place objects (usually for most gameplay objects, 200 is a good rangeout value. For rangein, 1000 is recommended for 3D, whereas for 2D, 400 is recommended.
- If copy pasting multiple objects, first select the first object you copied before pasting, then you’ll have an immediate arrow reference for moving them (this will only last until you click into the window).
- HedgeEdit will load models through ObjGismo. If you’re having trouble loading a model, you can put the model name into the gismo and use it as a position/rotation reference.
- Some objects may have to be rotated to face a certain direction in order to activate. (The objects that require this should have the “front” text rotated to face the player.
- You can make the controller rumble by using ObjVibratonTest and setting the name parameter to one of the ones in PlayerCommon’s .vib file.