Suit yourself but as someone who has gone fully into Chickynoid, it’s really not that complicated, and adding the animation stuff you’re talking about is not complicated either. But yeah the lack of documentation is the main issue I had when learning to use Chickynoid.
Anyways, you seem pretty set on not using it, but one bit of advice I would have if you do use it would be do stuff the “Chickynoid” way and everything is easy. I’ve moved my game to Chickynoid and now the entire game is only a couple of client/server mods.
Honestly, id say dont use chickynoid, my game is in dev hell thanks to it, it lacks a lot of features and you have to code them yourself, it also strips you away from using roblox’s advanced physics engine.
I only use it because i like to push the engine to its limits
I’m looking to turning fast_p2p on and off dynamically per player when that player is climbing a climbable wall. But turning it off has been tricky.
Let me know if you had an intended solution. Otherwise, here’s what I’m gonna try. I will need to add a Remote event to tell all other players I’m leaving the climbing wall. Then all other players would set the player character to HumanoidState.Running and no longer receive CFrame updates. At the point Roblox’s normal replication would take over. Does that seem like an alright general approach?
An anchored part parented in the player’s character (not welded to the character) get’s moved around with this script active even though it should stay still, this only happens on other player’s screens not on the server or localplayer. got a fix?
This system is very important for my game because of it’s gameplay relying heavilty on hitboxes.
(Asymmetrical game)
Hi. For anyone interested in making fast, performant, and reliable positional replication system, but got disappointed with the performance implications of the OP’s method, here is a post that might give you a step in the right direction. Except for extra added benefits, security & control, it can reduce network bandwidth around x3 - x20 (depending on how complex the replicated assembly is) compared to default Roblox using this method (if done right), while having much less delay.
Chickynoid is a Humanoid alternative. which happens to come extremely advanced replication.
This has one job, faster replication, and fulfills it well, explaining the lack of features.
Both of them cost in performance, but that’s to be expected and improved overtime.
Oh, and on the Roblox roadmap there is server-authority so that’s exciting!
" Server Authority (Beta): We are building native support for Server Authority. If a Creator enables this feature, the server will become the single source of truth for game actions, logic, and data; this should reduce cheating and improve fairness. Due to the additional latency incurred from a server authoritative solution we are also working on techniques like speculation and rollback to keep games feeling super responsive for your players. This feature is early in development, and we’ll be running tests through 2025. (2025)"
In my case I need a more precise way to position the character, which Chikynoid offers (with really solid rollback), but requires extensive implementation. On the other hand, there is this, which requires little to no implementation but is (very) limited in its scope. The fact that I can use Roblox’s Character Physics Controller kinda makes this post’s solution ideal for me because the Character Controller is highly integrated and has consistent updates. I’d imagine when server authority releases it’d be easier to integrate rather than rebuilding from Chikynoid too.
TLDR: I’m not really looking for a “humanoid alternative” more so I’m looking for a networking solution for character replication, which Chikynoid definitely fulfills, but leaves many other functions of a “Humanoid Controller” up to user implementation (not ideal).
Yes, I saw the Server Authority Beta and I’m excited to finally be able to make and play competitive fighting games without them suffering from horrible character replication! Not to mention the (hopefully) massive blow to exploiting it will deal!
Wow that’s rather impressive.
Is there like a simple breakdown of how this works? I’m quite curious about technical details.
I would assume there’s some prediction going on here and likely also the usage of unreliable remote events.
Pretty sure it’s impossible to send data faster, if a player has 300 ms ping it will always take at least roughly half that time for data to arrive at the server.
What impresses me most is that when you stop moving, the character doesn’t even seem to over-shoot it’s target that much, which is a flaw that prediction systems tend to have.
I think it just fires everyone’s position to the server on Heartbeat, sends it back to all clients, then the client changes every position to the latest one on renderstepped. I’d have to look at the code again, but I’m pretty sure it’s just a simple UnreliableRemoteEvent that does this.
I don’t think so. Roblox’s default replication system is just mediocre and laggy. Sure, this might be less optimized, but it yields better results.
There are still optimizations you can implement into this yourself. Some of the ones I can think of are:
Prevent firing the remote to the server if the CFrame hasn’t changed on the client.
Integrate the networking module you use or send the CFrame data in buffers.
Using BulkMoveTo.
Disabling Roblox’s replication system. (When/If they provide a way to do so)
I’m already working on a optimized replication system myself.
My own optimizations mostly include using only 16-bit numbers for player position and using relative location to some origin point.
And a whole bunch of bit shifts and some weird blackmagic code hoo-haa to encode rotation and remote event order with just 4 bytes or so.
I basically figured out a way to store position, rotation and order in 9 - 10 bytes.
Which is even less than a Vector3, a Vector3 uses like 13 bytes of I remember.
And CFrames can use somewhere between 14 - 20 bytes depending on if it’s axis aligned or not if I’m not mistaken.
My system does have a drawback however, every time the player exceeds like 2500 studs or so away from the “relative point”, the relative point needs to be moved using a reliable remote event but this happens only once.
This gives you about 5k studs of space to freely move around until you reach a invisible border that forces the system to move your origin location (you really won’t notice it).
Most games really don’t need that huge of a map or play area, but it should work in any large open-world too, I’m trying to keep the data as small as possible here.