• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Rochet2

  1. While the guide isnt perfect, it still captures the most important parts and is good enough for the job. Some of the issues you listed sound like user errors. You are clearly presented a way to create a new user in the mysql installer. If you did not have this view, then you are possibly using some other way of installing MySQL that was unexpected or the installer may have changed over time. You are clearly instructed to leave the subdirectory field empty. Then it will not create a subdirectory. Seems you missed this? The issue was possibly that you had the wrong boost version installed (did not use the provided links to download or accidentally downloaded wrong version) or that you did not restart CMake between attempting to do things like installing boost and configuring - which is mentioned in the guide. It is also possible that the system variables require a relog in windows or restarting the whole machine to take effect - this is not mentioned in the guide. Without the errors and the state of the machine it is hard to tell afterwards what your issue was. It is possible you installed wrong version of openssl accidentally. Unsure if some unconventional location may also be a reason. Most dependency errors during compile I have seen are caused by users installing wrong dependencies. For example 32 bit library when they compile 64 bit. This mostly happens for MySQL and Boost. Another problem has been the new boost and visual studio versions that required the boost finding script to be changed, but I have not checked if that was corrected already - it may have required some manual fixing. For the issues that you somehow solved it would require seeing the errors and possibly what you have installed and how you have set up the environment to figure out. This is why it is hard to imagine what could have been wrong. Even a small mistake can lead to nothing working and it could be that your system is different in some way from the majority of other systems (new versions of software etc.). So if you cannot solve the problems you should post the error messages and environment data, like what bit version you are compiling, and ask for help. In case you are getting errors there is also a troubleshooting section that has some guides for handling specific errors you may encounter: In the beginning the guide encourages you to search the forums and ask for help if you cannot find what you need. - There is even a support channel you can ask help live on irc. Anyone is free to edit the wiki, which means that after figuring out what is missing from the guide you can add it in. That being said this software is probably not being built for the average joe to use. Some knowledge about the used software and programming as well as problem solving is likely expected. It should also be expected that a new user will have problems configuring a project of this size and with this many dependencies - even with a perfect guide. New issues keep rising all the time as used libraries and software is being developed by third parties as well as TC.
  2. Take a look at what appveyor does in it's script I would recommend using some bash shell, like git bash instead of using windows commandline - windows cli is simply hard to use for anything. Im sure you can google a way to use git bash to get the current version hash from your repo and using that as the output folder should be relatively straight forward. Also you dont need to directly build to a new folder. You can build and then move/rename the build folder or it's contents. Cmake takes some arguments too, which may let you select the build output folder. cmake generates an install project that you can try to build to move the files after buinding them to the cmake configured installation folder.
  3. He says that the issue this thread we are in tries to fix cannot be fixed by using the method described if you downloaded the source as a zip. If you are saying that you can still do this fix, then maybe share some steps? The point is not that you cannot get the version of the zip. The point is that you cannot fix the version showing as Trinitycore rev. 1970-01-01 00:00:00 +0000 on startup and in cmake and everywhere.
  4. If you dont mind updating your core in the process with the fork's TC version that the pull request is made for then you can just do git pull <the fork address> <branch name> If you only want the pull request contents, then you can download it as a diff by appending ".diff" to the end of the pull request URL in github. Same for patch. The patch would be the same as doing a cherry-pick in a way I guess if you apply it with git am < file.patch There are many other ways to go about doing this. For example you could make a cherry-pick of the commits that are pull requested. (fetch the pull request repository and then do a cherry-pick firstCommitHash^...LastCommitHash) It seems you can also try reference the pull request repository through TC repository as seen here: git fetch origin pull/PRID/head:BRANCHNAME origin is assumed to be trinitycore repository.
  5. Its enough to just change the DB names in configs (and in DB hurr durr). I use this all the time to hop through the 5 different core/patch combinations I have.
  6. Hmm, looks like it does tho: master: 3.3.5; maybe you should post the error message. You probably have not included Player.h or WorldSession.h or something lke that
  8. You probably downloaded them as zip files instead of using git to download it (clone) The installation guide tells you what you should do.
  9. They were probably moved to rbac as permissions
  10. Follow the TC requirements page guide on how to install visual studio.
  11. Try delete cache folder in wow installation folder. What patch is this on?
  12. Changed windows guides. Another reference is made here though: Btw. this reminded me about this from 2013
  13. Should change release to RelWithDebInfo in the guide?
  14. Debug builds contain debug code and run a lot slower. Release is optimized more for actual production. Compile your core with release instead of debug to make it run fast.
  15. If you change things in your source folder (D:/Trinity) then you need to run cmake which will alter the files in the build folder, like the sln file. Also as you build the core many files will likely change inside the build folder, like logs and binary files and so on. But you probably dont want to keep track of the changes cmake does to build folder or the changes compiling makes to build folder or bin folder as those are not "your changes"
  16. Not sure how well Visual Studio 2017 is supported yet. Other reasons could be that you did not install your VS with C++. Did you explicitly select that you want to install C++ when you installed VS like the TC requirements page says?
  17. Can you post all the text in this box? Im not sure if read only is an issue. Could be, but the program shouldnt actually edit the files. Make sure D:/Build is not read only as files will be written to it.
  18. If you make changes in TC source files, then I guess the repository is C:\Trinity if you are using that as the source (see cmake what is source folder) If you make changes in DBC files then you should probably have them in a separate folder that has another git repository or you could move them to the TC source folder (the TC repository) when you want to add them to the version. To back up the config files you should do the same as with DBC files. Either have them in a folder that is a git repository or move them to TC source folder. One option is also to make the server folder a git repository, but Im not so sure that is a good idea. The whole build folder being a git repository seems to me like a bad idea. Though it will capture all changes you have done in the sln file. I think though that you should be editing the cmake files and not the sln file as when cmake is run your sln changes may get lost I think (did not test).
  19. Personally I dont use git extensions. I use git bash. But Im sure you just open the repository in git extensions, click on the "commit" button, stage your changes, commit them.
  20. What does C:/TrinityCore contain? In the image above it seems to contain stuff it shouldnt (some git stuff?) How did you clone the source exactly? It should contain the files you see here: or here
  21. Btw. you may have downloaded "wrong" boost. Im saying this because you are missing the lib* folder in the image. You probably want the precompiled version instead of the plain source code. Otherwise you would need to compile boost before compiling TC.
  22. A lot of people have asked how to debug so I made this short guide on how to set up debugging. This will not explain the basics of debugging. You can google those or play around with the debugger to learn. There are guides for Linux and Windows. (though linux is not as detailed) This guide contains multiple guides. Each list of bullet points is it's own guide. Make sure you can run the server normally before trying to debug. On Windows before anything you should check these - Before debugging or making crashlogs etc. with Visual Studio you must compile the core in "Debug" instead of "Release". You can select this in "Build>Configuration Manager" or at the top of Visual Studio window - You also need to move the new pdb files generate by compiling in debug mode on Visual Studio from the compile output folder (bin) to your server folder - these files contain information needed for debugging. - It is assumed that Solution Explorer is open. Open it by selecting "View>Solution Explorer" in Visual Studio -- You may want to click on the Home icon to reset the view on Solution Explorer - You can place breakpoints in Visual Studio editor by right clicking a line of code and selecting "Breakpoint>Insert Breakpoint" - At the top of the window you should see controls for stepping and continuing when you have started to debug. - Here is a video showing the basic Visual Studio functionality First off we go with the fastest way to debug on windows. This is the easiest way to start up debugging a script. - Start the authserver and worldserver normally - Open TrinityCore.sln in Visual Studio. This is what you usually open when you want to compile the core - In Visual Studio at the top select "Debug>Attach to process...>worldserver.exe" and click "Attach" - You are now debugging The second slower way of debugging on windows. This is useful for debugging something that occurs in the startup of the server. - Open TrinityCore.sln in Visual Studio. This is what you usually open when you want to compile the core - In solution explorer right click on worldserver and select "Set as StartUp Project" - In solution explorer right click on worldserver and select "Properties" -- In Properties you should go to "Configuration Properties>Debugging" and edit "Working Directory" to point to the server folder. For me this is the default compile folder so I use "$(OutDir)" - Start the authserver normally - Start the worldserver by selecting "Debug>Start Debugging". The server will start with debugging attached from the beginning - You are now debugging Crashlogs on windows. Once you have a way to reproduce a crash you can get a crashlog that can help you resolve it. - After compiling the core in "Debug" instead of "Release" start up the worldserver and authserver - Reproduce the crash you have - In the server folder there is now a folder called Crashes that contains txt and dmp files. - You can open the txt files in text editors -- At the top of a txt file there is some information about your system and below it there is the Call Stack and below that there are Variables of each part of the call stack -- The Call Stack will tell you at the top what was the last function call before crashing and what function calls led to that function call. -- Next to the function names there is the file that the function is defined in and the line number the code was executing in that function. -- In the Variables section you can inspect variables that were present at each function call. -- Based on this information you are often able to see what crashed or get a better view of what you need to inspect more in your code. - The dmp file can be opened in Visual Studio -- Open TrinityCore.sln in Visual Studio. This is what you usually open when you want to compile the core -- Drag and drop the dmp file to Visual Studio -- In the window that opens click to "Debug with Native Only" -- In the window popup click "Break" -- You are now in a state like you would have hit a break point in the code or a crash while debugging. You can inspect the call stack and the variables. Edit and continue on windows. When debugging this allows you to change the code and without restarting the server apply those changes so they actually work ingame. - Open TrinityCore.sln in Visual Studio. This is what you usually open when you want to compile the core - In solution explorer right click on worldserver and select "Properties" -- In Properties select "Configuration Properties>Linker>General" and set "Enable Incremental Linking" to "Yes". -- In Properties select "Configuration Properties>Linker>Advanced" and set "Image Has Safe Exception Handlers" to "No". -- In Properties select "Configuration Properties>C/C++>General" and set "Debug Information Format" to "Program Database for Edit And Continue". - At the top of the window select "Tools>Options". In the Options select "Debugging>General" and in there select "Enable Edit and Continue", "Enable Native Edit and Continue" and "Require source files to exactly match the original version". - Compile the server for the changes to take effect. - Set up "The second slower way of debugging" (I did not test edit and continue on other configurations) - Start the authserver normally - Start the worldserver by selecting "Debug>Start Debugging". - Try edit a cpp file a little and save it. - At top of Visual Studio window select "Debug>Apply Code Changes" and wait until the changes are applied. Warning: it can take considerable amount of time for the changes to be applied. - If you have issues, be sure to check the error messages in Output. You can view it by selecting "View>Output" - This guide was written based on and Debugging on linux. You can debug on linux by using GDB. - Here is a good video about it: - Basically you -- Start the authserver -- Start the worldserver by using "gdb ./worldserver" -- Enter breakpoints by using break command on gdb -- Use the run command on gdb to start the server -- You are now debugging - You may also be interested in using VScode or some other more visual debuggers. Crashlogs on linux. Once you have a way to reproduce a crash you can get a crashlog that can help you resolve it. - Compile the server with the cmake flag -DCMAKE_BUILD_TYPE=Debug - Take crashreport.gdb from /contrib/debugger from source folder and place it to your server folder - Start the authserver - Start the worldserver by using "gdb -x crashreport.gdb ./worldserver" - Reproduce your crash - There should be a backtrace.log in your server folder that contains information about the crash like the callstack and variables in each function call in the call stack - This guide was written based on Running valgrind on linux. This helps you find memory errors like invalid reads and writes and memory leaks. - Here is a good video about it: - Basically you -- Start the authserver -- Start the worldserver by using "valgrind ./worldserver" -- Run your code that you want to analyze and close the server -- The console or an output log should contain the valgrind log
  23. Debugging does not require incremental linking, so if someone has issues with that they should disable it. Incremental linking is required by edit and continue however. So if the build gets stuck then you cannot use edit and continue and should disable incremental linking.