Jump to content
TrinityCore

Magnuss

Members
  • Posts

    318
  • Joined

  • Last visited

  • Days Won

    16

Posts posted by Magnuss

  1. Haha, I'm wondering how much people on german p-server translate quest_complete_texts parallel and manually :-)

    But the quest_template_locale table contains a lot of field names from an earlier core version.

    Actually the relations are:

    quest_template:LogDescription - quest_template_locale:Objectives
    quest_template:AreaDescription - quest_template_locale:EndText
    quest_template:QuestDescription - quest_template_locale:Details
    quest_template:ObjectiveText1 - quest_template_locale:ObjectiveText1
    quest_template:ObjectiveText2 - quest_template_locale:ObjectiveText2
    quest_template:ObjectiveText3 - quest_template_locale:ObjectiveText3
    quest_template:ObjectiveText4 - quest_template_locale:ObjectiveText4
    quest_template:QuestCompletionLog - quest_template_locale:CompletedText

    quest_requested_items:CompletionText - quest_template_locale:RequestedItemsText

    quest_offer_reward:RewardText - quest_template_locale:OfferRewardText

     

    May it helps, otherwise please make an example of a quest.

    • Like 1
  2. 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.

     

  3. 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.

     

     

  4. 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.

     

  5. 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.)

  6. 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 ?

     

    • Upvote 1
  7. 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 ;-)

  8. On 26.5.2018 at 9:12 AM, Magnuss said:

    In the auth Database table realmlist: localAdress 127.0.0.1 is fine but address should be your public WAN IP.

    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.

  9. I haven't checked your config in detail but just some hints:

    1. In auth and world config must be BindIP = "0.0.0.0" to grant the servers are listening on all IPs (Local, LAN, WAN)
    2. In the auth Database table realmlist: localAdress 127.0.0.1 is fine but address should be your public WAN IP.
    3. Router: Depending on your model you may have to set security rules AND forwarding the ports. Means: allow traffic and forward it to your computer.

    Hope it helps a little bit.

×
×
  • Create New...