CDawg

It isn't fully developed yet.

Only 7x and 3.3.5a (not sure how long 3.3.5a will be supported) That link for 4.3.4 (at least i don't think) is not officially supported by the TC community, just a branch from TC. No vanilla, TBC, mop, or WoD.

You can request access from the owner. Unfortunately, real life gets in the way for most of us. https://github.com/orgs/trinityclassic/teams/devs/members

That's really odd. I'm only able to duplicate the issue if I try to run another worldserver on top of one already running (same configs). It gives me that exact error that you get, the only difference, is that I get couldn't bind to port 8085 which is obvious since they are running on top of each other. Try disabling SOAP or RA in the configs... I only get an assertion error if they try to run on top of each other, or the SOAP port is in use. It just vomits the same message you get.

Found the problem!!! I was able to duplicate it. I was working on screen sessions and just noticed that I already had a worldserver running on that port. So it was occupied. Long story short. it looks like worldserver is not "restarting" properly. you have to do a full .server shutdown check that you don't have another worldserver running on the same port. Example: $ ps auxf | grep -i worldserver cellyson 14595 0.7 5.0 1490564 1250720 pts/2 Tl 16:06 1:06 \_ ./worldserver

Running Ubuntu 16.04 here also, with latest updates. Here is a comparison of what process' should be running for TC Here is my netstat. Note: I am running (2) servers, so you can ignore 7879 & 8086 my soap and world socket. Also with the latest updates there is a snapd.socket. Make sure that doesn't prematurely close, due to it causing segmentation faults. Also check selinux for any wonkiness going on there as well. I had to turn mine off. I'm still theorizing it is something with the network and not the code itself (not 100%) ~$ netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 192.168.1.11:7878 *:* LISTEN tcp 0 0 192.168.1.11:7879 *:* LISTEN tcp 0 0 *:3724 *:* LISTEN tcp 0 0 *:8085 *:* LISTEN tcp 0 0 *:8086 *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp6 0 0 [::]:ssh [::]:* LISTEN udp 0 0 *:bootpc *:* Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 17959 /run/user/1000/systemd/private unix 2 [ ACC ] SEQPACKET LISTENING 9112 /run/udev/control unix 2 [ ACC ] STREAM LISTENING 9100 /run/systemd/private unix 2 [ ACC ] STREAM LISTENING 9104 /run/systemd/fsck.progress unix 2 [ ACC ] STREAM LISTENING 9111 /run/lvm/lvmpolld.socket unix 2 [ ACC ] STREAM LISTENING 9113 /run/systemd/journal/stdout unix 2 [ ACC ] STREAM LISTENING 9115 /run/lvm/lvmetad.socket unix 2 [ ACC ] STREAM LISTENING 16793 /var/run/dbus/system_bus_socket unix 2 [ ACC ] STREAM LISTENING 16794 /run/snapd.socket unix 2 [ ACC ] STREAM LISTENING 16795 /run/snapd-snap.socket unix 2 [ ACC ] STREAM LISTENING 16796 /run/acpid.socket unix 2 [ ACC ] STREAM LISTENING 16797 /run/uuidd/request unix 2 [ ACC ] STREAM LISTENING 16927 @ISCSIADM_ABSTRACT_NAMESPACE unix 2 [ ACC ] STREAM LISTENING 16792 /var/lib/lxd/unix.socket

I wouldn't use Mangos, only due to TC 335a having the most updated quests (data wise), and from there a dev would just negate those particular quests. However, getting some calls with talents, etc... we could get from mangos. There's always been an audience for any expansion

What OS are you using? Did you check if there was a security update? Iv'e ran Ubuntu/CentOS/Debian and IPTables have been updated in the past and causing issues. When it worked before, what commit did it work without choking the socket?

I'm not 100%, but it sounds like the firewall is shutting it down and choking the socket after initialization.

We started one and it didnt get enough support. We started working on the project by helping with reverse engineering some of the code from wrath so that authserver would be compatible with the TC branches. https://github.com/trinityclassic/trinityone It hasn't been touched in 3 years

.debug bg = Toggle debug mode for battlegrounds. In debug mode GM can start battleground with single player. Or if in your case if you want to do a true 1 vs 1. You can temporarily modify world.battleground_template with min players per team to 1 for that particular battleground. https://trinitycore.atlassian.net/wiki/display/tc/battleground_template#battleground_template-MinPlayersPerTeam 1. .reload battleground_template 2. level 80+ alliance queue up for that BG. 3. level 80+ horde queue for the same BG.

@Halebawa I think I see your issue, when skimming across the images. more clearly. Your Trinity Realm in the DB needs to be set to 8085. It's at 3724. Port 3724 is your authserver. You mentioned you added a second realm, was that also at 3724? That needs to be 8086 or another port configured. Let me know.

This is help and support for TrinityCore. Not your personal website issue.

Need more details on this error. Need a log dump. That would help. paste it into a gist https://gist.github.com/

If you are using mysql, dedicate more memory to increase your speed. Use more RAM to increase data storage going back and forth from memory and not use your physical hard drive to write, then upload. Make a backup of my.cnf file and do minor increases to: key_buffer_size sort_buffer read_buffer table_cache innodb_buffer_pool_size Then restart MySQL. Be sure to keep an eye on your memory usage. You don't want MySQL to much RAM. Also, see about increasing RAM in your computer. If I'm reading that correctly, you only have 3Gbs of RAM which is extremely low if you have more than 10 players in the future.

It's crashing (closing) immediately due to a configuration issue. In Windows, use cmd.exe to navigate your worldserver.exe path and run worldserver from the terminal via command line and dont double click binary to execute. That will prevent the window from closing. Also, everything should be 127.0.0.1. and not worry about your firewall. Windows whitelists 127.0.0.1 automatically. You should use that for your realmlist.wtf and your DB settings. Once you get an exact error message from the console (without it auto closing), report back what the issue is and we can help get you set up.

It still sounded like an issue with your DB in the beginning... Creating users on the DB won't solve it, unless it needed a restart.

run nload while all 9 players are playing and tell me if Incoming or Outgoing is spiking. This is a test on my server with 8 people playing who volunteered Your outgoing should be less Avg: 27.46 kBit/s Your Incoming should be less Avg: 12.59 kBit/s Does this happen when only you play by yourself? If you are getting spikes only with other players, then there is other activity going on. Possible that one of the players is DDOS'ing your network?

Your network seems fine. Especially with an upload of over 20mbits What are the errors that the server complains about? Unfortunately, I don't use TrinityAdmin.

if you summon your flying mount, it will default you back to normal flying speed, regardless of your GM mod command and speed

That may be your DB that needs more memory allocated. Assuming that your DB is running on the same node. Try learning all spells for one craft. Log out, clear cache, log back in and open your craft. For example if you open up Blacksmith there should almost no hesitation, if there is, then you need to beef up your DB. There should be no hesitation when reading the DB. Also, there seems to be some missing entries from your DB as well.

You can manually modify the name after in the database and bypass the client.

Wowhead is not always up to date. However, that isn't to say that it may be a good source for that particular spell. The terminal output of another ID may just not be updated correctly. It will eventually get corrected in time. Even though this was from 2015 and 3.3.5a, it could just be a wrong sync for https://github.com/TrinityCore/TrinityCore/pull/14785

You mean, this guy? https://github.com/TrinityCore/TrinityCore/blob/master/contrib/extractor.bat

with PhP? yes. I can share tidbits