eressea

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)

That would be great :) I was thinking about doing the same in the compiler but it would be much harder to do there and also it would be custom change in the compiler... I'd like to keep it all NCsoft way

Fixed - download http://download.l2shrine.com/MyExt64.dll I'm getting errors about undefined variable talker - it's missing in handler arguments so compiler doesn't see it - first error I get for your AI is 07/22/2018 12:07:04.931, ERROR(780692) : Undeclared variable [talker] Can you fix it somehow? :)

Something tells me it should be int - objectID/index of NPC who is boss for the group, but I'm really not sure about that +1 maybe globalmap_pch.txt... OR maybe parse all of them from manual_pch.txt - that would be the best way

Ah, ok :) How about boss_id - that shouldn't be global map ID or should it be?

I'm asking because of commit https://github.com/madyanov/nasc-decompiler/commit/87c177446322d3c2688ec3e53c75b216f50d2501

Are you sure that GM_... aren't global map IDs? EDIT: For example antharas uses global map ID of 10 which is same as gm_antaras_max... On the other side, it's usually defined as a parameter so it can't get resolved nevertheless...

--output option disappeared? :) EDIT: Ah, it never was there :D

Because they're custom and unique for MyExt64... Maybe add data/gf-myext? :)