Ambal

Also pay attention on Copy Constructor A(A const& ) and Assign Operator A& operator=(A const&) if you are willing to transfer ownership of object internals to another object.

Use smart pointers like auto_ptr<>, shared_ptr<> and week_ptr<> for your needs. They will solve all issues with your memory management.

So, imho, when I don't shut it down myself it would run easily 49 days+.

Since yesterday this is not an issue, herrtrigger. I'd added an overflow protection which worked fine during my tests.

Everyone, who is testing current patch, I would like you to check if following bugs from [10677] and [10688] are fixed:

1) mobs' corpses disappear correctly;

2) temporary enchants are bugged, e.g. Wound Poison should dispell in 60 mins but instead it dispells in 60 secs.

Cheers

I think this piece of code might be related to your issue:

typedef ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_NULL_SYNCH> WorldHandler;

try to change it to

typedef ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_MT_SYNCH> WorldHandler;

and report if this was helpful

I don't remember who made this code (migration to ACE lib) in the first place, but we sure could use his help right about now.

It was Derex who moved network code on ACE, but he is missing from long ago

lp-vamp, thanks for your comment. I already implemented and pushed into my repo similar approach as yours Using our own method of counting world time brings us more flexibility and stability in dealing with timer overflows + we are now able to generate 100% correct update diffs on overflow event.

Everyone is welcome to test latest version of this patch ...And don't be afraid providing a feedback if patch is actually working

So let propertly proccess in bear overflow.

uint64 is the most reliable solution, IMO, which is not that hard to implement w/o modifying code alot. But we can improve our overflow check too. Anyway, things should not be bound to 49.7 days of uptime, should they? :lol:

Assuming there would be some crazy guy out there, who has a costly server rack, and has his MaNGOS running for 49+ days....

Well, lets first meet such guy who will have a server running for 49 days with online > 0 players

Could you not error trap an overflow by resetting the mstime when a certain value is reached? This would avoid having to convert to uint64.

I use error trapping to test patch and see if we do not have situations where old_time > new_time (will happen ONLY if someone will move system clock backwards which I doubt dude in mind will do). Also, w/o using uint64 data type it is impossible to resolve overflow issue with high uptime in a correct way.

Current way of dealing with situations "old_time > new_time" is far from acceptable so we should consider a fix for it and not leave hacks around the code. Two patches with the same issue is the most obvious proof

P.S. Windoz has a well known function "DWORD GetTickCount()" which returns time in msecs from OS start time which is limited to the same 49 days as our current getMSTime() function. And I don't see complains about it, really

From MSDN: "The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days. To avoid this problem, use the GetTickCount64 function. Otherwise, check for an overflow condition when comparing times."

I refer to this.

In this case we should consider using uint64 data type to store time diffs instead of uint32. Current approach is a bad design, IMO, and we can't leave it as is if we want to deal with overflows with high uptime of 49 days (which is HUGE value, almost a 1.5 month running in 24x7 mode ).

P.S. Lets be realistic: we should not try to design systems which are capable of doing everything and handle all possible and impossible situations. 49 days of uptime is unrealistic even for Blizz just because they do server maintenance every week e.g. 7(!) days disregarding of the fact how long their servers are capable to run. Regular uptime of mangos servers is even lower... Don't see a reason to bother. What we should really deal with - is moving system clock forward/backward - current core does not handle this situation in a correct way.

This is just wrong as i think. mstime overflow is _correct_ thinks that can be happens after not so long uptime.

Overflow is not a case for mangos since we changed the way how we obtain and calculate values in getMSTime() function. We use time diff to calculate uptime in miliseconds, you can check rev [10694]. If you'll find a place in code where suggested code change might cause problems, please, report and we'll think about a fix.

Also, please note that even old mangos did not had any protection against system timer changes on runtime, e.g. moving system clock forward/backward on server machine.

P.S. Overflow for getMSTime() will happen if your server uptime will reach 49+ days.

Any test results for this patch? :rolleyes:

Patch looks good at first glance. After I'll put my other patches for review, will get back to this one.

Cheers

b482519 just don't realize simple thing: developer manpower is what big projects like mangos lacks in order to catch Blizz. This is also what delays Code Review stage for BIG patches like mmaps, vehicles as well as all others. - we don't want to submit patch just because "it is a suppa-cool feature we don't have in the core" but in most cases we don't have enough ppl to review your changes, sorry.

Blizz has dozens of programmers who are paid big money in order to earn even more $$$ to Blizz. If you need numbers, WOW team has ~30 programmers and ~320 QAs to bring success to this game. How many of those has mangos? I doubt your so lovely TrinityCore has the same set of features as offy WoW servers.

P.S. b482519, you remind me burlex who was very nice programmer, but also an expert in blaming everything around in mangos but not offering any help to our project. Noone needs your whines on this forum, sorry.

P.P.S. Talking about sh*tty code that works you are so proud of: If your sh*t does not smell, it is still sh*t, isn't it? Customers don't care about code quality - it is your problem in any way as well as set of features you need to implement in order to make everyone happy. But maintaining crappy codebase is PITA - I've spend 71 hours instead of 30 hours planned by project manager in order to make sh*t work nicely. :mad:

Patch updated: signature of Update(uint32 time_diff) functions has been changed to Update(uint32 update_diff, uint32 time_diff) to get rid of auxilary function WorldObject::updateDiff(). Patch supports latest revision. Have fun

Problem lies in algorithm of broadcasting packets - in your case it looks like you send packets to those players which are in specified range from the player. If your teammate leaves specified area - he does not get packets at all. Search for corresponding methods in Map class like Map::MessageBroadcast() to get an idea of what to do. And may the Force be with you

zergtmn has my vote too.

Activate fast-math on g3dlite, Detour, Recast and MoveMapGen (FloatingPointModel="2" in vcproj files or in project properties C/C++ | Code Generation | Floating Point Model).

Be very careful with such floating-point optimizations to not end up with something like in http://stackoverflow.com/questions/3042925/strange-results-with-fpfast. All FP comparisons might be affected by this change, so it is better to put a patch on forum so ppl can test it before pushing into repo.

Cheers.

MaNGOS itself isn't perfect, so why does it require third party developers to be?

On my job (I work for HUGE English bank), before you commit into the main repo, you have to pass Core Review, then the Test Team have to verify that our patches pass regression tests and do not cause ANY sorts of troubles. Only then you have the right to submit your code and wait for Production Release to prove you wrong - if bugs are uncovered at this stage, your changes are rolled back and you start scratching your head again. This is how BIG business needs things to be done.

We all know such intentions "I'm so tired updating my patch, plz, commit my work, I'll fix bugs later" because we all were 3rd party developers before invited to the team. But practice says that in some cases, authors just disappear or not willing to solve issues right away, and only mangos developer team is left because we have responsibilities!

after apply tbb concurrent vector and sql sync patches

You might try and figure out what patches might cause such behavior:

1) run mtmaps w/o any additional patches;

2) run mtmaps with concurrent vector patch;

3) if you have revision below [10865] - apply SQL sync patch.

I can test patch but need first some days to finish with Reloc branch1 test ...

No hurry, I'm just checking that patches are not lost from community view We appreciate your effort in testing patches

what if someone havent grid unloading turned on ? does it make any difference ?

no, it should not make any difference, maly32167.

Since today we think that branch 2 is enought good

Thank you, Undergarun, for making tests. We need numbers to compare performance of both patches before we decide if branch 2 can be improved

i got a question bout this: how are we supposed to test? what is the expected result before->after?

Killed unlooted mobs should disappear in inactive grids.

As I see, everyone are so scared after commits [10688] and [10677] so noone is willing to test similar patches anymore Ok, let's go another way: if you want more patches from me, test this one