Something I never really made clear was the way this works as far as defining the bricks. I don't know if any of this counts as bad practice, as it had been awhile since my last TS project when I made these. I tried to add comments to all of the code to make it understandable.
Boosters are pretty straightforward.
datablock fxDTSBrickData(BrickBoosterData)
{
brickFile = "./resources/booster.blb";
iconName = "config/scripts/server/Brick_Platformer/resources/icon_booster";
category = "Special";
subCategory = "Platformer - Misc";
uiName = "Player Booster";
isBooster = true; //Flag for boosters.
boosterPower = 50; //Velocity that the player is sped up by.
};
A flag for just being a booster and the power.
Bumpers need a bit more information.
datablock fxDTSBrickData(Brick2x2BumperData)
{
brickFile = "./resources/bumper2x2.blb";
iconName = "config/scripts/server/Brick_Platformer/resources/icon_bumper2x2";
category = "Special";
subCategory = "Platformer - Misc";
uiName = "2x2 Bumper";
isBumper = true; //Flag for bumper bricks.
bumperPower = 25; //Power of the bumper. Used only in bumper/bumperdir.
bumerAddSpeed = 0; //Don't mess with this, it doesn't do anything good.
bumperDirectional = false; //Flag for directional bumpers.
};
bumperAddSpeed has to do with targeted bumpers, and makes the loop occur more quickly. I've warned against using it because quick loop times function very poorly with latency. Directional bumpers require an additional flag because they don't go straight up; they go in the facing direction.
Grind rails are the most complex.
datablock fxDTSBrickData(BrickGrindRailData : Brick1x1FData)
{
brickFile = "./resources/1x1F Rail.blb";
category = "Special";
subCategory = "Platformer - Rails";
uiName = "Grind Rail";
canGrind = true; //Flag for grind rails
grindDir = "1 0 0"; //Direction of the raycast search for the next rail.
grindOffset = "0 0 0"; //Offset of start for rail search.
grindDirInv = "1 0 0"; //Direction of rail search when player is going in the reverse direction.
grindOffsetInv = "0 0 0"; //Offset of rail search when player is going in the reverse direction.
grindDetach = false; //Flag to automatically detach the player upon reaching this type of rail.
grindCanJump = true; //If the player can exit when on this rail.
grindAddJumpVel = ""; //Additional velocity addded to the player's speed when exiting. (Use angular velocity; empty string defaults to 0 0 0)
grindAutoJump = false; //If the player automatically exits when on this rail.
grindJumpVel = ""; //Scale of the auto-jump. (One float; empty string defaults to $Platformer::Grind::ExitVel)
grindReverseOffset = false; //If the player's reversal flag is toggled upon reaching this rail.
};All of the vector values are used in rail searches. A rail search is a simple raycast check to find the next rail on the track. The offset value is simply a vector added to the origin of this check to make life easier. Or harder, depending. The 'inv' values refer to the direction it searches when the player is going in the 'reverse' direction. This was necessary for certain types of rails (at the time, up/down ones specifically) to function correctly backward. It also allows for some interesting types of one-way rails.
grindCanJump was needed because up/down rails caused players to get stuck when they attempted an exit while on them. I actually think this may no longer be relevant, but it's a potentially useful flag regardless.
I feel like some may find this useful information if they wanted to create bricks for their own use, for instance, an up/down+left/right/ rail. I wanted to make this more easily possible, and cause no unnecessary pain while making new bricks during development. I have a few ideas for additions to this brickpack, but I don't want to start making updates until I know what the result is on RTB. I don't want to work on a failed mod.
