AudioDescription datablocks unavailable to AudioProfile
by Sim Ops Studios (#0003) · in Torque Game Engine Advanced · 09/06/2007 (2:40 pm) · 2 replies
Greetings all!
We've run into the bug that appears to be described in this forum post:
http://www.garagegames.com/mg/forums/result.thread.php?qt=16013#121359
Essentially, tracing through the code reveals that sometimes when an AudioProfile datablock is unpacked on a client, the corresponding AudioDescription datablock is not yet available. This isn't a problem on the server; it only happens with remote clients.
Does anyone have a fix for this problem? If no fix is available, is anyone at least aware of a better explanation for the problem? We were under the impression that datablocks were shipped to remote clients in the order they had been declared in the engine (so if I declare the AudioDescription before the AudioProfile that uses it, those components will always resolve in the correct order on all clients, local or remote). Is that not a true assumption regarding how datablocks are transmitted to the clients?
Thank you for your help!
Addendum: Continued analysis with the debugger reveals that sometimes, registerObject is run on the AudioDescription after the AudioProfile has been unpacked. I haven't fully traced the codepath, but it sounds as if objects in a batch of transmitted datablocks get fully unpacked before any of them are registered (as opposed to what I has assumed, unpack-register-unpack-register etc.). Is this understanding correct? If so, it seems that the correct solution is what has been suggested at other points in the forum: remember the ID of the AudioDescription object but don't attempt to retrieve it until the onAdd phase.
We've run into the bug that appears to be described in this forum post:
http://www.garagegames.com/mg/forums/result.thread.php?qt=16013#121359
Essentially, tracing through the code reveals that sometimes when an AudioProfile datablock is unpacked on a client, the corresponding AudioDescription datablock is not yet available. This isn't a problem on the server; it only happens with remote clients.
Does anyone have a fix for this problem? If no fix is available, is anyone at least aware of a better explanation for the problem? We were under the impression that datablocks were shipped to remote clients in the order they had been declared in the engine (so if I declare the AudioDescription before the AudioProfile that uses it, those components will always resolve in the correct order on all clients, local or remote). Is that not a true assumption regarding how datablocks are transmitted to the clients?
Thank you for your help!
Addendum: Continued analysis with the debugger reveals that sometimes, registerObject is run on the AudioDescription after the AudioProfile has been unpacked. I haven't fully traced the codepath, but it sounds as if objects in a batch of transmitted datablocks get fully unpacked before any of them are registered (as opposed to what I has assumed, unpack-register-unpack-register etc.). Is this understanding correct? If so, it seems that the correct solution is what has been suggested at other points in the forum: remember the ID of the AudioDescription object but don't attempt to retrieve it until the onAdd phase.
#2
Adding variables to remember the datablock object IDs in unpackUpdate and then resolving those IDs to object pointers in onAdd (as has been suggested elsewhere) solved the problem of AudioProfiles never being ghosted to clients. We have uncovered another bug---when a sound is playing on a ShapeBase and a new client connects, that sound doesn't start for that client. But I suspect that problem is in ShapeBase's packUpdate and is unrelated to this issue.
Update: The sound-start issue is resolved; that was a mistake on my end. So the method I describe above appears to be a valid solution to the problem.
09/06/2007 (5:29 pm)
This is in TGEA 1.0.1. I'm afraid I don't have a copy of the latest source handy to see if the problem has been fixed. Adding variables to remember the datablock object IDs in unpackUpdate and then resolving those IDs to object pointers in onAdd (as has been suggested elsewhere) solved the problem of AudioProfiles never being ghosted to clients. We have uncovered another bug---when a sound is playing on a ShapeBase and a new client connects, that sound doesn't start for that client. But I suspect that problem is in ShapeBase's packUpdate and is unrelated to this issue.
Update: The sound-start issue is resolved; that was a mistake on my end. So the method I describe above appears to be a valid solution to the problem.
Torque Owner Stefan Lundmark
Or it's possible it never got completely solved.
I don't use the stock TGE audio code so I can't help much, sorry.