Rochet2

The suggested fix may work, but it is a hack around the limitations of the send/receive AI event functionality. Instead of casting gameobject to a creature ReceiveAIEvent could be expanded to cover WorldObject as sender. @Gutterboy I would suggest either trying to rework the send/receive AI event system to allow WorldObject as sender or similar, or then we can use this kind of approach: diff --git a/scripts/eastern_kingdoms/scarlet_enclave/ebon_hold.cpp b/scripts/eastern_kingdoms/scarlet_enclave/ebon_hold.cpp index 30b970c..f51a194 100644 --- a/scripts/eastern_kingdoms/scarlet_enclave/ebon_hold.cpp +++ b/scripts/eastern_kingdoms/scarlet_enclave/ebon_hold.cpp @@ -1001,8 +1001,9 @@ struct npc_unworthy_initiate_anchor : public CreatureScript RegisterCloseInitiate(sender); break; case AI_EVENT_CUSTOM_C: // notify me; @TODO inplement normal ObjectGuid transfer between scripts + if (const GameObjectData* godata = sObjectMgr.GetGOData(data)) { - ObjectGuid guid = ObjectGuid(HIGHGUID_GAMEOBJECT, 0, data); + ObjectGuid guid = ObjectGuid(HIGHGUID_GAMEOBJECT, godata->id, data); if (GameObject *pGo = m_creature->GetMap()->GetGameObject(guid)) NotifyMe(invoker, pGo); break; @Necrovoice The locations are around SD3\scripts\eastern_kingdoms\scarlet_enclave\ebon_hold.cpp(1003) SD3\scripts\eastern_kingdoms\scarlet_enclave\ebon_hold.cpp(1245) It should be noted that I did not test these changes in game.

https://github.com/mangosone/server/blob/13d333f2686efebd65130b611b53d52b69674e00/src/game/WorldHandlers/GridMap.cpp#L38 https://github.com/mangos/Extractor_projects/blob/c835b82e9a930d747a15b5db19af180119656d45/shared/ExtractorCommon.cpp#L304 Seems like a mismatch here with the versions of extractor and core magic number. Probably same issue for all the maps (mmap, vmap, map) since all the versions were bumped in this commit: https://github.com/mangos/Extractor_projects/commit/51086dafc9477557ebe21f59ad7076802d04d6dc Looks like the change does not require changes in core code, so bumping the versions in core should, in my opinion, be enough to fix the issue. (see some of the latest commits at https://github.com/mangos/Extractor_projects/commits/master)

Seems you edited your post and added a question that I did not see. accountid is not characterid. account has multiple characters so accountid is separate from characterid. Characterid is actually character guid, which is lowguid. characterid = guid in database = lowguid in core functions And yes, you are right that it is characterid. But characterid is not accountid. Maybe this is the problem you have.

Just because your query matches some rows in the DB doesn't mean the query is correct. Like I said earlier, guid is not accountid so your query is wrong. If you look at the data in your database you will likely see that the guid and accountid do not match for the rows you try to get from the database. You could get the player guid from the player by using a function http://www.elunaengine.com/Object/GetGUIDLow.html You could get the player guid through SQL joins from the character table through the accountid: https://www.w3schools.com/sql/sql_join.asp Maybe you should not be using SQL at all. What is it exactly that you try to do here? Are you trying to get an item from the player's inventory? There are many functions for it http://www.elunaengine.com/Global/RegisterPlayerEvent.html?search=getitemby

The issue is not related to Eluna in any way. As you can see from the DB documentation: the guid is not account id. guid is the character guid from characters. So your SQL query is wrong. Test your SQL with an SQL client to make sure it works properly.

Alright. I will apply it as a fix to the source then. Thanks for testing. btw. on my machine I tried with VS 2013 and VS 2017 and in debug and release and couldnt reproduce it. The fault in the code does make sense though. The inconsistency is disturbing.

@khamarr3524 I may have found the issue. Remove the earlier edits and try this: https://gist.github.com/Rochet2/f47056785ccf864e9be481605380d2d7 The issue may be that the hash function that was supposed to take 2 or more arguments is used instead of the functions that take one argument. The changes above should make the function require at least two arguments so it cannot be confused with the ones that take only one. I couldnt reproduce the issue with Windows 10, MS VS12 2013 (windows desktop update 5), MaNGOSTWO, Release Win32 which should be close match to your setup, so I cant test possible fixes myself.

@khamarr3524 Would it be possible for you to try debug and see what the types of the variables are and where they originate from? Also information about your environment would be nice. For example are you trying to compile 64 bit and so on. Assuming you used windows since the report was posted at the end of windows installation guide. Tell us if this is not true. This is a first issue about such since the code was added two years ago and I cannot directly see where it would come from. Can you try making these changes and report back? https://gist.github.com/Rochet2/d2c4647df88aea3ebf3cb47b32a53baf For reference, this is the line reported: https://github.com/ElunaLuaEngine/Eluna/blob/c6b9d7364c811825465e82156c56656500ea9a64/BindingMap.h#L275

It loops through the elements in buffs table. _ is the key and v is the value from the table. _ is often used to indicate that the variable is not used. https://repl.it/HLJ3/0 http://www.lua.org/manual/5.2/manual.html#3.3.5 http://www.lua.org/manual/5.2/manual.html#pdf-ipairs http://www.lua.org/manual/5.2/manual.html#pdf-pairs

When you say that it works, does that mean that you also tried to compile the core? According to cmake docs MSVC should be defined as true when the compiler is some version of VS. If cmake running manually works, then probably the part that runs cmake needs to be tweaked in easybuild. Seems that cmake cannot determine the compiler or determines it wrong or after the step that we are using it at somehow. Probably need the easybuild source code for this one if it does not happen when running cmake on its own.

Here is the origin of the issue: https://github.com/mangosthree/server/commit/43b74a38206ae117e74e041c960b46daa6c7d92d#diff-cbff7f9dcb78a3b83d4b09941070082eL573 @H0zen

World.cpp 570 causes a lot of config options not to load (including maxlevel, causing it to be 0 and blocking level stat loading) This is because std::string forceLoadGridOnMaps = sConfig.GetStringDefault("LoadAllGridsOnMaps", ""); results in an empty string. https://github.com/mangosthree/server/commit/e62ece1fdbd1cfd757e270ed3af39a6c8d878bf4 https://github.com/mangosthree/server/blob/e62ece1fdbd1cfd757e270ed3af39a6c8d878bf4/src/game/WorldHandlers/World.cpp#L570 https://github.com/mangosthree/server/blob/e62ece1fdbd1cfd757e270ed3af39a6c8d878bf4/src/game/WorldHandlers/World.cpp#L659-L662 I feel that the config options should not be inside the IF statement. Someone probably make a mistake formatting the code.

Ask yourself: Does vmap extractor connect to the internet? (and I do not mean that you should answer here) Clearly it has other uses in addition to that. You make my suggestion sound like the guy fixing this should just remove all code from the functions as that compiles. (This is a playful example, I do not mean that you said this, but that it comes out like this) That is not what I meant at all. Obviously someone changing the implementation should have an idea about what they are doing. The point was that you asked for a guide, which doesnt exist, so I gave rough steps for what needs to be done.

I meant replacing it in the tools. So yes, entirely - in the tools. This means that we do not remove ACE completely form the server. JUST the tools. (vmap extractor, mmap extractor, mapextractor ..) We just implement the things we use from ACE, but in c++(11) ourselves. I dont think there is anything explaining this stuff, but its not like there needs to be. Simple steps: Remove ace dependency (linking) from tools and then fix the compile errors Im pretty sure the performance is not relevant. Even if any implementation we make would be 100 times slower, it might not appear at all to the users. Note that we are changing only the tools, not the server, and its only a small part of what the tools do that uses ACE.

It might also be possible to remove the ACE dependency from the generators and then there is no need for the dll (except on the actual server). Im relatively sure you can use C++11 to replace most of the stuff needed from ace.