Game Development Community

Complicated Reload System

by Chris Byars · in Torque Game Engine · 04/21/2006 (9:18 am) · 28 replies

Yes, this system is complicated, but it's quite powerful for what I need it for, so no bad comments on how it's done overall. :P I have a problem with it. An odd problem. Basically how it works is a player presses R, which sends a command to the server activating a reload command:

function serverCmdWeaponReload(%client)
{
   %currentWeapon = %client.player.getMountedImage($WeaponSlot);
   %currentWeapon.ReloadAmmoClip(%client.player);
}

Which in turn, for whichever weapon you have on you, checks a bunch of things making sure its safe to reload and then does it to that weapon using %obj.manualSetImageState. (edited out huge code block, unnecessary)
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine
Page«First 1 2 Next»

Torque Owner Chris Byars
Ion Productions
#21
04/22/2006 (7:15 pm)
When a client joins, the server player has no issues whatsoever setting the image state manually. Once a client enters the game, the server player's manual image state change ability ceases, however all clients are able to manually change image states. Once all clients leave the game, the server player regains their ability to manually set the image state.

Edit: Nevermind, you edited your post. Above is a deeper explanation.

Associate Manoel Neto
Default Studio Name
#22
04/22/2006 (7:30 pm)
Damn, I feel naked without a TGE working copy nearby... but lemme try it.

I think I see what the problem is... the way the code is written, looks like only one client will see the state change, due to this:

PackUpdate:
if(stream->writeFlag(image.changeState))
   stream->write(image.manualChangeState);

if (image.changeState) 
{
   setImageState(i, image.manualChangeState, true);	
   [b]image.changeState = false;[/b]
}

I am not sure, but I think packUpdate is called for every client that has that object scoped. If that's the case, setting changeState to false during a packUpdate would make it only transmit once. To fix that, the resource code would need to change a bit... the problem is, it isn't quite simple. Every way I think of to fix it leads to dead locks. I'll have to look into it at work, I'm also interested on this issue.

Torque Owner Chris Byars
Ion Productions
#23
04/22/2006 (7:34 pm)
I really appreciate your help.

Torque Owner Josh Moore
#24
05/02/2006 (7:01 pm)
Wow. I can't believe I didn't realise what I was doing with the networking when I wrote that. Thanks for pointing this out, I'm going to make a fix for this so it actualy works. Sorry to all that are using that resource, I'll post here once I get it working.

Torque Owner Chris Byars
Ion Productions
#25
05/02/2006 (7:28 pm)
Hey, thanks. :)

Torque Owner Josh Moore
#26
05/02/2006 (9:44 pm)
Ok, fixed the bug and made the whole thing alot cleaner (IMO). It now uses a NetEvent class to send the state change command to all clients that have the shapeBase in scope. I also changed the console method name to match the shapeBase function. TDN article updated as well.

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9141

Torque Owner Chris Byars
Ion Productions
#27
05/03/2006 (7:05 pm)
Errors, check resource.

Torque Owner Josh Moore
#28
05/03/2006 (8:58 pm)
I am using 1.4 and those are completely valid in my codebase.

After a quick look at the source, it looks like using write/read cussedU32 is actualy heavier on the network then using a normal method. I changed it to use rangedU32 instead.
Page«First 1 2 Next»