hyuga

Thanks ArhangelSM. I was having the same issue, and changing SECTION_TYPE_FACIAL_HAIR to SECTION_TYPE_HAIR seems to have fixed it. Perhaps the constant value is not correct. I do not know enough about the code to be able to tell.

Indeed. I updated the 3 wiki documents, to highlight this early in the process of building in Linux. That should play a role in your decision should you have the choice to build on either platform. That additional verbiage should be changed to include OS X, should the user be planning on running the client there. What does the connection patcher use from the client machine? Perhaps that could be passed as an argument to the tool running on Linux, to allow it to patch your non-Linux binaries without having to build TrinityCore on 2 platforms?

Found a solution. I used connection_patcher.exe built for Windows. Then I got this error: BLZ51914001 I then used the FAQ solution: 6) i can't connect i get You have been disconnected (some random values) You have been disconnected(BLZ51914001) you miss on bnetserver config the next data: [ . . . ]LoginREST.LocalAddress https://github.com/TrinityCore/TrinityCore/blob/dde620c402daf4ea8d132fb72a77eabc22f7a6d0/src/server/bnetserver/bnetserver.conf.dist#L58 I set LoginREST.LocalAddress in bnetserver.conf

Having a similar issue. I searched the forum and found the posts above. But they do not specifically state what the solution was... Also looked at Here are my details: My server is on a Linux machine. My connection_patcher is in Linux, because I compiled under Linux. My client is Windows, on a separate machine. I patched the executables in Linux, on the command line: "connection_patcher Wow.exe" and "connection_patcher Wow-64.exe". Then I copied the patched executables over to the Windows machine. Set the realmlist.address to the LAN IP address of the Linux machine Set the Config.wtf file to have "SET portal "LAN IP address of the Linux machine"" Started bnetserver on Linux Started worldserver on Linux Disabled firewall on Windows Started Wow_Patched.exe on Windows Tried login in with the bnet account I acreated user@linux + password I see "Connecting" and it never does. I do not see activity on the server, no attempts... The instructions do say to run the connection_patcher on the PC that will run the client... does this mean I need to compile under Windows, to get connection_patcher.exe? The post above seems to indicate that was not the case. Hence... what am I missing?

I ran into similar issues listed in this thread. I am (somewhat) happy to report they were user errors. :-P 1. I was a bit baffled at the client build listed as 15050, when I knew my client was 15595. The client was fine. The error was that I compiled the tools from the master branch, which is pre-CATA (i.e. 3.3.5.a 12340). Obviously, that will not work. Once I switched to 4.3.4 branch and recompiled the tools, things worked well. I think it would be good to have the tools list the WoW client build they are meant for, like printing "Map & DBC Extractor for 3.3.5a clients". 2. When running the vmaps4assembler, I got this message: ("Could not read dir_bin file!"). I looked at the source, which gave me a hint this had to do with the sourse directory (server/collision/Maps/TileAssembler.cpp: std::string fname = iSrcDir + "/dir_bin";), so I looked in "Buildings". I found it was empty, due again to the wrong tools version, which lead to vmaps4extractor not working. If I recall correctly, even though the output indicated errors, the last message seemed to indicate that there were no errors. Anyways, once I used the right level of the vmaps4extractor, Buildings was properly populated, which then lead to a successful vmaps4assembler run. I think it would also be good to have the "Could not read dir_bin file!" message be more descriptive, like "Could not read expected input in source directory <<DIR_NAME>>, please ensure you are not a noob and have the right files there!". Overall, these issues can be avoided if the users carefully understand and follows the instructions, but a bit more user feedback during the runtime would help identify user errors more quickly.