jolan

I didn't try it with 3.x maps/vmaps yet. it's still for old 2.4.3 files

for you info, ascent implemented it long ago. unfortunately AFAIK their licence is not compatible with mangos one. maybe a chinese wall approach would allow us to implement it.

unfortunately, I did not do anything on mmaps lately due to real-life stuff (changed apartment, holidays ...) that doesn't mean I gave up and that doesn't mean it can be applied to mangos right now.

If I understand correctly, you want to stop Update*Visibility when the player is not actually moving, and you add a timer in order to update only after the interval the client usually sends packet when moving straight forward. then modifying Player::SetPosition to check if x,y,z changed seems a better solution to me . you could pass an arg to tell if Update*Visibility are needed (if x,y,z changed) and force this flag to true in Unit::SetVisibility and i think in Traveller<Player>::Relocation too. or you can check before and after player->Relocate() in Map::PlayerRelocation() then you wouldn't need neither extra var in player* nor getMSTime() and you would have better speed / accuracy.

@ evilatwow : you are right , is miscalculated it . @smellbee2008 : I dont know how many grids are loaded in this case for a real server but the worst case is every grids is loaded :-) spawned GOs are not handled ATM. perhaps later ...

that's 3000^2 pointers at the lowest = 9M ptrs = 27MB per grid w/ a 32bit arch. thats still a lot IMO but maybe it would be better that 2ms per path (the time I get right now). maybe you could write your own pathgenerator_floyd.h so we can test.

yes, as long as the grid is active. I think. that would be hundreds of Mb per grid.

well , grids are kept loaded for a while, the more the players, the more grids get loaded at the same time, and remember there is an option for keeping grid in memory forever. that said perhaps movezones wont consume that much memory, I didnt check that. feel free to try these algo, and lets compare results about 3000-4000 zones, with a variable ammount or portal in each. that's not hat much and I expect to achieve faster path generation. yes that's supported. portals are one-way, so if we ever want to allow mobs to jump down, and use a different path to go back, it will be possible. I dont know if it will be usefull.

it's in src/mmap/PathGenerator.h (github) I think we can keep the generated path in memory for long paths in order to re calculate the end of the path if the destination object moves. it's more memory vs more cpu so it mays be configurable, and I dont like eating too much memory. other algorithm may be suitable, I focus on A* but someone else could try another one...

I didn't

you are right subhuman_bob, 5ms is slow; honestly I expected better results when I began this. I think (hope) there is room for optimisations. if it cant be optimized, a thread is an option, even a separate server as long as the latency is low. data exchanges would be quite small.

thanks for the offer. I think generation / usage separation will perhaps modify the way destructors will have to be implemented so it's a thing that should be handled then.

Several people (2 actually) asked me what's the progress with movemaps, so I think it's time to give a small status update. about when it will be done : I really can't tell, I dont always have time to devote to it. I progress slowly. what's done : mmap data is correctly generated : as I described it , it's rectangular move zones connected by portals. portals are correctly connected to nearby zones, including zones in adjacent grids. move zones are stored in an R*Tree which allows fast lookup (about 3 microsec. a lookup). a path generation starts by 2 zone lookups in order to get the starting and the ending zones. the Path Generator is not 100% perfect but works resonably well. there is still some bits to take care of but it have been tested inside a sigle grid (larger paths will need mmap load manager). it's an A* algorithm. a path takes about 5ms to generate for paths inside a given grid. what needs to be done : there is still some things to eventually take care of in mmap generation : some zones are completely contained in other zones and this is not handled. I dont know if its desirable to include them as these are usually terrain glitches. dependencies update : maps where changed since ralf started it, and I think g3d libs too, I didn't watch closely. right now I still use old 0.12 maps and vmaps generated with rev 6989. thats before DiSlord enhanced maps. those who took a look at some parts of the code know there is some garbage to clean. (my favorite one being : + printf("#### graaa ####\\n"); ) , destructors are not implemented, I'm not very good at memory management. mmap generation and mmap use must be separated. everything is in the same classes. functions and data that are only used for mmap generation have nothing to do in a pathfinder system. load / unload manager : similar to grid loading in mangos once these stuff are done, movementgenerators could be enhanced to use pathgenerator (with still the classical code as a fallback) a batch to generate and connect mmaps. I use a php script to generate mmaps but it might not be a good solution for windows systems. VC++ build files. an exemple of path, with and without vmaps :

pointers are much more efficient to move around. function doSomething(Player thePlayer); // will copy the Player struct each time it is called, will delete it when it returns, will not modify the original Player if the function modify (or call a member function modifying) thePlayer function doSomething(Player* thePlayer); // none of the above so the second version is faster and use less memory.

00_25_32.txt is in the StartCoords folder. there is no move zone in your file, either it was generated with an old version of the generator or there was an error when you generated it. can you provide the output of its generation ?