NetSky

ok thx i did not test it yet but looks proper should not have any spamm effect for spells using 262

what about this patch? any chance for implementation to 0.15 ?

balrok are you already working on wintergrasp outdoor pvp? if yes let me join development there

it adds vehicle support working when you got the proper data for vehicle in your sql tables

i want to rewrite this for 0.15 with more generic use of dbc...so there is just required aura left in vehicle data table and get rid of seat table... if it is working i will let you know

Boost is huge lib plus it contains only STL-containers memory allocator as far as I know. So no chance for it, sry :huh:

ok i will investigate by test implementation if there are any performance improvements and send you pm if necessary

@thyros you can create patchfile by yourself with git diff ...but i do not think this is 100% trinity compatible

if you want to leak this patch you should be able to do this yourself.... tsts :huh:

i cannot believe you got that bad laggs. With mtmaps and current grid-performance improvements ambal did mangos has the best performance out there in the wide world of wow emus - it is running just like a speedboat *jokingly*

i guess your laggs are mainly caused by a heavy loaded mysqld and bad my.cnf

this fix does not work with mangos i already did take a look at it when trazom posted it at their forums

this is a very good idea. what about boost libs? they should be usefull too - i used them with other projects and cannot complain about performance improvement

this patch works fine but i still wonder where he got his sql vehicle data from... testing one by one? and i am wondering why he did not use dbc data and introduced this table based system with this it will get hard to get this vehicle system really completed... we should convert this to use dbc data only but i still did not figure out where to get the required aura data from(dbc) if someone knew would help a lot - different way to solute this : use dbc data for flags,etc use db data for required aura which could also be moved to npc_clickspell table

one other thing that is still missing is the vehicle ehnancements like turrets, etc. -> ulduar leviathan tank for example. but this is just visuals and passenger_seat/spell handling

@ mynameis : use git fetch or git pull but you got to resolve conflicts afterwards

if this was so your guardian pet would do nothing like a passive pet... adding spell with autocast flag is enough a separated ai would be waste of code

i can give you exampple how i soluted snake trap or ghost wulve adds of shaman for example temporary the hardcoded way... but i can give also example how to do this more generic with database support or dbc(if this is possible, i got to investigate dbcs first)

yes there is acually no need for this you could just add a spell to a guardian if it is summoned with autocast_flag and everything is handled by guardian_ai so there is no need for this kind of patch... trinity soluted it this way but i think this is complete wrong way to handle this...

why using tables if you could also use dbc where you already got the needed data this patch is non generic and wasting database resources not needed at all... blizzard already gave you all the data you need look at your dbc folder

RemoveAurasDueToMechanic can be also used for removing snare mechanic at using charge if warbbringer is skilled works also correctly i will post patch if i added correct 262 handling for making warbringer and juggernaut finally work

anyone tested it? - i also got an alternative version but this one is better because we can use RemoveAurasDueToMechanic method for other spells too

Hey, I checked this patch, but there is one mistake I think, because I applied it and i cannot logout anymore.

Solution:

I think this part in void Player::_SaveSkills() should be removed:

if(itr->second.uState == SKILL_UNCHANGED)
   continue;

After that it works for me so far

this just means skip this one and continue with next ... has nothing to do with loop

if you deleted this your char data might get bugged now...

Shattering Throw does not Remove Immunity Effects

With this Patch it does! RemoveAurasDueToMechanic can also be used for future implementations like talent removing snare effect at charge (Warbringer/Juggernaut)

http://www.pastebin.org/18784

best regards

most things in trinity are hacky and non generic

trinity project was founded by brian to rip mangos ... this intent is an other reason why many ppl here do not like this project

you get crashes with this because there is no check if m_caster is still present...

if(!m_caster)

return;

is needed before apply

well i tested it and cpu usage actually was reduced a bit. one bad thing was stability was reduced also :-/

... because i got this access violations in visit method all the time i could not get enough data for calculating efficiency :huh:

http://pastebin.com/mc199b5f

there are some more safety checks needed in visit and visithelper

i think this patch could be problematic with joining bgs/arenas because you are changing faction of members to the leaders one... means this patch would allow to fight ally and horde along with each other in bgs arena ...

colorme does not work with addon channels activated and fake message preventing....

i dont think this fix is needed...

anyways this problem will only occure if you host public private servers :-/

NetSky plz don't spend Ambal time for empty conversation :wacko:

If you want help with test ... do it.

Belive, this person (Ambal) know what he do and from his "work" project get only speed up

i am spending time with empty conversation omg? i can try to interpret that as i should not take his time for a conversation that has no plot from your point of view :huh: . well if you are really confident of your statement then first try to inform yourself what this conversation actually was about ... jeez you are acting as if your life is depending on this patch ... calm down :cool: . i do not think writing a few lines in this forum is keeping ambal that busy that he wont get further progress with his work...

why are you offended? ... this is an educational project so this theory should also be part of this project ... i do not know what is the problem about dealing with such things because if you are part of such a project you should be willing to deal even with theory... this is no offense just a friendly advice

i will compare efficiency later on at the end of the week when i got some time left.

Sounds like an offense In practice I do not post optimization patches if they do not offer performance improvements. Plus, this patch allows you to have any visibility distances w/o need to play with MAX_NUMBER_OF_CELLS define.

So, if you want theory, draw a square 5x5 cells. Place a dot in central cell <- this is your player/mob/whatever. If you are familiar with current cell search system, you'll notice that with ALL_DISTRICT flag specified for cell search you ALWAYS visit 9 cells around object, and you are ALWAYS limited(!) to these 9 cells. Now, draw 2 squares with dot in central cell as its center:

1) small one which fits inside central square - here you can calculate benefits for small radiuses.

2) big one, which covers all 5x5 cells - here you can understand, why this algorithm works with any cell sizes.

Have fun torturing your brain

this is not exactly what i was asking for... if you are familiar to algorithm theory you should be aware that runtimes are calculated to test efficency of algorithms in theory but you were just pointing out that there is the possibility of generic use of cell size

i was pointing out poisons should not be removed at all when using vanish and this needs a change in methods where threat lists are set... to make exception for vanish...

Without patch:

CPU USAGE: 94% - 100%

Visibility Config:

Visibility.GroupMode = 0

Visibility.Distance.Creature = 100

Visibility.Distance.Player = 100

Visibility.Distance.Object = 100

Visibility.Distance.InFlight = 100

Visibility.Distance.Grey.Unit = 1

Visibility.Distance.Grey.Object = 10

With patch:

CPU USAGE: 85% - 92%

Visibility config:

Visibility.Distance.Continents = 90

Visibility.Distance.Instances = 90

Visibility.Distance.BGArenas = 90

Visibility.Distance.Object = 90

Visibility.Distance.InFlight = 90

if you want to compare realistic you got to use the same distances ... this is not really pointing out if you gained any performance... one other aspect is number of active useres moving around getting cell data updated...this should be equal in both tests...

@ ambal did you ever calculate in theory if the runtime of your algorithm is better in comparison to the existing one?

if you already did i would be interested what values you get as result for one cell update run specificly for one player moving.