Chucksta

See for more info:

[url]https://github.com/mangosone/database/issues/3[/url]

Gonna see if I can make any sense out of this :)

Corrections made to the database core (Develop21 branch) and update file also added:

core
[url]https://github.com/mangosone/database/commit/dee6a80a7fc67b82f202e6ecbf644289b3563921[/url]

Update file
[url]https://github.com/mangosone/database/commit/a6fc612f85b7abd03c6b81b746f977e6898aee30[/url]

UnitFlags (creature_template) setting is wrong for starters. That's what is preventing the cat from being attacked and from moving.

I set UnitFlags to 0, and you could then engage it in combat.

It looks like this may need to have a script added, in order to have the cat move out of the cage after is it opened. At least for that part.

Dealt with:

[B]script (Author: SylvainNeau)[/B]
[url]https://github.com/mangosone/serverRel20/commit/634f797732f6013b514bd65d60bb30a26119a989[/url]

[B]database[/B]
[url]https://github.com/mangosone/databaseRel20/commit/60f4967030478f134b2f0e763dc318919f6c0e92[/url]

I'll also add this to MaNGOSTwo

-----------------------------------
Now in MaNGOSTwo:

[B]script (Author: SylvainNeau)[/B]
[url]https://github.com/mangostwo/server/pull/100[/url]
[B]database[/B]
[url]https://github.com/mangostwo/database/pull/23[/url]

[quote=antz]@chucksta -

Could you create a pr for that ?[/quote]

Hmm, I need to check the forums more often, lol, I cannot remember much about this.

I'll see what's what, then do the necessary... vague enough for you ? ;)

EDIT: Light bulb moment... it's all come back in a flash!!!!
I'll grab Four and do as per that update linked to in my last post, and make sure that does solve it for Four, and not just some fluke.

EDIT: That has already been applied:
Line 4177
[url]https://github.com/mangosfour/server/blob/master/src/game/SharedDefines.h[/url]

Confirmed - will now fix this :)

This is mainly due the the wrong setting in the UnitFlags field, but there are also issues with some of the faction IDs too. I have had to use the Stormind ID for Alliance NPCs and the Orgrimmar one for the Horde.

[B][COLOR="#008000"][SIZE=3]FIXED ON ONE:[/SIZE][/COLOR][/B]
[url]https://github.com/mangosone/database/commit/68b6295ca77d3e573da513b0494ece848ba6ef5c[/url]

I'll check Two

Judging by the settings in the database, Two is fine.

Nice bit of research there, Olion. Thanks for that :)

Considering your findings, I'll vote for leaving it out of classic, unless the powers that be really want it in.

The item is in One's database, which is good, but it is also in Two's so presumably that should be removed?

A quick look and:

[url]http://www.wowhead.com/item=23072/fists-of-the-unrelenting[/url]

Display ID [B]3986[/B]

DisplayId acquired by entering &xml on the wowhead.com URL, next to the item's ID, thus
[url]http://www.wowhead.com/item=23072&xml[/url]

Therefore it might be this from the ItemDisplayInfo.dbc file:
[COLOR="#0000FF"]3986,"","","","","INV_Gauntlets_09",1,0,"",0,0,11,0,0,"","Plate_D_04_Glove_AL","Plate_D_04_Glove_HA","","","","","",0[/COLOR]

I'll deal with as soon as I have finished with Darrowshire, unless someone else does it.

Those map files should be fine, although you may need to rebuild the extractor.

For me to get it to be okay with the maps, I had to rebuild the extractor and apply the following cheat/fix:

[url]https://github.com/Chuck5ta/PandaWoW/commit/feedaeb504ff9f7d50535d5e17d71667291135a1[/url]

One thing you should check, is the version it thinks it has extracted. In the DBC folder, look for the component.wow-enUS.txt file

Open that file and see what version it has written to it.

It should have 18273 or 18414

For some reason it thinks it is 18273 even though the files are for build 18414.

If it has any other version number, then you do have the wrong client version.

Hmm, I had that, but it only complained that the build was not: 18414

After doing this:

[url]https://github.com/Chuck5ta/PandaWoW/commit/feedaeb504ff9f7d50535d5e17d71667291135a1[/url]

it worked fine.

Very strange :(

Have you definitely got 5.4.8 build: 18414 WoW game client ?

It's now an attachment at the bottom of this thread. You'll see "Download" on the bottom right, below the last post :)
[B][COLOR="#008000"][SIZE=3][RIGHT]\/ there \/[/RIGHT][/SIZE][/COLOR][/B]

[quote=zamalaev]Im not VS 10, 11
please blinary file x86 system win32[/quote]

Sorry, I don't understand. What do you mean ?

-----------------------------------------

Ah, exe of that mangosExtractor .... hmm, I'll see if I can upload it somewhere ...

For the DBC files, you'll need to use the mangosExtractor from here: [url]https://github.com/mangostools[/url]

That will extract the files in the correct format for MoP (Four).

I have managed to get the server some way into the loading process (dbc and database data). It's now stuck on "Loading BattleMasters". That's on my copy of this repo, where you kindly pointed out an error I made. Thanks again, matey :). I'll PR and merge those fixes on here (for Four), once I have the sever up and running. If anyone agrees that the fixes made are valid, then please go ahead and add them to Four :)

Of course, there's a crazy amount of database related errors, but I'm not going to sort that out until the server is actually running. Not far off from that, hopefully :)

From what I can tell, the only way to do this would be to move raid members into the same faction, then back again when the raid is disbanded. Not sure that it is a good way to do it, and a bit of a hack, plus a bit of a mare to figure out the best possible faction to use.

I could find nothing within the core that sets the player characters to being friendly towards each other when the group is formed, so I reckon it must be the client that on receiving a notification of the group being formed, automatically sets all members of that group to be friendly towards each other (do I hear an "ooo err, missus" ?).

Obviously, this setting, by the client, of being friendly towards other groups, does not happen when the group is converted to a raid.

Of course, I could be wrong, and it is set within the core somewhere.

[B][COLOR="#008000"][SIZE=3]Blacksmith specialisations fix has now been committed:[/SIZE][/COLOR][/B]

[url]https://github.com/mangoszero/database/commit/a37ceff8b057def4a34ac86a943d00636ec83c82[/url]

The scripts linked to the Blacksmithing and Leatherworking specialisations are not needed in Vanilla, so I will now remove them.

The acquisition of Blacksmithing specailisations now works in the same way as Leatherworking specialisations, in that the spell to learn the specialisation is cast on completion of the quest.


[B][COLOR="#FF0000"][SIZE=3]STILL TO DO:
[/SIZE][/COLOR][/B]

Make sure the specialisation quests are removed from the player character's creature_queststatus table, when the profession is unlearnt.

Logging in issue:
This will be due to an incorrect [B]address [/B]in the [B]realmlist[/B] table of the realmd database, well, in my experience that has been the case :)

You need to give it the address of the server's machine. It is probably set to 127.0.0.1, at the moment.

We now have all the necessary information, thanks, Xenithar. Now it's a matter of getting down and redoing the whole thing properly for Vanilla, and setting aside time to do it.

I've always been a fan of Gremlins, except for when they mess about with my computers!!! Actually, if they did exist and acted like they do in the films, I'd not care, because I'd be too busy trying not to die from laughter :D

Thanks, Arkadus :) useful input :D

Gonna have to set aside some time to sort this out properly!

That reminds me, I need to apply your code updates from way back!!! I'll make that a priority for tomorrow :) That last one went in without any problems :D Not your code (that be perfection is perfected), the damn Gremlins that haunt my PC are the issue :mad: bad, bad gremlins!

[B][COLOR="#008000"][SIZE=3]Pull Request has now been made:[/SIZE][/COLOR][/B]

server core
[url]https://github.com/mangostwo/server/pull/92[/url]

database
[url]https://github.com/mangostwo/database/pull/19[/url]

Corrections/changes made to server core. Currently building...
VS, and cmake (Linux)

----------------------------------------------

Build successful... going in-game and checking logs

-----------------------------------------------

Successfuly passed the Travis build :D

[B][SIZE=3]Server side changes[/SIZE][/B]

[B]CreatureEventAI.h[/B] from line 127
[PHP] ACTION_T_SET_STAND_STATE = 47, // StandState, unused, unused
ACTION_T_CHANGE_MOVEMENT = 48, // MovementType, WanderDistance, unused
ACTION_T_SUMMON_UNIQUE = 49, // CreatureId, Target, SpawnId
ACTION_T_EMOTE_TARGET = 50, // EmoteId, TargetGuid[/PHP]


other changes/additions to make:

[B][COLOR="#800080"]ACTION_T_EMOTE_TARGET[/COLOR][/B]

[B]CreatureEventAI.h[/B] new code (for Two): from line 426 approximately
[PHP]
struct
{
uint32 creatureId;
uint32 target;
uint32 spawnId;
} summon_unique;
// ACTION_T_EMOTE_TARGET = 50[/PHP]


[B]CreatureEventAI.cpp[/B] new code (for Two): in function ProcessAction( )
[PHP]
case ACTION_T_EMOTE_TARGET:
{
Unit* pCreature = m_creature->GetMap()->GetCreature(ObjectGuid(HIGHGUID_UNIT, action.emoteTarget.targetGuid));
if (!pCreature)
{
sLog.outErrorEventAI("Event %d. Cannot find creature by guid %d", EventId, action.emoteTarget.targetGuid);
return;
}


m_creature->SetFacingToObject(pCreature);
m_creature->HandleEmote(action.emoteTarget.emoteId);
break;
}[/PHP]


[B][COLOR="#800080"]ACTION_T_SUMMON_UNIQUE[/COLOR][/B]

CreatureEventAIMgr.cpp - function CheckUnusedAISummons()
[PHP]
switch (action.type)
{
case ACTION_T_SUMMON_ID:
case ACTION_T_SUMMON_UNIQUE:
{
if (action.summon_id.spawnId)
{ idx_set.erase(action.summon_id.spawnId); }
break;
}
default: break;
}[/PHP]

CreatureEventAIMgr.cpp - function LoadCreatureEventAI_Scripts()
[PHP]

case ACTION_T_SUMMON_UNIQUE: //47
if (!sCreatureStorage.LookupEntry(action.summon_unique.creatureId))
{ sLog.outErrorEventAI("Event %u Action %u uses nonexistent creature entry %u.", i, j + 1, action.summon_unique.creatureId); }
IsValidTargetType(temp.event_type, action.type, action.summon_unique.target, i, j + 1);
if (m_CreatureEventAI_Summon_Map.find(action.summon_unique.spawnId) == m_CreatureEventAI_Summon_Map.end())
{ sLog.outErrorEventAI("Event %u Action %u summons missing CreatureEventAI_Summon %u", i, j + 1, action.summon_unique.spawnId); }
break;[/PHP]

---------------------------------------------

[B][SIZE=3]Database side changes[/SIZE][/B]

[B]creature_ai_scripts[/B]

[B]ACTION_T_SET_STAND_STATE[/B]
Right now in Two, after applying the start-up fixes, there are 0 entries using 47 (ACTION_T_SUMMON_UNIQUE), and 6 entries using 48 (ACTION_T_SET_STAND_STATE); this is checking the fields: action1_type, action2_type, and action3_type.

So, we can safely change the records that use 48 to 47 (value should also be changed in CreatureEventAI.h)

[COLOR="#0000FF"]UPDATE creature_ai_scripts SET action1_type = 47 WHERE id IN (454207, 840003, 1684701, 1029903, 2861201);
UPDATE creature_ai_scripts SET action2_type = 47 WHERE id = 1722601;[/COLOR]

[B]ACTION_T_SUMMON_UNIQUE[/B]
Not currently used in Two, so nothing needs to be done.

[B]ACTION_T_CHANGE_MOVEMENT[/B]
Not currently used in Two, so nothing needs to be done.

Gonna raise a thread specifically for this. There may be a good number of database records affected.

Two needs to be put in-line with Zero and One, obviously.

issue raised under
[url]https://www.getmangos.eu/issue.php?issueid=883[/url]

----------------------------------------------------------------
Marking the issue in this thread as completed :)

Ah, yeah, very true, Olion

nicely spotted :)

[B][COLOR="#008000"]Pull Request has now been made for this:[/COLOR][/B]

[url]https://github.com/mangostwo/database/pull/18[/url]

Many thanks, Xenithar :D Very useful input!

That ties in with the comment in the link by Cabfever (in my last post)

So,
1) no unlearning in Vanilla
2) No gossip for learning

[B]npc_professions.cp[/B]p (all scripts) will need a major overhaul.