NoFantasy

That was a nice finding. In other words, some instances can not work as they should when mangosd.conf has visibility too low, even if database has all correct data.

Not having any problems here, and I don't see how script would have anything to do with it. Equipment are defined in creature_equip_template and creature_template.equipment_id point to the entry in creature_equip_template you want to use for this creature. As example: INSERT INTO creature_equip_template (entry, equipentry1, equipentry2, equipentry3) VALUES (10000, 5287, 0, 0); UPDATE creature_template SET equipment_id=10000 WHERE entry=14325;

It's 0.207 in current dbc, it could be you are looking at a 3.3.3 version of the spell.

We already have IsEncounterInProgress() for scripted instance. IsEncounterInProgress() is not implemented though, but the intention was probably in the early days to implement this feature. Personally i think it's much better to fully do this from Mangos side, just need to dig out the conditions and find a suitable location to do the check based on those conditions

...and then a summoned mob, having random movement as default get 0 spawndist. Fixing one thing, breaking another. The real problem must be in Creature::SaveToDB

Do you know if this only affect raid instances?

While reviewing, i don't think the others has much time, i see in the suggested patch: This is really not nice. Why have some duplicate KEY in the table creations, but in the SQL updates you add duplicates INDEX? This is not consistent, nor is it correct. From the data provided, we see that one quest can have many poiId's, but never the same poiId for the same quest. This mean it should be primary key (questId, poiId), this should prevent any mistakes. For the other fields, i see mostly fields with not needed large possible values. INT(11) when the known values are not even close to max uint8 (255) Database does not need more than TINYINT(3). To correct all the issues with the SQL as suggested, i propose something like: TRUNCATE quest_poi; TRUNCATE quest_poi_points; ALTER TABLE quest_poi ADD COLUMN poiId tinyint(3) UNSIGNED DEFAULT '0' NOT NULL AFTER questid; ALTER TABLE quest_poi CHANGE COLUMN questid questId mediumint(8) UNSIGNED DEFAULT '0' NOT NULL; ALTER TABLE quest_poi CHANGE COLUMN unk1 mapAreaId mediumint(8) UNSIGNED DEFAULT '0' NOT NULL; ALTER TABLE quest_poi CHANGE COLUMN unk2 floorId tinyint(3) UNSIGNED DEFAULT '0' NOT NULL; ALTER TABLE quest_poi_points ADD COLUMN poiId tinyint(3) UNSIGNED DEFAULT '0' NOT NULL AFTER questId; ALTER TABLE quest_poi_points CHANGE COLUMN questId questId mediumint(8) UNSIGNED DEFAULT '0' NOT NULL; ALTER TABLE quest_poi_points DROP COLUMN objIndex; ALTER TABLE quest_poi DROP PRIMARY KEY, ADD PRIMARY KEY idx_poi (questId, poiId); ALTER TABLE quest_poi_points DROP INDEX idx, ADD KEY idx_poip (questId, poiId); While making the PRIMARY KEY i notice that it will become many duplicates, since one of the fields used are added as 0 (if table contain any data from before). This is the reason tables might as well be truncated, as the option will be to drop all duplicates before adding the primary key, leaving the tables pretty much useless. I assume we all want this in master though, so to me it's a far better option to just drop all existing data and apply it again. Edit: and i also changed from the original code: unk1 -> mapAreaId, this is to avoid mixing up the field with what we usually know as areaId from AreaTable.dbc. It's really the id from WorldMapArea.

If some database doesn't bother to keep their data up to date or add custom values, they are free to do so. After all, it's your choice what database to use And i wish i could comment on the code itself, however i'm of little use with the loot-code, i have hardly had a look at it. Leaving it to others who has more knowledge, then i'm free to comment and review code parts i'm familiar with and know how works.

The database content provider must make sure they have proper data in the _template, this is not something Mangos should do. The basic concept of using data15 for type 3 GO is still valid though. Just adding query for others to see it more easy: SELECT entry,name FROM gameobject_template WHERE type=3 AND data15=1;

...which is basically just a "hack" from old SD2 script The problem you will face with this way, is that you have to call the function for _every_ time script side use JustReachedHome(). We don't want this of course, but instead find a better place to call it from Mangos without making things harder for script side to maintain.

This is not the cause, the cause is that SetSummonPoint() is not called for this summon, and then the crash here has nothing to do with this commit, it just trigger bug from another place. Will correct that issue soon. Edit: [9605] should solve this problem.

Nothing else that i can confirm what YuruY said, ZoneOrZort = -162 is expected for this quest. It is however, not a Mangos bug per definition, this has never been seen before as i know, and is more a missing feature. Remember that ZoneOrSort is the category where the quest appear in the quest log. Some time ago we added SkillOrClass because of this, since quite a few quests had the regular zone category but was expected to be available for a certain class only.

You can't "just add" some script call, this will need special care, especially at load. Without reading the actual code, i see that author here already are aware of the issues that may occur at load: Sure, it's easy enough when item expire when you play, but not so easy if it expire at loading

Tried to reproduce, but not able to. .quest add 10483 .quest com 10483 Talk to the guy and get reward, no crash. Problem with some custom data/custom code perhaps?

Have in mind that Item::UpdateDuration is also called at load player from database. As result, you may end up being in trouble when a player logs in and some item is expired.

No objections

Try [9401], should probably correct this problem.

Confirmed, and a more complex solution is already being made.

Overview of basic game features, remains to be implemented. Some are partially implemented, many are not implemented at all or need a larger rewrite of current code. Feel free to edit this post as you see fit, just don't list minor issues in here, we should keep this thread as a overview of the major features we are still missing The list are divided in three: 1. features that has always been available on official 2. features implemented at some point in 2.x client 3. features implemented at some point in 3.x client It is not a priority list, however: the basic features that has always been available on retail should of course get a higher attention than features that has been recently implemented. 1. Always present features - Mind control (partially working) - In many item send data cases (mail, trade, etc) we send hard coded and unknown values (packet structure not complete) - Outdoor PvP 2. Added in 2.x client - Progressing game event (existed to some degree in 1.x) - NPCs on transports (boats, zeppelins) - auction pending payments list instead old send mails way - Voice chat 3. Added in 3.x client - Calendar - Vehicles and Destructible Buildings - Dungeon group search - Dynamic Loot (loot based on which/how many raid bosses killed) - Dynamic instance difficulty - WotLK arenas and Battlegrounds. - BOP item trade for items dropped in dungeons/raids. - Item refund system. - Dungeon and Raid ID Extensions

Take a look at your own data Just as example, for one quest you have quest_poi data like ('9349', '0', '4', '530', '465', '0', '0', '1'); ('9349', '2', '-1', '530', '465', '0', '0', '1'); 0 and 2, right? This is the index, as we have in: for(QuestPOIVector::const_iterator itr = POI->begin(); itr != POI->end(); ++itr) { data << uint32(index); // POI index data << int32(itr->ObjectiveIndex); // objective index You need to use the value from database, instead of incrementing the index, like in current code. entry_POI is also a name i don't really like that much, as it indicate it's a unique value it can only exist one of (like for example creature entry). I would suggest you rename this to just id or similar, that indicate the value is not unique for the table, but a identifier for the poi row. I also note that you have renamed from objIndex to objective. This is not ok in my opinion. By reading, it is not possible to even guess what the value is. If a rename is really needed, use objectiveIndex. This is after all the index of quest objectives (at least we must assume it is, since it will match real data fairly well).

Maybe commit log was not clear about it. It update the XP formula, using the expected RewXPId as implemented in: So basically, if you have this field=0 for all quests, it mean no XP will be given. Content/data for RewXPId must be provided by some database provider though, so go ask "them" for the data

Main research done, and updated formula is in master. Thank both Tom for research of formula and Vlad for helping out with math Issues may occur, but i'm sure we're able to deal with those when they emerge from the depths, calling upon the Lord of Crash.

You are probably talking about weekly quests. Unlike daily quests, weekly and monthly quests are not implemented (you can avoid them being repeatable with quest_template.SpecialFlags)

Yes, it would be useful. If so, it would be a SCRIPT_COMMAND_FORCED_DESPAWN, with at least creature guid as parameter. Despawning a GO in a similar way would be wrong though, it would need a more generic SCRIPT_COMMAND_GO_USE, so the GO is processed properly.

Bug, or a feature not meant for TARGET_SCRIPT. TARGET_SCRIPT will not work as intended in client when you use a GO as the _target_ for the spell, mainly because the visual effects will not show. I cannot say with 100% certainty it is expected to be creature target in all cases, but research has shown that this is the case so far. Using GO as target for TARGET_SCRIPT was however the preferred way as a "easy way out" when the real creature target was not obvious or unknown. At first look at this, i would suggest try find a suitable creature target, if that doesn't turn out well, we probably need to implement a effect-field in database table so that we don't break too much of the functionality (adding code to fill TARGET_SCRIPT with a GO again, will only lead to problems with other spells, for cases where spell has more than just one effect using TARGET_SCRIPT).