Hey, so I had this remote funcction that would get the status of an event in my game and I’d invoke the server and I would feel noticable delay in a real game since, I did something with the UI after, but I changed it to be a boolvalue on the server that I would just read from the client and then do what I needed and it felt alot snappier
2 Likes
When it comes to reading data I would personally use Attributes. I’m not exactly sure what sort of data you’re storing other than the BoolValue which you mentioned. In this case, using a RemoteFunction to retrieve a boolean is not ideal and as you stated as well, suboptimal.
If you’re already using the BoolValue object to retrieve your data then go for it. But I’d take a look into attributes as they take up less space, and might even be faster, though I have no proof of that.
As for the speed between retrievals; it really just depends on the client(s) latency. You’ll encounter latency regardless of how you transmit data. But different methods will certainly have different speeds. I’m unfortunately unable to conduct sufficient material to tell you which would be the ideal “data reading method”.
If you’re looking for the absolute fastest method, I encourage you to test out the speeds of different methods. But once again, from a personal stand point, suggest using attributes. They’re even able to support different types ranging from Rects to NumberSequences or even Fonts.
1 Like
With this in mind, I was possibly thinking about maybe loading my clients data into string values and JSON encoding them, and then on the client using JSON Decode to maybe turn those strings back into lua table, so I wouldn’t have to invoke the server at all, but I feel like this probably wouldnt be worth all the effort
1 Like
That’s quite overkill considering you only want to send a bit of data to the client. If you’re going to those lengths, you might as well store “states” in a table. Sort of like this:
export type table = any
local reads: table = {
[1] = "Hello, the current round state is ...",
} :: table
return reads :: table
With sending data in mind, you’d send the index of the string you want to reference. Once the client receives the single number, it will look in the already required table and collect the string from there. I’m obviously just basing this ideology off the top of my head and it probably won’t do anything. I don’t think it’s worth trying, because again, you’re only sending a little bit of text.
As you’ve already stated, it probably won’t be worth the effort for merely sending some bytes. I suggest just sticking to your original method of BoolValues or Attributes.
1 Like
Oh I see what your saying no buy I was talking about like storing a whole players inventory into like a folder in like lets say replicated storage and it’s a string value and then I JSONEncode that loaded data into the String Value and then everytime I update something regarding the player’s inventory i’ll also update the String Value and then when I want information on the client instead of invoking the server, I just can go to the place where my player’s data is in replicated storage, JSONDeocde that data and then get the data I need, yeah it does kind of seem like overkill even with doing it with a whole inventory system but the thing is, I want my players interacting with UI and the game to feel as fast as possible, I’m just really trying to get that user experience down if you get what I mean
1 Like
Well if you’re talking about transmitting a player’s inventory, that’s where it sort of gets tricky. If you’re using datastores, you’re obviously obeying the UTF8 characters. Heading back to attributes, they’re allowed to store a plethora of types as I’ve mentioned before. With this in mind, you could create a player folder as such:
And then give attributes to that folder. Which would look a little something like this:
This is much easier to read and operate than the JSON En/De method, but apart from just reading and operating, it’s really easy to retrieve on the client:
local dataFolder: Folder = replicatedStorage:WaitForChild("DATA:" .. player.UserId, 100)
print(dataFolder:GetAttribute("Coins"))
Which I personally think is a big plus!
2 Likes
Yeah but what if I have an inventory with different items and like they have different values , im guessing attributes dont support tables I mean yeah attributes seems awesome but if they dont support table I just cant see myself using them
1 Like
Storing tables as well; I see. I suppose a RemoteFunction or RemoteEvent could be used. I unfortunately can’t help you any further than here. I mean, _G exists but the client can see it which might lead to some vulnerabilities.
1 Like