Echo - Player-data oriented, network efficient replication tool

[shy sage]

Wow I was actually looking into making something like this fairly recently for a project I was working on this looks pretty great and I may use this in the future

[obtuse bone]

remote table not mentioned? 🥀

[vivid compass]

Very cool I have something like this in my game but a more generalized replication

That all the way keeps the data synced between the server & the client always

Which isn't the most performant thing, but hey it simplifies the development a lot when dealing with data!

[obtuse bone]

otherwise you end up with thousand line data manager that has a specific replication code for every single change

which sucks

[vivid compass]

Yeah fr

[sacred rain]

I've had exactly this before making echo 💔

Was going to use the same approach for starting a new game

[obtuse bone]

Yeah this is really important for modern roblox games

Makes code easy to maintain

[sacred rain]

lets hope i dont bump into a bug i cant fix

💔

otherwise i've finally got a good replication tool

RemoteTable has too complex syntax for me, sorry drsinek..

[obtuse bone]

Dawg it's so easy😭

Its fine tho

[sacred rain]

im dum asf

if its not "get" or "set" im done for

mainly cuz my english isnt good enough

[obtuse bone]

Nah you just do .WaitForTable(token) to get the table and thats it for client

For server do .ConnectTable

[sacred rain]

devforum post seemd difficult to understand

i dropped immediately

[obtuse bone]

And rhen :AddClient on the returned object

[obtuse bone]

It's a demonstration of features

[sacred rain]

.New would be better ngl

[obtuse bone]

Didnt want to use that since it's not just new

[sacred rain]

cuz yk the module is alr called RemoteTable

[sacred rain]

You could make 2 methods .New and .FromToken

yk

[obtuse bone]

The returned table is anot a class tho its a raw table

Thats the thing

[sacred rain]

oh

[obtuse bone]

The table automatically mutates itself

Then you jsut change variables like a table

tbl.Key1 = 10

This will be replicated

[sacred rain]

But you store table's token on server dont ya?

[obtuse bone]

Ye I do

[sacred rain]

What's the problem to retrieve both raw table and token as 2nd argument from .New

[obtuse bone]

No like token is already used to get the tablr itself

[sacred rain]

OHH

and token is a string right

[obtuse bone]

I dont give much control over when the replication happens. It will replicate on mutation

[obtuse bone]

Yup

[sacred rain]

like {Player.UserId}

[obtuse bone]

Yes

[sacred rain]

idk still don't see a problem for 2 methods

seems doable

[obtuse bone]

Set and get is useless in remote table

Cuz they are replicated onmchange

[sacred rain]

i mean the .New and .FromToken

[sacred rain]

Maybe i don't get something

I haven't seen its api for a long time

[obtuse bone]

Icl you are kinda right

FromToken can be useful if you're not using ssa

But since I am using ssa everything can get the table ref from a module

[sacred rain]

ssa is?

[obtuse bone]

Single script architecture

[sacred rain]

Oh

Yea that'd be too pain in the ass for type checking part

[obtuse bone]

It would be icl

Cuz created tablr is not a class either

I keep everything lua

It's just a metatable interface

[sacred rain]

praying for more deep type checking

[obtuse bone]

That you can edit

[obtuse bone]

Me too bro😭🙏

[shy sage]

Small thing I recommend doing script.parent.EchoComponents instead of game.ReplicatedStorage.EchoComponents because I have echo in one folder called echo

[sacred rain]

I left it up to people for them to structurize however they want like you did here

It will work out of box only if you just parent components and client to rep storage and server module to serverscriptservice or wtv

Completely forgot to send updates here

1.1

• Fixed various errors if player had left mid initial setup.
• Implemented soft clean up after player removed, would cause a critical bug if player’s echo wasn’t manually destroyed by the developer.

1.15

• Made activation more reliable on server side.
• Added new event .Activated on client side, fires upon using :Activate() or :Deactivate() and returns a boolean determining echo’s current “Active” status.

The event is useful in cases when the client receives initial data and developer needs a key from it but doesn’t know if the activation happened and/or was successful.

Example

Client Script 1:

local Echo = require(game.ReplicatedStorage.EchoClient)

Echo:Activate()

Client Script 2: ❌

local Coins = Echo:Get({'Coins'})
print(Coins) --> nil

Coins = Echo:Receive({'Coins'}):Wait() --> Will yield infinitely unless server manually replicates the value after echo activated

Client Script 2: ✅

if not Echo:IsActive() then Echo.Activated:Wait() end

local Coins = Echo:Get({'Coins'}) or Echo:Receive({'Coins'}):Wait()

print(Coins) --> 500

@shy sage make sure u get latest version, ur the only one that acc uses my module 😭

[shy sage]

Yeah I will later

[deft bison]

why should I use this over Replica/Replica Service?

[sacred rain]

data compression using packet, received data cached on client and u can retrieve it at any moment, can detect replications on both server and client

and batching in everything idk if replica does that tho

the only thing echo is worse than replica is in impossibility to create multiple replicators for one player and lack of global replicators, i'll probably add those features in future

[deft bison]

i would like to use this, but since this library seems relatively new and is receiving updates frequently, im worried about things breaking if I use it

[obtuse bone]

replica has to most unmaintainable code, and also you get free quick fixes by the goat roldstred himself

[deft bison]

although having quick and direct communication to the developer is valuable, replica/replica service is popular and has a big community, which means it has been used at the production level, has tutorials and has been battle tested

[sacred rain]

well im using echo for semi popular game

and it doesnt seem to break at all

[sacred rain]

It won't break by itself, you just need to adjust code if needed to the new updates

And I dont think I'll change core methods but only add new ones

[deft bison]

ok, ill be using other libraries for now until there are stable versions, then consider migrating to this one over time

[sacred rain]

Alright

[obtuse bone]

I mean release should be stable honestly

this is such a simple utility

Idk what can go wrong

replica has the most bloated code ever

[sacred rain]

It could've errored in some edge cases at first version

But now it's fully stable imo

[obtuse bone]

That got patched in the next 48 hours max which is fine

Obv you are gonna need some quick patches after release

I had 2 patches right after release with remote table but rn its super stable

[sacred rain]

1.2

• Improved activation reliability yet again, now upon failing activation it will repeatedly try again until success (Infinite yield)

• Replaced :Activate() and :Deactive() with :Start() and :Stop(). Although the older methods will still be valid and act as aliases, It is not recommended to use them anymore

• Renamed :Destroy() client method to :DisconnectAll() as it fits the functionality more

• Added :SendAll() server method. Upon receiving the data table on client and detecting any changes they get separately processed just like any :Send() call

• Added .SentAll signal on server, pretty self explanatory, returns a deep clone of a replicated data table

• Manually cleaning up replicators on server side is not needed anymore

• Fixed edge cases when delayed requests would fire in incorrect order

[wide crystal]

Hey why was the post on Dev Forum unlisted and locked?

[sacred rain]

I took it down

[wide crystal]

What reason

Are you discontinuing Echo?

[sacred rain]

Yeah

[wide crystal]

😭

[sacred rain]

Will probably revive it with portfolio coming out