NoFantasy

Happy new year, and forum looks nice. Nice work chief-boss-in-charge.

This will not exclude the top aggro target, as it should. I'm a bit noob with the spell system though, will it still be proper to limit spell here and the exclusion of top aggro target must be done another place in code?

Added to [9080] in adjusted form

Accepted in [9080] with adjustments (not included player-related spells).

A function already exist, but i'm not sure when it's used. Take a look at it. bool Creature::FallGround()

A side note, GO's can be "attackable" in terms of showing a different icon than the default when targeting the GO. Set gameobject_template.IconName with the name ('Attack' in this case).

In [8770] Some minor changes, since we don't really need two functions for Player::GetQuestLe... Instead use one and renamed this to explain what it really does.

The majority are quests not used, or used as "flag" quests, such as quest entry 12845 for example. About 50-60 exist having questlevel==0.

Same has been discussed from DB devs for a while, and it looks like there is indeed a int32 value. However, you will still find value==0 in cache. That means you must also handle 0 as a valid value and not change all currently having 0 to -1.

Without checking too much what this is about, other than allowing pet and guardian to be scripted, isn't this already done? It was, as i can see, implemented as early as http://mangos.svn.sourceforge.net/viewvc/mangos?view=rev&revision=6287 and actually, patch was provided by original poster in this thread. What am i missing?

Thanks r8462

That is a full patch, pretty much the same as original.

+ SetUInt32Value(GAMEOBJECT_BYTES_1, uint32(-1)); GAMEOBJECT_BYTES_1 is not TWO_SHORT, andvalues are already set below in code by SetGoState(go_state); SetGoType(GameobjectTypes(goinfo->type)); SetGoAnimProgress(animprogress); You mean SetUInt16Value(GAMEOBJECT_DYNAMIC, 1, uint16(-1)); maybe? Edit: i tested patch, and had some problems when object created. That was solved by the below code (*data split in two uint16 values, since we now know type is really TWO_SHORT). diff --git a/src/game/GameObject.cpp b/src/game/GameObject.cpp index 6ddd5a2..e4c631f 100644 --- a/src/game/GameObject.cpp +++ b/src/game/GameObject.cpp @@ -150,9 +150,10 @@ bool GameObject::Create(uint32 guidlow, uint32 name_id, Map *map, uint32 phaseMa SetUInt32Value(GAMEOBJECT_DISPLAYID, goinfo->displayId); + // GAMEOBJECT_BYTES_1, index at 0, 1, 2 and 3 SetGoState(go_state); SetGoType(GameobjectTypes(goinfo->type)); - + SetGoArtKit(0); // unknown what this is SetGoAnimProgress(animprogress); //Notify the map's instance data. diff --git a/src/game/Object.cpp b/src/game/Object.cpp index 1601738..71b691f 100644 --- a/src/game/Object.cpp +++ b/src/game/Object.cpp @@ -592,10 +592,9 @@ void Object::_BuildValuesUpdate(uint8 updatetype, ByteBuffer * data, UpdateMask if (isType(TYPEMASK_GAMEOBJECT) && !((GameObject*)this)->IsTransport()) { if ( ((GameObject*)this)->ActivateToQuest(target) || target->isGameMaster()) - { IsActivateToQuest = true; - updateMask->SetBit(GAMEOBJECT_DYNAMIC); - } + + updateMask->SetBit(GAMEOBJECT_DYNAMIC); } else if (isType(TYPEMASK_UNIT)) { @@ -711,18 +710,27 @@ void Object::_BuildValuesUpdate(uint8 updatetype, ByteBuffer * data, UpdateMask switch(((GameObject*)this)->GetGoType()) { case GAMEOBJECT_TYPE_CHEST: - *data << uint32(9); // enable quest object. Represent 9, but 1 for client before 2.3.0 + // enable quest object. Represent 9, but 1 for client before 2.3.0 + *data << uint16(9); + *data << uint16(-1); break; case GAMEOBJECT_TYPE_GOOBER: - *data << uint32(1); + *data << uint16(1); + *data << uint16(-1); break; default: - *data << uint32(0); // unknown, not happen. + // unknown, not happen. + *data << uint16(0); + *data << uint16(-1); break; } } else - *data << uint32(0); // disable quest object + { + // disable quest object + *data << uint16(0); + *data << uint16(-1); + } } else *data << m_uint32Values[ index ]; // other cases Besides that, it now works ok.

Agree, i think we must see the difference between the offhand meele attack and the offhand item inventory slot. Many item slot types (one hand, offhand, etc) can be used for the offhand meele attack.

I've made a new sticky, those interested in spam can continue use this thread, those who are looking for something more meaningful can use the one tagged as Spam Free Problem solved, all happy (i hope). If it turns out the spam continues in the new sticky, i guess we just have to do more drastic things.

Thread for linux crash dumps. Hopefully this thread will be free from automated spam of logs (the user/s who do use automated methods will still post in own thread). Whenever you are able to (or have a hunch about what caused the crash), please tell us. You will need to post at minimum the Mangos revision, Mangos branch and if you are using any custom code/adjustments (including any third party script library)

Crash related to EventAI should be fixed in rev 8326 ( CRASH_ON_Thu_Aug_6_17_00_48_EEST_2009 )

15 posts about the exact same crash from one user just in 24 hours or so, is it really needed? #0 Spell::DoCreateItem (this=0x82620558, i=0, itemtype=21752) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x1a0be0c8, i=0, itemtype=40088) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x11f6cfc0, i=0, itemtype=43523) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x71ce7b30, i=0, itemtype=43523) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x17204568, i=0, itemtype=43523) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x9ef2b918, i=0, itemtype=43523) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x9c415f70, i=0, itemtype=43523) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x90ab8820, i=0, itemtype=43523) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x5fad1bb0, i=0, itemtype=43523) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x34d38428, i=0, itemtype=43523) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x118e2018, i=0, itemtype=36894) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x5ee99630, i=0, itemtype=36894) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x45ea8048, i=0, itemtype=15992) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x43cdd820, i=0, itemtype=22574) at ../../../src/game/Object.h:167 #0 Spell::DoCreateItem (this=0x79ace1d8, i=0, itemtype=4404) at ../../../src/game/Object.h:167 Sure, we must indeed appreciate people who provide logs and help us out, but maybe this "spam" defeat the purpose of this thread? Maybe also try remove custom patches, see if those are the cause? No info about what the patches does, so any who read can't even help out, trying to find if the custom patches are involved.

In case using third party script library, you can debug by doing this: Compile like normal, mangos and script lib (debug build of course). Start like normal. From script solution in VC, select from top menu Debug->Attach To Process. Browse the list til you find mangosd.exe and attach to this. You should now be able to debug script library, set breakpoints and so on. No idea if it work in older versions of VC, only tried for 90.

Closed, for obvious reasons. Also, take the flame war to a different forum than this, you guys should know better, pesonal opinions or not

If you talk about certain creatures that act similar to normal taxi master, then yes. Npcflag like the one mentioned and also check IconName in creature_template, this determine what icon appear when hovering mouse over creature.

Outrageous to even imply sd2 could be held responsible... Vladimir identified and fixed in http://github.com/mangos/mangos/commit/5e363f96a0e235e4577f99ec3dc7a2b17a5aa223

Why not use existing already EVENT_T_SPAWNED, avoid duplicate event and instead create condition for event? We already use enum ConditionType in code, no reason to not use this in my opinion. if EVENT_T_SPAWNED && CONDITION_ZONEID==your zoneId -> ACTION_T_SET_FACTION

Reporting at SD2 forum, when Mangos does not even build is futile. And currently, that is the fact. Mangos does not compile under Vista, VC90 x64 Debug. Once it's back on track, other projects depending on Mangos will follow, like usual

Just popping in to say thanks a bunch for this Higi! I admit it's a pain to go through the logs, try understand, and of course attempt to fix where should be fixed but i clearly see it's worth every bits doing this.