Hmm. May be thinking of the speed thing wrong. I tried both urs and Paraducks plugin. But im positive it was urs that I had the issue with. Going now to turn in some more rares. I'll report back in about 30 mins.

 

-----signature-----

Ok. Here's what I figured out. I went to the exchanger with 15 rares and 500 mmds. The only plugin running was the exchanger.


I had it set to keep only a few rares and exchange all the rest. I was keeping strength/armor tink/focus rares. All others were exchanged. I saw 2 of the focus rares get handed back and 1 strength rare.


I'm thinking that maybe because of the speed that it hands them in, any kind of lag/packet loss issues may cause it to mis-read or just not read at all, the rare that is handed to the character. This is just speculation since I don't know the inner workings of the plugin.


If you need me to try/test anything else for you, just let me know. I'll be happy to help.

 

-----signature-----

But it kept all armor tink rares and some strength and focus rares? The strength and focus rares it handed, did you happen to see if those were rares it just received (iow: did it hand them from the first slot of the mainpack)?

I went over my code again and the only way I can see this happening is under the following conditions:
- rare A is a rare that should be handed and has guid X
- Character hands in MMDs, rare A, the next batch of MMDs, receives new rare B which should be kept and has guid X again
- The "destroy item" message for rare A did not reach the client until this point OR WF for some reason did not handle it properly*

I am in no way an expert on AC protocol or inner workings of WF, but from what I know about it this seems the most plausible way. Maybe Virindi or hazridi can shed some light on this?

If I am right about what is happening, I think I can reduce the likelihood of this happening a good deal without sacrificing speed noticeably.

Oh and just out of curiosity: Do you happen to know how long it took the plugin to "burn" through those 500MMDs?

lino

*: Just guessing here, but if guid X exists in WF, the "destroy item" message gets lost (or simply lags behind) and there is a "create item" message for guid X, I assume WF does not overwrite the existing object (or at least not right away?).

If one object is created, and before a destroy notification is sent for it a new create arrives for the same GUID, Adapter's WF wrapper will continue to return the data from the first create. If a delete happens on the first object before the creation of the second object, the second create data will be returned.

I have never had this problem or seen anything to indicate that a GUID had been duplicated (other than this and the discussion about your loot data). But, it's certainly possible.

If this is what is happening, it should be easy enough to detect for logging by manually watching the protocol messages.

I have also reviewed COM worldfilter and vtank's dedicated world object tracker and both should rewrite the original data in the above situation. So, another method of testing would be to either use WF interops, or vtank with uTank2.PluginCore.FWorldTracker_GetWithID(int gameid) (PluginCore instance is uTank2.PluginCore.PC)

 

-----signature-----

Yes, they were always in the first pack slot.


And it took about 1 minute to burn 380ish mmds.


It was done at that point.

 

-----signature-----

Thanks for the explanation Virindi. I guess due to the high speed at which objects are created and destroyed, the chance of some messages arriving in wrong order is higher than usual. I will figure out a way around this problem without "artificially" slowing down the plugin.

Ball-Cruncher: I hope that angry smiley is aimed at Turbine for making it so costly to exchange rares and not at StuffExchanger for saving you a lot of time

Not at you. I like anything that saves me time and hassle.


Thanks for taking a look at this. I try not to bring anything up unless i'm certain there's a problem. I know you guys have better stuff to do than chase "ghosts in the machine".

 

-----signature-----

A few months ago I noticed something unusual in that IDs where being
reused more frequently. I've seen (from logs) where
an ID was destroy and fraction of a second later the next generated ID was the same.

So its imperative that plug code removes any persistent storage of
that ID when destroy is received.

It is also important to not to go to fast as you need allow for packets
to settle down so worldfilter will be statefully correct at the time your code is using it.

Now that I look at it further, I am not sure at all what is going on. It seems that it should actually work and overwrite the original data even when looking at the adapter wrapped WF objects.

Perhaps something else is responsible for this problem?

It seems that more logging is in order.

 

-----signature-----

Give me a few days to save up 20ish rares and i'll do another run.


Is there any way I can create a log as I run the plugin?

 

-----signature-----