Foereaper

This is due to the install step of the new build system, it is not yet complete :)

Good to hear :) The install location was made to be structurally similar to Windows, thus the binaries not being added to the bin folder. Will discuss this with LFX and Rochet as they know the install system better than I do. Will also take a look at using external Ace once we're done porting the system to One. Edit: Saw your update, it is not broken per se. For cmake to work properly on windows with a configurable conf dir, as that was wanted by a few, a new cmake option was added where you can specifically configure the path to the conf dir. -DCONF_DIR

Alright, will install a VM and try :) Mind attempting to try and use the internal ace lib just to see if you get the same error? If not then it's just down to an if statement :D

A lot changed since you left two weeks ago, we're currently working on restructuring the entire source as well as rewriting the build system :) What OS are you using and what cmake params are you using? Mind attempting to compile with internal ace to see if you have the same issues?

Did you use internal or external ace? Just tested and working on Ubuntu

The below commit will have to be ported to One. Do mind, changes done to ByteBuffer read/write SHOULD NOT be ported. [url]https://github.com/mangoszero/server/commit/8d0d8b918bb8101b11ab80d9a80aa4c8d1716c0a[/url]

Final fix as of this commit: [url]https://github.com/mangoszero/server/commit/12fc6cbc239445c23660b68476e29bf7bc50e2f5[/url] Tested and working

As of the latest changes to Rel20, SD2 is no longer compiled as a shared library, but a static library and integrated into the binary :) Thus the above comment is no longer "valid" and the issue should be re-tested if it indeed was SD2 related :)

Fixed with this commit, please confirm: [url]https://github.com/mangoszero/server/commit/8be9b36224aab1a76306c69628163b5c7f33ae0d[/url]

Check all the commits done to the AH bot files? :) [url]https://github.com/mangoszero/server/commits/Rel20/src/game/AuctionHouseBot/AuctionHouseBot.cpp[/url] [url]https://github.com/mangoszero/server/commits/Rel20/src/game/AuctionHouseBot/AuctionHouseBot.h[/url] [url]https://github.com/mangoszero/server/commits/Rel20/src/game/AuctionHouseBot/CMakeLists.txt[/url] [url]https://github.com/mangoszero/server/commits/Rel20/src/game/AuctionHouseBot/ahbot.conf.dist.in[/url]

He was "killed" in 5.0.4 during a quest line. The notes are not necessarily the correct ones for 1.x respectively :)

For future reference, you can use the below command when cloning. It automatically initializes and pulls the correct submodules: git clone https://github.com/mangoszero/server.git -b Rel20 --recursive The recursive tag is what does the submodule magic :)

The crash fix is not related to the player not being ported to the correct location. This should be posted as a separate issue to prevent confusion and preserve proper issue history :)

Did you recursively clone? Seems to me it didn't pull the submodules correctly.

I suggest something along these lines [code]bool Map::CanEnter(Player* player){ if (player->GetMapRef().getTarget() == this) { // Check if player is on a transport or not. Prevents crashes on transports like Zeppelines with dest. on the same map if (player->HasMovementFlag(MOVEFLAG_ONTRANSPORT)) { return true; } else { sLog.outError("Map::CanEnter -%s already in map!", player->GetGuidStr().c_str()); MANGOS_ASSERT(false); return false; } } return true; }[/code]

As far as I see it the entire CanEnter function, as it stands, is completely pointless. The only thing it checks is if the old map is the same as the new map, then assert. This makes no sense, and I know of several times where this would be true. Either we need to check if the player is on a transport within the CanEnter, or it needs to be "removed". That being said, CanEnter would be required for, as an example, TBC flagged accounts in WoTLK. It would need to be rewritten obviously, but if you tried to take the boat from Stormwind to Borean Tundra in WoTLK with a TBC account, it would teleport you back to the dock and tell you that your account is not eligible to be in any WoTLK areas.

This should all be handled locally by the client. Try typing /mountspecial and see if that produces any sound.

Passing it along to Rochet ;) This may or may not have to wait till the upcomming SD2 and cmake rewrite :)

The fix has been pushed to Rel20 :)

Is it only supposed to happen in IF or other major cities?

[URL]https://github.com/mangoszero/server/blame/Rel20/src/scripts/ScriptDevMgr.cpp[/URL] Blame on the said file here :) [url]https://github.com/mangoszero/server/blame/master/src/scripts/ScriptDevMgr.cpp[/url] Said file on Master

Which file specifically is this in? You could always do a history lookup on github to see when the file was changed last.

A temporary fix has been pushed, however we suggest going through and restructuring the unload process to be more clear as to what unloads when.

This is most likely related to this commit: [url]https://github.com/mangoszero/server/commit/989d66c62dcad884d361827b8cef1c12d421ad76[/url]

Alright, closing this one and moving to the next one ;)