Xenithar

I have a list of bugs, such as mobs or pets disappearing while moving and then reappearing, spirit healers being visible to live characters, rare mobs being shown as elite with no elite stats, etc. Once I get my new broadband connection up I can allow you into my server to view and work on these problems with me, but right now I am firewalled from outside my LAN, so no-go there. Hopefully the fiance will have a new job this month and I can afford the new wideband (50Mbps Roadrunner O_O) cable and we should be good. I will keep you posted. My goal right now is to get a 100% Blizzlike 1.12.1 server up, then export the data and hand it to the Zero devs so we can have a 100% perfect reincarnation of 1.12. After that I will probably work on 1.8.x for the REALLY old guys like myself who want large pets that are actually unique. Then I will be happy! Either way, I can drop the MaNGOS database and leave the realmd database so I don't lose characters, then re-import the MaNGOS Zero database, but I don't think that is the issue. I dropped everything and did it from scratch after I had it down-pact, so it should be fine.

That's nice, but I am referring to the skills you train in, not talents. At level 10, all feral druid skills become available at all trainers. In other words, skills that are not usable until you get cat-form are available to be trained at level 10.

Alright, I found my first major bug in Zero. All skills under the feral tree for druids are available at level 10. All three ranks in bash, claw, everything. Is this a problem with some extracted data from the dbc files or is this a database issue from whomever entered those skills? Also, how can I fix this? I can probably work my way through the database using UPDATE queries, but I will need some info on what level each skill becomes available.

Thanks, Vladimir. I am already squeezed for time, but I may take this up. I originally started WoW in the beta, and played through until Cataclysm, growing less enchanted with each expansion. I miss what WoW was and if I can get that back and share it with some friends on my LAN, it would be well worth it.

I can log packets easily. My problem would be the DBC files. As of this point I know absolutely nothing about the DBC file format. That would cripple me. Is the known format documented somewhere?

I just wanted to update this and say that after almost 60hrs (58.6 right now) the server has peaked at 7% CPU usage with three of us on from my LAN, and the RAM usage peaked at 4.9%. This is on a dual processor Athlon MP server (2.80GHz) with 4GB of ECC DDR. Steps for starting MaNGOS using screen are below, for others to use. Connect to your server with SSH or get to a shell if logged on locally Start a new screen session by typing screen and pressing enter Screen should show you a welcome message, just press enter to get out of it Change to the binary directory, which in my case is ~/wow-server/bin Start the realm server with ./realmd &> ./realmd.out & Start the world server with ./mangosd &> ./mangosd.out & Disconnect from the screen session by holding CTRL and pressing A followed by D Disconnect your SSH client or close your console if in KDE/Gnome Your server will continue running in the screen session until you shutdown or reboot your hardware Oh and just in case you need to reconnect to the screen session int he event of a crash or whatever, get back to your shell prompt and simply type screen -r. If you are running multiple screen sessions, you must also pass the screen session ID.

Alright, my Zero configuration currently uses 1.12.1 and most things are good. However, I miss what I personally consider to be "true" WoW, which was everything prior to 1.9. In 1.9 all pets essentially ceased to be unique and were stripped of their unique damage abilities. In a later patch they also made the animals shrink when tamed. These kind of upset me and while 1.12 is great, I really want to get back to basics without doing something illegal like modifying DBC files. With that said, can I get an idea as to what I will need to change in Zero to make it work with 1.8.4? I have the original release of WoW (Collector's Edition) and it is something like 1.2 or 1.1 upon installation, and I have the major patches for almost every version. Would this be as simple as modifying the code to allow version 1.8.4 and then extracting the DBC, maps, vmaps, etc from the 1.8.4 client, or is there more to it than that?

Windows does not care about it being named "ScriptDev2" as opposed to "scriptdev2" or even "ScRiPtDeV2". Only Unix/Linux are case-sensitive. I can guarantee the case isn't the problem.

What version of Visual Studio is that? I see v4.0 under MSBuild in your path. In fact, if the problem is with SD0, it is causing your compiler to complain about a Visual Studio file. The error you pasted is from VS, not SD0, though the problem may lie within SD0, it just "thinks" the problem is the VS file.

I can concur. I have been using nohup as detailed in a guide I read. I normally use screen. Using screen for this fixes the problem. For some reason MaNGOS hates nohup. Glad I install screen on every Linux system I setup!

Anybody? I know how to do this with a simple project, but not with something so complex as MaNGOS. Oh, and I have never used cmake either, so that may be part of it.

I will try when I get home this evening. I work 9-5 though! *UPDATE* Alright, how do I get gprof to work during the build process with MaNGOS? Is there something I do in the makefile or what? *UPDATE* I edited build/CMakeFiles/CmakeCXXCompiler.cmake and added -pg to the ARGS1 var. Building now, but not sure I did it properly.

Actually the database wouldn't have been the problem if it was empty. It would have thrown an error about the db_version. My guess is that it was a bad build. I am still thrown by the way the Lubuntu team has that firewall with all of that routing crap in it though. I am so blessed to be using pure Debian! Glad you are up though.

Mine does the same thing. I have two physical CPUs on a Tyan motherboard and the mangosd process eats 100% CPU on one of them at all times, even when I am not connected from my gaming rig. I am concerned as well due to possible high temperatures on the CPU that is being stressed. My server is a shell-only install of Debian 6.0.3 with no extras. I remotely administer it using SSH (PuTTY if I am in Windows).

I didn't think about that. The realmlist.wtf file has to point to 127.0.0.1 for this to work. Otherwise you are connecting to Blizzard servers!

We already covered that. His problem lies within the network configuration on his Linux box. He does not have his interfaces configured in the standard way, and he has some kind of advanced configuration with iptables going on. *UPDATE* I just figured out that all of those "NR" lines deal with routes. He is routing traffic from all networks to a class C network. That probably has something to do with it. I will keep digging, but why on earth is the Lubuntu team throwing in static routes?

Well your firewall is run on iptables, which does more than firewalling. Iptables also does NAT (network-address translation) and a whole lot more. Your default chains (rules) are much more than firewall rules. I see various networks specified, which makes no sense unless you have multiple networks in your home. I see class A, B, and C networks somehow being related to a class C network in those "NR" rules. On top of that, your networking interfaces are not specified in your interfaces file, leading me to believe that all of those chains have something to do with that. This is why I hate distros that don't conform to standards. Heck, even RedHat, Slackware, and Gentoo use an interfaces file! I will try to sort through those rules later when I get some time, but I have a job during the day.

Makes sense, but can I get an official response on this? If this is the case, how do I modify the database to handle pooling? My first guess would be to put the herbs into groups or something in a special table in the database.

I mentioned having way to many herbs and ore deposits showing up on my zero server a while back and somebody replied mentioning pooling. I cannot find any setting for pooling in my configuration files. How do I enable this so I can cut down on some of the herb spawns?

Alright, sorry for the delay. Ubuntu is doing something very, VERY screwy with networking. Normally your itnerfaces (Ethernet, wireless, etc) are listed and configured in /etc/network/interfaces, yet yours only has loopback. Then there's that extremely odd iptables configuration. I know a bit about iptables and I build firewalls, but I don't do routing and NAT yet, so a lot of your rules don't make sense to me. I would recommend that you speak with the Ubuntu team on their forum to try to gain an understanding of how your network is running. From my perspective, they are handling everything within iptables, which is just not normal, but I may be mistaken. Again, I use Debian, not Ubuntu. Debian is upstream (Ubuntu is based on it) and does not have the bloatware that Ubuntu has. Maybe Ubuntu has some extra package installed that is handling your networking, such as network manager. Either way, ask the Ubuntu team. They should be able to help. On a side note, I placed an iptables firewall on my WoW server last night after building, allowing only TCP ports 3724, 8085, and 22 through. Upon doing this, I had the same problem you have. I would sit at the connecting screen for ages and never get in. This leads me to believe that MaNGOS uses more ports than just 8085 and 3724. Upon removing my firewall, I could connect instantly. I still believe the heart of your problem is with the networking setup on Ubuntu. *UPDATE* Alright, I should not be allowed to use Firewall Builder after 22:00 any more. My problem was that I was testing against the source port for 3724 and 8085, not the destination port. It works fine now, and MaNGOS only needs ports 3724 and 8085 allowed. Just wanted to point that out since I assumed my problem was an unknown port earlier. Naz, if you want to try allowing your WoW ports, you can enter these two commands as root to open just the MaNGOS ports up. iptables -A INPUT -i eth0 -p tcp -m tcp --dport 3724 -m state --state NEW -j ACCEPT iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8085 -m state --state NEW -j ACCEPT That tells your firewall to allow traffic on the two MaNGOS ports to be allowed even if it is a new connection.

How do I know which revision to keep, head or mmaps? I am looking at "SpellEffects.cpp" right now and the head has nothing while mmaps has a small case section in a switch block. In this case I am assuming that it is OK to use the mmaps version since nothing is being changed, only code added, but I would like to be sure and I would like to know how to determine which revision to use. *UPDATE* The other differences were where a space was deleted in a function prototype and in the implementation. The final one was the revision. The mmaps version set it to 1765 and of course the zero version was at 1809. I kept 1809, committed, made sure sd0 was set to compile, and have just started my compilation. Now I must send the tools over to my Latitude laptop to build for Windows, then send those executeables to one of my lab PCs to pull out the stuff from WoW. Fun... *UPDATE* The server built and started with the mmaps, vmaps, etc I extracted and built when using the straight mmaps branch. Already tested with my hunter and the mobs do not act like they're high enough to float anymore, and they can now cross bridges. Thanks for all of the help! Now, when an update for zero and/or mmaps comes out, how would I go about updating the sources and rebuilding?

Thanks faramir. Since this is a server, I only have a shell which is accessible only through SSH. I will check it out tonight, fix the issues, and build the new executeables. I will post back tonight if I run into anything else. Also, I will make a guide for this once I get it working properly. By the way, what timezone are guys in? *EDIT* One more thing. How do I do this? Do i simply edit the files in vi, or do I do something with git?

Same problem. Still wants 1765. No merge errors or anything, just wants 1765... *UPDATE* Modified my script and am starting over... again. I took out the remote for the working branch and the patch code since I just add the line myself. I will update you when I get done again. #!/bin/sh clear cd rm -rf ~/wow-src ~/wow-server/bin ~/wow-server/include ~/wow-server/lib sleep 3 mkdir ~/wow-src cd ~/wow-src git init git remote add -f -t develop origin git://github.com/mangos-zero/server.git git remote add -f -t feature/movemaps mmaps git://github.com/mangos-zero/server.git git branch master --track origin/develop git branch mmaps --track mmaps/feature/movemaps git branch working git checkout master git checkout working git merge master git merge mmaps cd ./src/bindings mkdir ./ScriptDevZero cd ./ScriptDevZero git init git remote add -f -t master sd0 git://github.com/mangos-zero/scriptdev0.git git branch master --track sd0/master git checkout master cd *UPDATE* That worked. I got the merge errors you said I would get. Now, how do I fix said errors? I mean are these physical errors (such as null pointers) or what? What am I looking for in these files and once I fix the problems, how do I tell git that it can merge them? *UPDATE* Alright, I found the following in "CreatureAI.h". I assume that between "HEAD" and "=======" is the original code and between "=====" and "mmaps" is the proposed change. My big question is whether or not git commented out the lines and I need to uncomment them or what? Do I delete the old code and leave the new code as-is? I need more info to make an informed decision and git isn't helping. <<<<<<< HEAD /** * Called at any heal cast/item used * @param healer Unit* who healed the creature */ virtual void HealBy(Unit* healer, uint32 amount_healed) {} ======= // Called at any heal cast/item used (call non implemented) // virtual void HealBy(Unit * /*healer*/, uint32 /*amount_healed*/) {} >>>>>>> mmaps

Oh God, I was about to try that. I figured the "stable/master" was lagging behind and the development tree would be more modern. You just solved it. I will do a reset and setup the develop branch now. Thanks! *UPDATE* Thought I would share my reset script with you guys. Enjoy! #!/bin/sh clear cd rm -rf ~/wow-src sleep 3 mkdir ~/wow-src cd ~/wow-src git init git remote add -f -t develop origin git://github.com/mangos-zero/server.git git remote add -f -t feature/movemaps mmaps git://github.com/mangos-zero/server.git git remote add -f -t master working git://github.com/mangos-zero/server.git git branch master --track origin/master git branch mmaps --track mmaps/feature/movemaps git branch working --track working/master git checkout master git checkout working git merge master git merge mmaps cd ./src/bindings mkdir ./ScriptDevZero cd ./ScriptDevZero git init git remote add -f -t master sd0 git://github.com/mangos-zero/scriptdev0.git git branch master --track sd0/master git checkout master cp ./MaNGOSZero-ScriptDevZero.patch ~/wow-src cd ~/wow-src git apply ./MaNGOSZero-ScriptDevZero.patch cd

Wow, no clue what they are trying to do there, but you are setup to use your loopback interface for net access. They must use iptables to handle this as well as firewall your system. Let me get some advice for this and get back to you. *UPDATE* Alright, let's not wipe out your firewall and NAT setup. Instead, let's just set the input and output policies to accept by default. This is a simple command issued as root that should fix it while leaving your rules in place. iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT Try that as root or with sudo. That will allow all traffic in and out of your system without removing all of your rules. Once you do those two commands, use iptables -S as root and paste me the result. After you paste the result, try your server out and cross your fingers.