Schmoozerd

yes, you can. sd2 will not be installed.

I think we can savely extend the system for both JustSummoned and SpellHitTarget, but need to not change anything at all (like an original caster)

if it crashes there should be an entry in the crashs dir with a crash log. The very next step after the sd2 waypoints are loaded is that the sd2 database will be "disconnected." So possible that therein lies a problem in your setup. Maybe update your Mysql Server? (Or in case it is a version from yesterday, fetch an older stable version)

It might be an idea to also consider the way we currently handle the linked Traps of WildSummoned GOs. possible that it would be reasonable to summon the linked go in all cases, and just trigger it after it was summoned?

what Patman said. The path must be src/bindings/scriptdev0/scriptVC100.sln - no trunk there. and I suggest to rename "Mangos Files" to "Mangos_Files" or similar, blanks only cause trouble

you could try to use SetTargetGuid(ObjectGuid()) in case of npcs, might be related

In [11878]. Thank you! Also thanks to qsa for suggested alternate version

In [11877]. Thank you

in [11876]. THank you

not sure how the directory must be named, likels src/bindings/ScriptDev2 - but also possible that they have changed this. And be sure to open the project by double-clicking src/bindings/ScriptDev2/scriptVC100 [.sln] Also the mangos dir should be places in a ascii/dos styled path. (no blancs, no accents and similar)

if memory serves: MMGens for creatures are updated every 50ms - this should be more than enough for any visual impact. Also I am very positve that there is no difference between pet following and normal npc following. However npc movement is not very smooth, so this might result in a very unsmooth movement for followers - contrary to player movement which is relatively smoots (as client controlled)

i doubt there is a problem with the compiled binaries. Both mangosd and realmd start correctly and are up and running until they are shut down. Probably some annoying configuration error (like entry in IP field, wrong ports or similar)

very difficult. This automated system clearly has some very nice concepts (ensure that linked traps are spawned) However the main problem I see with this is that you DB guys must ensure that no linked GOs are spawned by default in the database - so you cannot fill the content of gameobject table by sniff, but always must use some selects to remove the linked GOs. Also I think other GOs as well have linked GOs which might be an idea to support as well with such a system. Unfortunately we know so little about how GOs should really work. Also maybe you might want to add a check for linked GOs which do not exist to some earlier place (GO-template checks?) - to prevent unexpected errors from gameobject table which will be consusing Anyhow - any research on how GOs should behave is very welcome

The first looks like a wrong check somewhere (like 64bit guid vs lowguid or so). Should be easy to find by doing a fulltext search in mangos for "HandleMoveNotActiveMover: incorrect mover guid: mover is Player" The other two would be nice to get some ideas how to reproduce - but ofc code analysis might also help (like a player being teleported while trading)

done, though could be a weird bot..

Hmm So the content of ZoneOrSort is sent from server to client, and hence can be < 0. The current check only checks if the (custom?) field RequiredSkill has a skill Corresponding to the value of -ZoneOrSort -- and reports a warning if they differ. This looks reasonable to me. So what is the problem with this check? Edit: Just trolled around on wowhead with quest http://old.wowhead.com/quest=12517 Is this true? This would mean that quest 12517 should have ZoneOrSort == -371, but RequiredSkill== 0? Which would now throw the error you want to remove?

see https://github.com/mangos/mangos/commit/a946ebcd3003d9fe7a67f151bb9cd86957af0f82 There were changes of this area, but I don't understand the problem atm. Perhaps you can clarify for me. 1) What data is sent from retail to client of the fields ZoneOrSort, RequiredClasses, RequiredSkill 2) What exactly is the problem with the check you want to remove - do they throw some error output which they should not? 3) What is not working as expected in any of the quests SELECT * FROM quest_template WHERE entry IN (13311, 12518, 12798, 12517); Edit: A short lookup returned that the values like -371 are identified with 371 from QuestSort.dbc, which yields to inscription

hmm, isn't it best to just remove the AUTO_INCREMENT from the first collumn? I see no reason for 0 as default values

@amaru It is possible that there must be some cmake change to include the subdirectory "WorldPvp" of src/game, not familiar enough about this. @ BG_TEAMS_COUNT depends on the meaning what this is required for - from normal view there should be no need to include this to shared define (it is used for oPvp, not BG) - so maybe a new define would be better choice

could you compile your sys in debug mode? then the crash logs should be way more informative. And if it crashes so frequent we should be able to get valid logs very fast.

conditions are always added with AND if an OR would be required this can be obtained with some multiple-lines constructions in most cases

it might be an idea to create a conditions table of the format (id, cond-type, val1, val2) with id as primary key and (cond-type, val1, val2) as secondary key. actually this is currently done internally in mangos (conditions are mapped to one condition id) advantages: * faster to load * less space in the database * easier to expand other systems with conditions, as a condition is only one collumn then and not three disadvantages: * way harder to read, because every condition requires an additional SELECT to the conditions table. * Also harder to port database content with conditions between different db projects (though could be possible to unify to one conditions table (agreement of ids)..) Now about the idea of conditions and db-scripts. At first this would require some serious rework of the condition system, because the condition system currently works only with players - for db scripting this must be extended to also work on worldobjects. Then ofc many conditions make no sense for db-scripting, only some special conditions like world-state values (or sd2-instance return values, which is a "bad" condition)

I think there must be placed an entry into realm database into realmlist for your realm. Also you must have proper values in the config files for the IP (leave to default there)

"dbc" is a database format of its own. (afaik one table per file) The content can be viewed by dbc-editors, read by some tools or converted to sql if required. MaNGOS reads various tables from the dbc files extracted out of the client and puts them to use. with "database" in MaNGOS content we usually refer to the sql-databases )like characters) which are required for MaNGOS to be started. The somehow most important database is the world-database which contains the content of the game. These datas are usually not shipped with the client, and hence are filled by content providers

Thanks very much for pointing. I will look into this beginning of next year, probably a simple problem I wasn't aware of (me = sql n00b)