Seems like it’s no longer crashing. It briefly crashed in studio but not ingame, I think that was just roblox jank though because it stopped happening after a second publish.
Seems like the rig that’s currently being used is missing wraptargets. If you swap out the rig with this one, layered clothing should start working on characters. wraptargetrig.rbxm (13.9 KB)
@MrChickenRocket Do you have any tips or things we should use when we wanna keep client’s synchronized to the server’s simulation?
I am working on this game and for example: how do I keep stamina on the client synchronized to the one on the server smoothly?, and also I have some instances of commands not being executed on the server when an user blocks too fast, any ideas for mitigating/ solving this?
While this is cool, chickynoid still has practically 0 documentation forcing people to go through the learning pains you did or read through 200+ posts. Gonna block a lot of people from picking this up.
If you could write up a post or tutorial based on what you learned that would really facilitate the adoption of chickynoid and your module.
I have thought of doing this, but I don’t exactly know what to include on it or how to write it and where to write it, I thought of making some documentation on a bulletin board post for my own resource that uses chickynoid to at least have some info related to it out there but I don’t know how to structure it and how to properly make it.
and lastly I am not an expert on chickynoid yet, in fact I dont even know how to change the deffault speed of chickynoids mid game yet because I have not looked at it’s code in a long time. So I could just end up spreading misinformation.
But yeah maybe ill consider again writing or making a youtube tutorial on my channel about chickynoid.
this issue is not present in @CCTVStudios’ version with chickytools
this resource is great and its been executed great here aswell. It’s unfortunate that it’s difficult to adopt especially since there is no documentation about the resource. It’s been a real curve personally.
yeah I want to write documentation I just dont know how, and what should I include and how to organize it, Also just download the placefile version of chickynoid, idk why people use these complex weird tools to install projects, just download the placefile.
What’s the best method of doing pathfinding using Chickynoid characters? I looked at the bot code for the example place but it seems like the most you can do is changing the direction of where they walk.
You could make them pathfind by changing the walking direction? I don’t know the Chickynoid API, so this is just a really simple example with a made-up function:
local PathfindingService = game:GetService("PathfindingService")
local Path = PathfindingService:CreatePath()
Path:ComputeAsync(StartPosition, EndPosition)
local ReachedWaypointDistance
for _, Waypoint:PathWaypoint in Path:GetWaypoints() do
ChangeWalkDirection((Waypoint.Position - CurrentCharacterPosition).Unit)
repeat
wait()
until (Waypoint.Position - CurrentCharacterPosition).Magnitude <= ReachedWaypointDistance
end
Oof, just found an issue… The hitboxes created under DoNotReplicate on the server completely block pathfinding. As soon as I set CanCollide to false, the Path returns Success every time. Not really sure a good fix around this, unless these hitboxes aren’t needed for some reason.
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.
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!)
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.
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.