Jump to content
TrinityCore

Kylroi

Members
  • Posts

    385
  • Joined

  • Last visited

  • Days Won

    17

Kylroi last won the day on December 17 2015

Kylroi had the most liked content!

About Kylroi

  • Birthday 09/03/1970

Profile Information

  • Gender
    Male
  • Location
    http://pastebin.com/u/Kylroi

Recent Profile Visitors

4437 profile views

Kylroi's Achievements

Newbie

Newbie (1/14)

39

Reputation

  1. On those requirements, did you happen to do any of the optional part (namely the first optional item)? Meaning, do you have the appropriate redist package for the Visual Studio version you're running? You say other, already compiled versions do the same thing, suggesting a missing/bad DLL file is involved. Reinstallation of the compiler and the appropriate redist package(s) would be my first suggestion. Does anything else behave wrong on your system?
  2. Ah, like the lawn mowing wind riders in Org (4.3.4 branch) and the many duplicate spawns (NPCs and gameobjects), huh. One has to wonder if some of these errors aren't the result of typos (signed vs unsigned or vice versa). Maybe a slight buffer overflow or stack size being too small? Perhaps, a simple issue of a variable not being cleared or initialized properly? Surely, such things would show up during compile and/or debugged, though.
  3. Except, based on the files listed and comparing to the log lines given, it would seem that the server was failing to load tiles which actually exit. Isn't the filename in the MMMXXYY.mmtile format (MMM=map, XX and YY are obvious)?
  4. Safe to assume it isn't something simple, like file permissions?
  5. Hmm. By any chance, were you using GM flight to go where players aren't supposed to reach? I've seen failed mmap loads for such areas on the 4.3.4 core. I assume your rebuilding of the data resulted in the same behavior, anyway.
  6. Just to be sure, you are making sure that the extracted files and generated maps are in the correct place as defined in your configs. Right? Are you manually running everything or using a shell script to perform the process? Not that you need it (but just in case), I use mkmaps.sh to extract/generate my data. In case you want to use it, the ClientDir, DataDir, and MMapsGenArg variables are the only things you might need to change. Comments in the script should explain what's going on with everything. Obviously, I run the script from the directory containing the executables. Minor alteration could allow for the script to run from any directory.
  7. auth.realmlist should have both Internet (aka public IP, in the `address` column) and local (aka private IP, in the `localAddress` column) addresses. The `address` column can be a host name, so `localAddress` may work the same. I assume your router is forwarding both ports (3724 and 8085, and only tcp packets are needing to be forwarded) to the appropriate server machine.
  8. I would check the realm configuration of the server (check worldserver.conf and the realmlist table on the auth database). If it's set for 127.0.0.1, only the hosting system will be able to connect to it. You can also compare those settings to the contents of a working repack. I'd wager that will reveal the issue.
  9. Using the object link, as in ".gob add tem [Chapel]", from the search results in "Game Object (Entry: 0) not found". Somehow, it would seem that the gameobject command was damaged by an update.There may even be other commands which were broken by the same update. I know that I used to be able to spawn objects by looking them up and using the link from the search results (I had, at one point, spawned some mining veins on GM Island, among other things).
  10. I think there's also the issue of not being sure of the proper way to implement some things. Of course, being a community project, we can't blame the "official" developers when anyone could be writing patches or processing their own sniffs for missing data and submitting them.
  11. The gitlab project isn't an official Trinity project. Certain Trinity devs are still working on it, though.
  12. Looking at that script, the current "version" code will always be broken. "if is_running; then" is always false since "is_running" isn't a defined subroutine, unless you added it. Make it "if is_running_worldserver; then" and it should work. Also, I suspect that the "tac" command after that if should be "cat". However, the log file could simply be added to the "grep" command to get the same result. Plus, the "This server is running" needs to be changed to something that matches the Trinity log. You could try using 'grep -m 1 "TrinityCore rev" $LOGPATH/server.log' in place of the current grep line. There are other issues with that script, telling me to stick with what I wrote (something I currently run manually because I simply haven't added it at boot time, and I have companion scripts using both bash and perl): http://pastebin.com/uaC8GF83 http://pastebin.com/3BVJ5SpC http://pastebin.com/bPedQwZK http://pastebin.com/mtfn5dCV or http://pastebin.com/8KzB13En I don't know if bnetserver is a required aspect for normal worldserver operation or not, but that init.d script (as it is) doesn't do a thing with the bnetserver process. I know that my scripts start/stop bnetserver, though. As far as it starting at boot and then not being active after the boot process, it may be getting run at the wrong time (too early), then a runlevel change is performed. That runlevel change will likely stop processes not being used by the new runlevel, resulting in the servers being stopped.
  13. There's no "official" repository, thus no official support for 4.3.4, but there are some forum users still able to spot issues which could happen for all supported versions. Case in point, the database errors look like incomplete or improperly created base databases (sql/create/create_mysql.sql, sql/base/auth_database.sql, sql/base/characters_database.sql, followed by http://community.trinitycore.org/files/file/9-legacy-tdb-full-434/). Another possible issue is that you created everything properly, but used a different mysql user than what the server(s) are trying to use. If that was the case, you could be getting denied access to the tables which are being accessed. Of course, not having access would likely be part of the improperly created databases option. I hope that helped point you in the direction of fixing your issue.
  14. Looks like a bad copy of the source (invalid revision identification) to start with. You may want to rebuild your source tree with a git client and try again. Also, the DBErrors.log is indicating a bad world database creation.
  15. Why not just copy the WoW client's Data (possibly Cache, too) folder to your Debian compile and run those extractors?
×
×
  • Create New...