Both of the sliders are overriding each other’s data, so try saving it like this:
local data = {
["Fov"] = 50;
["InGameMusic"] = 0;
}
1 Like
Oh? Mind if you elaborate please? I’m not fully aware of how tables and data stores relate. I’ll also do my research on Roblox’s documentation.
Wait, how come they’re overriding eachother? They’re separated by IAGData and FOVData 
Each datastore key (you use the player’s user ID as the key) is set to 2 values. How datastore works is basically, each key is set to a value, and when you try to get the data for that key, it returns the value.
Adding on to what others have mentioned, despite the fact that you mentioned this being a single-player game at the moment, it is still a good idea to leave your OnServerEvent event listeners outside of a recurring event (or generally any event function) such as PlayerAdded.
What you’re doing is a new event connection is being made each time a player joins, this can stack issues quickly such as the function being executed multiple times, memory leaks, etc. Hence it is usually best practice to leave such connections outside to prevent them being re-connected in such uncontrolled manner.
2 Likes
So lets say, for example, the players user is 700, your script will save 700 as the fov value of 50 and then override the value of 700 with the in game value of 0, thus making the fov value equal to 0.
1 Like
Also, I just realized he put the loading function as the saving function.
Wait, I just realized you made separate data stores for each of the values.
1 Like
Hmm, in that case, how do you think I should change this then? I can’t think of any other way, and honestly I wasn’t even aware that it’s prone to such things so thank you for informing me!
Specifically, seperate scopes. Not sure if that’s a massive difference.
Oh, I would honestly recommend, to save on datastores, to just save the values under one datasave, as a table. As mentioned above.
This would also save on time spent saving as it doesn’t have to do the same thing twice basically.
Okay! So, generally it’s more optimized, correct?
If that’s the case, I’ll work on that too. Though I’ll update tomorrow since it’s getting really late…
1 Like
I understand, no worries. Just to give you an overview on this, let’s say for an example that you have your OnServerEvent() function inside of an indefinitely recurring event such as PlayerAdded().
To simulate this example, I’m using a Changed() event of a BoolValue (parented to the script) that fires whenever it’s Value property is changed. Now to simulate a total of 10 players joining your game, I have a for loop that runs 10 times (from 1 - 10), and on each iteration, I’m reconnecting said Changed() event function.
Below code represents this simulation:
local BoolValue = script.BoolValue -- A BoolValue Object parented to this script.
BoolValue.Value = false -- Initializing with its default value of 'false'.
task.wait(3)
for i = 1, 10 do -- Simulating a total of 10 players joining (PlayerAdded() event firing 10 times)
BoolValue.Changed:Connect(function(newValue) -- A new :Connect-ion is made 10 times.
print("Event fired.") -- Function's code contents now execute 10 times in a row, simultaneously.
end)
end
BoolValue.Value = true -- Changing it's value in order to fire its .Changed() event.
The result of this is the event being fired a total of 10 times despite the BoolValue.Value changing only once due to 10 newly connected functions running in parallel executing the same code, but as many times as they were connected to the event.
This closely resembles your code as this is exactly what you’re doing by having your OnServerEvent() event function inside of your PlayerAdded() function. This means you’ll already begin to run into issues as soon as even if one more player (other than yourself) joins. Now the effect of this depends upon what the function itself is doing, but it stacks, taking up more and more memory of redundant code doing the same thing over and over and over.
To prevent this, its best to simplly not have any event function inside of another event function. Event function connections need to be made only once, and hence its best to have them in a part of your code that you know will run only once.
In your case, to rectify this, you can simply pull both of your OnServerEvent() listeners outside of the PlayerAdded event and simply correctly re-reference any required dependencies (in your case, the player’s leaderstats, and the respective IntValue Instance).
Something along the lines of:
FOVREMOTE.OnServerEvent:Connect(function(Player, newFOV)
local leaderstats = Player:FindFirstChild("leaderstats")
local FOV = leaderstats:FindFirstChild("FOV_VALUE")
if leaderstats and FOV then
FOV.Value = newFOV
end
end)
IGMREMOTE.OnServerEvent:Connect(function(Player, newIGM)
local leaderstats = Player:FindFirstChild("leaderstats")
local IGM = leaderstats:FindFirstChild("IGM_VALUE")
if leaderstats and IGM then
IGM.Value = newIGM
end
end)
The overall code’s behavior will not change at all by this, but it is simply more efficient now.
Since you mentioned you weren’t aware that your code was prone to such issues, I thought a detailed explanation would be helpful to you (or anyone reading) for future reference or as a general good coding practice.
1 Like
if the problem is the data is saving correctly just not saving and its in teamtest for some people dont you have to add a boolvalue in serverstorage named “SaveInStudio”?
1 Like
more efficient by using 2 different remotes for doing pretty much the same thing? lol also OP consider using profileservice
1 Like
More efficient by patching potential memory leaks. The response was keeping OP’s original method in mind so minimal code changes are required. Ofcourse you can list an array of different methods for increased efficiency but my post was keeping in mind the original code’s integrity, and about recursive :Connect() behavior, not about remote optimization.
1 Like
I feel like it would be better for @althruist to learn Datastores beforehand because, as he stated, he is quite new to them. While, sure it would be a lot easier to use a module for this, It would probably be more beneficial for them to hold off on using profile service for now and at least try and make their own datastore system. If only just for the learning experience.
1 Like
Hi! Not necessarily, at least from what I know of. Adding a boolvalue in serverstorage shouldn’t modify anything related to the game, it’s simply a boolvalue inside serverstorage, nothing else. Though, that could be a property of the game (at least I think)
Though, to inform you, the data store does save globally, whether be Studio or the actual client.
Though, thank you for the time to reply! 
1 Like
Hi!
Thanks for the time to reply.
Your suggestion probably makes a lot of sense, though to be transparent with you, I have NO idea what profileservice is. Yes, funny how I have been here for 6 years and I don’t know what it is.
Though, I’ll definitely do my research about it! At the moment, I’m currently going all Indie, and I definitely need my time to learn such things.
Rest assure I’ll check it out, though I don’t think I’ll be planning to use it for this project until I master it anytime soon.
Thank you for the suggestion though!