Kylroi

I stand by my "lazy developer" comment. If you don't have time or can't be bothered with filtering things out of a repository open to the public, that is NOT the communities problem. Own up to it. Admit your failings. Real life does take priority, but don't lie about why you have obviously wrong things in places that YOU have control over. Take responsibility. Stop placing the blame on other people. As for myself, I am operational on the HEAD of the 4.3.4 branch (well, my fork is, anyway). I have a couple patches on my fork that haven't made it to the Trinity repository. One of the patches I was applying has been added, but it wasn't a patch that I created (I only contributed to that patch being made by way of an issue ticket). I also have a bit of DB content from other sources (myself for some, but not all).

In other words, 1-3 are all the direct result of lazy developers. Fair enough. Before you take offense to that, what else would you call a developer that pushed sloppy content not meant for public use to a public repository? Temporary? Why was that content even pushed out? It can be shared via some other method that isn't revealed to the general public. If you guys don't know that, you really aren't qualified to work on a project such as this. I have code of my own that isn't ready for public use. It's not on my repository or published in any way because I don't want someone getting upset by it not working as expected or reverting functionality that they didn't want. As for 4, I did perform a search relevant to the updates and 4.3.4, but it either wasn't listing that thread in the results or it was very low on the list (on a secondary page, maybe). However, "4.3.4 sql updates" had this thread as #2 on my results (#1 is a closed thread that doesn't answer the issue). That was a search for the entire site, not just this specific forum. Still want to say that using the search will answer perfectly every time? Don't be a fool and say "yes". That search term is pretty specific on the issue and should easily catch any thread mentioning the question/problem.

Fair enough. On the same line, however, separate concepts tend to blend together. You may wish to keep that in mind for future posts. Just so this is available for others to find without asking it again and again: What exactly is the point of the sql updates in the TC repository for the 4.3.4 branch? Why are there updates specifically flagged 434 in the filename if they are still not to be used? Why are there ANY updates in the 4.3.4 branch flagged with 335 in the filename? I believe that having those questions asked and properly answered will help eliminate many of the threads created as a result of DB creation errors. Surely, you can agree with that, especially with those 335/434 files being available even when staying in sync with the TDB repository.

More indications of hostility, intentional or not. Not even you were perfect when you began everything in your life. I bet you fell a lot when you started to walk (we all do). Same goes for riding a bike, writing, spelling, and even using search boxes. Did you really have 100% perfect search use the very first time you ever used a search box? I bet not. Lighten up. Don't be so aggressive towards people that aren't as computer literate as you and I seem to be. Have you ever needed to point me to the search box? I do still have one problem, though. I reflect (and almost always amplify) the type of feedback I get. Lately, and I assume there's some personal problem causing it, you have been showing more and more attitude. The community isn't your enemy. New members are simply not going to know as much as you know about this project. I know I have a lot to learn still, but I try every search I can think of before I ask for assistance. I'm not Joe Average, though.

Excuse me? Do you realize that you effectively contradicted yourself there? If TC and TDB are in sync, there shouldn't be any sql updates from TC at all. Otherwise, anything that changes the DB structure would, supposedly, break that revision of the core. Or, are you saying the TDB repository is not as perfect as you guys keep insinuating?

Forgive me, but many of the "I can't get worldserver to run" posts are a result of people doing EXACTLY what the wiki says. Meaning, they don't apply the updates from the TC 4.3.4 repository, so the server fails to work. They can't ignore that update tree AND still run the server. So, how about amending that "don't use" clause to list the required exceptions? For the record, I recently created a test world database. I started with the 434.05 full, applied the TDB updates, then applied all of the TC 4.3.4 world updates. I just wanted to see what the errors were. I seem to recall that there was only 3 or 4 (if that many, actually) "errors" that I filtered out. The only errors I saw were dealing with a table that was removed (it was something about creature AI). I can't speak for any other conflicting changes, though (i.e. updates that actually reverted things to pre-Cata settings). Is it possible that the "*434.sql" (102 of those as of rev adc4b3b46b0d) files are safe to use? I seem to recall that none of those had to be excluded in my test.

If you're familiar with both C++ and SQL (MySQL specifically), you should be capable of using the updates from both the TDB repository as well as the updates from the core repository (assuming that you stick with the 4.3.4 branch...using the updates from the master branch would certainly mess up the database contents). There will be certain conflicts, but they will be easily filtered out by someone familiar with SQL. From there, you will find plenty of erroneous and missing functionality which you are more than welcome to contribute towards core and/or database development. All that is asked is that you follow the coding methods and SQL structure that is detailed (I forget where, but I think that's all mentioned on the forums here).

You should have something like the following: | GRANT ALL PRIVILEGES ON `world`.* TO 'root'@'localhost' WITH GRANT OPTION | | GRANT ALL PRIVILEGES ON `characters`.* TO 'root'@'localhost' WITH GRANT OPTION | | GRANT ALL PRIVILEGES ON `auth`.* TO 'root'@'localhost' WITH GRANT OPTION | Your grants listing suggests an incomplete or improper MySQL setup. Additional thought: In theory, your grants should be ok. My setup uses a modified version of the sql/create/create_mysql.sql file (changing the user and password as I saw fit).

Close, but not quite. The command I gave is what you run in a CMD command line window. When at the "mysql>" prompt, you should not need "-uroot -pascent -e" or the quotes. You do, however, need to end the query with a semicolon (. You aren't retarded, but you are showing your lack of knowledge of SQL. You may wish to read up on that if you intend to run your own server. Trust me, that will help, despite what some others will insist. Luckily, the syntax (command structure) is quite simple.

For command line, you could execute: mysql -uroot -pascent -e "SHOW GRANTS;" The line with "IDENTIFIED BY PASSWORD" isn't important. Just need to see the specific database grant listing. As I believe I said before, to benefit other users that may run into the same problem, it would be best to keep the conversation here. Plus, if we run into a brick wall, you won't have to explain everything all over again when someone else tries to help. Public records are are a good thing, even if they do seem to take forever.

Just to be sure, execute "SHOW GRANTS;" (via command line or GUI interface...at least my GUI can do it) and paste the result.

Since we're seeing the world database login info, could you post what LoginDatabaseInfo (authserver.conf) is set to? You aren't getting a table missing error, so it's some issue with initial connection. I assume that worldserver.conf has the same connection information for auth, characters, and world. I just want to see if there is anything different between the 2 files. Surely, you didn't set a connection limit for the root user (https://dev.mysql.com/doc/refman/5.5/en/user-resources.html).

http://www.trinitycore.org/f/topic/9214-updated-trinitycore-requirements-deprecation-of-old-compilers/ That covers what you need. Looks like v12 is the 2013 release.

Upgrade your compiler version. You have VC v10 and the code now needs v12.

Yes, they should be, but they aren't always. Especially when crossing from x86 to x64. Sometimes, and I ran into this personally, the x86 compile will be using calls that the x64 OS just doesn't answer the same. No, it wasn't a TC issue. There were no missing DLL files for my own app. The app simply went instantly "not responding" to Windows 7 x64. It ran perfectly on Vista x86, though. Glad you got it fixed up, though. I had assumed that you already knew to match the redistributable version or I would have added that to my first response.

It might work if the same VS 2013 Express was installed on the public server. Even then, you may still need to recompile on that computer. Also, advertising it as a public server isn't exactly a good idea on this site at all, though. The Trinity crew doesn't help anyone with public server issues.

Sounds like a bad/incomplete 4.3.4 client. I've heard that a few of those are floating around. Even my copy seems to be missing things that mapextractor looks for. However, I seem to recall that certain map files were removed in 4.3.4, with others only available on the DVD distribution. The rest of the tools run without error or warning, though.

For 4.3.4, I have: DBC: 328 files Maps: 7192 files MMaps: 4717 files (142 .mmap, 4575 .mmtile) VMaps: 13668 files (9904 .vmo, 142 .vmtree, 3622 .vmtile)

So, auth.realmlist, column gamebuild is saying 12340? That sounds like you're using the master branch (3.3.5a) authserver process. As for the SQLDriverLogFile, I assume you uncommented "#Logger.sql.driver=3,Console Server" in your worldserver.conf.

MySQL and worldserver are running on the same computer, I assume. Possible firewall conflict? Which operating system?

It's leftover merge failure. In src/tools/CMakeLists.txt, change #if (WITH_MESHEXTRACTOR) # add_subdirectory(mesh_extractor) #else() # add_subdirectory(mmaps_generator) #endif() to if (WITH_MESHEXTRACTOR) add_subdirectory(mesh_extractor) else() add_subdirectory(mmaps_generator) endif()

Or your tongue has to be hanging the right way.

You're assuming that TDB was used and not some other world DB (that changed things in a way to break the official updates). Perhaps they used a repack as a starting point, which used different account settings for the MySQL install, too. Assuming that only the Trinity sql files were used, the same account information was used for the create files as well as for the shipped conf.dist files. As such, how else was there an access issue?

I assume you're just clicking the icon for the program, so please start it from a command prompt and copy/paste the error here. We can't tell you what is wrong based on nothing other than the window closes.

The Express versions, as I understand it, tend to have trouble with compiling in 64-bit. CMake may have detected your system as 64-bit and set the project to compile accordingly. I know I didn't have to specify 64-bit compile for my Linux install, anyway. When you load up the sln file, I believe there should be a Win32 or Win64 showing next to the build mode (defaults to Release). If it's on Win64, try rebuilding as Win32 and see if that works better for you. If it's already Win32, someone else may need to step in. I stuck with 32-bit Windows for the most part on my server system (the board has a max RAM of only 3GB, but has a 64-bit processor...go figure). It's a rather old board (Socket 754) with an Athlon 64 3200+ in it. Due to the age of my server system, I find Linux to be a better choice. It's certainly running faster in Linux than it did on Windows (used XP and Vista on it). If you're using a spare system for your server, you may want to consider switching over. You wouldn't necessarily need to disable X Windows like I did, but I'm just as comfortable with a command line as I am with a GUI.