arrai

Warden relies purely on obfuscation. As soon as MaNGOS, as an open source project, would implement it, all security is lost. For that reason it is not planed to implement it.

#mmorpg-dev has been created by TheLuda especially for mangos. Dunno why he didn't called it #mangos

committed in 6847, thanks EDIT: damn it, forgot "patch provided by" - sorry

Why do you want to insert the guid of a NPC there? It makes no difference from which NPC the player got the quest, you can complete the same quest just once per day. :confused:

Your idea doesn't solve the main problem of dynamic reloading of such data: What should the sever do if some entries are missing? All creatures based on those template might cause a crash or would have to be despawned immediately

It's not true that there won't be any changes. We will have to add phasing information to creature and gameobject spawn tables since their visibility is based upon the current phase of a player.

Yeah, you could implement this in a similar way. Have a look at m_timers in World.cpp/h, it should be pretty easy with them

While I like the idea to do have a "lazy character deletion", I personally disagree with exporting the housekeeping task to an external script. Having a configuration entry to define the time after which those characters are deleted once and for all seems more reasonable.

Those spells exists in the current 3.0.3 live servers, but there is no cast opcode send - they only appear in that cooldown packet. From my point of view those Dummy effects don't have to be implemented, all they do is sending the cooldown. I assume the effects only exist because every spell has to have at least one effect :lol:

committed in [6815], ty

Another update: DON'T commit to origin/303-willcrashforsure like I did - changes will get lost. instead create an own locale branch with git-checkout origin/303-willcrashforsure git-branch -b 303 and push using git-push origin 303:refs/heads/303-willcrashforsure

Didn't work for me, I had to use git-checkout origin/303-willcrashforsure

something like if(m_KickDelay > 0) { if( (m_KickDelay%1000) < ( (m_KickDelay-p_time)%1000) )) ChatHandler(this).GreenSystemMessageToPlr(this,"You will be removed from the server in %u seconds.",p_time/1000); if(p_time >= m_KickDelay) { m_KickDelay = 0; Kick(p_time); } else { m_KickDelay -=p_time; } } should fix this

While there might be some more work with having a public 3.0.2 branch in form of unnecessary threads and flames, I acknowledge that this is also a chance to include users in this development process. Additionally tom did already publish a patch and I can't find any flame thread regarding this. So I'm not against that branch

I agree, this is a really bad coding style. Try adding a new variable to the player class and handle it in Player::Update instead

Please be more precisely and fill a proper bugreport with debug output. Adding an anti freeze thread is a bad hack and should be the last "solution":(

Wyk3d mentioned a system, which assigns each commit a consecutive ID, maybe he will implement this in the genversion script.

git-apply PATCHFILE

committed in 6755, thanks

Under certain conditions players are not saved; for example in battlegrounds. Being more precise with your bugreport would help a lot

Added in [6519]

I can confirm that there were problems with some specific nicknames and renaming was the only solution. However, I neither wrote them down nor had a look at their SHA1 hash.

Have a look at here. This scripts generates a list from an up to date UpdateFields.h

You're missing the update 6298_characters_characters.sql, just apply that file on your db

Are you talking of Ksniffer, the kde application? I didn't know it was capable of such a thing