• Content count

  • Joined

  • Last visited

  • Days Won


Rochet2 last won the day on July 28

Rochet2 had the most liked content!

Community Reputation

189 Excellent


About Rochet2

  • Rank
  • Birthday 10/26/93

Contact Methods

  • Website URL
  • Skype

Profile Information

  • Gender
  • Location

Recent Profile Visitors

6417 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  7. You probably downloaded them as zip files instead of using git to download it (clone) The installation guide tells you what you should do.
  8. They were probably moved to rbac as permissions
  9. Follow the TC requirements page guide on how to install visual studio.
  10. Try delete cache folder in wow installation folder. What patch is this on?
  11. Changed windows guides. Another reference is made here though: Btw. this reminded me about this from 2013
  12. Should change release to RelWithDebInfo in the guide?
  13. 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.
  14. 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"
  15. 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?