[WIP] Sonic Forces HedgeEdit Tutorial

Discussion in 'Engineering & Reverse Engineering' started by The Duck Dealer, Apr 4, 2021.

  1. The Duck Dealer

    The Duck Dealer

    Member
    4
    5
    3
    Hey all, this is a tutorial for using HedgeEdit to modify stages in Sonic Forces that was made by Brandon Jones & I. If you have the willpower to mod Sonic Forces, hopefully this helps you out!

    Note: This tutorial is currently a WIP.
    Note: I suck at formatting, so apologies for any issues to those reading this.

    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 updated 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.

    HEDGEARCPACK: 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: (This issue has been patched for ObjRing and ObjRedRing as of V3. Other objects that possess this issue will be updated in the future.)
    When placing or moving Rings using the arrows, their vertical height will be offset by 6-7 units (this is not reflected visually). If you want to move rings without encountering this issue, you can type the position in manually.

    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:
    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.

    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 dunno why. You can’t fix em to my knowledge so… Sorry again. Just use switchvolumes.

    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.

    Not really a bug, but:
    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.


    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):
    -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 it’s 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: I don’t know
    -CaptureDistancePassing: I don’t care (in all serious it might 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: I have no clue
    -HasGravity: Duh, but idk y ud ever use this
    -In3D: Duh
    -DoesRespawn: Duh
    -DoesAttack: Duh
    -MoveTime: How long the object moves for

    Eggwalker (i’m just guessing for most of these, this badnik is very inconsistent in its behavior)
    -PathID: Duh
    -MoveSpeed: Duh
    -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 the badnik jumps.
    -JumpHeight: The height of the badniks 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: i don’t know, might be the offset for the badnik to fall from if isFallStart is set to true.
    -PathOffsetPosition: Duh
    -IsFV: Whether or not the badnik is in 3d or not.
    -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:
    -MoveType: The direction of this Badnik’s movement.
    -MoveDistance: I think this is self-explanatory.
    -MoveSpeed: Ditto.
    -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:
    -Speed: The speed this Badnik launches towards its next position at after being hit.
    -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:
    -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): 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:
    -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.
    -StartPosObj: The locator that defines this badnik’s start position.
    -EndPosObj: The locator that defines this badnik’s end position.
    -Repat: Supposed to be “repeat”, and it decides whether or not this badnik continuously respawns or if they only appear once.
    -Pad values: Unknown. Possibly just padding values.
    -Repeatspantime: The time between respawns.
    -Homingrebound: Whether or not you rebound off of the badnik chain?
    -HomingDir: The direction you travel at once you homing attack these badniks.

    Egg Pawn:
    -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.):
    -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 worm-esque Badniks from Planet Wisp (in Colors) and Metropolis in Forces.
    -Type: 0 = Standard (fires lasers in a straight line). 1 = Flame (fires flames.)
    -IsFV: If this badnik is in 3d or not.
    -CollisionShape: The shape of this Badnik’s collision range…?
    -SearchExtents: The search range of this badnik.
    -SearchOffset: The position offset of the Badnik’s search box.
    -HeadAngle: The angle this Badnik faces. (This is pretty useless considering you can rotate objects lmao)
    -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:
    -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:
    -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 probably 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.
    -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:
    The Laser Turrets in Metropolis.
    -LaserLength: The length of the laser beam.
    -FireType: 0 = All lasers fire at the same time. 1 = Each laser fires depending on the phase value. 2 = Same as 1, but inversed.
    -turretNum: The number of turrets to place.
    -firstSpeed: The speed of the turret’s laser during its first attack.
    -secondSpeed: The speed of the turret’s laser during its second attack.
    -Phase: the phase of the turrets movement.
    -ShotPhase: the phase of the turret’s attack.
    -BeforeShotWait: How long to wait before firing.
    -AfterShotWait: How long to wait before the turret deactivates once it fires.
    -waitDownKeep: How long to keep the turret disabled before it activates again.
    -Interval: the distance between each turret.
    -shotNum: How many times this object should fire.
    -checkBarricade: Unknown, likely detects if something is blocking its view?
    -Cycle: Whether or not the turret’s lasers should cycle.
    -eventDriven: Whether this object is active by default, or must be triggered by something first.
    -noFrame: Whether or not to disable the turret’s frame. Idk y this exists lol
    -hitEffect: Whether or not to play the particle effect for being hit?
    -Sideview: whether or not this turret is in 2d.

    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.
    -Size: The Size of the platform. This varies between 2D and 3D.
    -VisualType: The model to use. Only works in Guardian Rock and Arsenal Pyramid, but can probably be set up for other stages.
    -MoveType: How the platform will move. 0 = No movement. 1 = Uses MoveVector parameter. 2 = Uses a SetPath.
    -PatrolType: How the floor moves. See object description in-editor for elaboration.
    -TimeType: 0 = This object is timed to itself. 1 = This object is timed to the stage timer.
    -IsEventDriven: Whether this object is active by default or must be triggered first.
    -In3D: Whether or not this object is in 3D.
    -IsOneWay: Whether or not you can jump through this floor from below.
    -DoesFall: Whether or not this object falls after standing on it. (Usually this takes 3 seconds, but if you really want it to fall faster, have it set to move and trigger it using a switchvolume once you’re ready.)
    -DoesBreak: Whether or not this platform can be broken from taking damage (Iron Fortress).
    -IsSyncRot: Whether or not to sync this platform’s movement to the rotation of the path.
    -IsSmoothMove: Whether or not this floor’s movement is smoothed (It basically accelerates/decelerates if set to true).
    -IsReverse: Whether or not this floors movement is reversed.
    -IsPressDead: Whether or not this platform can crush you.
    -MoveVector: How far you want this platform to move on an axis.
    -PathUID: The path this floor uses if movetype is set to 2.
    -LocatorList: I don’t think this does anything.
    -WaitTime: How long this platform waits after it reaches its destination before moving again.
    -InitialDelay: How long to wait before this object starts moving.
    -Speed: The speed of this floor’s movement.

    (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.
    CameraVolume parameters:
    -Camera: Has two values, ID and GroupID, which as you'd expect need to match the ID and GroupID of the camera object you want to assign.
    -Priority: When volumes intersect the camera with a higher Priority value will be used over the one with a lower value.
    -UseHighPriority: I believe if set to True the camera will override all other cameras with UseHighPriority set to False regardless of their priority.
    -EaseTimeEnter and EaseTimeLeave: Controls how long it takes to transition to and away from the camera when entering/exiting the volume.
    -InterpolateTypeEnter and InterpolateTypeLeave: These control how the game interpolates the movement as it transitions to/away from the camera. I can't really describe the difference between the interpolation types but they do affect the camera's movement somewhat.
    -DefaultState: If set to 1 then the camera won't activate until a SwitchVolume or other type of event-triggering object sends a signal to turn it on first.
    -Action: If set to 0 the game will let you enter and exit the volume as many times as you please; if set to 1 you can only activate it once and then never again upon exiting the volume. If the volume is triggered by an event then it can be re-activated each time the event-triggering object sends a signal to it however.
    -Shape: Determines whether the volume will be shaped like a box (which is what you're gonna want to use 99% of the time), sphere or cylinder.
    -BasePoint: Determines the origin point of the volume, 0 sets it to be in the center while 1 sets it to be at the start of the object's Z plane.
    -Width, Height and Depth: Controls the size of the volume in distance units. There's no way to preview the volume size in HedgeEdit so you just kinda have to guess.

    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).

    Common camera parameters:
    -FOV: Controls the camera's FOV (shocking!)
    -ZRotation: Tilts the camera on the Z axis.
    -Distance: Controls how far away the camera is from the player.
    -TargetOffset, PlayerOffset and WorldOffset: By default most cameras directly target the player so you can use these parameters to offset the camera's target on the X, Y, and Z axis. I'm not entirely sure as to what the difference is between these three types.
    -GravityOffset: Offsets the camera target upward (I believe the direction it's offset in is also influenced by the stage's gravity direction but i'm not entirely sure about that).
    -FollowType: Features two types, Simple and Intelligent. As far as i can tell the only difference between the two is that when set to Intelligent the camera waits to start scrolling up until the player gets closer to the top of the screen.
    -PathUID: Only seen on CameraRail objects, as you might expect this needs to match the ID of the path you want to use.
    -Azimuth: Generally only seen on CameraRail objects, it basically controls how the camera is rotated left/right around the target.
    -Elevation: Generally only seen on CameraRail objects, it controls how the camera is rotated up/down around the target.

    CameraFollow:
    One of the simplest camera types, as you'd expect it simply just follows the player.
    Parameters:
    -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.
    Parameters:
    -EnableLimitAngle: If set to true a limit will be placed on how far the camera will rotate to look at the player, based on the AzimuthLimitAngle and ElevationLimitAngle parameters.
    -AzimuthLimitAngle: Controls how far the camera will rotate left/right?
    -ElevationLimitAngle: Controls how far the camera will rotate up/down?
    -PositionMode: There's two options for this parameter, "Fixed point" and "Maintain some distance" Fixed point means the camera will look at the player from wherever the object is placed without following along with the player's movement, while Maintain some distance means that the camera will follow along with the player's movement instead of staying where it was originally placed. If the camera is set to this value then the Distance parameter will also control how far the camera is from the player instead of the object's position.

    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.
    Parameters:
    -PathOffset: Controls the vertical offset of the camera from the path.
    -ReversePathFront: If set to True the camera follows from the end of the path instead of the start.
    -UsePathVerticalComponent: If set to True the camera will rotate to follow slopes in the path.
    -AngleSensitivity: Kind of hard to explain but basically controls how sensitive the camera is to turns and slopes in the path, so if you set it to a low value the camera is slow to rotate with the path and moves more smoothly while if it's set to a higher value it will follow the path more exactly and become more jerky unless the path is very smooth.
    -AngleSensitivityBoost: Ditto, but only affects the sensitivity when you are boosting.

    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.
    Parameters:
    -LimitLeftRatio and LimitRightRatio: These are a bit weird but they seem to basically control how far you can move before the camera will start scrolling to the left or right. The values are also generally set very small, somewhere between 0.1 to 1.
    -UpScrollRatio and DownScrollRatio: Ditto, but they control how far you have to go before they scroll up or down. Use negative values for DownScrollRatio.
    -UpScrollDistance and DownScrollDistance: These control in distance units how far the camera will scroll up or down before locking in place. Use negative values for DownScrollDistance.
    -IsLimitPathDistance: You can set this to true or false (usually it's set to false) but idk what it actually does.
    -LimitPathDistanceMin and LimitPathDistanceMax: Related to the above value but idk what it does.
    -OrientationMode: Has two settings, Gravity and Path Normal. I believe if set to Gravity then the rotation of the camera is determined by the stage's gravity while if set to Path Normal the rotation is based on the sloping and curving of the path the camera is attached to.
    -IsEnableAzimuthOffset: Makes it where the camera will rotate when moving at high speed to show a better view of what's ahead.
    -IsSmoothPath: Idk what this does. Possibly the equivalent of a dividelength on a setpath?

    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 (they're either extremely simple or extremely complex)

    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 (ugh). 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.
     
    Last edited: Apr 4, 2021
    • Like Like x 2
    • Informative Informative x 2
    • List