Seems like it’s used for hit registration, e.g. raycasting on the server. It also says “This box is also used to stop physics props from intersecting the player. Doesn’t always work!”
I’m assuming that if you don’t have physics props in your game setting collision off is fine, just make sure you set “respectcancollide” to false in your raycastparams and use the canquery property instead to flag things as being raycast-able.
Does this have R6 Support? I’m looking forward to using this in my games - also, very good resource, thank you
I think rigs are purely visual with chickynoid. It’s more like moving an invisible rectangle with a rig inside of it. Any rig should work with it. As such, setting your visual rig’s health to 0 likely won’t do anything. (It should be fine to add your own mod that reads chickynoid’s internal health value and applies it to the visual rig to have the health UI display your real health, though!)
1 Like
Yes it does, heres a reply a left to someone else with the exact question on how to do it Chickynoid, server authoritative character replacement - #227 by CCTVStudios
Update: Theres now documentation in the works, so now people can learn and not go through the struggle of having to waste countless hours creating their own inventory systems.
Chickytools documentation [W.I.P.] - Bulletin Board - DevForum | Roblox
@MrChickenRocket I need some advice on this.
So I have my game’s mechanics coded on 2 independent simulations (Server,Client) such as cooldowns, stamina, and states. How exactly do I synchronize them?
Do I use a network event to constantly send the client the current server values of the server simulation?, How do I check or assume they are synced if the result is already late?. Im a bit confused on this, For now I will look into the chickynoid weapon prediction module you mentioned since maybe it has info related to this.
As far as I understand it:
When chickynoid resimulates, it just sets the state of your character to what the server thinks it is, then plays out whatever commands the server hasn’t confirmed yet. This puts you back roughly to where you just were.
The weapons are synchronized in a slightly different way;
- Client makes commands. Executes weapons based on said commands. Sends commands to server for it to follow through with.
- Server plays out command (whether they’re fake, predicted commands or real commands). This leads to the gun being shot on both the client and the server.
- The server sees that there’s been a change to the weapon record. It then sends a list of the changes over to the client.
- Client sets it’s weapon record to match the server.
The main difference comes in that your inputs are not re-simulated, your weapon is just being forcefully set to reflect the state of the weapon on the server. Now this could lead to some issues, i.e firing a machine gun making your ammo count seemingly increase right after firing a bullet, before lowering again. The way chickynoid solves that is by preventing the weapon’s state from being overwritten for a few seconds. (“SetPredictedState” function in WeaponsClient).
Basically, yeah. You should check out how the weapons module does it- it employs a delta table util to only send relevant data when needed.
The client holds on to the states it receives from the server and updates it as new info comes through. The server state is never cleared, you shouldn’t have to worry about this scenario.
Here’s how you could handle the things you’ve listed, based on how the weapon modules are structured:
-
When applying a cooldown, note down your record’s totalTime. Only allow the command for using said ability to pass through if the weaponrecord’s totalTime exceeds the noted cooldownTime by X seconds.
-
Stamina can be treated similarly to ammo.
-
States are auto-replicated based on the model provided by chickynoid.
Finally you may want to be mindful of splitting things up in ways that make sense. Since a machine gun ignores server states until it is done firing, it wouldn’t make sense to couple it with an ability system since a possible cooldown mispredict won’t get corrected until you stop firing your machine gun.
5 Likes
WONDERFUL writeup! Thankyou for that, I think I’ll add it to the documentation…
To add to it, the weapon system is what I call “predict forward only”. The reason it’s handled differently than movement is because it doesn’t make any sense to resimulate a big visual/audio event like a bullet being fired on the client - the player has already seen the effect and animation so there’s no real way to fix that even if it mispredicted.
About the original question - if you’re doing skills like stamina and sprinting, don’t use the weapon system for that. Those should be done as moveTypes and handled through the player simulation.
3 Likes
This Module is very nice! I’ve been using it for my combat game It really had major improvement the Hitbox is more accurate since all the player is server authoritative.
@MrChickenRocket Is there a way to cleanly teleport a player on the server without having the client treat it as a misprediction and it interpolating to the teleport destination?
I could probably call the function on both the client and the server but it’d be great if it were possible to just flag a state update for not being interpolated for a single frame.
EDIT: It seems like the “step up” and “step down” simulation functions are broken in the current github repository & example place. I am unable to walk over the smallest of steps, only getting pushed up by slopes from my horizontal momentum. Letting you know as this seems like a pretty big issue.
Thanks for the report and patch, taken.
Ok thank you so much for your reply, it holds valuable information but I still have a few questions.
So what I understood from what you said and other articles is this:
-
I create a command on the client, Got it.
-
I execute commands, on the client first.
function Melee:ProcessCommand(command)
local playerRecord = ClientPlayerRecord:GetPlayerRecord(LocalPlayer)
if command.CTID and command.MAI then
local EquippedMelee = Melee.ParentClass.CToolRecords[command.CTID]
if command.MAI == Enums.MeleeData.Block then
EquippedMelee:Block()
elseif command.MAI == Enums.MeleeData.Unblock then
EquippedMelee:Unblock()
elseif command.MAI == Enums.MeleeData.Shove and command.SC then
if command.SC > playerRecord.Commands.SC then
EquippedMelee:Shove()
playerRecord.Commands.SC = command.SC
end
elseif command.MAI == Enums.MeleeData.Charge then
EquippedMelee:Charge()
elseif command.MAI == Enums.MeleeData.Hit and command.HC then
if command.HC > playerRecord.Commands.HC then
EquippedMelee:Hit()
playerRecord.Commands.HC = command.HC
end
end
end
end
- Server gets the commands eventually and then executes them there
function Melee:ProcessCommand(command,playerRecord,CTool)
-- Sanitize data
if command.MAI and CTool.IsEquipped == true then
if typeof(command.MAI) ~= "number" then
Firewall:Kick(playerRecord, Enums.FirewallKickType.InvalidDataType)
return
end
else
return
end
if command.MAI == Enums.MeleeData.Shove then
-- Sanitize data
if command.SC then
if typeof(command.SC) ~= "number" then
Firewall:Kick(playerRecord, Enums.FirewallKickType.InvalidDataType)
return
end
else
return
end
if command.SC > playerRecord.Commands.SC then
CTool:Shove()
playerRecord.Commands.SC = command.SC
end
elseif command.MAI == Enums.MeleeData.Hit then
-- Sanitize data
if command.HC then
if typeof(command.HC) ~= "number" then
Firewall:Kick(playerRecord, Enums.FirewallKickType.InvalidDataType)
return
end
else
return
end
if command.HC > playerRecord.Commands.HC then
CTool:Hit()
playerRecord.Commands.HC = command.HC
end
elseif command.MAI == Enums.MeleeData.Charge then
CTool:Charge()
elseif command.MAI == Enums.MeleeData.Block then
CTool:Block()
elseif command.MAI == Enums.MeleeData.Unblock then
CTool:Unblock()
end
end
- We set up the server to send data related to the weapon’s simulation running on the server to the client every tick using a mod’s :Step() function, right?.
So thats what I got right but here are the things I did not understand:
- Lets say a client wants to swing his melee, So he sets a command that says, I wanna hit.
- Then this command gets executed on the client and it gets to the server, Now as the client we are constantly recieving data containing the cooldown value of the server, while also running our own cooldown value on our client simulation
Heres the problem, am I supposed to rewind my client sided cooldown to the server cooldown? and then keep simulating back to normal every time I recieve a server state? but I still dont get how to tell if my state is out of date, Am I supposed to use the server time provided by chickynoid to then somehow compare the last server time to the current state recieved and then check somehow if my values are technically synced?, If so whats the best way to do it.
Also I totally get the part where i am not supposed to rewind actions that have already happened or actions that are not crutial such as bullet tracers, Sound effects, particles and those sort of things.
How do I detect other players? is there any documentation to this?
You’re writing your cooldowns directly to commands. Your commands should only include info on what the player’s inputs are. Your mods/weapons/movetypes can then infer what the player is trying to do based on the inputs.
For instance:
-
You write to commands that you are holding LMB down.
-
Your melee (your currently equipped weapon) processes the commands, sees that it has LMB set to true, checks the last time you’ve attacked (using the command’s serverTime variable).
-
If it’s been over 0.5 seconds since the noted time and the command’s serverTime, note down the new time to the weapons record’s state and perform an attack.
You’d then do the exact same on the server.
If you take a look at the example weapons built into chickynoid, this is what they do. They do use the command’s deltaTime instead of serverTime, but I used serverTime in this example since it’d be easier to explain it that way.
Also everything you write to your weapon record’s state gets auto-replicated to the client and gets corrected as need-be. This is where you’d put stuff like a weapon’s ammo, the last time they were fired, etc.
Yeah but it’s out of date. You’ll want to directly download it from github
I don’t think im using the right words to explain what I actually wan’t to know, All of the things you mention are already done.
I only process inputs and nothing else, a separate function sees these inputs and does whatever they are meant to do, You can see this here on the client and server
Client:
function Melee:ProcessCommand(command)
local playerRecord = ClientPlayerRecord:GetPlayerRecord(LocalPlayer)
if command.CTID and command.MAI then
local EquippedMelee = Melee.ParentClass.CToolRecords[command.CTID]
if command.MAI == Enums.MeleeData.Block then
EquippedMelee:Block()
elseif command.MAI == Enums.MeleeData.Unblock then
EquippedMelee:Unblock()
elseif command.MAI == Enums.MeleeData.Shove and command.SC then
if command.SC > playerRecord.Commands.SC then
EquippedMelee:Shove()
playerRecord.Commands.SC = command.SC
end
elseif command.MAI == Enums.MeleeData.Charge then
EquippedMelee:Charge()
elseif command.MAI == Enums.MeleeData.Hit and command.HC then
if command.HC > playerRecord.Commands.HC then
EquippedMelee:Hit()
playerRecord.Commands.HC = command.HC
end
end
end
end
Server:
function Melee:ProcessCommand(command,playerRecord,CTool)
-- Sanitize data
if command.MAI and CTool.IsEquipped == true then
if typeof(command.MAI) ~= "number" then
Firewall:Kick(playerRecord, Enums.FirewallKickType.InvalidDataType)
return
end
else
return
end
if command.MAI == Enums.MeleeData.Shove then
-- Sanitize data
if command.SC then
if typeof(command.SC) ~= "number" then
Firewall:Kick(playerRecord, Enums.FirewallKickType.InvalidDataType)
return
end
else
return
end
if command.SC > playerRecord.Commands.SC then
CTool:Shove()
playerRecord.Commands.SC = command.SC
end
elseif command.MAI == Enums.MeleeData.Hit then
-- Sanitize data
if command.HC then
if typeof(command.HC) ~= "number" then
Firewall:Kick(playerRecord, Enums.FirewallKickType.InvalidDataType)
return
end
else
return
end
if command.HC > playerRecord.Commands.HC then
CTool:Hit()
playerRecord.Commands.HC = command.HC
end
elseif command.MAI == Enums.MeleeData.Charge then
CTool:Charge()
elseif command.MAI == Enums.MeleeData.Block then
CTool:Block()
elseif command.MAI == Enums.MeleeData.Unblock then
CTool:Unblock()
end
end
I just use a counter to let the :ProcessCommand() function know when an user presses the same key again, so that way it doesnt thinks we are just holding it, since packets are sent every tick.
Also cooldowns are checked like you said from both sides:
Client:
This code just steps all cooldowns using delta time so they are actively simulated and can be rewinded or fowarded with no problem, same for the charge mechanic.
function Melee:Step(client,_deltaTime)
local playerRecord = ClientPlayerRecord:GetPlayerRecord(LocalPlayer)
local States = playerRecord.States
-- Step the charge state
if States.IsCharging == true then
-- step it according to equipped melee stats
local EquippedMelee = playerRecord.Inventory.Hand
if EquippedMelee then
local CalculatedCharge = States.Charge
local ChargeSpeed = EquippedMelee.MaxDamage / EquippedMelee.ChargeLength
CalculatedCharge += ChargeSpeed * _deltaTime
if CalculatedCharge >= EquippedMelee.MaxDamage then
States.Charge = EquippedMelee.MaxDamage
playerRecord.GUI.HUD.ChargeBarOutline.Charge.Size = UDim2.new(1,0,1,0)
else
States.Charge = CalculatedCharge
playerRecord.GUI.HUD.ChargeBarOutline.Charge.Size = UDim2.new((1/EquippedMelee.MaxDamage) * States.Charge,0,1,0)
end
end
else
States.Charge = 0
end
-- Step cooldowns
if States.SwingRecovery > 0 then
States.IsSwingRecovering = true
local CalculatedSwingRecovery = States.SwingRecovery
CalculatedSwingRecovery -= _deltaTime
if CalculatedSwingRecovery <= 0 then
States.SwingRecovery = 0
States.IsSwingRecovering = false
else
States.SwingRecovery = CalculatedSwingRecovery
end
end
if States.BlockRecovery > 0 then
States.IsBlockRecovering = true
local CalculatedBlockRecovery = States.BlockRecovery
CalculatedBlockRecovery -= _deltaTime
if CalculatedBlockRecovery <= 0 then
States.BlockRecovery = 0
States.IsBlockRecovering = false
else
States.BlockRecovery = CalculatedBlockRecovery
end
end
-- Step LMB charge delay thing
if playerRecord.Input.IsHoldingLMB == true then
local CalculatedLMBChargeDelay = playerRecord.Input.LMBChargeDelay
CalculatedLMBChargeDelay -= _deltaTime
if CalculatedLMBChargeDelay <= 0 then
playerRecord.Input.LMBChargeDelay = 0
ClientCommands:SetCommand("MAI",Enums.MeleeData.Charge)
else
playerRecord.Input.LMBChargeDelay = CalculatedLMBChargeDelay
end
else
playerRecord.Input.LMBChargeDelay = playerRecord.Input.LMBChargeDelayDuration
end
end
Server:
Same for server side as client side.
function Melee:Step(server, _deltaTime)
for UserId,playerRecord in pairs(server.playerRecords) do
local States = playerRecord.States
-- Step the charge state
if States.IsCharging == true then
-- step it according to equipped melee stats
local EquippedMelee = playerRecord.Inventory.Hand
if EquippedMelee then
local CalculatedCharge = States.Charge
local ChargeSpeed = EquippedMelee.MaxDamage / EquippedMelee.ChargeLength
CalculatedCharge += ChargeSpeed * _deltaTime
if CalculatedCharge >= EquippedMelee.MaxDamage then
States.Charge = EquippedMelee.MaxDamage
else
States.Charge = CalculatedCharge
end
end
else
States.Charge = 0
end
-- Step cooldowns
if States.SwingRecovery > 0 then
States.IsSwingRecovering = true
local CalculatedSwingRecovery = States.SwingRecovery
CalculatedSwingRecovery -= _deltaTime
if CalculatedSwingRecovery <= 0 then
States.SwingRecovery = 0
States.IsSwingRecovering = false
else
States.SwingRecovery = CalculatedSwingRecovery
end
end
if States.BlockRecovery > 0 then
States.IsBlockRecovering = true
local CalculatedBlockRecovery = States.BlockRecovery
CalculatedBlockRecovery -= _deltaTime
if CalculatedBlockRecovery <= 0 then
States.BlockRecovery = 0
States.IsBlockRecovering = false
else
States.BlockRecovery = CalculatedBlockRecovery
end
end
end
end
What I actually wan’t to understand is how to deal with these going out of sync with the server, since from what I understood. Clients and server can get out of sync due to ping fluctuation, if ping was always the same for a client we wouldn’t have to worry about this.
Please I just want to know this, its the last piece of knowledge im missing on how to properly do server authority.
Sorry, I read “HC” as “Hit Cooldown”. Either way, I’m not entirely sure what it’s doing inside of commands? It’s not an input, it’s a stat being kept track of. That means an exploiter can just spoof it as much as they want. Why not just do this inside of a record instead?
You don’t have to worry about this. As long as you are writing things to states- which you are, the server will automatically restore states should they desynchronize for any reason at all. As for the location of the code responsible for these things, ctrl+F “numChanges” in WeaponsServer, and ctrl+F “WeaponState” in WeaponsClient.
If there is any sensitive function that needs to be interrupted if a desync occurs (Only a problem in niche cases), you can either add your own functions that you run when the client receives a state update or compare states with a local copy of states in :ClientThink().
Do note that simulation related things can run multiple times, so if you, for instance, make a sound play when you start sprinting, rewind could make it play again. This can, again, be avoided by making a local copy of states to compare your new state to.
Did you come up with that weapon prediction solution yourself yielding the overwrite? Pretty neat way to avoid worrying about resimulation.