search

evil-morfar / RCLootCouncil2

RCLootCouncil - addon for World of Warcraft
https://rclootcouncil.com
GNU Lesser General Public License v3.0
19 stars 29 forks source link

v2.8 #150

Closed evil-morfar closed 6 years ago

evil-morfar commented 6 years ago

Mandatory

Included if ready

Nice to have, but might be pushed

SafeteeWoW commented 6 years ago

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

evil-morfar commented 6 years ago

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.

SafeteeWoW commented 6 years ago

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

evil-morfar commented 6 years ago

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.

SafeteeWoW commented 6 years ago

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

SafeteeWoW commented 6 years ago

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

evil-morfar commented 6 years ago

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.

evil-morfar commented 6 years ago

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