April 2023 Update - CTF, Teleport, Grapple

Updated: Sep 15, 2023

One month into the next milestone

When finding a couple nights to work on WFR, I've focused my time on implementing some of the key features of Weapons Factory. One of them is the ability to take the flag and capture it. Other features including a full re-usable and server aware implementation of the teleport system, and a grapple system revamp to solve some fundamental issues I came across while testing.

CTF System Overhaul

The flag system was derived from the Roblox CTF example, but has been heavily modified to meet the requirements of Weapons Factory style CTF, including a smooth steal and sound play, dropping the flag when dead and resetting after 30 seconds playing a sound, and capturing the flag with a sound.

Here are some of the issues I came across using the original Roblox implementation of capture the flag.

Relied on collision of the flag, in which case players can not walk through the flag. In Q2WF, players walk right through the flag without colliding.
When taking the flag, there was a pause from hitting the collision before taking it. This is not ideal, it should be a smooth walk through to take the flag, with sounds going off.
The configuration aspect of the original implementation is nice, and had some functionality I didn't need, as well as didn't have all the requirements I needed. So I removed/added some functionality.

The flag system is purely on the server, driven by events when the player touches an invisible cylinder that encompasses the flag area.

This resolved the collision hitch and ensures no exploits can occur.

Next update, we'll hopefully be using the original flag asset from Q2WF instead of this Roblox flag stand in.

Portals and facing the player a specific direction.

The largest update from this month related to Teleporting, is converting the local client script to a re-usable Module script, that is used from a re-usable package that contains everything needed for the teleport system to work with a source and destination. This teleport folder can be duplicated and the destination model object can be re-positioned as needed.

One of my main focuses was ensuring the player faces a specific direction when teleporting, like it does in Q2WF. I was originally using Player.Character:MoveTo() , which turns out is not the ideal approach for first person shooters, because the humanoidRootPart is literally positioned to that location, with no player rotation argument. I wanted to be able to easily control which direction the player faces when coming out the destination object.

The key to making this work was two things:

On the server set the CFrame, humanoidRootPart.CFrame = dest_cframe
Afterwards Fire a client event with the rotation, teleport_src_to_dest:FireClient(player, dest_cframe.Rotation)
Set the CFrame of the camera, camera.CFrame = CFrame.new(camera.CFrame.Position) * dest_rot

The server setting the cframe of the humanoidRootPart, positioned the camera to the proper location, but the client needs to know to what the rotation should be for the player's camera. I didn't find this answer anywhere on the forums, so I hope this helps others.

Also, in this event, I've added functionality to ensure any devices, or grapple being used cancels when teleporting.

The image above, shows a cylindrical trigger object, that when touched, invokes a server event to ensure that the player is allowed to teleport from here, and go to the specific destination it's linked too.

Grapple System Revamp

In the first iteration of the grapple system, it was just a beam going from initial position to target position and nothing in between. No hook firing off, no rotation, no texture. In the 2nd iteration from the March update, we saw a grapple hook and a beam texture, but the hook was facing the wrong way, did not rotate, the hook did not detect hitting players, and when hanging the vector direction of the player was still moving trying to go into the wall.

This update includes a rotating hook, a true match of the grapple hang, if the hook grapples a player of the other team, it will hurt the player. Original implementation was using a tween from point A to point B because that's how I figured out how to animate an object over time back in 2021. After checking the quake 2 source code, I ended up matching the implementation of moving the object in a specific vector direction and raycasting a stud in front of it until it detects a hitobject, from there determine what to do based on that hit object. This allows a lot more control, and still replicates to other clients.