Wyk3d

What is wrong with just looping all creatures in the world, checking the AI for each and changing / resetting accordingly ? Just because it's not impemented yet doesn't mean it's impossible ..

The core can and does ensure that all IDs are generated in the order 1...N (where N is the number of scripts) so you can use the position of the element in the vector as the key of the association. In fact, scripts are never added without reloading the library, so it would be enough, and most efficient, to use a simple array but allocated dynamically at load.

Adding i and ui for integer and unsigned integer is inconsistent with the rest of the code. These things were invented for a language where there were no integer types so they had to be marked, but in today's typesafe languages it's useless. In fact because of the need for camelcase, they are just irritating to read in my opinion. Adding the p for pointers generally doesn't improve readability either. If consistency is needed I'd rather remove all p's than add them everywhere. The compiler will definitely tell you if you tried to use a pointer as a normal reference.

You don't need std::map to allow it to resize dynamically. std::vector is far more efficient for integer keys without holes.

I think I fixed all of the cases where GetMap was used incorrectly, they were very easy to spot. The crash that people still have long after that is because it is used correctly but some subsystem has deep hidden bugs. There is one in the spell system but a more common one is in the object update system. That one appears like the object is left in the update set after the map unloads, like it was not properly unloaded. So if the object's mapid/instanceid was not changed then its map pointer should not change either and then it might still crash, unfortunately that is harder to detect in order to print some debug info with this patch, and it will likely appear not in the getmap function but outside it, where the invalid pointer is used.

Even that is a fairly weak argument when with the precompiled header, SD2 compiles in seconds. And if someone fixed the makefiles on linux and implemented the very few missing things required for full runtime script reload support it would be perfect.

It still works fine even then, assuming you do it properly, by merging branches or at least using properly formatted patches (that you can use with git am) and fixing conflicts is easy if you use the tools which suit you best.

Git is working fine. Whether or not a certain service provided by GitHub is working is usually unrelated to that fact.

And if that's not enough, use http://www.cplusplus.com/reference/clibrary/cstdio/setvbuf/ after opening the stream to create a larger write buffer. With that, file writing should be very fast, probably faster than mysql queries. Ofcourse this means that in the event of a crash, the log entries which have not been written yet will be lost, but it's the same with the async sql statements (assuming you didn't DirectExecute) so if that doesn't bother you then this shouldn't either. The idea is to maximize performance, if you need more flexibility in viewing logs you can always write an app to convert a log file to a DB table.

That doesn't sound quite right .. have you tried just removing the line "fflush(logFile)" from the logging methods and comparing the performance ?

First of all you did not ask that question before. Ofcourse that is an exageration, not to be taken literally, but then others explained what was really meant by it. The question you asked was answered: Subhuman answered that by giving you the analogy with browser plugins which usually do not work with other browsers or on their own, but you still cannot call them part of the browser as the browser does not depend on them. This is the same with SD2, it doesn't work without MaNGOS but that does not necessarily mean that it is part of it. We're getting deep into semantics but technicly it isn't. VMaps for example are an optional part of MaNGOS, you can enable/disable them. SD2 is different in the sense that it has a much looser coupling with the core. If you don't use VMaps, you will not have LOS detection, but if you don't use SD2, you could in theory still use another script project, for example your own custom script library, without needing to compile it into the core, and you could still have the same or even more functionality. SD2 is like an addon/plugin to MaNGOS, not a part of it in strict terms, and that is done so intentionally to allow it to be managed separately and developed by people who are more interested in that kind of stuff.

This is not free advertising space => deleting.

Well obviously they should put their stuff on git so we can access it easily and maybe they can be given a bit more attention but that's not the point I think. You did propose a good solution for the case when a quick look over the code is enough (when the trust and problem complexity ratio is just right), but there are a number of problems. Clearly in a lot of cases that is not enough, they may not always know when those cases are and they may even produce the right code for the wrong reasons. I think the most important thing is to get to know THEM and NOT just their code. This is why I said they should post on the forum or come to IRC and describe the stuff they do in detail. Having things documented is good anyway, but most importantly it allows to find out how they think.

What I don't understand is, if these people do want to make their contribution here, why are they not posting their work (well except for Raczman's latest patch) ? Even if they do get added to the team we can't have them bulk-committing their stuff for a while, those changes need to be rediscussed. They will probably have to post some things as patches and document them to get everyone else up to speed as well as interact with us on IRC to iron things out and they don't need a dev status to do so. Sure, you can always revert commits but it's better to prevent having to do that. Maybe they could commit some small changes faster if they get a dev status right away but it's the big changes that they really need clearance for, besides the definitions of small and big are very fuzzy .. We need to learn how they think and how they make their decisions to correct any problems, misunderstandings.

There were already commits fixing problems from your previous logs. I think about 2 crashes and memory leaks, don't remember exactly. They also helped confirm another major problem with grid unloading though the fix for that is yet to be written.

You coulduse something like Rational PurifyPlus. The version that you will likely find around the interweb works with VS 2003 and 2005, but you can download an update for 2008 from IBM. Each of the project files needs to be modified slightly to work with it, namely non-incremental linking in the linker settings and fixed base address in the compiler settings.

Why add yet another threading library when we have two already ? Do you know what you are doing differently compared to Derex's patch that may give different results ? Did you do an in depth search for any possible resources which might be used by two of those threads at the same time in a manner that may require locking (IIRC there were a few cases that were addressed by Derex's patch) ?

Only if it will work on any type of GPU, with varying performance on different types maybe. Before resorting to that kind of stuff better just implement something that will work fast for everyone while designing it in such a way that its components can easily be optimized further after that.

And how can pet->CreateBaseAtCreature(creatureTarget) return false when CreateTamedPetFrom is called from that particular location .. These are the things that should be mentioned in comments around the NULL check. You don't need to think of all cases, just give one example of how such an error can occur and it's all justified.

If you don't specify why that function can return null this is just another hack.

No. The long waypoint path only starts when you trigger the escort quest, and then you can also set the creature active so even if no player is near, creatures around it will still attack. After the escort ends, you remove the active state because it would just waste resource otherwise. Escorts are one of only a few cases where you expect other creatures to react to the movement. In the vast majority of cases it's enough to calculate the result of the movement when players get near again. You save a lot of cpu usage and get the exact same effect, you can still meet them in the middle of the path.

Yeah it seems it got lost at the forum switch somehow. I found a link to it but that leads to nowhere. The basic idea is that, from a player's point of view, when it enters a grid that hasn't been updated, the waypoint mover just needs to be in the right location, it doesn't matter whether it moved there bit by bit or all at once. So for example if you pause the creature update when the grid stops updating, when you start updating it again, the movement generator could fast forward to its correct location. This would be a fairly simple calculation except creatures can move across grids and you don't want to loop all waypoint movers every time a player enters a grid. So what can be done is for each grid to store the list of waypoint movers that need to be placed on grid activation. When a player enter the grid you just loop the list, calculate the exact locations of the creatures and place them. These lists need to change in time as a waypoint route can pass multiple grids so for each waypoint mover you calculate when and what grid it will move into next. You can put these waypoint grid change event times into a priority queue where the nearest time is the highest priority. When that time is reached you do the grid change (remove from one grid list and add to the other), remove that event from the queue and add the waypoint's next grid change to it.

Keeping a grid active for waypoints just means unnecessary overhead for the vast majority of cases (unless proven otherwise). If we just set all waypoint creatures to load the grids, even if it's just a switch, then nobody will try to do it better as most just assume it's not possible.

This has been discussed before and it is possible, albeit complicated, to do waypoint movement efficiently, without updating the creatures when the grids are not active or even unloaded. Please search for the respective threads.

Offtopic: just out of curiosity, who are those people and why do they need to work at the same machine ? .