Sherer

I don't see the point of disabling loading files from pack. As I'm concerned, client built in distribute mode has this option disabled by default. On the other hand you can just disable this option by setting appropriate mode (sometimes reading from disc is useful for debugging stuff).

Any syslog upon drop?

Try to disable both firewalls and check then.

I mean you'd suggested to change part of m_map_pkShop destruction (introduced collector etc.). The problem is leak is not related to this container. Have a look at piece of code you provided: m_map_pkShop.insert According to C++ docs insert method tries to add element if it not exists. Because of that fact pkShopEx is never, ever added to map (if one exists, which you rightly mentioned). Bear in mind that clearing m_map_pkShopByNPCVnum is not enough since it stores pointers to objects (allocated with new operators). Your recent alterations already handle it well. Good job man. for (auto it = m_map_pkShopByNPCVnum.begin(); it != m_map_pkShopByNPCVnum.end(); ++it) delete it->second;

Well, the collector you came up with doesn't really does the job for me (pkShopEx is not stored anyway in m_map_pkShop since insert fails in that case). That's why I mentioned it

Just wrap it into smart pointer mate. Or... Clear data from m_map_pkShopByNPCVnum instead (since every, singleobject ends up there).

Add "-static" to compilation flags.

Did you try to recompile is as static?

Yes, show your alterations.

You ought to add this to projects preprocessor defines: [Hidden Content]

You have to rebuild cryptopp as well (in that case when you use GCC this should be done via port, with USE_GCC set to "YES").

You can just wrap size into std::min(1, size) during protos reading process.

Nowadays with so many system collectors (like built-in unix/windows) there isn't a real memory leak at all. On the other hand if you keep stacking those unused items, memory will may grow to ridiculous values. Same outcome you are going to have because of classic memory leak - a lot of memory is allocated most of them is junked.

Still, better to keep unused object deleted rather than keep them scrapping in memory.

Open database (assuming you use navicat), click on offline_shop_item table and edit its structure.

You should investigate your offline_shop_item structure.

It's impossible to help you without getting even a leap of code.

Nah man idk what did I write boost. I meant cryptopp.

Small hint. Don't put any table/container loose like that. Keep it either in anonymous namespace or add static keyword in order to make it internal linked (just in a matter of good code style). Additionally bear to check for nullpointers/array elements once they can cause a lot of unexpected stuff in your code. I like the idea but I think this implementation might not be the point. The player data can still be DB's cache thus once flush session kicks in the data may be resaved. Same applies to billing. You might like to handle this as well.

Or use older version of boost Meant cryptopp

Updated github repo with code line that's gonna solve this issue.

Looks really interesting. How did it work for you? Once you added the ip into mitigation one wasn't able to connect to the server no more? Did the user get dropped immediately?

Thanks for the hint. Due to your feedback I refactored handshake authentication to be done through P2P rather than by CORE->DB->CORE. If someone follows this tutorial you need to reimplement that part (with github stuff). According to your third question I don't really think it matters since some of methods don't even bother sending any packets at all. They just spoof the queue with fake connection and stuck in handshake stage. Nice idea with OVH_API - haven't really heard about that (you can make some tutorial if you find it helpful for us). In reference to the code you attached all methods bother sending packets at all.

Added new link

Reupload (cannot edit thread): [Hidden Content]