NoFantasy

No comments from experts and seem to work fine. Teleport destination part added in 10999

Parts added to master in rev 10967 I'm not sure of the way you do fill target for the actual teleport spell though, need to get hold of some additional expertise on the issue

Prefer "ours", but no, it's not The official SD2 repo is at SVN like it always was, and in addition we have reserved https://github.com/scriptdev2 on github. The plan is to eventually move to git, in case you wonder. Once moved, we hope to get better organization of the different "branches", although we have not made any decisions on how yet. Time will tell (could be likely to follow a similar path as Mangos now has, but i want the other sd2 team members to be with me in that decision). As for UDB, who on earth are you discussing with? This is the very same thing, there are rogue people out there how apparently has plans, but has not brought these plans to our attention so it at least can be discussed internally before making some public statements. Once we have figured this out, feel free by all means to re-post the thread (with correct info ), the only reason i moved it was to avoid mass-confusion about third-party project plans and official repositories/links. Ah, and a small edit/note: the name "ScriptDev" is the old name of the project, from the times before Ntsc took over and started "ScriptDev2". I can't really remember who was the leader of that project, some remains may still exist on sf.net (no clue really). ScriptDev2 is not just a repository, it's also a brand/"trademark" if you understand.

Got too much Christmas beer? We in Scriptdev2 have our own home page and repository, what you announce here is something by someone else than us. If we decide to change the current, we will announce this at our own site. Please remove this, or make sure to tell the users that they are not looking at the official Scriptdev2. Edit: i moved this thread here, TheLuda, you need to contact me about what is going on.

Rejecting this (based on quest example given). Database bug, the item should drop regardless of quest active or not.

Oops, yes. Sorry, forgot to add link.

The load from database was the problem, fixed. As a side note, it had nothing to do with contested zones at all, nor was "all mobs in contested zones" affected.

Nothing against it.

The 'problem' actually start with https://github.com/mangos/mangos/commit/a93605ce748b228cb2f98ebb9e00a4f04e7a31c9 Some cases were found where faction alone could not be used explicit to determine pvp state. Since the conditions are not known, manual data is the only way to set pvp state where we cannot detect it automatically. That has the side effect of using the older data, which may be wrong (the 16 flag mentioned) and then naturally revealing the bugs in that data.

That would be expected, most likely many of them had wrong data initially, data that came from 2.x and was not updated for 3.x. That is database related of course. Another thing is, the pvp state itself are more dynamic than what we earlier assumed. One creature entry may or may not be flagged for pvp, it seem to be conditional. What the conditions are, is not known. Possibly related to player state, area the creature is in, etc.

https://github.com/mangos/mangos/commit/edfc2d19b47c23b0c46416f250f278fef7e26e2f

There are some issues with compiling (after 10790), the green gnomes are working to find a solution

Added in [10646], from latest post. It is not needed to extract only certain flags, all flags must be preserved when field is not 0

I don't see any reason to not preserve any of the existing flags if they exist. In other words: // preserve all current dynamic flags if exist uint32 dynFlags = GetUInt32Value(UNIT_DYNAMIC_FLAGS); SetUInt32Value(UNIT_DYNAMIC_FLAGS, dynFlags ? dynFlags : GetCreatureInfo()->dynamicflags); More clean and probably most proper for this case.

Problem should be solved with http://github.com/mangos/mangos/commit/a946ebcd3003d9fe7a67f151bb9cd86957af0f82 ZoneOrSort can stay the same as it's expected to be, and RequiredClasses = 0 (or bitmask of class for a different case where you would need to limit quest to a class/some classes).

added in [10607] with an additional check in HandleGameObjectUseOpcode. Doesn't expect client to send anything for this GO type, and then error if it receive anything (hack attempt possibly?)

confirmed, and fix is in progress

All forums (except Management-forums) are visible and readable by guests. I really can't remember if they was in the past, but i think only Community Talk -section was visible. Hide them might in any case be something to consider.

case CHAT_TYPE_WHISPER: - if (!unit_target || !IS_PLAYER_GUID(unit_target)) + if (!unitTarget || unitTarget->GetTypeId() != TYPEID_PLAYER) case CHAT_TYPE_BOSS_WHISPER: - if (!unit_target || !IS_PLAYER_GUID(unit_target)) + if (!unitTarget || target->GetTypeId() != TYPEID_PLAYER) Why are those different from each other?

Is it for custom use or does real examples exist where $n are used for creature->target Say() ?

Btw, it would be nice to get the real values for Corpse.Decay.RARE = 900 and Corpse.Decay.RAREELITE = 1200 I think it should be fairly easy: Find a rare/rare elite outside instance, kill the mob (do not loot!) and take the time from kill to corpse disappear.

Changes made in [10458]. This change will at least solve the problem as described in first post, assuming database spawntimesecs are set accordingly.

No new columns, that is correct. Config options can stay, i just want the default values changed.

Ok, the two basic definitions we need to deal with: - Corpse decay: The time it takes from you kill the mob til the corpse disappear. * The default/max time per type (rank) is set in config file. This is the time used if you do not loot the body - Re-spawn time: the time it takes from you kill the mob to the mob appear in alive state at his re-spawn position. * The value are set in creature.spawntimesecs In most cases, you will loot the mob before the corpse decay time is expired. This is when the corpse decay time change. For a regular mob with low respawntime, the corpse will vanish fairly short after you loot the mob. My goal is to make the creature.spawntimesecs be the actual time it takes from killed to respawning and at the same time have the corpse vanish as close as possible compared with the real thing. As example, the looted corpse of a rare elite may be found in the world several hours later. Similar cases you may find inside instances, the corpse of the looted mob will be around for quite some time. This is the reason why we, with the current features need to use a modifier of creature.spawntimesecs to determine how long the corpse can remain visible in world after it is looted (remember, the values in config file are the max values, the values used _unless_ the corpse are looted). As a side note, i left the CONFIG_FLOAT_RATE_CORPSE_DECAY_LOOTED as an option to those who prefer the current way. If not set to 0.0, the corpse (no matter what rank) will disappear at a certain time after looted, no matter how long spawntimesecs it has in database. Now, this is still a kind of work-in-progress from my side, and the details are still a bit unclear about how to deal with the code in AllLootRemovedFromCorpse() -function. To be honest, I'm still trying to figure out the best way/most proper way, without implementing any new/bigger features, I realize our system will not become fully like it should be without.

1. the default values in .conf are most likely incorrect 2. i think you are mixing up respawn time with corpse decay time 3. yes, we do need some changes to the corpse decay / re-spawn time system From a rather small base of research, I've been messing around with some changes so that the system becomes a bit more like expected, especially for the corpse decay. The changes are as follows: http://paste2.org/p/976252 It's not too easy to see what will really change, so breaking it down in some examples: There are at least two significant changes made: * Database field creature.spawntimesecs is now defined as the actual time (in seconds) it takes from you kill the creature to the mob re-spawn (assuming corpse is looted before the corpse decay values from config expire) * The corpse decay time _after_ you loot the corpse is no longer a multiplier of Corpse.Decay.TYPE -value but creature.spawntimesecs / 3 as the default. This will have a noticeable impact on the visual, especially for creatures that has a long re-spawn time. As example, the corpse of a creature with 6 hour re-spawn time (spawntimesecs=21600) will decay after about 7200 seconds (2 hours). Also, the issue you initially report should be corrected. If creature does not have any loot, the proper function is used to update the corpse decay values. In your case where the expected time to re-spawn is always ~1 minute, you simply need a low value in creature.spawntimesecs. It must be noted that Corpse.Decay.RARE = 900 and Corpse.Decay.RAREELITE = 1200 are guessed values. It is assumed though that the time are static for all/most mobs. The way to get them should be fairly easy i think: - Kill a mob that you know has loot - Do not take the loot, but instead take the time from you kill it to the corpse disappear. That is the value to use as Corpse.Decay.TYPE Have in mind that the test should be done outside instance, as instances may use some different system (yet to be determined) Overall, i personally think this will improve the system, but i realize it is only a step closer to how it should really work.