In a project im working on I need to have a table that can be modified by the server, then have those modifications viewed by the client, what would be the best way to go about this? Id prefer to avoid using folders and values except as a last resort.
2 Likes
You can do the table creation, modification, or anything with a server script. And then you can do the viewing with a local script, that seems to be a good way to me.
1 Like
Yes, however the client won’t be able to view a table inside a script stored on the server?
Well, you can use folders, it’s a much simpler way.
But, as for simplicity, the most simple solution other than this is to use remotefunctions, which basically the client fires to the server if they want to get the table and the server returns the table to the client. The layout would be something like this:
--// Local Script //
local Table = RemoteFunction:InvokeServer()
print(Table.Foo) -- prints "Foo"
--// Server Script //
local Table = {Foo = "Foo")
function RemoteFunction.OnServerInvoke()
return Table
end
2 Likes
You can make clients (using local script) communicate with the server (server script) by using RemoveEvent.
Im dealing with tables on quite a large scale so I rlly want to avoid folders at all costs, also remote functions would eventually crash the server since the table would most likely be updating every second at the very least.
My use case is a mining system where only the position of blocks is stored on server, then rendered on the client, so I only render blocks the client can actually see
1 Like
Maybe to counteract that, you can fire the remote function less. Maybe once every 5 seconds, and on the client, you can have a copy of the table, just in case the server fails to send the info. In addition, client can also try doing predictions on what will happen to the table.
Now that the context is edited in, maybe you can render a larger chunk of the blocks so you don’t have to update it that often. So instead of rendering a block around the player, maybe 5 or more. I don’t really get the context, maybe a bit more explaining can help.
The problem with it updating every 5 seconds in comparison to real time is if two players are standing on a block, and one player mines it there is a large enough window for the other player to fall into void due to the client not being told to render blocks around the destroyed position, same problem if you keep a table stored on the client, this update has to be in real time. Predicting could work, however predicting what another player is going to do 5 seconds before they do it feels impossible to me.
So its a classic mining game, when you mine blocks generate around the destroyed point to give it that ‘infinite’ mining feel, however since I want a system where the mine does not need to reload im simply storing the position of the blocks on the server then rendering them in a ‘bubble’ around each player so only 1000 blocks can be spawned in at once.
So, let me just get this straight. You are making a mining game, that you can mine blocks using pickaxe and basically you keep mining downwards and there are different types of blocks that you can mine. Is that right?
To a degree, yes. But im also having a competition of who can make the most effieicnt system so ever feature mentioned is necessary.
Now that I have more context, instead or using any remote events or functions at all, why not just load it all onto the server, and just render it all on the client? What I’m saying is that any blocks that are not in the viewport of the player will not get rendered, kind of like streaming enabled. There really isn’t a need for a table, because if the block got destroyed by the server, why would you have to render it anyway.
Instead of using these table thing, couldn’t just try other ways? Maybe you can render all the block in the mine in the server side, but limit the blocks player can see, for example up to 10 blocks to bottom (and then you update every 5 seconds).
Because if I were to load all the blocks into the server and there were say 100,000 blocks all with textures on I feel that would have some major performance implications, this system isn’t for a game as I said, its an efficiency contest so I really need to overkill with only loading in what NEEDS to be loaded.
What you can do is setup a table on the serverside, hook it up with a metatable through a proxy, and then each time that table’s values are changed you can hook it up to a RemoteEvent to send that table to the client.
To edit the table from the clientside you would just use a RemoteEvent to the server, do sanity checks and then edit the table, and if you setup your table correctly the table would have changed on the clientside.
If I were to add 5 values to the table say 4 times a second thats 20 remote calls / second which I feel is impractical given my use case.
You’re probably better of just using remotes then altering values on the server, and on request (through remote events or remote functions again) send back the value, remote functions would be more convenient here.
You can queue up remote calls then, if you really wish to. Realistically speaking there’s no real other efficient way (that I can think of) to do this, you could try using Instances but that would just be a headache.
The problem with that is roblox module scripts are really misleading, what looks like one module script in the explorer is actually 2, one exists on the client the other on the server, so if I were to update the module on the server, the only way I could get the data onto the client is through remote events.
I also only need the server to modify the module, the client only has to read it
1 Like
If you update a module script on the server, the changes are not replicated to the client
I have tried re-requiring it ever time I run the check however its still yielding the same result where the server and client’s versions of the module are completely out of sync. Modules contents are not replicated across the server-client boundary