Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Souldoubt's Achievements


Newbie (1/14)



  1. Sorry for the delay: msvcp140.dll and vcruntime140.dll
  2. Figured it out. Yes you can pick up the patcher and 3 DLL files and successfully patch a machine that does not have TC installed. HOWEVER... Microsoft pulled a fast one on me. You can't mix 32 and 64 bit DLLs an run the patcher. The 64 bit DLLs you need are in the system32 folder. The 32 bit DLLs I was using by mistake were in the SYSWOW64 folder. The names are identical. Sheesh. Anywho. I am logged in and running thanks to everyone's help. Cheers!
  3. I would say about 80% of my time working with TrinityCore has been spent trying to get the patcher to work in various scenarios. I think perhaps I just don't understand how it was intended to be used. I have some questions about what will and won't work: - Can the patcher ever be used on a system where the full TrinityCore is not installed? - Can it be made portable? - Can the patched executable be moved to another machine after it has been tested and connected properly? At this time the only successful patch I have run was on a machine with Trinity's tools compiled and installed (and all the prereqs that go with that...). I have moved dll files around, run the patcher locally on the TC machine on a remote shared install of the client, re-pulled and recompiled a number of times, made all the proper adjustments to the WTF/config.txt and at the right times, you name it. If the patcher cannot be deployed in the manner I am trying to use it please let me know and I will start getting used to the idea that I need to the full Trinity install just to patch a single executable. It's frustrating for sure but I am very thankful for the work you guys have put in on this, and for the support I have received this far.
  4. At the character creation screen I set up a new toon and select a name. Right as I click to finish and create, I am disconnected from the server and cannot log back in. The process seems to crash the worldserver with the following error: Received not handled opcode [CMSG_BATTLE_PAY_GET_PURCHASE_LIST 0x05E8 (1512)] from [Player: Account: 2] Received not handled opcode [CMSG_BATTLE_PAY_GET_PRODUCT_LIST 0x00F0 (240)] from [Player: Account: 2] Received not handled opcode [CMSG_UPDATE_VAS_PURCHASE_STATES 0x006C (108)] from [Player: Account: 2] Prevented sending of [SMSG_UPDATE_TALENT_DATA 0x0277 (631)] to non existent socket 1 to [Player: Account: 2] Prevented sending of [SMSG_SET_PROFICIENCY 0x0668 (1640)] to non existent socket 1 to [Player: Account: 2] Prevented sending of [SMSG_SET_PROFICIENCY 0x0668 (1640)] to non existent socket 1 to [Player: Account: 2] [ 2802.557916] worldserver[427]: segfault at c ip 00000000013f8b20 sp 00007ffd054e0428 error 4 in worldserver[400000+21ba000] Segmentation fault I did some looking up and found one possibility about port forwarding being the issue but I checked and confirmed that it was correct for 8086. Thanks in advance!
  5. This seemed to resolve itself naturally after another pull and compile over the weekend. Timing issues with the announcements of supported client versions. Error went away and was replaced with an error saying that the username was not found. Created a second user with bnetaccount create and logged into the character screen. Of course I have a new problem now when creating a new character it disconnects from the server and crashes the worldserver process in linux, which I will post in a separate thread.
  6. Note: I am re-extracting all my maps again so I have not launched the worldserver yet, which I know will update the databases. So that revision number should be a few days old.
  7. Ran another pull last night. From the DB: core_version Core revision dumped at startup. core_revision db_version Version of world DB. cache_id Edit Inline Edit Copy Delete TrinityCore rev. d2d41c119b99 2016-01-13 21:43:01 ... d2d41c119b99 TDB 6.03 3 I followed the directions on the keeping the code up to date section of the core install for linux. - git pull -cmake... -make -make install
  8. So my client version is more advanced than my server (log below). I thought I had been fairly good about re-pulling code and recompiling but that does not advanced the version number that I need to connect the client. How do I verify the version number of my trinitycore server, and if it is not high enough, how do I upgrade it sufficiently. I ran the git pull and recompile after I saw the message in the supported version thread that matched my current client version 20886 Log: 1/16 10:14:34.817 Login program=WoW platform=Wn64 locale=enUS 1/16 10:14:34.845 Component WoW.Wn64.20886 1/16 10:14:34.845 Component WoW.base.20726 1/16 10:14:35.196 Battle.net is Component Bnet.Wn64.37165 1/16 10:14:35.209 LOGIN: state: LOGIN_STATE_CONNECTING result: LOGIN_OK 1/16 10:14:35.223 Connecting to x.x.x.x:1119 1/16 10:14:35.303 LOGIN: state: LOGIN_STATE_FAILED result: LOGIN_BADVERSION 1/16 10:14:35.303 Disconnected from x.x.x.x 1/16 10:14:35.307 Client initiated Disconnect from x.x.x.x 1/16 10:14:35.337 LOGIN: state: LOGIN_STATE_FAILED result: LOGIN_BADVERSION 1/16 10:14:35.339 Login program=WoW platform=Wn64 locale=enUS 1/16 10:14:35.339 Component WoW.Wn64.20886 1/16 10:14:35.339 Component WoW.base.20726 1/16 10:14:35.339 Battle.net is Component Bnet.Wn64.37165
  9. Did a full setup of TrinityCore 6.x now a few times and I feel like there are easy ways and hard ways to do things. Knowing what I know now, here is how I would do it in the future: - Linux server with a virtualized guest application system and a separate virtualized guest mysql server. This has been good for performance and tweaks and makes it much easier to scrap and rebuild sections of the system without having to redo the whole thing. Backups are a cinch. One lesson learned is not to declare the number of processors on the virtual server while compiling (make). Virtualizing the application system means I can also just leave it at the TC prompt and access it through Xen console as necessary. - Set aside an old laptop that can run the client at bare minimum with a matching architecture to my game machine. Compile Trinity there for the tools and create the patcher locally and patch locally. I had a TON of problems trying to build and apply the patch on my main games machine. Missing and unregistered dll's, patch errors (0xc7000..), file permissions... I also do not want my main games machine to be bloated out with all the prereqs for compiling. I originally virtualized a win7 system to do this but you can't install the client there because it cannot properly detect an acceptable graphics processor to do it. - Share out the client directory on the laptop and mount it on the application server for easy access to the maps, etc.
  10. Yep, the missing bits showed up and was a huge help.
  11. First off, thanks so much for all the work you guys have done to make Trinitycore happen. As the wiki is currently missing tabs from the installation and configuration pages (Unknown macro: 'localtabgroup'), I need some help with final steps: - Options for configuring the server for LAN connections. I believe there is a line for setting the bind IP and address. - The initial TC prompt command for setting up and admin account in bnet or anywhere else. - The steps for running the connection patcher properly. Can the patcher just be moved to the machine with the client or does the patch need to be run on the machine with TC compiled? Setup: Debian essie running Xen -xen guest running trinitycore 6 on debian jessie -xen guest running mysql databases on debian jessie xen guest running windows 7 with TC tools compiled (for the patcher) Gentle prod to fix the wiki, but if anyone has the final steps info please feel free to pass it along. Thanks! SD
  12. Got it working. Just for yucks I compiled the entirety of TC on an old laptop (including tools) and ran my connection patcher. Took a few tries to understand how the patcher has to function. In the end I had to run the patcher locally on the machines running the client after also registering a missing DLL (libeay32.dll). Works fine after that. I agree that the tools compile should not be quite so needy for dependencies but that is just my personal pain threshold. It would have been a perfect setup if the patcher could run properly from linux but I understand that library access is the problem. My setup is: TC compiled and running on a virtualized debian guest. Client computers running on Windows 7 64bit Again thanks for all the work! Now I just need to figure out why none of the npcs or monsters are moving. Time to figure out how the waypoints went funny. SD
  13. OK. Thank you. I will install GitExtensions, CMake, and Visual Studio. I will leave out MySQL and OpenSSL. Do I need to install Boost and ZeroMQ? Souldoubt
  14. I just built out a working (so far as I know) 6.x server using the posted documentation. Please allow me to thank you all for the work that has been done. While there are a number of confusing/misordered items in the documentation, I was able to work out most of the details on my own. I have hit a brick wall with the connection patcher. I followed the several lines of instructions in the documentation on the topic but the patcher fails when run from my linux server on the Wow-64.exe file in my client directory on my client computer (shared and mounted on my trinity server via CIFS). I did discover from a number of searches that you must run the patcher in the same/similar OS environment as the client files. I am happy to do that but I am hoping that I do not have to pull and compile the entire TrinityCore project on my windows machine to simply compile and run the patch for the client. Can anyone tell me which steps/programs are needed to compile JUST the patch? Thanks again. Souldoubt
  • Create New...