I was a bit rushed when posting that change. At the time I was in the middle of rewriting a lot of code so maybe there was something I changed that I didn’t list. What isn’t working with it? It’s more of a holdover until margins are implemented as it has some quirks that would personally prevent me from using it in any actual game.
Do you think they will still implement margins? It’s been 2 years
If roblox took over a decade to add UDP remotes, then they will likely take another to add a basic feature.
in my game it just made me go upwards infinitely when i tried moving, i just hope we can just get margins and be done with all the workarounds.
1 Like
Antiwarp doesn’t seem to counteract the “Holding X” bug that Roblox has.
Holding the X on my client freezes the Chickynoid character mid air despite Antiwarp being enabled.
This occurs in the test place as well, so it isn’t specific to my game’s settings.
1 Like
It is obviously going to still freeze your client, because Roblox cannot tell windows to lo longer freeze it, try running the simulation on a real Roblox server and use another client to view the simulation.
1 Like
This happens in a Local Server session in Studio (separate Server and Client windows).
This also happens in the official Chickynoid test place on Roblox and has the same effects (you can stay mid air).
1 Like
Then I don’t know what to tell you chief, I think you are cooked.
1 Like
I’ve made a pull request to fix this issue which includes an explanation on why it happened
I’ve also made another pull request to include two optimizations to bots which I recently implemented for my bot-intensive chickynoid game, these changes allowed me to have a lot more bots than with stock chickynoid
After some more digging I found that the Fake Command doesn’t work because the “event” generated by the FakeCommand lacks a [1] or [2] entry, meaning it never gets processed.
I fixed this by adding this line under “GenerateFakeCommand()”
event[1] = command
Additionally, when FakeCommands are ran through the ProcessCommand() Function, they get returned and are never processed. I fixed this by adding an if statement to the first portion of the function.
Again, I’m not particularly experienced with the inner workings of Chickynoid, but this seems to allow Antiwarp to function properly (specifically when freezing the client via holding X). There is probably a less blanketed solution out there. If anybody has any information on how this fix could be further improved or optimized, that’d be great.
Chickynoid hurts my brain too much, I don’t 100% understand how it works but I think the whole freezing thing would happen because it still relies on clients sending their deltaTime to step foward the simulation on the server.
1 Like
Antiwarp seems like it was designed to fix that issue, but it doesn’t work in Base Chickynoid because of an oversight or something.
It detects the time since the last processed command, and if it’s too long, the server starts creating “fake commands” to move the character. This is done at around 20 times a second, equivalent to the player running a 20fps game.
It detects the fact that the player is frozen just fine, but when it tries to act on it, it does nothing. It creates the fake command and sends it to be processed, but it’s missing data in a way that stops it from being processed.
But yeah, that’s most likely why the freezing bug still happens. The server relies on the client to step forward the simulation, and when that flow stops, nothing happens on the server. Thankfully, Chickynoid was clever enough to detect when this was happening.
Does anybody know how to make the environment update collisions according to changes made?
For example, I set a part’s CanCollide to false, and I’m still able to collide with it. I move a Part away, and I’m able to collide where it previously was and not the new spot.
Deleting a part completely seems to work (no longer able to collide with it), but not any other changes.
You will probably need to fork the Collision module, there are tags used to update collisions on certain parts referred to as “DynamicParts”
Fork it so these parts update when the collision properties change.
1 Like
Yep good catch! I simply forgot to test it back when I did the 2.0 update.
3 Likes
Is there a way to increase the precision of TerrainCollisions?
Right now, Terrain seems to be measured in a 4x4x4 area. This works fine, but characters can appear to “float” above the ground if that part of the Terrain isn’t aligned to voxels.
I’d like to increase the accuracy to maybe 2x2x2 if it’s possible.
I don’t even think this is possible easily because Chickynoid uses something like the marching cubes algorythm to get the collisions of the terrain, like it runs its whole internal algorythm to get the vertices of terrain, it’s crazy.
I apologize for replying to such an old topic, but did you ever find a solution to this?
I’m trying to teleport a Player 5000+ studs away and the Teleport isn’t instant due to this.
You’d have to make a replicated variable for teleporting (like how the player’s position is replicated) that gets set to true on the same frame as the teleport, then when the client handles movement it checks if the teleport flag is set to true and if so skips interpolation. At least that’s off memory from v1 of chickynoid so it might not be accurate anymore
1 Like