faramir118

Submitted patch to under review that should fix npcs slowing as they move to dest

What bug does the patch fix? What features does the patch add? several bugs related to pets: Unit::Update always calls StopCombat for pets that are owned by NPCs Pets are prevented from calling for or receiving assistance Pets aren't unsummoned when NPC owner dies (may not be blizzlike) For which repository revision was the patch created? 11000 Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread. no Who has been writing this patch? Please include either forum user names or email addresses. me patch: https://gist.github.com/777044

From first post:

Transports (boats, zeppelin, etc) a) NPCS don't move with transports like players do (not implemented in core, as far as I can tell) b) even if a is fixed, we can't pathfind onto a transport for a lot of reasons. Simply detecting when start/end pos is on a transport is sketchy. npcs slowing as they move to dest There are a few places in the core where MoveChase is called almost every update cycle, sometimes more than once per cycle. Destroying and creating the movement generator like this means the NPC never actually moves. Need to re-write some of this code. Some stack traces here. edit: There's more to it... need more debugging to find root cause of this.

It's a bitmask, one bit per player title

If you're reading http://srp.stanford.edu/design.html, scroll up and read the key

Or google: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=0x0000010000000000+in+decimal It does binary, octal, decimal, and hex http://www.googleguide.com/calculator.html

fix/test existing bug reports transports (haven't personally confirmed this) npcs slowing as they move to dest (hard to reproduce) actively try to exploit pathfinding in game cheating is something I want to avoid just as badly as crashes and again, more testers If you have english speaking players, tell them they can report bugs directly to us If you have questions, ask If you don't find any problems, tell us! It's not too early for a code review from a dev I expect small, local changes. But the system as a whole shouldn't change much

updated to [10986]

Because he picks players up, I always assumed that they were vehicles.

Completed the implementation, now handles all network traffic if you set the config value I added. Testing on Windows from a couple different computers... my client always eventually stops sending CMSG_TIME_SYNC_RESP - when this happens, the client stops updating even though it stays connected. I can't figure out what is causing it... going to work on something else for a bit

I just had a rough time with this scenario: class ApiClass { // some member variables }; class StupidApiClass { BadClass(ApiClass &myClass) : m_apiClass(apiClass) { ... } ApiClass &m_apiClass; }; void api_func(ApiClass &apiClass) { BadClass b = new (apiClass); } In case you are wondering, ApiClass = ACE_Message_Block With these horrible semantics, it's no wonder we have strange crashes in network code...

While it's true that ACE spawns a thread to block for IO completion, I think there's more possibilities with a system like this. (edit: referring to asynchronous system, not specifically ACE proactor) For example, we could handle all DB writes, and maybe some reads via continuations, asynchronously. In this way and others, the mangos update cycle would get more dedicated time to do its thing. The supposed efficiency of IO completion ports, RT signals, aio, etc might just be icing on the cake. And it would be neat if mangos were 'multithreaded' out of the box

I finally got around to playing with an asynchronous network IO implementation. I've only thought it through a little, so before I get carried away I figured I would open a discussion. In a nutshell, the benefits are: better scalability via non-blocking IO - read this paper for some explanation on why reduced synchronization complexity - not really seeing this yet the code: https://github.com/faramir118/mangos/tree/aio And like my other project, I'll update this post occasionally.

On US servers, raids and PUGs have almost universally used moon as the marker for which target should be polymorphed.

I'm not sure if compilers perform this sort of optimization. If they do, it's only when you aren't modifying the parameter. If you want, you can just use pass-by-reference to force this 'optimization': void passByRef(myStruct& m); // allows modification of m to persist after passByRef returns void passByConstRef(const myStruct& m); // m is read-only (compile error if you try to modify it) myStruct& retByRef(); // allows modification of return value const myStruct& retByConstRef(); // lhs must be declared const Just watch out for things like this: struct myStruct { int data; myStruct() : data(0) {} ~myStruct() { cout << data << " says goodbye!" << endl; }; void passByRef(myStruct& m) { m.data = 1; m = myStruct(); // destructor is called on m AFTER the constructor (for me, anyway) }

Without the platform SDK, VS Express won't compile for x64

They must be spawned GOs Thanks for testing patch, I suppose I'll push it

In the same spirit as the op: http://www.google.com/chrome/intl/en/p/cause/ Happy Holidays

Not dtTileRef struct dtMeshTile { unsigned int salt; // Counter describing modifications to the tile. unsigned int linksFreeList; // Index to next free link. dtMeshHeader* header; // Pointer to tile header. dtPoly* polys; // Pointer to the polygons (will be updated when tile is added). float* verts; // Pointer to the vertices (will be updated when tile added). dtLink* links; // Pointer to the links (will be updated when tile added). dtPolyDetail* detailMeshes; // Pointer to detail meshes (will be updated when tile added). float* detailVerts; // Pointer to detail vertices (will be updated when tile added). unsigned char* detailTris; // Pointer to detail triangles (will be updated when tile added). dtBVNode* bvTree; // Pointer to BVtree nodes (will be updated when tile added). dtOffMeshConnection* offMeshCons; // Pointer to Off-Mesh links. (will be updated when tile added). unsigned char* data; // Pointer to tile data. int dataSize; // Size of the tile data. int flags; // Tile flags, see dtTileFlags. dtMeshTile* next; // Next free tile or, next tile in spatial grid. }; 4 x 4byte primitives + 11 pointers = 60B x86, 104B x64 I do want my earlier fix tested more, I don't know if it will have runtime side-effects.

It's sizeof(dtMeshTile) * 2^21, which on x86 works out to about 120mB (without padding)

See if this helps (you need to re-extract maps, but it will skip all tiles so it won't take long) diff --git a/contrib/mmap/src/MapBuilder.cpp b/contrib/mmap/src/MapBuilder.cpp index 27d8eab..d53635c 100644 --- a/contrib/mmap/src/MapBuilder.cpp +++ b/contrib/mmap/src/MapBuilder.cpp @@ -646,7 +646,7 @@ namespace MMAP int tileBits = STATIC_TILE_BITS; int polyBits = STATIC_POLY_BITS; - int maxTiles = 1 << tileBits; + int maxTiles = tiles->size(); int maxPolysPerTile = 1 << polyBits; /*** calculate bounds of map ***/

Some memory is pre-allocated when the navmesh is loaded (before any tiles are loaded). I didn't think it would be that high though, I will look into it. edit: Probably because we hard-coded 2^21 maxTiles

Maybe not expected, but using that value still works. Checks are done in such a way that INVALID_HEIGHT is invalid height (except for that one case in Creature::FallGround() above) Should maybe create IsValidHeight helper function

In a combat log, you can look at the diff between each proc's timestamp Should be able to tell if it is per-player if the diff is less than 4 seconds