Eden

use 120000 (2 mins) as SaveInterval. that helps.

UI mod/addon for sure.

not sure if its related to your problem, but i have noticed a bug with respawning spellcaster GOs (they just do not respawn or respawn randomly). anywy here is my fix for it, maybe it helps you (around line 380 in GameObject.cpp -- sorry i cant supply a .patch file right now): case GO_JUST_DEACTIVATED: { //if Gameobject should cast spell, then this, but some GOs (type = 10) should be destroyed if (GetGoType() == GAMEOBJECT_TYPE_GOOBER) { uint32 spellId = GetGOInfo()->goober.spellId; if(spellId) { std::set<uint32>::iterator it = m_unique_users.begin(); std::set<uint32>::iterator end = m_unique_users.end(); for (; it != end; it++) { Unit* owner = Unit::GetUnit(*this, uint64(*it)); if (owner) owner->CastSpell(owner, spellId, false); } m_unique_users.clear(); m_usetimes = 0; } //any return here in case battleground traps } // -- SPELLCASTER RESPAWN FIX BELOW -- // FG: fix for proper respawning of charged spellcaster GOs else if(GetGoType() == GAMEOBJECT_TYPE_SPELLCASTER) { m_usetimes = 0; } // -- SPELLCASTER RESPAWN FIX ABOVE -- if(GetOwnerGUID()) { m_respawnTime = 0; Delete(); return; }

check http://amki.kicks-ass.org/~lawrence/php/playerdatafield.php

thx a lot for the code - can you also tell me how to generate a crc.bin file? i'd like to add that feature to stuffextract. afaik it must contain some original client memory region, but not sure. ... i will also try to fix the RealmList packet handling soon.

anyway, the fact that the licence says that its not ALLOWED to connect doesnt mean that it shouldnt be POSSIBLE to connect would be nice if you can post your patch, especially the CRC hash stuff. thx all in all this is just educative; but its your sanity what you do with it. btw, pseuwow needs devs

bump

getMSTime()

just an else is missing here: Index: src/game/MotionMaster.cpp =================================================================== --- src/game/MotionMaster.cpp (revision 6133) +++ src/game/MotionMaster.cpp (working copy) @@ -145,7 +145,7 @@ DEBUG_LOG("Creature (Entry: %u GUID: %u) targeted home", i_owner->GetEntry(), i_owner->GetGUIDLow()); Mutate(new HomeMovementGenerator<Creature>()); } - if(i_owner->GetTypeId()==TYPEID_UNIT && ((Creature*)i_owner)->GetCharmerOrOwnerGUID()) + else if(i_owner->GetTypeId()==TYPEID_UNIT && ((Creature*)i_owner)->GetCharmerOrOwnerGUID()) { sLog.outError("Pet or controlled creature (Entry: %u GUID: %u) attempt targeted home", i_owner->GetEntry(), i_owner->GetGUIDLow() );

it was possible back in 2.3.3, but the ****** client devs prevented that since 2.4.0. there were attempts to make it work again with a hack, but failed.

... and dont use repacks. ry to compile your own core, then you know at least what you have.

<div class='quotetop'>QUOTE </div> that was exactly what i was talking about. with instance i mean 1 PseuInstance, which is the parent class of WorldSession/WorldSocket and RealmSession/RealmSocket. Creating many WorldSessions in one PseuInstance would kinda fuck up everything. Many PseuInstance's = many World connections.

do you mean multi-instances in one pseuwow.exe? i have thought about that long ago, but actually never realized it. the code is somewhat optimized/intended for parallel usage of instances, but there are some pieces of code that are not yet "good" for multi-instancing: - the SCP database takes up too much memory if loaded 100 times or more - same for the item prototypes and playernames cache - also maps (omg!) - more then one DefScriptPackage instance would cause a large amount of used memory as well, because it is used to store individual configurations. one package must be loaded then for every single instance. there might be ways to get around this, it would require a 'Master' class, that, if running multi-instanced, took care about all data loaded only once and distributed to all PseuInstance's. - one gui per instance? or all instances all merged into one gui, tabbed? too early to decide that, and too hard to implement since its only the very beginning, and absolutely not needed for operation. better to disable gui in multi-instance mode. - CLI must be disabled too, or only enabled for first instance, or for all instances simultaneously. sure, your idea is good, but imho its too early to realize it. to do serious stressing, a lot more needs to be done before beeing able to get mangos cough. automated movement (i mean not depedant from the gui) is only one factor of it. i am interested to get more suggestions, and i would like to help mangos with it, but i also have a bad feeling about it, cuz it can be abused so easily... k, waiting for comments (or patches ) EDIT: pseuwow is not a client EMUlator. remember, mangos devs kill u if u say this about mangos

models not yet implemented. k then i'll consider posting as safe. (just for future)

the follow command was removed a looong time ago. but yeah, we are working on movement, but this needs 100% correct map reading code, which will still take a while until its done. for now concentrating on graphics, to make the debugging process easier. btw @ mods: am i allowed to post "client" screenshots here? i mean, this is not the payware client, so...