Not much to explain about this. All it would add are two new value objects named UDim2Value and Vector2Value. I believe after adding this, it would be all of ROBLOX’s supported data types besides table.
Why? I thought value objects were mostly obsolete, except for using them as ‘settings’ that builders who don’t know anything at all about scripting(Which are somewhat rare, most can change a variable in a script) can have something easy to modify, and if that’s the case, UDim2 is completely out of the question, as it should be replaced with terms that are more generic, and NumberValues like ‘GuiWidth’, etc, I can see the case for Vector2, but really, I think Value objects should start to be phased out now that we have Modules…
Weeve, the *Value are used in Official Toolbox Objects, along with the Configuration folder to hold them all.
It’s useful for static read-only data for the client that’s generated by the server. That’s what I use Value objects for. Can’t do that with ModuleScripts, and sending this information over remotes would be too expensive compared to just letting the client load the instances beforehand on join.
1 Like
It’s useful for static read-only data for the client that’s generated by the server. That’s what I use Value objects for. Can’t do that with ModuleScripts, and sending this information over remotes would be too expensive compared to just letting the client load the instances beforehand on join.[/quote]
The client can change a value object as well… And as long as the values in the module are being changed only for the client(FE games work like this), what’s the concern? That data they change will never matter when sending to the server, because the server won’t take bad data, and they can already mess with how the game looks like on their PC, so it won’t stop them to use values, all they have to do is modify the script that reads the values, and use ones they input themselves.
This actually makes zero sense. If there’s any performance difference at all it won’t matter until you have tens of thousands of assets to load, and at that point you’ve got other things to worry about.
That being said I use Value objects a lot to contain settings-type data. I’d like every data type to have an associated value container.
5 Likes
Whether you should use a remote or *Value to transfer data from server to client (not client to server) is mostly personal preference I think.
I’d love to see the line of *Value instances be completed.
It’s useful for static read-only data for the client that’s generated by the server. That’s what I use Value objects for. Can’t do that with ModuleScripts, and sending this information over remotes would be too expensive compared to just letting the client load the instances beforehand on join.[/quote]
The client can change a value object as well… And as long as the values in the module are being changed only for the client(FE games work like this), what’s the concern? That data they change will never matter when sending to the server, because the server won’t take bad data, and they can already mess with how the game looks like on their PC, so it won’t stop them to use values, all they have to do is modify the script that reads the values, and use ones they input themselves.[/quote]The items for example, are fetched from a remote database via the server, so I can’t store the information in a ModuleScript - even if I wanted to. It doesn’t matter if the clients edit it, if they do - it’s only going to change it on their client. It doesn’t affect anyone else (FilteringEnabled), and it doesn’t make any difference to the game itself.
This actually makes zero sense. If there’s any performance difference at all it won’t matter until you have tens of thousands of assets to load, and at that point you’ve got other things to worry about.[/quote]Well, considering I already have 101 items - I don’t see thousands as impossible. This is an RPG.
*Value objects are easier to use than Remotes. M’gosh.
4 Likes
Wait, so if you’re fetching from the server via remotes anyway, why not just store the information in a table? you could even have the information stored in a table in a module, and have the module fetch the information on it’s start, there’s no reason to use values at all in your case, as they are much more expensive than just using a table, and they clutter like crazy
Wait, so if you’re fetching from the server via remotes anyway, why not just store the information in a table? you could even have the information stored in a table in a module, and have the module fetch the information on it’s start, there’s no reason to use values at all in your case, as they are much more expensive than just using a table, and they clutter like crazy[/quote]> remote server
I use an external database. Not ROBLOX. That’s what I was trying to say.
Wait, so if you’re fetching from the server via remotes anyway, why not just store the information in a table? you could even have the information stored in a table in a module, and have the module fetch the information on it’s start, there’s no reason to use values at all in your case, as they are much more expensive than just using a table, and they clutter like crazy[/quote]> remote server
I use an external database. Not ROBLOX. That’s what I was trying to say.[/quote]
Same case still stands, why not store in a table? there’s no reason to use values.
Wait, so if you’re fetching from the server via remotes anyway, why not just store the information in a table? you could even have the information stored in a table in a module, and have the module fetch the information on it’s start, there’s no reason to use values at all in your case, as they are much more expensive than just using a table, and they clutter like crazy[/quote]> remote server
I use an external database. Not ROBLOX. That’s what I was trying to say.[/quote]
Same case still stands, why not store in a table? there’s no reason to use values.[/quote]So what I do currently is, when the server reads the information from the remote URL, it does two things at once - it creates a server-side OOP object and a client-side string value with the data in JSON.
Now, I could just do the OOP object thing, and just that. Have the clients request the server for the data, have the server then have to go through and serialize all the OOP objects into a regular table - send the client the data - then the client has all the data in a table.
Since all the items are number-indexed by Id, what ends up happening when I have a deleted item?
The way ROBLOX’s JSON serializer works, is it will cut off at the point where there’s any missing values.
A good demonstration is this:
local httpService = game:GetService("HttpService");
local testTable = {[1] = 100, [3] = 200};
print(httpService:JSONEncode(testTable));ROBLOX’s remote objects work the same way as this, probably because they internally use JSON to send things over the network.
And this is only talking about items. I have spells as well. Spells include buffs, debuffs, class abilities, passives effects etc. that I would have to send to the clients.
What I do, works. My game has no problems resulting from using this sort of method. This isn’t a small game, and I have thought this all through… especially considering how high of a latency ROBLOX’s servers give me.
Wait, so if you’re fetching from the server via remotes anyway, why not just store the information in a table? you could even have the information stored in a table in a module, and have the module fetch the information on it’s start, there’s no reason to use values at all in your case, as they are much more expensive than just using a table, and they clutter like crazy[/quote]> remote server
I use an external database. Not ROBLOX. That’s what I was trying to say.[/quote]
Same case still stands, why not store in a table? there’s no reason to use values.[/quote]So what I do currently is, when the server reads the information from the remote URL, it does two things at once - it creates a server-side OOP object and a client-side string value with the data in JSON.
Now, I could just do the OOP object thing, and just that. Have the clients request the server for the data, have the server then have to go through and serialize all the OOP objects into a regular table - send the client the data - then the client has all the data in a table.
Since all the items are number-indexed by Id, what ends up happening when I have a deleted item?
The way ROBLOX’s JSON serializer works, is it will cut off at the point where there’s any missing values.
A good demonstration is this:
local httpService = game:GetService("HttpService");
local testTable = {[1] = 100, [3] = 200};
print(httpService:JSONEncode(testTable));ROBLOX’s remote objects work the same way as this, probably because they internally use JSON to send things over the network.
And this is only talking about items. I have spells as well. Spells include buffs, debuffs, class abilities, passives effects etc. that I would have to send to the clients.
What I do, works. My game has no problems resulting from using this sort of method. This isn’t a small game, and I have thought this all through… especially considering how high of a latency ROBLOX’s servers give me.[/quote]
Before sending information over a remote, move all your index keys to be strings with tostring, I do this for Control, and it’s simple because I only push the table over once(When a new player joins/start of a round), so there’s no concerns with it being laggy, and it allows me to have more optimized code where it matters (No long time to index through Roblox’s objects, I can directly access the table of information on the client for what I want)
Indexing through Roblox’s objects does take significant time, and it’s something you should consider when making an efficient and clean system
This would be really useful that when creating a module or a script that you don’t want people to mess with but still want them to configure it as they like, UDim2Value would be really helpful for GUI positioning.
I am currently working on a project that allows the developer to configure the UDim2 to what they like, but I could not find the Instance, It’d make sense to add it since we have Vector3Value…
Oh nice! I’ll add this to our internal review list.
6 Likes
Is there any chance we could possibly input UDim2’s as X,X,Y,Y instead of {X,X}{Y,Y}?
2 Likes