   What's the object/concept I want for this?
  Supposing I am doing a multiplayer online RPG.The player clicks an object, which sends a coded message to the server, that fires off the "OnUse" event for the item.  Now, this works all well and fine for me if that function requires no furth input.However...Suppose the function has a line (or lines) that requires more input from the player.  Say, GetTarget() if it's a spell or GetText() if naming an item.  Obviously, the thread running the function has to stall untgil it receives some sort of event.void OnCastFireball (Player){  if (Player.Mana > 20)  {    var Target = Engine.RequestTarget(Player);    if (Target != null)    { Target.Health--;    }  }}Engine.RequestTarget() has to pretty much stall until the Engine gets either a target message or a cancel message from the player's Socket.  As I understand AsyncCallbacks for Send/Receive, that might be what I want.  I'm not terribly sure how to make my own though.Or would it just be negligible to have that function just loop until the Socket's incoming queue turns up what it wants?  Seems like managing simultaneous threads gets harder and harder.  Do threads associated with an object automatically terminate when you kill the object?   
  I sugest you reform your system a bit.Give the client enough information about the world that it can figure out all the infomation before telling the server anything.Client clicks a spell, clicks a target.Client sends server "cast fireball on goblin#17"Server recieves the message. It checks that the target is valid(can be seen, in range, player has enough mana).It checks that the player even knows the spell, and that the spell is ready to cast.Server then responds by casting the spell, or sending the player back an error message(Target invalid, out of range, not enough mana).The server should not have to ever wait on clients. If a client does not send enough information to the server, it should drop the request.AND, when the server recieves information from the client, it should assume that the client could have spoofed information,and should therefore confirm that the request is valid.   ;  About the server waiting for the client, I have seen this before with the POL engine.  Unfortunately, they are extremely protective about their source.  Simply asking how is like stealing their code and grounds for excommunication.  So ultimately I was going on the assumption that the scripting language's (which I used extensively) flow translated literally.My problem with refactoring that design is that I wanted to keep all the system computation (and therefore 99% of the updates) on the server end.  If every new spell or item requires client code, well, that defeats the purpose.  Because, supposing there has to be a {Int16 spell, Mobile target} message for spells, every single time you need another input there has to be a new message type.Making a sword?   {Item hammer, Item ingots}Making a leather tunic?  {Item scissors, Item hides, Item thread}Making posioning explosion potion?  {Item mortarpestle, Item sulphur, Item volcanicash, Item nightshade}And so on and so on.  Because you have to do everything on both sides, it makes a dynamic number of targets hard.And what about the case where there's a chance, not certainty, of requiring more input?  I once played on a server where a high level smith had a 5% chance of being able to name a mastercrafted item.  Under the "predetermine all your input" system you have 2 choices (well, technically a 3rd of extreme simplification of everything in the world to 1-way interactions):1.  Split the 2 functions.You get a message saying you can name the item.  Now you have to go out of the way and run .cmd_nameitem() or something.   Of course, you don't know which item to run it on.  The server either sends a boolean (renamable) about every item in range of you or you click several (sending packets and recieving denials) until you find the one that works.Or you ask and ignore.  That would probably irritate people on the 95% of attempts they aren't ending up with mastercrafted items.  Heck, if the ability only opened up at level 9 of 10, you're bothering them 100% of the time for the first 9 levels.  Unless you want a deterent for people advancing crafter characters (for economic reasons, perhaps), this'd be a serious problem.Whereas with a waiting script, you'd already know what item and only get asked for extra info when you succeeded.2.  Trust the client.You could always trust the client to run it's own random number generator and determine whether it's named and thus send either {Item sword, String coolname} or {Item sword} depending on that.  Then you run the risk, however small, of a modified client running a function that sends the first message every time.And you have the joy of updating the client every single time you balance.  That means another download, another minor hassle, another possibly lost player.  Sure, you can force someone to use the updated client...until they figure out your logon handshake and spoof it.I think I'll keep looking for a way to block a thread on server initiated requests :)   ;  Taking the 5% mastercraft chance possibility example:The basic problem is that of differing contexts. 95% of the time you end up with:[Object Type]5% of the time, you end up with:[Object Type][Object Name]There are a few ways to approach this:1) Everything up front. The user attempts to name the object in the hopes of naming it that.Pros: simple.Cons: wasteful in data sent and user time (why bother naming it if it isn't mastercrafted?)2) Transitional object stages. The user creates the object - and he ends up with either an "Plain Old [Type]" or a "Un-named mastercraft [Type]". Another forging "stage" which can only be applied to such "Un-named mastercrafts" is then implemented (automatically triggered?) such that "Un-named mastercraft [Type]" can be transformed into "[Name]'s mastercraft [Type]" - similar to how, say, "5x iron" can be transformed into "Plain Old/Un-named mastercraft [Type]".Pros: each stage is finite and has all the inputs up front ("forge type", "name mastercraft as ____").Cons: more complex, must take into account partially-completed transactions.3) Player-tied Finite State Machine. Basically, on the server side, the player's state enters either "normal" (render the world and whatnot) or "name item" (name a mastercraft item). The server side stores the namee-target, or the stats of the item not quite yet crafted. In the case of the mastercraft item, once the player sends the naming message, the server will then create the object and transfer to the "normal" state.Pros: maybe simpler, forces the user to name his object before being able to do anything else.Cons: forces the user to name his object before anything else, possibly/probably just as complex as #2.Basically, in both 2 and 3, the idea is to say "OK, let me know when you've decided to name it" and go on doing other stuff instead of going "OK, I'll wait until you send me the name".[Edited by - MaulingMonkey on December 12, 2005 8:08:54 AM];  http://www.csharphelp.com/archives2/archive409.htmlAccording to this article, I should be able to do this:void function ThrowFireball (Player){  var Target = Engine.GetTarget(Player);  if (Target != null)  {    Tagret.HP--;  }}Mobile function Engine.GetTarget (Player){  ManualResetEvent Staller = new ManualResetEvent();  Player.EnqueueRequest(Staller);  Player.Send(new TargetRequestPacket());  Staller.WaitOne();  return this.somepropertysetbythesockethread;}void function OnReceivedFullPacket (Packet){  switch (Packet.Type)  {    case Enumerated.TARGET:    {  Engine.Players[Packet.Serial].DequeueRequest().OverriddenSet(Packet.Target);    }  }}Can't wait to try this at home...   