Xenithar

No problem. I can easily shoot a video of this happening if you want. I know the server has crashed when NPCs and mobs stop spawning as I move south!

I have been working with Karel on this issue. I built Zero from scratch and all is good, but it crashes on his system after being built, even with databases and what-not up to snuff. This does not happen on my systems. As you can see in step 8 below, SD2 calls InitScriptLibrary(), which attempts to create an array of a single element. This is where the crash happens. Now, I am going to check my system and compare databases. All I can figure is that something is wrong and it needs to allocate more than one script element. Might be the DB informing the program of an incorrect number or something else, but I will be digging into it. [code] SD2: Loading C++ scripts [[Thread 0x7ffff1c70700 (LWP 9031) exited]*********] 100% Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5dcc2de in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) backtrace #0 0x00007ffff5dcc2de in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff5dce930 in malloc () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff67f607d in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007ffff1e195ec in __gnu_cxx::new_allocator

Sweet! I imagine the two most important modes are group-loot and loot-master. FFA should be cake to implement.

Yeah, that's what we are suggesting.

As somebody who tested some GM stuff years ago in the beta, I can say that GMs do indeed spawn in starting areas. The key? GM account characters ALWAYS start invisible to players. I have an acquaintance who was a GM in retail that can tell me if this was true through WoTLK. I will ask him in a day or two when I expect to see him again.

I have not had this issue. Mail is working in Rel19, though I am not allowing my mother and fiance into the R20 server due to the large number of things being worked on, such as pets not being there.

He may be correct. I will check my 2004 issue of the Brady Games WoW guide. As it stands, we have to be level 5 or 10 to get T1 skills now. This may be correct, but I can get an official answer tonight.

The placement of ores are a database issue. The ores spawning too many is due to not using pooling. My experience with pooling in CMaNGOS was that there was too little when set to retail levels. At retail, there are four or five silverleaf in Mulgore. In retail, with a ton of players, somebody was always picking some, so it kept respawning in other locations around Mulgore and made it workable. With three players, this was not working. With that said, we need resource pooling and we need it working out of the box. I assume this would be a two-part process. First, the server-side code, and second, the pools of resources being created in the database. The DB pool creation would take a LOT of man-power since one zone (ie: Barrens) could have dozens of pools by itself. Off the top of my head, we'd have pools of herbs at each of the Oasises, pools for herbs in WC, etc etc.

I did not realize this was the same issue on two different systems. That changes things! Witht hat in mind, I could only think of the problem being a missing dependency. Also, are you running this on a server or in a shell in X (KDE, Gnome, etc)? I run pure servers (no X) and have never tried running in an X environment. That is all I can think of for now, but I will look ino this since it is affecting Wheezy as well. Also, you must provide your MySQL DB admin credentials when it asks for them. When you (re)install the databases that is required for dropping and creating the databases as well as creating the MaNGOS user and granting it access to the tables.

I like the skipping of cinematics, but the other I find to be useless. Unless you're on a production server open to the public, this would not interest most people. They simply want to get in and play. On top of that, we have nothing on GM Isle. Years back I seem to remember having a bunch of NPCs that sold about any item in game to GM's populating the island, but now it is barren. If I spawned there I'd have to teleport to my starting location to begin playing anyway. With that said, I can see it being a useful option on production, public servers. As long as the default for it is off, so I spawn like a normal person in my starting area, I am cool with the addition. *EDIT* Why is this listed as a bug? Isn't this a feature request?

Gotcha', no biggy then. However, has he run a memtest yet? Memory corruption could be a bad chip. If not, was it compiled with standard malloc selected? It may very well be an outdate C library if it was and the memory is in good shape. *EDIT* I just added logging to my script. Would you mind running the script again and private messaging me "getmangos.log"? I'd like to see what it says. I also changed a few things to make the script more compatible with older builds of Linux.

It's no problem. I have actually tested the script on Wheezy again after I replied and had no issues. My assistant (we are ahead of schedule today and bored) tried it on a RedHat VM and it worked. These are all current distros though. I really believe the issue being experienced is that you or your friend is on a distro that was out in 2011. Again, I had a major issue with MaNGOS a year or so back and upgrading to Wheezy was my only way to get it going. It seems like something is VERY wrong with his system though. I am seeing all kinds of symbols and such that should not be there. I would consider a fresh install of Wheezy if it was me personally. Also, if his system is in another language I do not know if that would affect the script.

Alright, the issue I see is the old OS. Squeeze has been "oldstable" for years. I did not test the script on Squeeze and don't intend to. It works flawlessly for me on Wheezy 64bit, Ubuntu/Kubuntu 64bit, and Fedora. I have yet to test it on Slack or Gentoo. May test on Mint also. I have no plans to support Squeeze at this time. Also, I believe that MaNGOS needs ACE 6 now. I remember reading something about changing the requirement to 6 a while back, but I do not know if that was ever made official. Maybe somebody else can chime in here. Also note that your C libraries are also older than what is on Wheezy. I would suggest using squeeze-backports and updating your development libraries and ACE to see if that helps. Now that I think about it, I was forced to upgrade to Wheezy a year or so ago on my MaNGOS system. I had been running Squeeze, but something happened and my only choice was to upgrade. After upgrading all was good. This may also be related.

No, in fact I was in GM mode when I tried to run my Orc warrior from Camp T south. It crashed just south of Camp T. Yes, I use Linux for all of my server needs. After all a Windows Server License can be over $3,500!

Make sure he can get to this ticket. Have him try the automation script I wrote. I know it isn't released yet but if it solves his issue, it may indicate whatever guide he followed was outdated. [url=http://dhta.oesm.org/getmangos.sh]MaNGOS Automatic Installation Script For Linux[/url] Just grab and run that, and it will clone, configure, build, and install the server. It will also setup your databases and update them if needed. *EDIT* It looks like he is using Debian Squeeze. He has some old libraries there. Wheezy is up to ACE 6.0.3, which is my main clue. That or an old version of Ubuntu.

I agree. If the transports do not need to remain loaded, they should probably be unloaded with everything else. I would like to understand why they're not unloaded before we change it, however. Does anybody know why this is configured like this?

I cannot because it is random. My hunter is in Freewind Post and with that commit in my code, I cannot even login. Likewise, if I play my warrior and start walking south from Camp T, the server will crash somewhere between Camp T and The Great Lift. However, the exact location appears to vary. I can do some specific testing if you give me some direction as to what you need.

I imagine the transport is not unloaded for some reason like, if the grid is unloaded, the transport still needs to stay on schedule. If not, I do not see why it is unloaded after the grid.

Alright, after removing that commit I was able to play, but naturally no mineral deposits (ores) were spawning.

Seems like it. How would I remove just that commit with git? I am a novice with git. Cloning, pulling, pushing, I can do. testing by removing a single commit, not so much. *UPDATE* I figure it out, I think. I ran the following and am now rebuilding. [code] git rebase -p --onto 989d66c62dcad884d361827b8cef1c12d421ad76^ 989d66c62dcad884d361827b8cef1c12d421ad76 [/code] If this fixes it, then there is something wrong with that commit.

I did, check the issue I created this morning. Runs fine, but crashes on shutdown with Eluna. Well, appears to be Eluna.

I confirmed this is a bug with the mineral system. I started south along the road from Camp T and it crashed. [code] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb20f3b70 (LWP 3001)] 0x08651a92 in GameObject::RollIfMineralVein (this=0xc1270c8) at /home/.../zero/src/server/src/game/GameObject.cpp:1795 1795 SetDisplayId(goinfonew->displayId); (gdb) list 1790 uint32 guid = GetObjectGuid(); 1791 1792 GameObjectInfo const* goinfonew = ObjectMgr::GetGameObjectInfo(entrynew); 1793 m_goInfo = goinfonew; 1794 1795 SetDisplayId(goinfonew->displayId); 1796 1797 Object::_ReCreate(entrynew); 1798 } 1799 } [/code] So it isn't just Needles. This makes it impossible to keep a server up, so I set the priority to urgent.

Alright, all of my characters load except for my hunter, who is in Thousand Needles. He is parked at the Freewind Post inn. Every time I load him, this happens. [code] CHARACTER: Sent Initial Spells Initializing Action Buttons for '2' Action Buttons for '2' Initialized PLAYER: UpdateHonor Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb20f3b70 (LWP 2964)] 0x08651a92 in GameObject::RollIfMineralVein (this=0xcea67f0) at /home/.../zero/src/server/src/game/GameObject.cpp:1795 1795 SetDisplayId(goinfonew->displayId); (gdb) list 1790 uint32 guid = GetObjectGuid(); 1791 1792 GameObjectInfo const* goinfonew = ObjectMgr::GetGameObjectInfo(entrynew); 1793 m_goInfo = goinfonew; 1794 1795 SetDisplayId(goinfonew->displayId); 1796 1797 Object::_ReCreate(entrynew); 1798 } 1799 } [/code] Now, I did load my warrior in Camp T and he walked around with "find minerals" active and I saw plenty of ore, so it may just be something in Needles. I am going to walk my warrior down there and see what happens.