Static TNObject IDs

[danfoo]

Thanks for the replies!

Do I also understand things correctly in that I can use static objects already present in the scene at load *if* the scene is loaded via JoinChannel? I could have 2-3 managers set up in the scene before loading and these will be able to communicate assuming I use JoinChannel to load that scene?

TIA!

[danfoo]

Also, maybe I am being ignorant, but as far as I can tell JoinChannel does not always lead to a level loading asynchronously? If it is not connected, LoadScene is called which uses LoadLevel. If it is connected, it fires off a join request which I cannot readily see what the result of. Maybe that leads to LoadLevelCoroutine being started?

[cmifwdll]

Sorry for the late reply.

Yep, but remember you'll have to remain in that channel for the lifetime of the objects. ArenMook pointed out an issue I overlooked though: TNet 3 more closely manages object lifetime, so to avoid the issues he mentioned you shouldn't use any of the Target.___Saved RFCs. There might be some other issues involved, so consider ArenMook's advice (don't use static objects). Though, I don't think it'll cause any issues if you're just using them for persistent singletons (even with saved RFCs). But ArenMook's strategy of instantiating your managers from the OnJoinChannel notification is just as effective as static TNObjects and you'd be able to use saved RFCs without worry. And, of course, if the dev himself discourages something, then you probably shouldn't start a new project with that thing. Could be phased out in later patches.

You're right, a call to JoinChannel without being connected to a gameserver results in a non-async load level. If connected, the server sends a ResponseLoadLevel (and a bunch of other stuff) which does lead to LoadLevelCoroutine being started.

[danfoo]

Thanks for the reply!

Regarding the RFC._Saved, we currently use it as follows:
1. first player starts server, joins channel x
2. after scene load creates procedural
3.procedural parameters sent with TNO.Send and Target.OthersSaved
4. when another players joins channel x they will receive the calls in #3 and proceed to create the same procedural content as the host

Is this the discourage (the Target.OthersSaved)? If so, what is the proper way to ensure the data is saved and available for reuse by joining players...?

TIA!

[cmifwdll]

No, that's the intended usage of saved RFCs. It's just that ArenMook discourages static TNObjects because TNet 3 has no way of knowing when a static TNObject is destroyed, so the saved RFCs will always remain in the channel even if the object it belongs to is destroyed. This could lead to inconsistent behaviour if for some reason one of your client's static TNObject is destroyed. But like I said in the previous post, if you're just using static TNObjects for persistent singleton managers I don't think you'll run into any issues.

[danfoo]

Again, thank you!
Understand the caveats and agree that this particular implementation will probably not run into problems. Will let you know if it does.

Again, thank you for your patience and help!