[MUD-Dev] Containing automation?

AR Schleicher ars at nwu.edu
Mon Jul 26 20:00:13 New Zealand Standard Time 1999


At 01:28 PM 7/26/99 -0700, Wayne Pearson <wpearson at verity.com> wrote:
>||  "Koster, Raph" wrote:
>||  > A more advanced form of this mined memory in order to get data the user
>||  > wouldn't normally have, in order to generate a packet using a wedge. For
>||  > example, when you target something, you send back a packet with the 
>id# of
>||  > the object being targeted with the mouse on your screen and the id
of the
>||  > particular targeting you were doing (eg, targeting with a fireball,
>||  > targeting with an arrow, whatever). Players used this to spam the server
>||  > with fireball targeting without actually having received the prompt to
>||  > target first--without mousing over and clicking on them. Essentially a
>||  > quickie hotkey instatarget. A semaphore fixed this, but when you
consider
>||  > the zillions of places where you need to set up semaphores, it's easy 
>to see
>||  > why it was missed.
>||  
>||  How did a semaphore fix that? 
>||  
>||  Do you mean that you returned an ID provided by the server, or do you mean
>||  that you counted the number of received requests, queing of requests or
>||  something else?
>||  
>||  --
>||  Ola

He means they now allow a fireball targeting message to be accepted if and
only if the server as sent a fireball targeting request that hasn't been
answered yet.

>One old, similar bug in UO involved selling items:
>
>When selling items, a packet is sent to the server saying "sell X, Y and Z".
>The server accepted this, since it had provided a list of items to choose
from.
>However, if dozens of these packets were sent rapidly, the server would decide
>that they were all valid, and give you money that it shouldn't, essentially
>selling the same items more than once.
>
>This was likely fixed by raising a semaphore saying "I'm currently processing
>a sale, and until I'm done moving inventory about, I won't process others."
>Once the items are removed from the user, the semaphore is removed, and 
>subsequent faked packets would fail, since X, Y, and Z don't belong to the
>user anymore.
>
>Of course, I'm not a UO developer, but this is the way I can see it working.
>*:^)
>
>I think the idea of 'location' in general has been semaphored in UO;  if
>someone grabs an item, a flag is set so no one else (even someone trying
>at the same time) can grab it.  The second user's client may have thought
>that you grabbed it at first (until the server denied the request due to
>the semaphore).  Unfortunately, it can be overdone, as is the case when
>a user moves his own belongings too quickly;  a semaphore seems to get
>stuck on an item, and reconnecting is the only way to clear this.
>(The "You cannot pick that up" bug, Raph.  *:^) )

Actually, most instances of the "You cannot pick that up" bug I've seen and
heard of have been a result of the server thinking you're still holding an
item, but, for whatever reason, the client does not think it is holding
anything.  Therefore, an attempt to pick something up results in the above
mentioned message.  When you login, if you were holding (with the cursor)
an item when you logged out, it is automatically dropped onto the ground.

AR Schleicher (Jerrith)
ars at nwu.edu (changing over to ars at iag.net soon)



Allison Rae Schleicher IV (AR)     
ars at nwu.edu   | Comp Sci Major   
http://www.nwu.edu/people/~ars     




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev




More information about the MUD-Dev mailing list