Jump to content
TrinityCore

jududdar

Members
  • Content Count

    17
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by jududdar

  1. No no, quest givers aren't handing them out. They're simply still there in the database - I didn't know if they were being left there for posterity's sake, or if they were planning to remove them at some point. They're not hurting anything at all, just appearing as I was doing some lookups and making lists of quests to test.
  2. In looking through the database and testing quests, I've found a few that are deprecated (and labelled as such). Are these outdated quests being left in the database for a reason, or just doesn't help anything to remove them? Simply wondering whether I should report these or just leave them be. Thanks!
  3. Tried that, takes me back to the old errors... trying to connect to localhost again. I know with git, it's highly unlikely that I have a botched install, but since I've already got the dbc/maps/vmaps/mmaps, I may just try to rebuild it from scratch to see if I've messed anything up.
  4. So I got it to work... sort of. I went to /etc/mysql/my.cnf and under the [client] section added host=192.168.0.30 protocol=tcpNot a very elegant solution, but it does what I need it to do!
  5. Minor update: I went into /etc/mysql/my.cnf and told the client to only use TCP as a test. The error I get with that is >> Applying update "2015_07_02_00_auth.sql" 'E5EE384'... ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (111)Same error I get if I just run "mysql" with no arguments from the terminal. I know 111 is connection refused, but there's no mysql server running, so I guess not existing can be a method of refusal.
  6. Removed all of the additions from that commit and recompiled, same issue. I'm probably hung up on the wrong thing here, but when I have the local mysql server running, it appears to be attempting to connect to the local instance - when I do not have it running, I get the socket error. It's my assumption based on what little bit of the code I can understand that unless I am throwing the connection string like this: ".;/tmp/mysql.sock;root;password;WoD_auth"The server will attempt to connect via TCP instead of via sockets - yet the error is telling me it can't find the socket. Banging my hea
  7. My assumption all along is that I am just connecting via IP, but when the MySQL server isn't running on the local machine, I do get a sockets error? This is where it doesn't make sense in my head - I'm not 100% positive that in doing the update query, the updater is even connecting to the remote MySQL server. I did a bit of research on sockets as I've never dealt with them before, but none of the nomenclature I could feed into the connection string got me any further. I'll describe my setup below if it will help any: Trinity 6.x server = Debian 8.0 x64 (192.168.0.62) Trinity 3.3.5a server =
  8. Alright, didn't work this time. Here is the console output: Updating Auth database... >> Applying update "2015_07_02_00_auth.sql" 'E5EE384'... ERROR 1049 (42000): Unknown database 'WoD_auth' Applying of file '/home/<username>/TrinityCore/sql/updates/auth/2015_07_02_00_auth.sql' to database 'WoD_auth' failed! If you are an user pull the latest revision from the repository. If you are a developer fix your sql query. Could not update the Login database, see log for details. MySQL server is installed on the machine, but the service is stopped (I assume it has to be there to compile
  9. (none of this was wholly accurate looking back, just reference post below it)
  10. You're only trying to source the file: sql/updates/auth/2015_07_06_00_auth.sql into your database, correct? The other file: sql/base/auth_database.sql is edited to reflect initial setup, not after the fact.
  11. Newest code commit seems to fix that - recompiling now: https://github.com/TrinityCore/TrinityCore/commit/d8338669d51fe114ce0698ddde44de113d95e76e I've got to get rid of Battle.net to see if that's what keeps making my client update, but I want to keep my Hearthstone - gotta login once a month to keep my card backs coming!
  12. Here's a bit of an odd question regarding database auto-updates: I host my MySQL database on a separate server as I got tired of having multiple VMs with each having their own local MySQL install. This has been working out great as I host a couple of 3.3.5a servers and a 6.x server along with a few different web servers. Is there any way possible to specify a database host for the auto updater? I don't have a problem with applying the updates manually, but in the past it was pretty nice to git pull > recompile > launch program with updates auto applying. If this doesn't exist, I'm not
  13. You won't find anybody on the forum to upload DBCs/maps/mmaps/vmaps for it. It is in the forum rules posted here. I am in the exact same boat as you guys. I blew away my 6.x server to move it to a different host and am now patiently waiting on the core to get updated to support the new DBC files from 6.2. The devs will get there in time - I see multiple commits daily fixing up 6.2 things!
  14. Okay, thanks! I guess I'll just start playing through and reporting things I see (provided there's not already something on the tracker for it). Although I'm not really proficient with programming or SQL skills, I'd like to contribute whatever I can, even if it's just play time.
  15. Greetings all, I just have a few questions about the current state of 6.x to make sure I'm doing things right and don't open needless issues. Here's what I've done: Compiled latest rev (812fa65c613e as of today) using Debian 7.0 x64 and Windows 7 x64Created dbc, maps, vmaps, and mmaps on bothImported latest TDB and all of the world/hotfix updates in the /sql/updates folderUsed correct client to connect to both, and experienced same issuesHere's what I'm experiencing: Major: Trainers of any sort do not work (blacksmithing, enchanting, riding, flying, etc)Flight paths do not work (EDIT: appea
×
×
  • Create New...