VladimirMangos

In different from old forked branches for diff cleitn versions like Zero/One no reson do same for 400. It more easy merge and cherry-pick commits when master and 400 in same repo. Ofc, maybe TOM can comment this because he more often do it. Independent repo for me for something stable that will continue exist not limited time. About permissions to new repos, maybe more easy just grand all mangos team access to at least mangos one? And maybe to mangos zero (if Yehonal no have objection for this part). Maybe not many devs really interesting Zero/one development but we i think can be sure ( ^.^ ) that mangos team devs will not do wrong things if we trusted to commit to master repo

i think most easy made script for OnGOGossipSelect and in script query DB. You mast understand that with direct Db query you will server stuck at query time so no good for often asked npc. Another way you can look how do asyn queryes as used for character loading for example and do same in script part in some way.

I update project names in code for MaNGOS One (from mangos-0.12) and MaNGOS Zero (from MaNGOSZero) and in same time test repost commit access. All look like working

client known what object seen or not. So it send (as i expect not test) query for recently created at client side objects (so seen now)

this need research. I know about proble, but i don't want make any time notes.

CMSG_QUESTGIVER_STATUS_MULTIPLE_QUERY and CMSG_QUESTGIVER_STATUS_QUERY used by client for ask npc state

Hmm, its no have summon spells and currently can't be despawned. I think fix must be in way allow propertly expire traps. Current core code not let do this.

Also if you check sd2 svn then see that team work and sd2 development continue.

instance scripts use lot default despawned GOs. You can look sd2 sources for many examples how this done. GAMEOBJECT_TYPE_TRAP (6) _don't must be despanwed/spawned/etc. In most cases it or static or spawned as linked object for different GO. If this is limitation wrong for this object then need core support for.

its despawned by default, then you spawn its at some time by set timer, just set timer back to 0 and its will despawned.

Most GO that diff ppl attempt do as temporary spanws in reality pre-spawned in despawned mode until triggering (so exist at server but not viisible for clients) and have fixed pos. Other known cases have related summon spells. So if you need temporary GO spawn then possible you do dirty hack.

Ofc...

i saw a patch that makes 1 thread per map and add the possibility to restart threads if an error happen in this thread sending all players in this map to the character selection menu, For same mangosd (for diff threads in same application) this is unsafe. You can't be sure that memory not corrupted because it shared by all threads in application. In retial servers cases you see not thread restart but map _server_ restart. In like case it safe (in way: at map server crash, relogin with last saved version character to main continents map server). We attempt move with multi-threading and etc in way that in final state will allow in clean way add support for cluster map-servers.

Main problem with teleport to BG is need set bg id that created at bg creating. When character teleport to another caracter then we can use bg id get from targeted character. In case instances we also need instance id but we can generate instance copy in normal way at teleport to. As alternative possible write semilar .goname command that will teleport to specific BG copy by id. But make it useful need have copy that list all created at moment BG as shift-links (as done for in many .lookup commands)

if(!InBattleGround() && mEntry->IsBattleGroundOrArena()) return false; This is correct result, just missing normal error message. You can't teleport to not existed bg, you can teleport _to player_ This is check exist long time, in .goname case exist special code for do req. preparations. Not bug because before it not work also.

and how you will can use it when none from us have special GM client version?

Making master as 4.x related just will create porblems and confussion. I think current state in this part fine: we have 400 branch until it will be playable at some acceptable level. It just useless made master 4.x related when most devs who not work at low level connectivity staff as me for example can't use client with it. So just move mangos-0.12 branch to new repo i think only need for current repo state.

in secs as i remember

#0 Aura::Update (this=0x7ffdf59f7380, diff=137) at ../../../src/game/SpellAuras.cpp:597 Not see any special in it and callers...

hmm, we have antifreeze protection that do what you describe: explictly triggering crash at freeze detect with result core dump generation. Maybe it disbled in your version. Look option MaxCoreStuckTime in config

ok, commands must be allowed maybe [added]in [10921] must be fixed

About bg commits for backport. Some commits dependent for clean apply from applied in end of 2009 year and current top in backporting near to this time so maybe batter wait with until its backporting in normal order. [8818] in other side cleary applied so i backport it in [s0566]. Thank you for pointing to it. I will return to this thread as will backported 2009 end bg changes (mostly in port to bg code)

why count+1 Ok, also extracted build info file but it's not .dbc file... Maybe possible add additinal string part for it but not in just incrementing counters. Also mangos code style against use { in and of code line and recomment place it at same indenet as closing }

I also discuss this with Yehonal and also remember original suggestion from freghar. freghar mian point that i also agree: mangos-0.12 branched long time ago and all tail have different git commit hashs, so just not help in share data in repo. For mangos master or mangos-0.12 users will be improvment not need download at original repo checkout unrelated branch data. For mangos devs interesting in 0.12 development help for example by backporting own commits don't must be problem just add local branch linked with new repo instead branch in master repo. Just for clarify: you suggest create for mangos-0.12 repo under mangos organization account as main repo placed. Maybe this also let re-host back mangoszero to mangos organization account...

First item at lease not freeze server after [10920]. I can't test not working second item.