v2.8 about rclootcouncil2 HOT 8 CLOSED

Just hope Argus is dead this week, so I may help a bit. #134 is close to finish, and it is just untouched for a while. Adding some filters to #143 is not hard, and it is a nice feature to have.

#125 is a bit complicated, and I am not sure if it should be in v2.8. It could be a part of v3

from rclootcouncil2.

I've already started on #125 - I'm only missing the receiving part of it. The reason I want to do it now is a reconnect command has the potential to fill the comms buffer thus delaying everything significantly. The only remaining question is which serializer to use, and if LibCompress should be used as well.

from rclootcouncil2.

Dont change the serialize or use LibCompress which breaks all compatibility.
The new serializer isn't ready yet, and I am planning to implement an optimization targeting specific to the item string.
Full compatibility break should come in the next expansion, or in the pre-patch, in the version3, when it's likely we will change the addon comm prefix from RCLootCouncil to sth else

from rclootcouncil2.

I wasn't planning on breaking any compatibility but the reconnect. I considered using LibCompress just for that, however it would require it to use a separate comm system and prefix (or some ugly extra checks) - all in all probably not worth it for now.

from rclootcouncil2.

I dont think all these changes should be in v2.8. Many should be in v3.0, because I don't think RCLootCouncil is very important addon at the end of expansion. Since we're going to restructure RCLootCouncil in v3.0 anyway, it's better to implement some features there instead, for example, Optimize reconnect data #125. This will spend you lots of time to fix it in v2.8, but it should not be a problem in v3.0

from rclootcouncil2.

I have planned to implement pure LUA version of DEFLATE algorithm, which is used by zip. According to my tests, it takes ~200 bytes to transmit all equipped item strings if the data is compressed by zip. However, it will be long time if I manage to make it work and fast. Speed expectation: as fast as libcompress's CompressLZW+CompressHuffman

from rclootcouncil2.

I dont think all these changes should be in v2.8.

That's why I've mostly chosen those that's almost finished anyway. I'd very much like to get the PL stuff out now while especially many uses PL, to get a feel for how it's received. The rest is just optimizations, a lot of which is easily reuseable in later versions.

I don't think RCLootCouncil is very important addon at the end of expansion

While true, it's not the right mindset to have, and is no excuse for not doing any updates (a lot of people still use it). Besides, I'd rather do new features and get feedback now where any potential shortcomings doesn't matter too much, than finding out at the start of the next xpac that feature x breaks everything.

LUA version of DEFLATE algorithm

If you think it's worth it, then cool.

from rclootcouncil2.

2.8 is released, not all of the bullets made it into the release though. Closing this.

from rclootcouncil2.