qsa
-
Posts
289 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by qsa
-
-
Crash again =(
Registers: EAX:0B4580F8 EBX:47AE90C0 ECX:00000000 EDX:00000002 ESI:0B458180 EDI:47AE90DC CS:EIP:B45001B:7C80BEF7 SS:ESP:60023:0B4580F4 EBP:0B458148 DS:E070023 ES:0023 FS:003B GS:1700000 Flags:00000206 Call stack: Address Frame Function SourceFile 7C80BEF7 00000000 RaiseException+3C 7857DF56 00000000 _CxxThrowException+48 004753F0 00000000 operator new[]+40 0069364D 00000000 dtCustomAlloc+D 00401965 00000000 dtNavMesh::init+95 0096F998 00000000 MMAP::MMapManager::loadMapData+278 Call stack: Address Frame Function SourceFile 7C93860C 00000000 KiFastSystemCallRet+0 7C821C8D 00000000 WaitForSingleObject+12 Call stack: Address Frame Function SourceFile 7C93860C 00000000 KiFastSystemCallRet+0 7C8024FD 00000000 Sleep+F 00A80460 00000000 ACE_Based::Thread::Sleep+30 00A86810 00000000 SqlDelayThread::run+50 00A80249 00000000 ACE_Based::Thread::ThreadTask+19 00292E34 00000000 ?invoke@ACE_OS_Thread_Adapter@@UAEKXZ+74 78543433 00000000 _endthreadex+44 785434C7 00000000 _endthreadex+D8 7C82482F 00000000 GetModuleHandleA+DF
mmaps tune off =(
Latest revision of mmaps...
I can't say anything elso...
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.
Seems like we need to do some memory profiling.If there are memory management issues, it would be nice to know before we send it to under review.
And even if there aren't leaks, it seems like we should know the system requirements for running this code.
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
-
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....
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.
-
Anyway, just pushed latest mmaps to my 2 player testserver (thank you university upload :-) (1.3GB in less than 5 minutes)) will report soon.
I guess it is "solved"
- 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.
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
Blade's Edge Arenamap: 562
x: 6243.017578
y: 267.434357
z: 11.084449
tile: 5622031.mmtile
http://filebeam.com/12ea38182daab4b7fc79533d68fc8a0d.jpg - without bigBaseUnit
http://filebeam.com/17c0a9790f33d2d4609c6e7446e4eef2.jpg - with bigBaseUnit
marked places must be walkable
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....
- Transports (boats, zeppelin, etc)
-
Hello!
Last time I have very often crash
Call stack: Address Frame Function SourceFile 7C80BEF7 00000000 RaiseException+3C 7857DF56 00000000 _CxxThrowException+48 00472CD0 00000000 operator new[]+40 0068F6BD 00000000 dtCustomAlloc+D 00401965 00000000 dtNavMesh::init+95 00964FF8 00000000 MMAP::MMapManager::loadMapData+278
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.
And:
...
mmaps is tune off...
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 sure if this should be put here as well, but since pathing is involved and all... on Live servers, creatures dont regen or clear auras till they reach home position once they hit that spot, all auras cleared and gain instantly full health... at least from my tests...
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
-
is this done? or need more implementations?
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
-
patch rewrited
Removed changes in ThreatManager, added single boolean to Creature class
Tested, seems like no problems with single boolean. Need help with stopping creature movement (In my repo I've made this stuff with MoveIdle() and my function IsTargetReachable(), here is a demo: http://www.youtube.com/watch?v=wGeN49UPOcE ).
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.
-
qsa, tried - got tons of errors:(
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
-
I need that code into ThreatManager because I didn't find a better way to store information about an aggro event: that target is already in threat list or it is first time aggro (I know that it was ugly phrase)
Single boolean in Creature class can't provide this information for each target for more than one attacker at one time
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.
-
OK, here is an updated version of my patch: http://pastie.org/1402691
now creatures have 26 sec timer and they are not attackable if target was unreachable and while target is unreachable
Need help with stopping creature movement if evade timer enabled. StopMoving() looks kinda ugly...
EDIT: fixed timer logic, now timer starts only if getThreatList().size() < 2
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.
-
implementation of timed evade and immediately evade if target was not in threat list
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.
Only two things, first, about some bosses like Blood Queen Lana'thel, that has a phase in combat where she starts flying. In this encounters the boss get's buggued when ihe must returns to ground he enters in evade mode, because he can't found a valid path (from air to ground). May be change the InhabitType could solve this?
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.
Other little problem appears at zones like Dalaran arena, where players start in tubes. They summon their pets in the tube and when the battle starts, owners leave the tube but pets can't find a valid path, tubes are isolated from ground.
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.
EDIT: Testing in Ubuntu 8.04 x64, in windows compiles fine but on Linux I must add:
#include "../framework/Utilities/UnorderedMapSet.h"
in MoveMap.h
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.
-
I didn't read the whole topic so I'm not sure if this was already written here, but...
I think I found a bug connected to this patch, more precisely in MoveChase().
If a player is being attacked by a creature and moves (backwards) very slowly (push and release S or back arrow quickly), step by step, he/she can move away from creature's attack radius and the creature won't come closer if the player won't move with longer "path" (I mean if You simply run and don't stop then it will chase You, but when move step by step then it will not do so).
If tanks has a lot of aggro, then he/she can move away from boss and stand still, not being hit by boss' autoattack.
The problem doesn't appear on clean core so I'm guessing that it's the "pathfinding" issue.
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.
There is always the possibility of disabling it in code. ie. check if areaid is in blocked list (setting) and then don't even try to generate path, but tbh. not sure why this would be helpfull
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.
ok, now I understand about lazy target evaluation.but... in case target is in unaccessible place, it is necessary to disallow players to cheat (with pets too), even if LoS check was successful
I think, double path generation only for players and pets is defensible
I'm sorry if I was wrong
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.
-
Here's an updated version of that patch with implementation of SPELL_EFFECT_CHARGE path checking (will return "No path available" if target is unreachable): http://pastie.org/1388943
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.
-
A solution could be to get some trusted community members (or release it to the public, does not really matter), and create a development branch with the most viable patches implemented, such as vehicles and MoveMaps, and let them run loose....
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!
-
Just to direct you in the right direction, I'll ask you a question: what functionality this patch adds?
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.
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.
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".
-
sizeof(dtMeshTile) = 8 byte
Not dtTileRef
Its the small things that get you in the end
thanks.feature request: mmap disabling by ZoneID\\AreaIDWill 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.
function to check that target is reachable...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.
If creature is underwater - they can't find path.Test on http://www.wowhead.com/npc=17153
Thanks. Pushed something that should solve this little case. Please do test, this and other underwater cases.
Contact Us
You can also email us at [email protected]
Privacy Policy | Terms & Conditions
MMaps Redux
in ... acceptedOld
Posted
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.
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.