Server->Client Resource downloading is in!
by Mark Frohnmayer · in Torque Game Engine · 04/03/2002 (5:22 pm) · 28 replies
Hey all,
Just finished up the checkin on version 2 of the resource downloading code, which now works with datablocks. So models, textures, interiors, terrains, sounds, etc... can all be downloaded from the server if they are missing on the client.
Details of the process:
When ghost always objects or datablocks are received, they are queued on a vector in the NetConnection. If they add properly, they are popped off the queue and processing continues. If they fail to add, or in the case of datablocks if they fail to preload, the list of resources that the object tried to load is sent to the server, which will download any missing ones to the client. The client then tries to reload the object. If it fails again, any new resources it requested are downloaded from the server.
If the server is unable to download any resources to the client and the client object still fails to add, then the connection terminates like before with the appropriate error message.
I also bumped the net protocol, since the new code is incompatible with the previous net version.
If anyone out there wants to hammer on this, go for it...
Just finished up the checkin on version 2 of the resource downloading code, which now works with datablocks. So models, textures, interiors, terrains, sounds, etc... can all be downloaded from the server if they are missing on the client.
Details of the process:
When ghost always objects or datablocks are received, they are queued on a vector in the NetConnection. If they add properly, they are popped off the queue and processing continues. If they fail to add, or in the case of datablocks if they fail to preload, the list of resources that the object tried to load is sent to the server, which will download any missing ones to the client. The client then tries to reload the object. If it fails again, any new resources it requested are downloaded from the server.
If the server is unable to download any resources to the client and the client object still fails to add, then the connection terminates like before with the appropriate error message.
I also bumped the net protocol, since the new code is incompatible with the previous net version.
If anyone out there wants to hammer on this, go for it...
About the author
#22
boy, am I GOOD, or what! ;)
unfortunately, clearing the fields just seems to be hiding something, imho. callbacks are still getting made constantly, just that some global is now null and thus it exits a bit earlier.
d
04/11/2002 (8:20 pm)
so fixing the Mac fixed everyone else's problems too??boy, am I GOOD, or what! ;)
unfortunately, clearing the fields just seems to be hiding something, imho. callbacks are still getting made constantly, just that some global is now null and thus it exits a bit earlier.
d
#23
04/11/2002 (10:33 pm)
David, what callbacks do you mean?
#24
Who knew Mac programmers could solve windows bugs :)
04/12/2002 (4:41 am)
Yeah, David, that and some things Tim checked in (according to the CVS log) seem to have made my issues vanish.Who knew Mac programmers could solve windows bugs :)
#25
There is some handler/callback for processing datafile packets. In netconn or the other new file. It had a few lines at the start of the func, then checked the 'curr datafile ptr' -- which was garbage until I nulled it to start -- and did some work if not null. Some kind of data packet is getting generated for file-management, even though there is no file to be managed. Yeah yeah, that made no sense. :)
Some packet handler function gets called a bunch of times during the level load/startup, despite the fact that there's nothing to sync -- that is, there is no current-file-ptr, and thus calling the handler would seem to be a noop. More than that, I would guess the code shouldn't have gotten to the point it would call the handler.
But, I'm just throwing darts -- don't have the code right here, and even when I had it in front of me the most I could figure out was a function was thinking there was a file to be processed, and it then started trying to read buffers, with negative (or huge) read lengths, due to the uninited vars.
If I have time to poke around, will try to find the fn.
d
04/12/2002 (5:30 pm)
I'm not at home, so I'm responding from memory.. ;)There is some handler/callback for processing datafile packets. In netconn or the other new file. It had a few lines at the start of the func, then checked the 'curr datafile ptr' -- which was garbage until I nulled it to start -- and did some work if not null. Some kind of data packet is getting generated for file-management, even though there is no file to be managed. Yeah yeah, that made no sense. :)
Some packet handler function gets called a bunch of times during the level load/startup, despite the fact that there's nothing to sync -- that is, there is no current-file-ptr, and thus calling the handler would seem to be a noop. More than that, I would guess the code shouldn't have gotten to the point it would call the handler.
But, I'm just throwing darts -- don't have the code right here, and even when I had it in front of me the most I could figure out was a function was thinking there was a file to be processed, and it then started trying to read buffers, with negative (or huge) read lengths, due to the uninited vars.
If I have time to poke around, will try to find the fn.
d
#26
Oh, this sucker works alright ! Hehe.
I deleted the entire 'data' directory tree on the client, then joined the server, which was starting out with WaterWorld. After 30 minutes, I noticed that the server was reseting the mission ! Eeek!!
The client seemed happy, though, so I let it go. 10 minutes later (After 40 minutes of downloading), The client was able to join the mission - in the Test Mission (the one with all the 'F' textures) !!
The client never missed a beat, the server automatically resumed when it cycled to the next mission, and the client got everything it needed for the new mission.
Cool. Good job Mark !
04/13/2002 (8:52 am)
Test update:Oh, this sucker works alright ! Hehe.
I deleted the entire 'data' directory tree on the client, then joined the server, which was starting out with WaterWorld. After 30 minutes, I noticed that the server was reseting the mission ! Eeek!!
The client seemed happy, though, so I let it go. 10 minutes later (After 40 minutes of downloading), The client was able to join the mission - in the Test Mission (the one with all the 'F' textures) !!
The client never missed a beat, the server automatically resumed when it cycled to the next mission, and the client got everything it needed for the new mission.
Cool. Good job Mark !
#27
mCurrentDownloadingFile->read(len, buffer);
... where len was some really large garbage value, and buffer is a local array, AND I think mCurrentDownloadingFile was bogus as well, but it'd proceed along blindly trying to do a read and would blow up. At least, looking at the fn, and remembering the fix I did weeks back, that's my best guess. Hope that helps.
I was guessing that sendFileChunk wasn't supposed to really be getting called in the first place...
d
04/13/2002 (1:49 pm)
don't quote me on this (heh), but I think the issue I was seeing was that NetConnection::sendFileChunk() was getting called repeatedly, but all the mCurrentZzzzzz variables were garbage. Thus, it would eventually hit the line:mCurrentDownloadingFile->read(len, buffer);
... where len was some really large garbage value, and buffer is a local array, AND I think mCurrentDownloadingFile was bogus as well, but it'd proceed along blindly trying to do a read and would blow up. At least, looking at the fn, and remembering the fix I did weeks back, that's my best guess. Hope that helps.
I was guessing that sendFileChunk wasn't supposed to really be getting called in the first place...
d
#28
08/27/2002 (12:17 pm)
So, Is this code currently working at 100% or is it still considered buggy?
Torque Owner Edward Gardner