Need some testing on the test server

[Entropy]

I changed the way the bags are sent to the clients (now they are sent only when you are nearby), and since it's a pretty big change, we need to test it.

 

How to test it:

Split in teams of 3 to 5 people, each team preferably on a different map/area.

 

The objective is for one player to put/remove a bag and for the other people in the team to walk around, back and forth, and communicate with eachother to make sure everyone sees (or doesn't see) a bag. So one player should be stationary, and have/don't have the bag at their feet. The others should also exit and re-enter the map constantly, and check for any problems with the bags. Also try logging in and out and stuff like that.

 

If you find a problem, let me know.

[Entropy]

Ok, let's test again now, but with some twist; ONLY people with the CVS client compiled no more than 2 weeks ago can come. The reason for this is that a client bug existing in the client that comes with the download and older CVSes will sometime send a wrong bag ID.

 

It is really important to test the bags, because the next server update will use this new bag mechanism, and we don't want problems with the bags, now do we?

 

So if you have a new CVS client and find a bug, please post here.

[Entropy]

I added some new debug stuff, so there are now two commands on the test server:

1. #debug_on (gives the ID of the bag you want to pick, as well as telling you if it is a remote bag or right under your feet). Typing it again will disable the debug mode.

 

2. #bag_debug (gives the information about the bag you have open and the bag you have at your feet. Ideally, they should be the same, if not post here. This command should be used only if you can't pick stuff from a bag).

 

Again, you should only go on the test server with a new CVS client, not the 'stock' client that comes with the game.

[Espresso_Boy]

Using three day old CVS on the test server, I have two players in DP insides. Annraoi is at the second floor of Elandria's Temple, and Slacker is in the Cactus Blossom General Store. These are roughly opposite ends of the map. If this isn't far enough apart, then just skip this post.

 

Just sitting:

Annraoi at 152,175 drops bag id 0 and picks it up. Slacker at 50,43 recieves GET_NEW_BAG for 152,175 id 0, and then DESTROY_BAG id 0.

 

Logging in:

Annraoi logs off. Slacker drops bag id 0 at 50,43. Annraoi logs on and recieves GET_BAGS_LIST with a bag at 50,43 id 0.

 

Changing maps:

Slacker leaves. Annraoi drops bag id 0 at 152,175. Slacker returns and recieves GET_BAGS_LIST with a bag at 152,175 id 0. Once again Annraoi picks up the bag, and Slacker recieves DESTROY_BAG id 0.

 

I hope this is the kind of testing you were looking for, and that I was of some help.

[Entropy]

Yes, thanks, but I reverted the test server back to the 'standard' way of sending the bags for the time being, to detect another bug.

This bug has been detected, and Learner will commit the fix in the client CVS tomorrow, then I will announce when we resume the testing again.

[Espresso_Boy]

Everything looks good. I didn't get any information about far away bags being dropped, or far away bags on map changes or login. I dropped some bags nearby to force the server to send me GET_BAGS_LIST when I login or re-enter a map, and the list didn't contain info about far away bags either.

 

One issue I did encounter was once I've seen a bag, I can go far away and the client still knows the bag is there. That makes sense because in real life one will remember noteworthy things they've seen. When a bag that I've previously seen is picked up, the server sends DESTROY_BAG. This could be used to keep tabs on people far away, but at least it's nowhere near as abusable as having the whole bags list. It doesn't seem to remember what bags I've seen across map changes and logging out/in, so that's good. Perhaps it should send DESTROY_BAG when you leave the vicinity of a bag to compliment sending GET_NEW_BAG when you first walk near a bag.

[Entropy]

No, the whole idea is to save on bandwidth, not to make it even more bandwidth intensive than it is.