VladimirMangos

it not working in clean core without scripts. So if freeze show then or you use custom changes or script problem. [added]Ok, i can confirm problem with visibility update in some way But i get it only at logout with active aura

this is security not safe commands, by default allowed only from console.

No, accounts not deleted. Maybe similar account command can be writed: deelted accound that have all characters older some time (in days). Hmm, But for account maybe better own command base at last login time. Because this more clear in case recently added accounts without characters for example.

I revert commit in [s0554]. Related code has been rewriten some weeks later so i will reaplly and update when will ready backport later applied commit.

map not updated until next player save

You know conditions for crash?

Look like you have DB strcuture not compatible with mangos. I don't known how you can have recently added `npc_trainer_template` without this field. You can re-apply 10867_01_mangos_npc_trainer_template.sql (with removed first guard line) as quick fix. But must attempt understand source of problem for future, because it from some your side wrong data...

Hmm, possible related to [s0548] Can you revet it, it must revert clear and look at stability.

for svn you can use https://github.com/VladimirMangos/mangos-svn/tree/head

Localizations can be dependent from main DB content so better look for its at main DB projects resources. In suggested link case it also listed in French localization subsection at UDB forum. Some other localizations listed in own sections.

now? it work in this way from 1.x...

You wrongly understand bank work. Current way work is expected and correct.

Playing in game GM-s also not bliz-like and MOST not bliz-like is free in both meanings open source project. So i suggest use term in limited form, apply to normal player in game expirience. No to random other parts

Non uint32 non appropriate by client expected value size as point Ambal at irc to me. But discussion _not_ secondary because selection this part set way how all code work. It will can't easy replaced to another way work. Better discuss and search acceptable sollution that add and then resolved problems in not easy way.

Ok, maybe compromise sollution: use native int time. So at x86 platform will be 49 days limit and at x64 platform will lot lagger values. Anyway with time x64 used more wide.

Old code in part that work with ticks have way avoid problem in overflow case. For this not ned use uint64, only need expect one limitations: compared values near each other, So let propertly proccess in bear overflow. And please not use as point :2 reverted patches". Second has been reveted by flow in design not related to mstime calculation ways. In fact this part work in it after return to use another counters.

I refer to this. Not good add limitation and expections just because "512Kb memory will only need for any program run"

if (oldMSTime > newMSTime) + { + //don't try to push stupid code in mangos! This can't happen!!! + MANGOS_ASSERT(false); This is just wrong as i think. mstime overflow is _correct_ thinks that can be happens after not so long uptime. All code base at expect impossibility new time has been in raw values < old time is wrong.

Fixed in [10899]. Thank you

Hmm, for player phase not stored but set or gm command or by applied aura. So you must look for SPELL_AURA_PHASE (261) in aura list at player Possible it not removed in result wrong `spell_area` table data, or not listed in table phase spell.

Just remark at: We often add patches that not imporve anything for end user but imporve code stly for example, or rewrite code in better way internal logic but not resolve any known problems for end users. More, also added patches that can be from end user point look like regressions in some parts but from our point do something in more correct way, like: old way work in A and B cases but totally in hack way just by chance, new code work _correctly_ base at new known data for A but now B cases broken. So we can add changes need for implement something but not req. directly, just need prove that this will need really and this right way do this.

None from devs say this. But I sure that current mangos code lot better that in past from this point. Policy avoid increase hack code amount without _real_ reason for rare specific cases. I personally not like idea use fake player for work, because this auto-add not safe code work in this part because we have after normal and fake players. About harmless, in current version maybe, but long time i read diff crash raports related to it. In AHBot case i agree that maybe good have like _feature_ in to core but fake player use let me think that need for _me_ at review search alt. way implemention, so _possible_ need rewrite, so _possible_ need many time research and etc, so i look another not less prio problems existed in mangos that from my expection need expected less time for resolve.This in my personal case applied to any other cases (and later not related to AHBot directly). I have many diff problems/features in hand and only can work at single, so mostly select what look clear for fast adding, or more priority _for_me_ or interesting by self _for_me_. Yes, this make big patches "all fix/implement in one patch" low chance for my review. But i sure _any_ big monster patch can be implemented as series clean one per patch feature aspect implementing, progressive in series. If someone can't look at some feature implementing as some steps and subgolds that can be implemented independently he is bad developer.

Yes, NoFantasy refer to this commit when write "fixed"