Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Magnuss last won the day on June 18

Magnuss had the most liked content!

Community Reputation

20 Excellent

About Magnuss

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    : Switzerland

Recent Profile Visitors

2475 profile views
  1. You have to use the different search options.
  2. Compile or cmake problems

    Just use any new folder you want but NOT the build folder. (And also NOT c:/program files/something because they are write protected.) This configuration is the same for static or dynamic linking.
  3. I see. For caching purpose.
  4. Locking to the code I came to the same conclusion. xD Thanks for the fast fix. But I also got the impression that this table is only to save the quest status as a kind of summary. Internal the requirements seems to be checked on the fly whenever needed. What is the purpose of this table exactly?
  5. Quest templates can have up to 6 required items. Quests are working well with 6 requested items. I checked it with a custom quest. But in the table character_queststatus are only 4 fields (itemcount1 - itemcount4) that have counters for the requested items. How does this work? Is the character_queststatus only an informal table for the first 4 items ?
  6. You should set your focus on the fact you have TrinityCore rev. unknown 1970-01-01 00:00:00 +0000 in your log. It's quite useless to search the problems at the different SQL files. If you setup the files manually it's likely you will do it wrong. If your core is up to date and has a proper commit hash incl. timestamp you don't need to take care anymore for the sql update. Everything will be done automatically. Post your CMake log. I'm quite sure there is already a warning there.
  7. Personally I think you should check why you have TrinityCore rev. unknown 1970-01-01 00:00:00 +0000 in your log. Normally there is a new timestamp and a commit hash. Maybe you made something different by pulling the git repository. Please read the wiki again. I don't know if this is the reason for your problems with the database. But at this point I don't have any more ideas, sorry.
  8. Repack is a very bad word here in this community. ;-) You have to take an original Trinity Core as descripted in the wiki. Nothing else, otherwise we can help you. TrinityCore rev. unknown 1970-01-01 00:00:00 +0000 shows that you have used a repack (or have done something else wrong) Or you have to ask the issuer of the repack what you have to do. TDB_full_world_335.64_2018_02_19.sql goes into the folder where your worldserver.exe is. But it works mostly only well together with original Trinity Core.
  9. Yes, that's it. Is your world database still empty or was the inital setup from the TDB 335.64 successful ? Edit: 1146] Table 'world.updates_include' doesn't exist ( Ok, I think it's still empty ;-) )
  10. The crashlog is useless. This line show that you have made something wrong or didn't use original Trinity Core: TrinityCore rev. unknown 1970-01-01 00:00:00 +0000 As far as I remember you have to change in the worldserver.conf something that autopopulates an empty world database. Please recheck if it's on.
  11. I found 2 very simple solutions: Solution 1: Change the name back to TDB_full_world_335.63_2017_04_18.sql (or whatever you have started once with the custom project). Thanks to the magic of programming of this wonderful updater the updates are processed in the right order. The name of the full database is in revision_data.h.in.cmake . Solution 2 (not tested): Provide an own full world database file. As far as I have seen you need only to do all updates incl. custom updates into a clean database and than export it. Thanks to the table updates and its hashes the updater knows later what to do. (Additionally you may also need to save a starting file with the db structure of auth and characters at the beginning of a custom project. Depends of what kind of custom sql queries you have.)
  12. Hello, I don't understand how to use custom SQL queries in files in the /sql/custom/xxx folders in the right way. Here's an example of what I'm doing: In Juli 2017 I start a complete new project and use TDB_full_world_335.63_2017_04_18.sql and all the stuff from git repository at this date. I commit to whole stuff in my own git repository. In Aug. 2017 I made some database modifications, create therefore some custom SQL files. I let do the core an automatic update as usual. I commit the custom SQLs in my own git repository. I do regular updates of TC 3.3.5 branch and merge them in my repository. In the meantime databases and table change their structures by different TC updates. In Spring 2018 Trinity is providing a new TDB_full_world_335.64_2018_02_19.sql In June 2018 somebody else would like to start on another system a copy of our customized project. He's cloning the custom project from git repository and compiles it. At the updating process the core is asking for TDB_full_world_335.64_2018_02_19.sql After that (I guess) the core is applying outstanding TC updates and all the custom sql updates I made before. But how can I prevent possible database conflicts between my sql queries in the custom updates I made in Aug. 2017 with the database structure of Spring 2018 ?
  13. Compile or cmake problems

    I use TC335 core on a Windows 8.1 without any problem. Now I have setup a Windows 10 Build 1803 system and got different problems. CMake produces different errors, it doesn't recognize well Boost and OpenSSL. It finds the Boost root folder and I set manually the openssl root and include folder. It find something but not all libraries. But looking into the log I found the line 'Detected 32-bit platform'. That's definitely wrong. I guess CMake is looking for 32bit libs now. But I have everything in 64bit. I use: CMake 3.11.3 / VS Community 2017 Ver. 15.7.3 / OpenSSL 1.1.0h / Boost 1_66_0 or 1_67_0 CMake Log (Debug Mode): https://pastebin.com/Et54UWG5 Any ideas ? EDIT: Found the problem. On a completely new system you need not only to choose the right compiler, you also need to choose the right complier for 64bit ;-)
  14. @Aokromes Good to know, I changed that part in the wiki. Is it also updating the IP if it's a dynamic IP ? @Vell May you should remove the record in your hosts file. Because the core is than using a wrong IP if you set a domain name in the address field. *******.ddns.net
  15. https://trinitycore.atlassian.net/wiki/spaces/tc/pages/2130016/realmlist#realmlist-address As far as I know address must be a numeric IP address not a domain name. The core doesn't resolve name and isn't updating dynamic IPs. Means you have to update the IP manually whenever it changes. Somebody correct me if I'm wrong.