This is not a bug and is expected behavior, but seems that you can improve some things, here are some details that can be useful for you:
1- Notepad (or any other raw text file encoding) is not Memory Allocation. It does not behave in the same way as a functional programming language. Instead, it allocates directly to the computer storage.
Due to that, size comparisons like what you mentioned are not accurate at all, such as this example:
- Storing
0.0 on notepad will be 24 bits, where each “char” is stored as 8 bytes each
- Storing the same
0.0 on verse as float, will be 64 bits (Check here for details).
The same applies for every other types and occasions around verse.
2- Verse provides functions to check if a player persistable data will fit or not before saving (FitsInPlayerMap[]), it is the developers job to account for that and prevent errors, and handle edge scenarios if does not, preventing crashes or other logic failing on the experience (See this for reference)
3- The error can’t be showed for a single player like you suggested, because even if you are saving the persistable data for one player only, there is no way to know how that piece of the code is dependent or may affect other places of your experience, such as that data being needed on other parts of the code before and after trying to save. What is failing is not something related to a specific player, but the main gameplay logic loop/flow, and that’s why it shows to everyone and not only the affected player.
4- Persistable data has 128kb, and sincerely, that’s a lot of data for the current state of available UEFN features. It means that probably your code can be improved a lot if you choice to study a little about that topic, on how data management works, better ways to avoid duplicated/uneeded values, data storage layouts and so on…
5- It is also worth mentioning that due to how your map works (according to how it looks on your video), you are probably using maps or arrays on persistable data, and it is important to know how and when to clear the persistable data to remove “junk” data that is not needed anymore.
Other important points is to consider when is needed to save the data, for example, saving it every tick or on every/each prop change (idk if is the case), is very performance expensive and unoptimized (and worse if it generates junk data), also can escalates up too quickly when not handled with care.
