Xenithar

This also happens with the orc peons in "The Valley of Trials" in Durotar. Some will be asleep like they're supposed to be. Others will be awake but doing nothing. It as if something half-processed. Not sure what happens with these guys.

I imagine you do. I just assumed everybody is not an IT geek with an actual lab in his home to test things. I can multibox and control five characters at once if I want to, making things easy to test. I was curious as to whether there was a built-in way to do it. Kind of like spawning a bot to help you in UT or something. Let me know what your test results are though.

How will you validate it without a group? Is there a way we can test group things solo? I have never tried so forgive my ignorance.

Mind you, the case I was stating was tested in R19 and it happens every time. However, I have not allowed anybody on the R20 server due to bugs that worry me may cause hours of labor lost, such as the pets not spawning. I would HATE to have my mom lose her pet after hours and hours of raising it. Same for my fiance. Therefore, I have not tested this in R20. I am available to connect to another server and test with you if you need my assistance though.

It has been this way since before the split. In fact I remember doing this in 2008. How is setting a number to 255 going to cause a stability issue? The only thing I can see even remotely possible is that one aura from a talent tree may adversely affect an aura from another tree, but during the beta there was a week or two where they did just that: Grant everybody all talents. Also, this is something to be used by GM's. I had spoken with Luda or Salja about keeping the level data from WoTLK in Zero and One so the GM would be mega-buff when going above 60 and was told that it was a simple matter of bringing the level data from WoTLK into the databases for One and Zero. Never was it mentioned that this would be an issue. If it is an issue, you can tell it to my pally who has been 255 for eons and never brought down a server. If this is such an issue, I vote we put a setting in the configuration file that defaults to 60 but allows a GM to raise his/her level up to whatever the value is set to, or a max of 255. This way the server admin is in charge of how buff the GM's can be.

If group loot works, does setting the loot level for rolling work? In other words, if I set group loot and choose blue or better, will greens be rotated like whites as it should be, or will we still have to roll on greens? Also, does any of this fix the "never happened in a million years in official" issue where if I open a chest, the entire group must roll on items? Normally the group would do "/roll 100" and whomever had the highest roll got to open and loot the chest. However, in R19 (not sure about R20 yet) when I open a chest, my entire group gets to roll and win the items inside. Not Blizzlike at all.

That should be normal. After all, we only have stats data for 1-60 in Zero, and 1-70 in TBC, etc etc. I played as a lv255 paladin for a while messing with friends (Horde) while killing Cairne. He still kicked my bottom because I had level 60 stats, just a bunch of extra talents! The normal cap is 60 for players. GM's can go above and beyond, up to 255 which is the max for an unsigned char. Seems fine to me. Also, it does not crash anything.

I agree, just overload our existing commands. The last parameter (the message) should be optional.

In the beta it was supposed to be implemented elsewhere, but never made the final cut and I suppose it was not priority after release. It never happened elsewhere to my knowledge.

You are correct, Max. I remember this from my early days playing Alliance.

Any update on this? I am not getting errors or anything that leads me to what is causing this. This should be fixed prior to releasing R20 since hunters are kind of dependent upon their pets. Also, my warlock has a voidwalker, but no pet tab. It is like the VW is not linked to my lock.

I cannot reproduce this either. I will try again later today.

I wrote a script to fix this a year or so back. It basically changed all Tauren characters to 1.39 or 1.40 scale, except for Cairne, who was a hair larger. I assume during the rollback this was lost.

If it is just this one guard, what script is he using that the others are not? That's my first thought anyway.

I know that, I just ALWAYS used the one mentioned before. I never bothered trying the others, which is probably why I forgot about them.

Odd, it did. I do not know what to say, but that was the only way I knew how to kill the server "correctly". I did not know of the other two commands.

Actually, "server shutdown " will kill the server after X seconds even if players are on. How do I know? This is the only way I have ever stopped my server, and it has stopped the server after the specified time even if players are on.

A quick and dirty fix would be to do this. [code] entry, int, PK, unique, auto inc, not null realmid, uint, not null starttime, big uint, not null uptime, big uint, not null max_players, small uint, not null [/code] Also, you do not have to specify the PK column when adding data. I never do, and they teach you not to in colleges now. For example, to add entries above, you would insert realmid, starttime, uptime, and max_players. The DB will auto-assign (and increment) the entry field. This is who it works on MSSQL, MySQL, and MariaDB. Not sure about PostgreSQL.

I can confirm this. I just pulled and built R20 last night and I was wondering why it was not shutting down.

Wiki page is wrong. Look at the "Nullable" column. Every item is set to "NOT NULL", but they default to NULL. Another problem is that a primary key should NEVER be NULL. Base don these two facts, you would be required to put in a zero for a PK, but you should also remember that a PK should not change once set. Seems like that table is in need of a refit!

The Unix timestamp uses less data. Let's assume a string with no hyphens like "20140918203045" which means "2014-Sep-19 at 20:30 and 45sec". This uses 14bytes of data. A timestamp is a 32bit integer, which uses 4bytes. It could save loads of space depending on how string dates are stored.

I apologize, but I will be working until 2130 tonight. I will try if I get a second. *EDIT* I ran it from my work system. Don't tell the boss. [code] @01:~/zero/src/server$ git blame --incremental src/scripts/ScriptDevMgr.cpp 909c1dcabd1aa8a5a91d686a47b69119ee72132a 2 2 1 author Antz author-mail author-time 1405675179 author-tz +0100 committer Antz committer-mail committer-time 1405675179 committer-tz +0100 summary [Sync] Scripts project sync previous 60a71cc6559444c73d130d0e35520bddfe3c37a1 src/scripts/ScriptDevMgr.cpp filename src/scripts/ScriptDevMgr.cpp 909c1dcabd1aa8a5a91d686a47b69119ee72132a 4 4 1 filename src/scripts/ScriptDevMgr.cpp 116b56ac87bd7a63ea4bd8cd7ef08576985948d4 133 133 1 author Antz author-mail author-time 1403701079 author-tz +0100 committer Antz committer-mail committer-time 1403701079 committer-tz +0100 summary [Sync] Project Sync. Thanks Project Goblin previous d959e6a7451781e7b30d720596391203da67d36d src/scripts/ScriptDevMgr.cpp filename src/scripts/ScriptDevMgr.cpp 116b56ac87bd7a63ea4bd8cd7ef08576985948d4 146 146 1 filename src/scripts/ScriptDevMgr.cpp 0c6243ddc5f40b079fb644ea0f495f1776181234 37 37 12 author Antz author-mail author-time 1402519295 author-tz +0100 committer Antz committer-mail committer-time 1402519295 committer-tz +0100 summary [Scripts] Further merging of Scripts into the core. Scriptdev2.conf settings are now part of mangosd.conf and scriptdev2.conf no longer exists previous 59db5c5e515443b34cfbf71b812c52f1ef1c0cc2 src/bindings/scripts/ScriptDevMgr.cpp filename src/bindings/scripts/ScriptDevMgr.cpp 0c6243ddc5f40b079fb644ea0f495f1776181234 94 94 1 filename src/bindings/scripts/ScriptDevMgr.cpp 0c6243ddc5f40b079fb644ea0f495f1776181234 127 127 1 filename src/bindings/scripts/ScriptDevMgr.cpp 0491fbf5b084c4a42dffb5ae0b7bf7f40b8c8f58 234 247 1 author Antz author-mail author-time 1401321515 author-tz +0100 committer Antz committer-mail committer-time 1401321515 committer-tz +0100 summary [Scripts] Build fixup part 2 previous 6f0eca6da771e68beadd43514b575d1ea4fc162d src/bindings/scripts/ScriptDevMgr.cpp filename src/bindings/scripts/ScriptDevMgr.cpp 0491fbf5b084c4a42dffb5ae0b7bf7f40b8c8f58 249 262 1 filename src/bindings/scripts/ScriptDevMgr.cpp 0491fbf5b084c4a42dffb5ae0b7bf7f40b8c8f58 253 266 1 filename src/bindings/scripts/ScriptDevMgr.cpp 41c72606bed1c0daf5960231aafb7f617e94ff1c 26 26 1 author Antz author-mail author-time 1397817589 author-tz +0100 committer Antz committer-mail committer-time 1397817589 committer-tz +0100 summary More Scripting Fixups previous c1fa7e72927a73af9209366faaf2d39cd1ddc9aa src/bindings/scripts/ScriptDevMgr.cpp filename src/bindings/scripts/ScriptDevMgr.cpp 41c72606bed1c0daf5960231aafb7f617e94ff1c 35 35 1 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 1 1 1 author Antz author-mail author-time 1379961463 author-tz +0200 committer Antz committer-mail committer-time 1397772694 committer-tz +0100 summary Script Library Fixup #1 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 3 3 1 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 5 5 21 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 27 27 8 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 36 36 1 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 37 49 45 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 82 95 32 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 115 128 5 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 121 134 12 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 134 147 100 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 235 248 14 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 250 263 3 filename src/bindings/scripts/ScriptDevMgr.cpp c1fa7e72927a73af9209366faaf2d39cd1ddc9aa 254 267 387 filename src/bindings/scripts/ScriptDevMgr.cpp [/code]

It is in "ScriptDevMgr.cpp", line 161. If my memory serves me correctly, the problem was that a class or struct was defined multiple times or something along those lines. However, it was fixed as I ran an R19 server up until last week when I moved to R20.

I will leave it disabled for now. We need pools. There were many separate pools for zones, not one gigantic pool per zone for everything. Throwing everything into one zone pool could be hard on players. Take for example Barrens. A lv14 guy harvests a few nodes up north around XR. The nodes spawn south where the level 20+ mobs are. Now what? Either use GM or have a public server with enough players to keep them harvested. However, pools of generic stuff should be based around the levels of he players in that zone. Separate pools for north and south, in other words.