qsa

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. Not enough memory? But I've already got crash from memory full error - and it was another crash-log... I can build debug and give you debug crash-dump... P.S: Always: MMAP:: MMapManager:: loadMapData +278 We need some info about your system and how much it tried to allocate. I'm pretty sure installing *nix will magically solve this problem. But, I feel even windows server edition will. If anyone have similar problems, please do report. Otherwise I will consider it as "user's system issue" Well, thanks for report - even positive reports are good indicators. If you notice issues, do report. hm... that gives me an idea. Now that we have all mmap loading handled from singelton, we can keep some statistics there. Things like number of maps loaded, overall number of tiles, etc. + some commands to show this data. Can be nice to do some theoretical calculations Since without those, knowing memory usage don't tell us much, well unless something really really wrong, but that's different story.

You are running out of memory again. If you turn off the mmaps from configuration file, mmaps are still loading, just not used If you want to prevent them from loading, just rename mmap folder to something else. I think its something like ~4mega per tile and some pre-allocation per map. Someone real testing can be nice from someone who's OS shows the actual memory usage

What do you think about fixing these kinds of spots with offmesh links? Could hardcode them in sources or new db table I think it should be done by different utility. Something that gets specific tile, loads it, and patches it accordingly to given input. Not the prittiest thing around, but it will get the job done. I don't think we should add hacks into core to handle those issues. Simply since this should e done only once - when maps are generated and NOT every server run.

I guess it is "solved" Transports maps aren't yet implemented in mangos, tho, there was patch somewhere. From what I remember, it is done, not by actually moving anything, just translating local map position to global world position. So, from our point of view, this should not change anything for us - same logic as normal maps. But it depends on how it will get implemented on mangos. But early talking about it There is no generic solution for this piggy. The only thing I can think about, is allowing to manually edit some meshes. I think we can do it by editing the input mesh. but, mehhhh....

You are running out of memory. Plain simple. Are you using latest version? Some info can be handy here. How ( on what maps, etc) this can be reproduced. Don't see how it is related to mmaps. faramir118 : what do you think about what I said in post #821. The criteria part.

Not really related to pathfinding. Its the same on clean mangos. Issue with evade code. Please open bug report over bug section.

Well, increasing buffer sizes didn't do the trick. While that particular crash "gone" (haven't seen it in along long while) we have different related issue. EDIT: I was wrong, crash in ACE_Message_Block::total_size_and_length is still there Even more sinister. Plain freezes. just after adding "WorldSocket::SendPacket enqueue_tail" to log. Need more research on this one, maybe some asserts

If by "done" you mean "ready for testing" - then it is "done". We do need detailed reports. Both negative and positive, so we could evaluate how the code really runs. Things like with and without mem/cpu loads, bug reports, issues - pretty much anything that will allow us get a better picture of things that have to be done. In general, if we talking about moving this thread to "under review" section. We need to list some criteria for that. Things that have to be finished prior. It can also be nice to have some of the dev's to look around the code and pitch us few ideas for improvement, some general things. Maybe we can make that criteria list. Things we want done by the time of review. Right now, I can't remind known bugs. Just missing features and some ill defined conditions.

It can be nice to test it under load and see the actual difference. It may not be as good as we imagine it to be, simply since (as far as I know), all async sockets are more or less "hidden" listening threads. The way they implement non-blocking functions with callbacks are by running thread pool on the background transparent to user. Those threads do all the dirty, blocking work. When its done, callback called. So, in reality, we don't save anything - we just use build-in lib's solution. ACE still doing the dirty work behind the scenes. So, I don't know how much we really save here. Maybe I'm totally wrong and ACE lib does some kind "dark magic" or simply implements it efficiently or differently. But, those things require testing. You don't get anything for free. In general, its really nice to see this attempt! Cheers.

This is a pretty ugly bump. Problem still exists and solution is still valid

Finally got time to test it. There's problem with this code.Pretty easy to reproduce. Attack from unreachable place, go to reachable place - creature is still stuck, then just evades. Another issue, is that StopMoving call - creature moves forward by jumping from time to time. Cheers.

Can you post those, I'm bit far from *nix with mangos to test it right now. PS: you also may need to remove "game bindings mangosd" from src/Makefile.am

What you really need, is make file that supports different builds. As a quick and really dirty solution, you can remove the lines in configure.ac that configure mangosd/game/bindings (around line 340). Should do the trick.

That's great news. I don't know if that going to affect this particular problem tho. I'm pretty sure it exists even if you don't use any map-threading. It's impossible to reproduce on local/small sever, since that query is used to buffer packets only when output buffer is full, so it takes some significant load even to make some usage of that section of code. Making it hell for debugging. I can try lowering m_OutBuffer to force more usage of msg_queue(), but meh... even then its shooting in the dark. If anyone can get this crash logged on valgrind, that sure would help. Actually, as a temporary solution, you can increase m_OutBuffer size. If that wont cause problems elsewhere in the code, it will surely lower the queue usage, therefore lowering chance for that particular crash. Maybe someone will have luck guessing what exactly is wrong. I can't see the problem

From what I understand, you do not need this info for every target in thread list. All you need to know, if you had ANY valid target. If you did and now you don't - just evade. If you never had valid targets (fight just started) - wait 26 sec, etc ... So, I think single boolean in Creature will do just fine. I may be wrong, since I haven't had time to test it yet, but it sounds logical enough. I will "play" with those things to see the effects as soon as I have time (soon enough, hopefully). You also don't need things like resetting variables in class destructor. Stack objects are automatically deleted anyway.

I haven't had time to test it yet, but i have a question: Why do you need all that code inside ThreatContainer/ThreatManager code? Why do you need to check if path was generated for every possible target? Why using single boolean inside Creature class won't do it? All you care about, is whenever creature had valid target which then became invalid (immediately evade), or he was attacked from unreachable location - use the evade timer. Best regards.

Thanks, I will check it when I have the time. But in general, I think you don't really need all that code in ThreatContainer. You don't really care if you had path to specific target. In addition, target (on retail) will use evade timer only if there no alternative targets. What happens in your code ( from what I can see), is if there's no path to main target, creature will wait 3 sec, then try to get to next target. EDIT: I was not accurate : check post #469 - Toinan67 explains the exact behavior. The only change that has to be added from what we have right now, is 26 sec timer if you attack while being unreachable. This was already discussed - you have to have script support for kind of encounters. You can try playing with InhabitType - maybe it help, maybe not - but it is not proper solution. Same thing, scripts. When arena starts you and your pet should be thrown by water outside of the tube. No pathfinding is involved there. You better find some script for that arena that does just that. Thanks, I'll add it. Strangely it goes fine on FC12. Oh, well, cant hurt too much.

Spend some time on this issue by now. Still nothing. There are very few access points to msg_queue(), and its data. I can't figure where ACE_Message_Block (which is element in ACE_Message_Queue) can get corrupted. It really feels like threading issue. 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.

As long as people thing of this project in terms of "product", we'll always have this discussions. This approach implies all the above. Things like "features first", "quick and dirty", "results now". I think in terms of educational project. Therefore, I tend to disagree. Sure, working features are nice. But considering very limited manpower, you cannot get everything at once. Work being done by volunteers, you cannot force anyone doing something they do not like/don't consider critical/don't have time for/whatever. So, what exactly is your point guys? That we lack talented people who will work for free? I fully agree. What I disagree about, is forcing people to spent their time on what you want. This is what its basically what it is about. You want vehicles/etc implemented. None on the staff have the time/will to do it. Simple. You want something done, you got to do it yourself. For some peculiar reason you expect things to be handled from above or something. How does this approach work for you in other aspects in life? There are projects which focus on features. It is not (as I like to believe) mangos's main goal. This is one, among other thing that allowed it become what it is now. If you like "product" approach better, thats OK. There are wonderful projects which support this set of ideas. But coming here from those projects, claiming that mangos should change its model? It just smells bad, I'm sorry. b482519: You can be superb deity all I care, but I can give you the credit only for what I see. Posts you made, are consist mostly of criticism. I failed to see any valid point for improvement. By that, I mean : things that should be, and can be done in reasonable manner. Without those, it sounds very similarly to plain flaming. You know what they say: "It's such a shame all the people who really know how to run this country are too busy driving cabs and cutting hair". As for mangos being "if you don't like the way we do things in our project, go away" : From my personal experience, this is by far the most open minded oss filled with helpful people. Try doing the same thing in ANY successful open source project. Make an account in mozilla dev forums and say that their management technique suck donkey balls and you propose to improve it by XYZ. I'd love to see the responses you get. The reason is simple : stability is what make those things tick. But with all your experience in the field, you already know it, don't you? I do tend to believe it's since you may actually care. I do appreciate it. Shame if I'm wrong. Best regards.

Try this one : diff --git a/src/game/PathFinder.cpp b/src/game/PathFinder.cpp index f1bb944..edfca15 100644 --- a/src/game/PathFinder.cpp +++ b/src/game/PathFinder.cpp @@ -93,7 +93,11 @@ bool PathInfo::Update(const float destX, const float destY, const float destZ, b // this can happen only if caller did a bad job calculating the need for path update if (oldDestInRange && inRange(newStart, oldStart, dist, dist)) + { + setEndPosition(oldDest); + setStartPosition(oldStart); return false; + } // check if destination moved - if not we can optimize something here // we are following old, precalculated path? Should solve this issue. Thanks for report. Sure its doable, but the problem is with movement from area with mmaps enabled to one without. Path generating logic there is ill defined. We can cook something ugly, but same way you can just delete the tiles and get same results. The reason you charge to the base of the pillar is due to GetClosePoint() returning that point. So (in this particular case) pathfinding doing the right thing, as far as it concerned. If you'd charge a target that stands further from the edge, you'd fail LoS. That's the reason I don't think we have to check anything. Problematic cases do exist, but they are really hard to reproduce. On a sidenote : I appreciate you willing to learn.

Thanks But, well, .. You are generating additional path in order to check reachability, this is very expensive. So, if everything is OK (the common case), you generated twice as many paths. That's one of the main reasons why this approach was abandoned in favor of lazy target evaluation. But you already know about it, since you read the posts, just like it was suggested. What happens now, is that if you can cast charge effect, it is guaranteed, that the last point on path will be the destination. This is due to simple logic : if you can cast charge despite LoS check, you can find a path. If path generation still fails, we allow it to use shortcut.

I know I shouldn't reply to this one, but I just can't resist. Forgive me. Tell me b482519, are you speaking from personal experience? You must be one of those folks, who after years of contributing to this project, still do not see any of his hard labor rewarded. Must be so frustrating. Wonder no more, the only two thing prevents people from submitting their patches is laziness and oversize ego. You are right about one thing, its hard to be exited by actually contributing something. Trolling on the other hand, is much much better. After all, its so lonely under the bridge. Cheers, you made me smile.

If the authors of those patches we talk about, was not comfortable enough adding them into "under review" section (aka: marking them as ready). I find it really arrogant of people who had very little to none input, claim otherwise (aka: add them NOW!11). Correct me if I'm wrong on this one, but all the patches people whine about aren't anywhere near "under review" section. There's phrase fits this perfectly : Everybody want to go to haven, but nobody want to die. PS: sorry for quoting you Nick, its nothing personal, it just emphasizes my point better. EDIT: As for so called "tester community" - I can count the number of people who actually properly report bugs in patches on the fingers of my two hands. Most are just using them with no freedback. Just take a look at some threads we have now, where people practically have to beg to get some feedback (see relocation, thread packets, etc). Funny enough, as a rule of thumb, those who complain are never those who do the testing/reporting. There are always exceptions, but I'm talking about general. On same occasion, I would like to say thanks to all the guys and gals to whom the above do not apply. Keep up the good job!

with changes in Unit::isInAccessablePlaceFor (see my 2nd patch) my code does not allow creatures to aggro if target is not reachable. How is it different from what happens now? I do advice you to find and read posts regarding this matter. 2: without PATHFIND_INCOMPLETE this check fails if creature is far (if it attacked by range attack, for example) You are pretty much checking now for "is creature reachable OR is creature unreachable".

Not dtTileRef Its the small things that get you in the end thanks. Will never happen. We cannot deal with the consequences of disabling some tiles on map. The logic of pathfinding between tile with and one without is ill defined. As for areas : same thing, but even harder, since area detection in mangos isn't too solid. You can always just do what caeruleaus suggested : delete tiles you don't want. You will have problems in the borders, but its upto you. You can read some relatively old posts in this topic. There are about 5 pages on this subject. Why we should and why we shouldn't use this approach. Just to direct you in the right direction, I'll ask you a question: what functionality this patch adds? Few other things, just to get it going : 1: i_path cannot be null, you just allocated it with new opperator, if it failed, exception was thrown. 2: check what PATHFIND_INCOMPLETE mean and where it used. Thanks. Pushed something that should solve this little case. Please do test, this and other underwater cases.