eressea

I've got a request to patch the latest version (2.7.0.146) the same way so here it is http://download.l2shrine.com/hauthd-new-unpacked-patched.exe

Hi, is cached really running and listening? Do you have proper address and port in l2server.ini? Did you try to temporarily disable firewall?

I've forgot about amped - this strategy of using two extenders at once seemed weird to me so I didn't care much about it :D Still not fixed in leaked H5 and GD... maybe still not fixed on offic server :D

I'm not sure about purpose of the second map (I just know it's there and that it contains all account IDs since server start, maybe I'll dig bit more into it later), on retail server it will be big (surely 10k+)... That will be big difference between O(n) and O(log n). Probably it can be omitted - but it would probably have some performance impact.

That's true for the first map (accountId -> sessionId), it usually contains just few items. But the second map contains all account IDs that were logged since last server start so O(n) would be bad

Well, you need to map one ID to another - and as those IDs are sparse, you can't just allocate few megabyte array and store it there. You need some associative container - either red-black map or hashmap... Of course it still can be some sorted (or unsorted) array or something like that, but it will be harder to manage, especially in case there won't be enough allocated memory to store all elements; you would have to reallocate and copy; also insert and delete function would be far from O(log n), however search operation would be O(log n) via binary search if it's sorted. I don't say C is bad - but std::map is really much more convenient and when used well, it's perfectly safe.

Writing red-black tree or hashmap in C is really pain in the ass unless you use macros (which I’m trying to avoid/minimize). It can be done in asm, it can be done in C and it also can be done in C++ - with no or really little performance impact. I find maintaing clean C++ codebase easier than in C or asm - but it’s up to you to pick language you prefer. If written correctly, the result will be almost identical. But it will probably take twice time in asm vs C and twice time in C than in C++. All languages have pros and cons.

If they wrote it in C, there would be many more problems than this one (much more code to write). As for map [] operator - all good C++ programmers KNOW that it inserts element if it's not already present. Operator overloading is good feature - if used sanely - I definitely like writing s == "abc" more than writing s.isEqual("abc") or strcmp(s, "abc") == 0. Generally speaking, I see C++ bit safer, but you have to use it well. You can write bad code in any language.

Hello everyone, I'd like to inform you about critical security bug that's present in all widely known NCsoft l2server.exe binaries. If you're using Vanganth, you're definitely vulnerable to this one. If you're using MyExt64, update your server immediately (it's fixed in commit c52b36e). When a player tries to log in, client sends LoginPacket with account ID and session ID. L2server should search for given account ID in std::map<int, int>, compare result with session ID and decide whether it's the correct account and session. However, some programmer at NCsoft made a terrible mistake. Instead of searching in the map like std::map<int, int>::const_iterator i = map.find(accountId); if (i == map.end() || i->second != sessionId) return true; // disconnect user they ended up searching the map this way: if (map[accountId] != sessionId) return true; // disconnect user As you can see, if you supply arbitrary accountId and sessionId of 0, l2server will let you in (because it will add std::pair<int, int>(accountId, 0) to the map and then return 0). In reality you can't use any account ID as it's also searched in another std::map, so it works only for accounts that have been logged in since server start - but this is the only limitation. This bug is really critical, if a player is able to guess account ID of some character with builder that has been logged in since server start, nasty things are going to happen... I suggest everyone to fix it as soon as possible - you can see the fix in this commit https://bitbucket.org/l2shrine/extender-public/commits/c52b36e8aad518a094774aca49f2b78da7da390b (for Gracia Final, for other chronicles you'll have to find correct addresses)

As title suggests, I've tried to adapt MyExt64 compiler for Glory Days AI (classes, variable offsets, functions) but it's just an experiment. If there's anyone who can test how it really works, I'd be glad :) It's just a first draft and proof-of-concept, if there's any bug, I'll try to fix it. Stay tuned ;) Compiled DLL: https://bitbucket.org/l2shrine/extender-public/src/compiler-gd/server/MyExt64.dll Sources: https://bitbucket.org/l2shrine/extender-public/branch/compiler-gd EDIT: Fixed few bugs (missing handlers and wrong 'myself' type in NPC maker event), now it compiles default NPC and default maker

Patched hauthd - supports one server on multiple IP addresses: Newer version (2.7.0.146) here: http://download.l2shrine.com/hauthd-new-unpacked-patched.exe Older version (2.0.0.123) here: http://download.l2shrine.com/hauthd.exe What you need is just to add this configuration line with number of your endpoints: [Adv] ServerEndpoints = 2 When l2server connects, it takes first n servers with matching internal address from database (where n = ServerEndpoints)

I'm writing a brand new Gracia Final/Epilogue extender, if you want to try it or have a look at sources, I'll put some development versions here: it's hosted on bitbucket. https://osamelahora.cz/MyExt64/ https://bitbucket.org/l2shrine/extender-public Now it does almost nothing but I'll add some new stuff over time... I'm adding new stuff over time :) MyExt64 What is MyExt64 MyExt64 is new opensource extender for l2off Gracia Final server (l2_off_gracia_final) supporting Gracia Final and Gracia Epilogue chronicles. It uses some knowledge from OSIE extender, MXC extender and maybe other extenders. Features Supports protocols 83 (Gracia Final) and 152 (Gracia Epilogue update 1) Protocol 87 (Gracia Final update 1) should be working but is not tested Supports Gracia Epilogue skill enchanting + buy/sell Supports Gracia Epilogue refund Supports Gracia Epilogue mail system Bunch of bugfixes (some ported from OSIE, some ported from MXC extender) Voice commands - offline trade, experience gain on/off, server time, online player count Configurable item enchant (safe/chances) Custom drop/spoil rate algorithm Custom event drop algorithm (flat chance based) Players in the same command channel are treated as allies Configurable max level for main/subclass Global shout/trade Vitality multiplier Configurable clan restriction (penalties) Configurable buff slot count + max divine inspiration bonus Configurable vitality level ranges Configurable autoloot system Embedded Gracia Final AI (NASC) compiler How to use it If you're not familiar with l2off, it will probably require learning some stuff (MXC forum is a good start). To just use the last build, copy following files from server folder in this repository to your server folder: * MyExt64.dll - main extender file * MyExt64.ini - extender configuration * MyExt64Loader.exe - extender loader and run the server via MyExt64Loader.exe If you're more experienced with messing around PE files, you can add MyExt64.dll to import table of L2Server.exe and add call to DllMain. How to compile it You should get Visual Studio 2005. Maybe it would be possible to compile it on some newer Visual Studio, but you'll have to define your own templates for std::vector and std::map (and possibly more containers) to match memory layout of their VS2005 versions. MyExt64 has no external dependencies and requires only standard libraries for Windows development.