DontDestroyOnLoad on TNObject

[ldw-bas]

Hi!

I wanted to make a PlayerData object containing the team and such for the player. I had made this PlayerData an TNObject so all the persistance happens automatically. But I want to set the team in the gamechannellobby scene and keep this information when I load the actual game scene, but unfortunately all TNObjects are unloaded when the level is loaded. So is my method just not the way to go or is it a missing feature?

[ArenMook]

Put a TNObject on the TNManager and give it a non-zero ID. TNManager is persistent. You can also add a child to the TNManager and place your script there (along with TNObject). Either that, or you can simply use the normal DontDestroyOnLoad call to make the object persist. In either case, the point is to have a TNObject with a non-zero ID. You can't create it dynamically.

[ldw-bas]

Ok thank you. I understood the ways to not destoy onload, but it is unfortunate those cannot be created dynamically. Nevertheless your suggested solution with fixed IDs will do I guess since there is always some kind of playerlimit

[ldw-bas]

In the meanwhile I have created the playerdata implementation that is not destroyed when the levels are loaded. Everything is working now but I am not really satisfied with the implementation.

I did the following:
Define a range of id's for my PlayerData.
Have a set of entries using those id's (I generated those before connection so I can easily change the range), this is so the saved RFCs get loaded correctly when joining a channel, creating when in the channel would make lose the save RFC functionality.
Every client has this set of all entries, but the host assigns them to the players. (I feared if every client claimed one for them selfs this could lead to dual claims).
Release entry when a client leaves. (release id for new player, remove existing RFCs)
Reset all entries when you leave the channel.
Resend RFCs when level is loaded so players joining in a new level get the correct data.

What I don't like about this implementation is the management of ids and the resending of RFCs when the level is loaded. Although it doesn't bother me that much it is also not so nice to have a collection of PlayerData entries waiting to be assigned.

I hope my explaination is understandable. I wonder if you have any improvements or comments on this and whether you think this is an uncommon feature or not.

[ArenMook]

If I understand you correctly, you ended up creating a lot of static TNObjects? This isn't needed. One is enough. RFCs that need to stay persistent through scene load should be under that static TNO. If you are trying to set variable size data, do it by sending an array via the RFC call. So instead of doing something like tno.Send("SetPlayerData", Target.OthersSaved, "abcd"); via a single TNO, send the entire array of data for all active players: tno.Send("SetPlayerData", Target.OthersSaved", playerDataArray);

[ldw-bas]

You have understood my correctly about creating alot of static TNObjects. Every player has an object for its own data. If I understand you correctly, every change a player make send the whole array to everyone again. Isn't this going to lead to a lot of traffic. I suspect other issues start occuring as well, for example when two players change soon after eachother. So the one array is not updated when the other is sending it. The change of the first one has disappeared.

Maybe I do not understand you correctly or maybe I am overestimating all those problems that might occur.

[ArenMook]

If stuff will be done frequently, you can always use the one static TNO object to create smaller, non-persistent objects. Re-create them when the scene changes from the data stored on the main TNO.