You got it, that’s the idea. Is it worth it? Well, if you need just a few sizes of character then probably its fine, its not a huge chunk of work.
Is it ever going to be competitive with native casts? No. But it’s still very, very fast.
1 Like
I managed to get no humanoid rigs working on roblox studio, I can finally ditch humanoids entirely on chickynoid!
They can load clothes through surface appearances.
Here is the rig if anyone wants it:
NoHumanoidR6Rig.rbxm (51.1 KB)
7 Likes
I needed that confirmation as permission to do it - you don’t know until you try!
and try I did.
(just pretend for now that the character would fill up the size of that red box)
Here’s with debugging hull expanded visuals enabled.
It did take some trial and error though. I cut a lot of unused bits of code out from the CollisionModule to make it easier to work on. The unexpected twist was figuring out how the pattern for returning hulls from terrain cells was different from returning hulls from instances in workspace. I had to modify TerrainModule:FetchCell() to include expansionSize (aka playerSize) in its parameters.
For a short explanation, the hulls for instances, meshparts, and terrain exist in a spatial partitioning grid (implemented as a hash map). Instances and meshparts have a condition where they might exist in multiple cells of the grid and would be cached in the fatGrid. Depending on the position that :Sweep is called, the CollisionModule finds the appropriate cell and returns all hulls within that cell. From there, its as simple as multiplying the points of each hull by an expansionSize (Vector3 * number) and caching it.
Instances:
MeshParts:
Terrain:
For networking, I had to change the :SendCollisionData() parameters to include playerSize as well instantiate CharacterData with it. Big shoutout to @CCTVStudios for the mini-tutorial on how to work with the CharacterData module.
Most of the time was spent understanding what was really going on (as well as restoring code I shouldn’t have deleted 
). It looks simple but there’s a lot going on that Chickynoid already handles.
That’s as far as I got today. I’ll return to this in a few days when I get the time. I still have to implement a way to update playerSize and clean up unused memory.
2 Likes
I’m glad you found my tutorial from like a year ago useful.
1 Like
I had no idea you moved to a different account! I would lurk this thread when I first discovered Chickynoid (about a year or two ago). You and amp’s work inspired me to pull the trigger late this year and work with the library.
The biggest hurdle is simply lack of documentation. I don’t have a lot of free time, so I try to get as much out of Roblox development when I can. Posts like yours make it easy to know what to look for to change something.
I don’t want it to go unappreciated in a project like this, so thank you again 
1 Like
The chickynoid humanoid less rig is now out for the public!
Citrus R6 - R6 rigs without humanoids - Resources / Community Resources - Developer Forum | Roblox
Finally! get rid of humanoids from chickynoid once in for all!
6 Likes
How can I exclude water from the TerrainCollision of Chickynoid?
Characters collide with water terrain like any other terrain, making it solid.
1 Like
How do I disable the “Pushing” Chickynoid does?
I’ve already disabled the collisions of this part of the code, but my Chickynoid character is still able to push non-anchored objects like ragdolls.
1 Like
This is probably because roblox physics handle ownership of parts to your client, and in your client your character model still exists and it is able to push them, Set the Network ownership of parts to the server.
2 Likes
This seemed to fix the issue, thanks.
Had no clue the client side Chickynoid models still had the ability to push objects. The default Roblox physics still messes with my head today.
2 Likes
I still haven’t figured this out.
Is there anyone here who knows a little bit about the CollisionModule and TerrainCollision modules?
I imagine I’d be able to make this change myself if I knew a bit more about the actual code for collisions.
I confirm that this is accurate information.
1 Like
I figured this out.
I turned off water collision by changing the Sample() function inside the TerrainCollision module.
local water = Enum.Material.Water
local function getAverage(occs, mats, x, y, z)
local val = occs[x][y][z]
if mats[x][y][z] == water then
return -(val*0.175)
end
return val
end
local function Sample(occs, mats, x, y, z)
local avg = getAverage(occs,mats,x+0,y+0,z+0)
avg += getAverage(occs,mats,x+1,y+0,z+0)
avg += getAverage(occs,mats,x+0,y+0,z+1)
avg += getAverage(occs,mats,x+1,y+0,z+1)
avg += getAverage(occs,mats,x+0,y+1,z+0)
avg += getAverage(occs,mats,x+1,y+1,z+0)
avg += getAverage(occs,mats,x+0,y+1,z+1)
avg += getAverage(occs,mats,x+1,y+1,z+1)
avg /= 8
avg = math.floor(avg * terrainQuantization) / terrainQuantization
return avg
end
There’s probably a better way of doing this, but this solution seems to work well for normal uses.
You get the “mats” variable by passing the “materials” variable from the :ReadVoxels function
local materials, occs = game.Workspace.Terrain:ReadVoxels(region, 4)
local topA = Sample(occs, materials, xd + 0, yd + 1, zd + 0)
local topB = Sample(occs, materials, xd + 1, yd + 1, zd + 0)
local topC = Sample(occs, materials, xd + 0, yd + 1, zd + 1)
local topD = Sample(occs, materials, xd + 1, yd + 1, zd + 1)
local botA = Sample(occs, materials, xd + 0, yd + 0, zd + 0)
local botB = Sample(occs, materials, xd + 1, yd + 0, zd + 0)
local botC = Sample(occs, materials, xd + 0, yd + 0, zd + 1)
local botD = Sample(occs, materials, xd + 1, yd + 0, zd + 1)
I didn’t even know water had collisions on chickynoid, what the flip.
I’ve been messing around with this and I added a few move states. I’m running into an issue where unreliable remotes are being dropped for being oversized. Specifically when I add to the simulation.constants table it starts dropping remotes. Am I doing something wrong and misusing the table or do I just need to keep the constant count low? Any help would be appreciated, Thanks.
Its probably because simulation.constants is larger than the 900 byte limit that unreliable remotes have causing your packets to get dropped.
I was thinking that, but I was under the impression it was delta compressed so as long as they don’t change it wouldn’t be going over the limit. Also It seems a bit odd to be replicating something that should be constant right?
1 Like
Yeah so from what I understood the compression on chickynoid is useless because it will only compress if the packet is under 900 bytes. I could be wrong.
1 Like
Would you suggest I just put the constants in their own module script and separate it out from the simulation object?
1 Like