Minor GUI bug: multiple "cannot access storage" messages for "StoAll"

[Andalan]

Minor GUI bug: multiple "cannot access storage" messages for "StoAll"

 

Component: Client/User Interface

Severity: Trivial

 

When too far away from the storage and pressing the "Sto All" button, the "You cannot access the storage from here!" message appears not only just once, but once for each item that should've been put into the storage.

 

Steps to reproduce:

1. Put two different items into your inventory from the storage.
   
2. Walk away a few steps.
   
3. Press the "Sto All" button.
   

 

Expected results:

One message that the storage is too far away.

 

Actual result:

Two such messages.

 

Reproducibility:

Always.

[LabRat]

Each item is transferred into storage so you can theoretically get 36 messages.

If I put my finger in a plug socket nothing happens while this switch is up.

If I flick the switch and put my finger in I get bitten

Don't walk away from storage.

[LabRat]

Can the message be sent as one of those that get diverted to the inventory window?

 

INVENTORY_ITEM_TEXT

Edited March 12, 2009 by LabRat

[Andalan]

If I put my finger in a plug socket nothing happens while this switch is up.

If I flick the switch and put my finger in I get bitten

Not quite. I stand on the ground, put my fingers in 5 different plugs, turn thw switch on, and get killed five times. Killing me once should've been enough.

 

Sending to the inventory window makes more sense though, since it's nearly guaranteed to be open indeed And the inventory window could send each item only if the previous one didn't result in such a message, much like the "Mix All" button does.

Edited March 12, 2009 by Andalan

[LabRat]

Sending the items one at a time and waiting for failure/success message would be a major pain with anything other than an incredibly good #ping which is why I chose to code it "send all the messages to the server" rather than "send one, await response".

 

At the moment it does unfortunately come down to "don't walk off".

 

Mix all is a completely separate subsystem - the server is sent one packet containing the list of items to mix and the number of times to mix them, and the server does the actual tracking of the quantity mixed so far.

 

The server still sends a "You successfully mixed" message for every success. Close all the windows after clicking mix all to see the spam 55 FEs cause.

[robotbob]

Instead, calc'd the distance from the player to the storage npc prior to StoAll.

 

if (dist > max_dist_to_npc) kinda of thing, this information is available to the client

and there is no reason to spam 36 fails or parse the inbound failing messages.

I know this is possible from creating my killbots, I don't spam attack messages if the

enemy is beyond the allowed melee range.

 

Seriously, "don't walk off" isn't a solution, I'll try that with my clients "the app crashes when

I click this button" Solution: Don't click that button.

 

Edit: (thought) yes, what npc is targeted, I haven't looked at the npc interaction section of the

client but you could just test all the npcs in the actor_list, to see if at least one is within

range. Perhaps give storage npcs a different color name than other npcs, to make this easier.

(really can't recall if they are\are not)

Edited March 12, 2009 by robotbob

[LabRat]

A while back I was talking to Learner (at least I think it was Learner) and he was saying that code was being written to allow any object to be a storage which would make "search for nearest NPC" fail immediately.

 

The easiest option is for that message to be sent as an INVENTORY_ITEM_TEXT message as I posted above. We just have to wait and see whether teh g0d considers it worthwhile.

[robotbob]

(well direct question, mildly off track)

Eh? So every object will have a name, colour byte, and actor information?

I love the idea of a storage as a chest instead of a NPC, but how would

this eliminate being able to search and actor list for a NPC or Bot?

 

"Any object to be a storage" There would have to be some data for the client to know

this... Ok I am totally confused. All ingame objects will function like NPCs?

 

I understand the need to thwart any automated cheater, but this sounds incredibly

ambiguous. Is this something related to Pawn? and the dynamic interactions and events

that was planned (Shelved indef atm?)

[LabRat]

No.. for example a rock. No need for a name or anything else, just like "click on the rock to enter the cave".

The client is basically stateless, it receives a packet and responds to it.

 

If the server says "open a storage window" the client does. The client does not care how it got the message, it just knows the message arrived.

 

You should already know about the statelessness if you are a bot coder.

[robotbob]

"click on the rock to enter the cave"

That is a server messages, from the maps def file, associated with the object ID.

 

So instead of interaction with an NPC that is an actor, you interact with an object

that the server associates its IDs with certain actions. Just like USE_WITH on particular

objects to enter guild maps. Just because the client doesn't send a direct message asking for

particular action and is dependent on the server to send the state, doesn't change the fact that

a particular ID would be identified as a storage.

 

Rock1, Object ID 32, etc that will be a known storage on that map.

Unless the IDs are dynamic, and the storage changes daily, how is this any different

[LabRat]

Because as you already noted players/npcs have IDs. You can have player 500 and object 500, they are not the same.

 

This isn't really achieving anything, I answered the question, I am just sitting back and waiting for g0d

[robotbob]

Last question I just want to get it straight.

 

Your solution is for the spam failed messages to be sent to the inventory window

instead of the client chat? (aka INVENTORY_ITEM_TEXT), instead of avoiding sending

a possible 36 fubar messages to begin with?

[LabRat]

Sure, changing one byte serverside would negate the need to write a workaround.

[LabRat]

I could write it to save every item to be transferred in a list and send the top item on the list to storage and add a hook to either clear the list on "you are too far away" or send the top item on the list if the previous top item gets removed from inventory - way back when I coded the TC client it could do that, making the client stateful.

 

The problem with this is lag. Just like your solution would suffer if you are laggy. I had a guildie today with 22000 ms lag, one click of Sto All and she watches the server store 3 items per minute.

Edited March 12, 2009 by LabRat

[robotbob]

Redirecting the spam, is a workaround.

Checking if a condition is true before you attempt it, is a solution.

 

Don't get me wrong, I love the addition of StoAll, very handy and

should have been day one. I'll never understand how asking Radu to redirect

stoalls spam, to avoid checking a condition is negating a workaround.

 

Well anyway, debate all day, really up to the owner.

(Forgive me if I come across aggressive, personality quirk,in RL I'm a tank too 8D)

 

edit: was typing while you double post, so reply does not apply to the above text.

Edited March 12, 2009 by robotbob

[LabRat]

NP.

 

that's why god invented testicles.