Kylroi

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?

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.

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)?

Safe to assume it isn't something simple, like file permissions?

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.

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.

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.

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.

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

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.

The gitlab project isn't an official Trinity project. Certain Trinity devs are still working on it, though.

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.

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.

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.

Why not just copy the WoW client's Data (possibly Cache, too) folder to your Debian compile and run those extractors?

Try the following script: #!/bin/sh # site settings User="kylroi" ClientDir="/home/$User/WoW Client/World of Warcraft" DataDir="/home/$User/WoW Server/Core/data" # these should be safe to leave alone DBCDir="dbc" MAPSDir="maps" MMAPSDir="mmaps" VMAPSDir="vmaps" BLDGDir="Buildings" cd "$ClientDir" # clean any existing data directories if [ -d "$DBCDir" ]; then rm -rf "$DBCDir" fi if [ -d "$MAPSDir" ]; then rm -rf "$MAPSDir" fi if [ -d "$MMAPSDir" ]; then rm -rf "$MMAPSDir" fi if [ -d "$VMAPSDir" ]; then rm -rf "$VMAPSDir" fi if [ -d "$BLDGDir" ]; then rm -rf "$BLDGDir" fi # extract dbc and map files ./mapextractor cp -r "$DBCDir" "$MAPSDir" "$DataDir" # extract vmap files ./vmap4extractor # create vmaps directory and build core vmaps mkdir "$VMAPSDir" ./vmap4assembler "$BLDGDir" "$VMAPSDir" cp -r "$VMAPSDir" "$DataDir" # build mmaps (movement maps) - the longest process mkdir "$MMAPSDir" ./mmaps_generator cp -r "$MMAPSDir" "$DataDir" Obviously, you'll need to adjust the User, ClientDir, and DataDir variables for your system. I also have symlinks for the executable in the client dir, as can be guessed by their execution method. Assuming you have the database correctly created and the .conf files set correctly for your configuration, this script should put the appropriate files into your data dir. The mmaps creation is known to take a very long time to finish. If you do not wish to use them, you can comment out that portion of the script. That way, you could decide to activate the mmaps support later and already have a script that could generate that data again (if necessary). As for your questions: 1) you can't 2) Google is your friend 3) yes, they should 4) realmlist.conf? never heard of that one. am I missing something on my operational 4.3.4 server?

The base spell damage is going to be found in a dbc or db2 file, but intelligence turns into spell power. So, you can adjust the intelligence stat for some control over spell damage, but that won't really put as much of a limit as you may want. Various items also add stats, including attack power and spell power, so you could be looking at a lot of work to limit that. Do you feel like manually editing every single item (weapons and armor) in the game to ensure a certain limit?If unaltered, the stat reached the 8000 range (try about double that for Cataclysm stats), you may find that the base stats of the character are negligible compared to the bonuses from the equipped gear.

I was mostly pointing out that the commands you posted included 3 commands (gameaccountcreate, link, and unlink) which are not in the 4.3.4 branch. It was more for information to other people reading the thread. If it was important (to me, anyway), I would have created a ticket about it rather than make that post.

I see the 4.3.4 branch doesn't have all of those capabilities. Only "create", "lock", "set", and "password" seem to be in there. No way to link the accounts ("link" and "unlink" aren't in cs_battlenet_account.cpp for the 4.3.4 branch). An update to the support that wasn't merged into 4.3.4? I know the accounts were linked long before the 5.x or 6.x updates came out, but the 4.3.4 branch can't form that link.

http://collab.kpsn.org/display/tc/player_levelstats Maybe that will let you adjust the stats to your liking. You can adjust the stats for every level of every class, but you won't find a global setting to adjust them all. You'll need to tweak the appropriate stat values that you want changed.

Wouldn't it be just as easy to have your web form pass data to a script that executes the server commands (say, via telnet on port 3443)? Why do you require the method to be SQL? I even made a perl script that I can run on a Mac while TrinityCore runs on a Linux system. All that script needs is the console command to execute. The other settings are set in the script, and perl scripts are regularly used by web pages. Here's the perl script (edited to remove personal settings): #!/opt/local/bin/perl # 1/27 update - quotes around command when calling script are no longer needed use Net::Telnet; # adjust these variables for your server my $host = "<host IP>"; my $username = "<admin username>"; my $password = "<password>"; my $command = ""; if ($#ARGV == -1) { print "worldserver command not providedn"; exit; } if ($#ARGV == 0) { $command = $ARGV[0]; } else { for (my $l=0; $l <= $#ARGV; $l++) { $command .= $ARGV[$l]; if ($l != $#ARGV) { $command .= " "; } } } $telnet = new Net::Telnet ( Port=>3443, Prompt=>'/TC>$/' ); $telnet->open($host); my $stat = $telnet->login($username, $password); if ($stat == 1) { my @results = $telnet->cmd($command); print @results if scalar(@results); } else { print "login error for user: $usernamen"; } $telnet->close; That should be easily altered to work with a web page, if any alteration is even necessary.

Isn't the current requirements to use VC2012 (or is it VC2013)? I thought VC2010 was no longer capable of compiling the code.

Did you clean the project and make sure EVERYTHING was recompiled after patching the code? The error I see isn't a core problem but a compile issue.

If you went back to the "last sync" revision, the only updates you need are the ones in the TDB repository (ignore the sql tree from the core if you're only having world DB issues). Only when you update the core will you need to "just know" which updates for the core repository to use. Otherwise, you've applied changes to the DB that the core simply doesn't know about. In general, worldserver will be able to tell you which changes are needed, so you would need SQL knowledge to locate the appropriate files to apply from the core repository. That's the "just know" part. @Thugly I suggest you take your own statement to heart. Grow up. Someone mature wouldn't post like you did. There was absolutely no need to swear. As for those that don't speak English natively, maybe you should consider the fact that this is not a community made up from English-only countries.

Yes, stop head banging. You're only giving yourself a headache. I could say a lot more, but trying to add water to a sieve just doesn't do any good.