qsa

Got some time to comment on some of the post here

I found another bug on Undergarun's server : if hunter stands on edge of floor/stage（e.g. the towers in north Western Plaguelands and stage of Lethtendris in Dire Maul East) which connects to ground with stairs/slope, the aggo mobs will not go up stairs/slope but go directly to the position on the ground under hunter and just watch hunter without any motion(except range spell). In this case, hunter can easily kill the boss or mobs and even hunter moved back to floor/stage center from edge, the mobs still can not go up stairs/slope but follow postion on the ground under the floor where hunter is and evade after few seconds.

Regards,

AMING51

I can confirm this issue. I'm not sure if its caused by GetContactPoint() or by TargetedMovementGeneratorMedium::Update line 231 - I suspect the later ... Unfortunately, I do not have the time testing it at the moment. But, I'll get to it soon enough.

Sorry for not following through on some of these maintenance and support things - I've shifted most of my attention to real life issues, trying to improve my lot in life (nothing is wrong - I just want a better lifestyle for me and my gf)

The charge movement generator patch is still around. Movement works, but you should test it before really using it - not 100% sure I return correct values in the Update function.

If you report a bug, please use map number and coordinates! If you can't/don't use the gps command, our capacity to help you will be greatly diminished!

As far as testing goes:

• make sure the pathfinding log filter is disabled
  
• judicious use of mmap debugging commands when investigating issues
  
• use RecastDemo to inspect the meshes
  I will find out why it's not working on zero - until then, you should be able to use the master branch's version instead
  

At this point, since Undergarun is apparently still using mmaps, things seem to be going well.

On the other hand, some people seem to be having lots of trouble with pathfinding, yet they I don't think they've been around to ask for help. For example, this pserver says they bugged alot of the server (don't worry, that pserver and its website seem to be defunct)

Thus, I don't know where we stand - are there really that many problems, or is it just a usage problem? Which leads me to...

It would be nice if someone created a mmap guide thread - details on how to do the generation, configuration options, commands, proper ways to test in-game and through RecastDemo, etc. Maybe include a list of community-provided offmesh connections?

Fully agree on everything said here. We do need test results. Both positive and negative.

Unfortunately, we cannot rely on reports from aforementioned servers which do not run our version, so trinity guys are on their own for now.

- Good luck dude.

I must ask, since recastnavigation still is in active development (as i see it last commit 38 h ago as i post this) how often will you update the recast library? it might also solve navigation bugs in the pathfinding?

Recent updates in Recast has nothing to do with the code we actually use. It is nice to stay up-to-date but currently it provides no benefits.

As for implied "navigation bugs" - mind listing those here please?

Hi everybody.

I have to disabled mmaps due to freeze issues with latest sources

Crashdumps:

http://pastebin.com/29CS8hWx

http://pastebin.com/a0Rp1Bwr

Test about mmaps performance will come when i finish some tests for some Ambal's patches.

Cheers.

Can you provide some additional info?

Those started after some mangos change, or mmap change, or they always were here?

Not saying that mmap code is freeze-free, its just can be many factors affecting this. Things like multi-threading in particular.

Just some interesting facts about pathfinding and charge-pathfinding http://filebeam.com/c5ce986b6e31758ac2c248743ee0a143 (3 of 4 videos captured from official server)

as you can see Charge effects can even climb at mountains under 90 degrees %) and mobs can even jump from these mountains

I think we need to change

maxWalkableAngle

to 90 instead of 60 and use it as parameter in path-selecting functions (to determine when we need to use paths generated for 90 degrees)

It can be implemented?

Changing the clime angle to 90deg is nonsense ( even with marking them). This will only cause the mmap contain all surfaces making searches even longer while not actually solving anything.

Given examples (movies), show only one thing : retail ensure that if succeeded casting charge, it will get you to the destination. I can grantee, this is not done by having 2nd set of maps, but by appending destination to any generated path.

This is what already happening in our code as well, from the last set of changes https://github.com/faramir118/mangos/commit/6cd0ec8f9a37604d1a74c02ba5d08cbf60adb7cc.

I haven't had the time to properly test this commit, but feel free reporting the results.

The only case, in which I think it can be worth having additional set of mmaps, is for different agent size.

Thanks in advance, Cheers.

Don't know as in MOne and LK,

But in MZero i have bug.

Mobs can't find way to player in this location:

Map(0) Eastern Kingdoms

Zone 40 - Westfall

Area 109 (Furlbrows pumpking farm)

x ( -9872) Y (1315)

0002950 mtile

Sorry, can't check on zero - but it works just fine on master using the default parameters.

Maybe someone with zero can extract that tile with debug info and upload or post a screen.

I got this one too, because of C++ limitation. I solved it by replacing GetMovementGeneratorType() by this->GetMovementGeneratorType() (C++ need precisions here). But maybe it's not the way the author intended to do it, so maybe qsa solution is better !

It should be exactly the same thing, I didn't use the "this->" thingy, since it should be implicit as in C++ standard, so I wasn't sure it will compile on *nix systems. Good old cpp and its corner cases.

EDIT: pushed the change into repo.

/home/MaNGOS/source/src/game/TargetedMovementGenerator.cpp: In member function 'void TargetedMovementGeneratorMedium<T, D>::_setTargetLocation(T&)':
/home/MaNGOS/source/src/game/TargetedMovementGenerator.cpp:84: error: there are no arguments to 'GetMovementGeneratorType' that depend on a template parameter, so a declaration of 'GetMovementGeneratorType' must be available
compilation terminated due to -Wfatal-errors.
make[2]: *** [src/game/CMakeFiles/game.dir/TargetedMovementGenerator.cpp.o] Bł±d 1
make[2]: *** Oczekiwanie na niezakończone zadania....

compilation error with cmake, in visual studio on win7 goes without errors

Please try this one :

diff --git a/src/game/TargetedMovementGenerator.cpp b/src/game/TargetedMovementGenerator.cpp
index cd2d372..45d5048 100644
--- a/src/game/TargetedMovementGenerator.cpp
+++ b/src/game/TargetedMovementGenerator.cpp
@@ -81,7 +81,7 @@ void TargetedMovementGeneratorMedium<T,D>::_setTargetLocation(T &owner)
    bool forceDest = false;
    // allow pets following their master to cheat while generating paths
    if(owner.GetTypeId() == TYPEID_UNIT && ((Creature*)&owner)->IsPet()
-        && GetMovementGeneratorType() == FOLLOW_MOTION_TYPE)
+        && owner.hasUnitState(UNIT_STAT_FOLLOW))
        forceDest = true;

    bool newPathCalculated = true;

What about system statistics w/out mmaps? Thanks in advance.

I'll post it as soon as possible, currently i'm very busy at work.

No rush, as long as it isn't forgotten completely

Qsa or faramir118,

Can you please add the MaNGOS copyright in the python file I gave you to generate mmaps (contrib/mmap/mmap_extract.py)? I did forgot to add it.

Thanks,

Neo2003

Added.

Personally, I find this kind of copyrighting silly, but, its a strange world we live in

1. Pet always stand on the terrene or ground under water when following hunter who is floating in the water. So it's easy to aggo the mobs under water.  At this time, pet can not attack the target floating in the water near my hunter. So if hunter attack the mobs floating in water near by, pet just stand below and can not find the way to my target and watching me to die.  I think it's bug according to my retail experience. 

Tried setting InhabitType to ground and water?

That's the reason.

Furthermore, I removed to hack that allowed pets who "cannot swim" to enter the water in the first place.

This have to be solved somewhere else in the core. Maybe some special case for pets in canSwim function, or overload in pet class.

I can't recall if on retail, all pets can swim in the first place.

2. Sometimes( about 30 percent especially on the hill ground ) pet can get to run very slowly when close to my target, the more it get close to the mob, the more its speed get slow. Sometimes no such speed issure especially on the plane ground.

Added faramir's old patch into repo, it should solve this issue.

3. Pet and mob choose different moving path and form a circle path which means pet can not catch up the mobs when hunter attack mob firstly. Pet should intercept the mob on the way mob coming. This issue can happen when the mob stand behind obstacle like fence, carriage etc.

Not sure if we can, or should do something in this case.

This sort of things can happen regardless of path generation logic used.

4. The hunter skill " Eyes of the beast " can only use in close range( about 45 yard) and cancel automaticly when controled pet go out of this range. I don't know if relate to the Movemap system( Pets disappearing range/zone). While I have 1 mins to go more far distance on my retail to aggo mobs in the mountain.

Pretty sure that it isn't move map related.

The only range limitation we currently have, is around 300yards paths at any given time - this clearly is not this issue.

5. When hunter jump down from the cliff, the pet just stand there above me becouse of no path found and can not follow me. So I can only use " Eyes of the beast " to make pet jump or reload my char. I think whether we can set pet to follow hunter without MMap when no path found to become more smart as retail.

Added patch to allow pets follow their owners even if there's no real path.

If by "smart" you mean jumping off the cliffs like on retail, than it is "smarter" now.

6. Sometimes pet suddenly disappear when following hunter and need to sommon out. Especially in some complicated area like in a construction/building/tower with many stairs and passages in Stormwind City, the pet become very easy to get lost when following hunter and disappear suddenly and never come out again no matter how many times I pressed the follow button. Even my hunter move a few steps on the stair, I still can not see my pet follow me. When I come back to the position where pet disappear, some time it will come out nearby. I feel pet is not smart enough to find the right path or shortcut or even can not find path to hunter in this complicated area.

Same as above.

In general, if path cannot be found, creature will evade.

Every such place should be handled separately.

7. Other issue not relate to mmap system: pet always follow hunter's step so always keep about 8 yard distance behind the hunter in moving straightly. While on retail pet have speed up function (or advance movement algorithm) to keep position with hunter. So you can see that when hunter suddenly stopped, pet will go forward few steps and turn back to hunter's position. At present without this algorithm, the distance will become larger and lager when hunter running in complicated area where pet need more time to pass by. This is another reason why pet disappear after too long distance behind hunter.

Just like you said, not related to movemaps.

Updated the repository with mentioned above, feel free testing.

Cheers.

http://pastebin.com/w4gtA7YD

Appears only once in 1 week.

Mtmaps.UpdateThreads = 4

Pretty strange dump.

Some things just don't make sense, like "mapId = 3901870289" which suggest invalid source object, but the strange thing is that it still tries to build the path while it should have failed right there.

Can't say much without more crash dumps.

Feel free posting those if them repeat.

What about system statistics w/out mmaps? Thanks in advance.

sorry for double post...

I don't think adding vmap checks will solve the falling-underground problem, because vmaps don't perform tests on terrain terrain. I can see the corner cases where the random destination is on the other side of a wall, so our path takes us through 10 rooms. This is a problem with the naive random destination selection - it only cares about euclidean distance, not walking distance.

There are some detour-provided things we can leverage to solve this problem. dtNavMeshQuery::findLocalNeighbourhood will give us reachable polygons within a certain range, which can confine our 'random' destination to an area that is reasonably within the walking distance we specify.

From my experience, people fell underground mostly in places like arena's ramparts/pillars - LoS covers those. For general terrain (which is not covered by vmaps) the Z value is checked from maps, so this falling doesn't occur there (mostly).

Sure, we can use navmesh to implement those, won't be too pretty. We'll have to teach PathInfo couple new tricks, or make different class.

Which reminds me, it can be good idea to encapsulate all direct recast calls, so we wont be tied to it directly in code.

The only place we use it directly, is in debug commands, if I remember right.

Some bugs reported:

Pets are attacking themselves until they reach their target.

Can anyone can please confirm this?

It isn't sound like something related to mmaps, nor I can reproduce it on local.

When the pet's target moves behind a column, stand still in but should return to the hunter or continue moving to the target. (don't know how does it works on retail).

Pet stop following when they fail generating path.

This is done to avoid logical loop.

Lets assume while pet was failing to move, it would try to come back to its owner, then fail again - loop with no exit point.

What happens now, is that, it just stops. Player can click follow/attack again, to try once more.

Some bosses, as the lich king, move under the map when we attack them.

Same problem here, but don't know if is mmaps related ;-)

Same problem, same solution - read above, this issue been addressed multiple times.

Can you please provide server statistics : CPU/MEM usage w/out mmaps? What mmap revision used? Uptimes ...

Things like that. Thanks in advance.

Player being under effect of fear, disorient and other auras causing it to lose movement control, cause the player to fall under map texture when moving on nonflat surfaces. Can this be fixed by mmaps?

Maybe is possible to implement pathfinding use in ConfuseMovementGenerator but not yet implemented.

About confused/fleeing movement generators :

I don't think we really need pathfinding for those. You see, on those distances, visibility implies reachability. In other words, simple LoS check will do just fine. The reason players fell down while confused, is lack of those checks.

Below code (around line 47 ConfusedMovementGenerator.cpp) will do the trick.

// check LOS
       if(!unit.IsWithinLOS(i_waypoints[idx][0], i_waypoints[idx][1], z))
       {
           i_waypoints[idx][0] = idx > 0 ? i_waypoints[idx-1][0] : x;
           i_waypoints[idx][1] = idx > 0 ? i_waypoints[idx-1][1] : y;
       }

In conclusion, I think adding pathfinding to those generators, will not solve anything better - it will only create more corner cases (taking long path to get near-by point). Nor it will simplify the code, therefore, it is not necessary.

Cheers.

Hi !

I'm using this branch :

https://github.com/faramir118/mangos/tree/mmaps_clean

I have problems with all the mobs which fly. Some bosses, as the lich king, move under the map when we attack them.

Am I alone with this problem?

Thanks by advance

I advice you to try other branch. Maybe something gone missing at porting.

If the issue persist, please provide additional information - location, etc.

I know for a fact that flying creatures do work just fine on my test machine. I'm sure other's can confirm this.

Lich king has different issue - his thrown is GO, the actual ground is far below. So it can cause issues. I advice on disabling pathfinding for him, from his script.

ERROR:1308623044's Path Build failed: invalid polyRef in path
ERROR:184648746's Path Build failed: invalid polyRef in path
ERROR:184648762's Path Build failed: invalid polyRef in path

Are these messages useful?

Depends how often you get those, I can imagine few cases when it is "expected".

If it is often, this may indicate some problem.

That number is GUID of creature that encountered it, so it vary from system to another.

It cannot hurt us. Maybe we'll get it reviwed and some ideas for improvement.

But prior, I'de love to get feedback about some of our latest changes. Those thread issues in particular.

Cheers.

Now i am upgrading my servers to 48 GB DDR3 ECC in order to continue tests with high populated and mtmaps enviroment realms.

Stay tuned!

New versions don't need that kind of memory sizes, but it surely cannot hurt.

I'm looking forward for results, thanks.

updated to [11204]

Also created a new branch, mmaps_clean - it is a rebased version of mmaps_rewrite

With qsa's approval, I will post this branch in Under Review forum

It cannot hurt us. Maybe we'll get it reviwed and some ideas for improvement.

But prior, I'de love to get feedback about some of our latest changes. Those thread issues in particular.

Cheers.

patch to use shortcut if tiles are not loaded or do not exist (untested)

https://gist.github.com/842876

I think http://pastie.org/1606946 is more than enough.

Just recently added, I haven't looked at it very much:

https://github.com/Lynx3d/mangos/tree/transport

Hrm, branch deleted.

Shame, it was just the same idea I had Wonder what went wrong

This sort of thing happens when you have .mmap file for given map, but you stand where there's no tile loaded, maybe no .mmtile for that map?

I think I see the problem. Extractor errors on those maps. I think there its from my cleanup back in the day

Oh, well - good that this issue was found. I'll push something shortly.

Thanks for reporting.

You will have to extract aforementioned maps ( on any maps with .mmap files but no .mmtile files ).

Cheers.

yes, but the reason there's no npc support on transports, is that server virtually oblivious to their existence.

There's no system to translate map coordinates to moving transport coord set.

Having it implemented shouldn't be that hard ...

Below something that's hopefully solve (atleast some, if not all) issues with offmesh connections.

http://pastie.org/1590468

Please do test.

About all those compile issues : sorry, but I can't see a single one, related to our code.

Patches are always welcome.

If you have issues on your platform compiling our CLEAN repository, please do let us know. Including platform description and solution.

About my previous patch, the one with threading issues.

I'm going to assume it is sparkling ... so, I'm going to commit it.

1- Does exist a way to detect boat, zepplin and other transports ?

Transports aren't supported at all in mmaps. At best, you can disable pathfinding to players where Player::GetTransport() != NULL

Since mangos do not support NPC on transports by default, we have no way doing it either, so, with or without mmaps you wont have it working. What I'm saying here, is that disabling mmaps on transports wont solve your problem.

I think its been discussed few times already.

Here we go, http://pastie.org/1576286

Test patch to solve those threading issues. Do not forget to remove that code from post #916.

Thanks in advance for testing and reporting results.

PS: Is it just me, or TerrainInfo never unloaded on runtime? Tiles unloaded just fine, but not the TerrainInfo itself.

I haven't seen Map::~Map() called on runtime either, while I do have Instance.UnloadDelay set to just few minutes.

shouldn't you be relatively easy (and save) when moving the movement-meshes to terrain manager?

Movement meshes are for pretty long time now loaded/unloaded from terrain manager, just like VMAPs.

They are not the issue. The issue is dtNavMeshQuery - the part that does the calculations on top of those meshes.

It is not thread safe on itself. So, we have to have one of those per instance and NOT per map.

We "cannot" have it per path calculation either, since it is pretty heavy on memory.

Hi qsa

All freezes disapear with your patches but i notice a mem-leak in somewhere

This is my 1000+ ppl realm after 6-7 hours of uptime with mmaps.

Cheers

Unfortunately, this is not a memory leak, it is the actual memory usage under this model

You see, what used to happen, that all creatures on same map used to share dtNavMeshQuery (the engine that does all the calculation). What happens now, is that every path calculation has its own dtNavMeshQuery. Just like we used to have while back. Well, as you guessed, it is pretty expensive, memory wise.

What it made me realize, is that I was looking for the problem in wrong place.

The actual issue is thread safety. As "simple" as that.

Right now, we have single dtNavMeshQuery per map. So, what happens, is that two different instances from two different threads of that map use it simultaneously, that's why we get those results and consequentially, crashes.

Find the problem, is about 70% of the work, now its just a matter of fixing it. I'll allocate query for every instance.

Going to change our loading/unloading model a little bit, we'll have to hook somewhere in Map class

Please do correct me if I'm wrong with the logic here. From what I can tell, every instance run in thread of its own right now, not every map.

If, that is not the case, spare me some time digging into instance code.

Need update to latest mangos revision =(

I merged the latest.

Unfortunately, I do not have *nix system with mangos at the moment, so, someone else will have to make cmake files, or wait till I get to setting one up again, which wont be in any immediate future. (thanks in advance)

Cheers people.

New freezes in another two maps:

http://pastebin.com/RtkbKT7B

http://pastebin.com/pi8Trd1Y

Different crash, but I guess they caused by similar issue.

Can you please try this : http://pastie.org/1568503 - thanks in advance.

PS: how often does it crash?

It looks ok I think, so the reason why the mob desappear should be in the server core and not caused by the mmaps generator. Probably because of the remaining differences between master and one, like ambal's modifications like you said. This is maybe still over my head but I'm still available for help I can do any good.

You are half way there

Anyway to reproduce it? doe's it always happen, or just sometimes?

sometimes, when you have a pet and pet follows you to the pillar, or when pet attacks target on pillar

Thanks, found a way to crash it. Now only left to find a way to solve it, or atleast understand why it does.

mehh, all those new issues coming from pretty deep in recast code

Yes, SilverIce already put his changes regarding dynamic LOS in his git repo - you are free to check it.

Qsa about dynamic LOS - I saw SilverIce working on it I guess, I hope he will release some under-development patch or something for it some day

Good to know someone working on that issue.

In general, I don't think we should have support for dynamic objects as pre-requirement to "first stage".

qsa : I tried to open my mmaps file into RecastDome but could manage to do it (such a noob...) I renamed them .map and .mesh in the meshes folder but the app crashes. I took the files from the mmaps folder. Could you give me a hint on how I should open the mmaps in RecastDemo ?

You have to compile recastDemo from our repository, then copy the binary to folder with SDL.dll, DroidSans.ttf - you can find those somewhere inside recastdemo folder.

Then, you should extract mmaps with their debug info. You have two folders now, one named "mmaps" and another "meshes", copy them into same folder as recast binary. There's no need renaming anything.

Thats about it, if the format is proper, recastDemo will have no issues opening extracted maps.

It's still relevant, but only this part is the fix for our issue:

diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp
index 38b78c1..7c043b0 100644
--- a/src/game/Unit.cpp
+++ b/src/game/Unit.cpp
@@ -321,7 +321,7 @@ void Unit::Update( uint32 update_diff, uint32 p_time )
        getThreatManager().UpdateForClient(update_diff);

    // update combat timer only for players and pets
-    if (isInCombat() && (GetTypeId() == TYPEID_PLAYER || ((Creature*)this)->IsPet() || ((Creature*)this)->isCharmed()))
+    if (isInCombat() && GetCharmerOrOwnerPlayerOrPlayerItself())
    {
        // Check UNIT_STAT_MELEE_ATTACKING or UNIT_STAT_CHASE (without UNIT_STAT_FOLLOW in this case) so pets can reach far away
        // targets without stopping half way there and running off.

Why don't you push it. One bug less.

Just as question would it be possible to have NPCs using mmaps on their default movement?

It is their default movement.

On ytdb there is a certain Ironforge guard moving right through the great forge, if it was using mmaps it should not move through lava and fly across the air.

Mmaps will not work with gameobjects (forge in ironforge) - same reason why LoS don't work. We cannot implement it till LoS has it working.

About that guard flying around : I guess it uses waypoints, if they are set wrongly (he have waypoint to unreachable location), you can get some strange effects.

Other than that, these special places (like in bootybay) where movement is blocked by "strange" environment can be fix after adding the mmaps patch to the core. They are spotted by coincidence.

See post #891, those spacial places have to be fixed manually. Dock in bootybay, pillars in blade's edge arena, maybe some otehrs. In any case, there's a mechanics that allow solving those.

So it's time to think about moving this to underreview...

I think we need to list all known issues first. Then, get it tested on major sized server for some time and get proper feedback. Only then we can start talking about moving to review.

In any case, it can be nice to get some remarks about the general design from one of the devs.

I'm sorry to bring that back, but did anyone else tried to apply this great project to a mangos-one ? I'm still trying to help, but didn't find out yet why the mobs disappear when aggroed. Maybe it's the mmaps extractor that needs more modification than I already did (I just in fact changed the MAGIC ver. and deleted the "holes" part of the extraction.

Make sure the maps extracted by the ported extractor are proper. Open them in our recast demo and see if you get what you expect there.

Afterwards, you have to be sure you ported the core part properly. Keep in mind, that the current implementation of map loading/unloading system tied to terrain manager code, which in tern has to be backported first. Alternatively, you can use our old scheme, the one we used before terrain manager, but I think it is easier and safer to backport.

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

Sorry for digging this corpse, but, is it still relevant? Anyone test it?

You can either common parent class if you use inheritance, which isn't that trivial in c++.

You see, since c++ isn't real level 3 OO language, it do not support things like common inheritance root. Like object in java. Actually, java used to store objects in all its datastores before it had templating.

back to c++ ...

The real problem with storing void*, is that you don't know what type they are.

One way it is "solved" in c++, is by having wrapper class, that holds void* and "type" variable. You store wrapper classes in your collection. When you pull it from it, you check the type, and upcast accordingly.

Really easy to implement, or you can just use ready one, just like darkstalker suggested.

I finally crawl from under the rock I was stuck for a while and had the time to play around with things.

What came out of it, was the ability of create off mesh connection. In other words, the ability to patch

mmaps generated by the extractor.

Pushed in to the repo today.

Why? That's the simple: we cannot cover all possible cases in generic code, therefore, we have to have mechanism to allow exceptions.

How? Simply by providing input text file to the generator. You can see the example under offmesh_example.txt.

Some more info can be found in readme.

Basically you provide map, grid, start and finish locations and it will create link between those points.

The pro's : Things like this (for those who remember) http://oi53.tinypic.com/2qipzeu.jpg are history.

The con's : It have to be done manually (no shit), and it will work only on same tile (aka: you cannot link locations on different tiles - not a biggie, but still worth mentioning).

The format must be exact! The "parser" is pretty weak, so if you don't follow the exact input format, it wont work. So, don't forget things like spaces, etc.

In offmesh_example.txt I gave the example of booty bay dock, feel free posting here your entries! Please include screenshots if possible.

It needs some testing, since I didn't had too much time testing it

Cheers people.

PS: been checking some posts here, I "missed":

1. faramir118: cheers for backporting.

2. about charge: I think the only thing that's missing at the moment is the delayed stun - beside that we have it working exactly as buggy as on retail (talking about charging from one side of the map to another).

Well operator new[] followed by an exception means most likely out of memory

Out of available contiguous addresses, more precisely, which on 32bit windows (without tweaks) can happen when the process uses about 1.5GB RAM already...

This is pretty much nonsense on any modern OS (since VAXes) thanks to virtual memory. God knows what really goes on in windows universe

I never saw allocator throwing anything on normal usage. But, then again, I never run anything that takes over 1Giga memory on windows either.

Well sorry exchange "RAM" by "Memory", but it's not nonsense. Virtual memory doesn't help with the fact that you eventually run out of contiguous 32bit addresses to allocate a memory chunk, virtual or not.

Your post made me think about it once again. Thanks.

OS takes the upper quoter of our address space, which leaves us with around 3giga.

Lets assume all mmaps are loaded and never unloading, so we take another 2.5giga. Add all other things that have to be loaded, maps, vmaps, add some fragmentation and we can get pretty grim picture. We can have problem with continues address space.

I can't say we can solve it right now from our side. Upgrade to x64 architecture going to handle it tho.

Don't know if we can significantly lower memory usage right now. Using bigger world metrics will do the trick, but it will lower the quality of our meshes.

But thinking about it once more, if you do unload unused grids there's no freaking way you can fill the entire 2.5g.