faramir118

@EARTHWALKER: that file:linenumber refers to the section of the patch that failed. In this case, the patch is looking for m_timers[WUPDATE_CORPSES].SetInterval(3*HOUR*IN_MILLISECONDS); but instead finds m_timers[WUPDATE_CORPSES].SetInterval(20*MINUTE*IN_MILLISECONDS); You can update the patch file and no more problem (assuming that there aren't more conflicts)

Here and here are all the changes we made for x64 VC when you updated G3D during vmap v3 dev. Might be more that I missed... edit: seems like these changes are intact in update (just not always in the same place)

qsa: I like the changes in your most recent diff. For pets, we will need to handle nopath in PetAI::UpdateAI (or PetAI::_needToStop). If pet can't reach the target, PetAI::_stopAttack If pet can't reach the owner, what is the expected behavior? Relocate to owner?

Differences in the way they build the mesh might make their output not very accurate. (liquids, tile bounds/size, max edge length, etc) The Solo Mesh sample can come back for parameter testing. The tiled ones are too different IMO.

updated the demo with single-tile load feature Exposed bug while working on this... --tile 35,47 0 has something wrong with the map liquid types. edit: fixed: http://img836.imageshack.us/gal.php?g=gameva.png

Hrm, looks like the part that hides the mesh went missing. I will add it back in. Right now I just have a slider at the bottom of the debug pane (bottom right of window, scroll down). It lets you change which tile's debug data is rendered. PS: I don't like this 'procedural UI drawing' RecastDemo uses

Yes, my modified version is in dep. I'll probably mirror Recast on git so that my changes can be tracked, and updating to latest SVN revision will be easier.

map#.obj = unmodified RecastDemo #.obj = modified RecastDemo I modified RecastDemo to use it with our project, so that I could load the navmesh produced by the generator, as well as the raw debug output. This version loads the intermediate data debug files and the #.obj file produced by the generator, and it has some functionality that allows you to display 1 tile at a time. It only builds on Windows (only other build I saw was Mac Xcode). The unmodified version only uses the map#.obj file produced by the generator. You won't get to see the generator-built navmesh. The generated obj file for this version had an off-by-one error in the triangle indices. It should be fixed now. edit: Oops, didn't see your edit. My change works fine in the binary on github.

Doing some cleanup on the generator. None of the changes add functionality yet (not until vmap liquids)

Should probably check the length of the charge's path, and return an error if it's too long. That would at least prevent the scenario in the video.

There is also cell height (config.ch - MapBuilder.cpp:750), which can have an impact on obstacle detection. The only one I tested extensively was cellSize. If you make it any larger, there will definitely be areas on several maps where doorways are impassable. Mikko made a post a long time ago about the settings and what values to try first.

It's just easier for me to commit pieces as I review them, but in this case there are too many inter-dependent changes in the same diff. You can push to my repo, please go ahead and add your changes.

I'll work on pushing your changes today. I'll also make you a contributor - just try to break commits into smaller pieces so it's easier to understand what changes do. You'll have to add parameters. I'd make the custom recast parameters optional for the --tile option You'll probably hate the parameter parsing code - it's a hack

qsa, do you have a github account? I can add you as a commiter, so this doesn't take so long.

Then you should try character encoding, instead of just casting the char to a byte. UTF8 is most likely.

Would like to see some tests where player is not flying. That is probably handled with aura and height checks. I might see if I can borrow an account from a friend, or maybe just reactivate mine for a bit... if targets are removed from the threat list, we will have to do so in ThreatContainer::selectNextVictim(). Path check (lazy or eager) will have to be independent of any other checks.

Is gobject position information (offset, rotation, scale) stored in client?

127.0.0.1 is the local loopback interface. You need to use the actual IP of your server's physical network adapter. Put it in the realmd DB as well as in the clients' realmlist.wtf. edit: nevermind

I did have trouble with the connection state not reseting after a bad username or password. Just had to close the socket and try again.

I think the part we really disagree on is the intent of pathfinding. Is it a tool to only build a point path, or should it be used for other things? The statement "breaks modular coding way by mixing pathfinding into AI" is contradictory to me. Pathfinding is AI. Behavioral corner cases are easy to handle, or even avoid, when you can see the big picture. Reachability tests during target selection accomplish this nicely. IMHO the debate about lazy vs eager path generation, performance vs robustness, etc is just a side effect. On a side note, I want say thanks. It's really refreshing to work with people who care enough and are able to form logical arguments for and against different aspects of a design.

We all have our own stuff to keep us busy. I have no idea why it's crashing. Can you post your code at gist.github.com or paste2.org?

http://rawr.codeplex.com/SourceControl/changeset/view/54512#294974 A lot of diminishing returns info.

The advantage is that we have an algorithm that correctly emulates retail behavior, no matter the circumstances. It's been a long time (couple years) since I played retail, but I remember how this part works. In Magtheridon's Lair there is a spot on the door/portcullis where you could stand that monsters can't path to. If the tank jumped on there, Magtheridon would start killing other members of the raid. He would only reset if the entire raid (minus the dead people) were standing on that spot. The same is true for my suggested way. We generate the path, it is valid, so save it somewhere where the MovementGenerator can use it. We don't do double work. If the AI doesn't require a complete path the the target, it should tell SelectHostileTarget not to use pathfinding - no wasted cpu, no unused path lying around somewhere. They also don't have anything in the threat list or attacker list, nor do they have taunt auras applied. As long as this is true, we generate 0 paths for creatures that aren't in combat. No extra overhead here. It's not going to turn into a code blob, I promise. We are making the pathfinding API - make the API right, and there won't be any problems of this sort.

I'm looking for 100% guarantee that we pick a reachable target, assuming that there is one. I'm not convinced yet that what you propose (no pathfinding during target selection) is going to accomplish that. Even after several iterations, how can we guarantee it will settle on one reachable target? How can we guarantee correct behavior when there are 0 reachable targets? The MovementGenerator isn't aware of the big picture, and less-than-ideal circumstances may cause problems: In the previous example, assume that Alice and Bob (and for the sake of argument, 8 other players) are on the roof. Eve's movement generator will reject each target in turn, but never all at the same time. SelectHostileTarget is already dealing with the big picture. It already makes decisions based on location of the potential target, and pathfinding is a (really complex) extension of that functionality. AI should use whatever information it has at its disposal to make the best choice possible. Categorically denying information based on cost is possible, but in this situation I think the cost is reasonable most of the time. I know it's potentially costly to generate paths in SelectHostileTarget, but in most cases it should only generate (or update) one path. I think that it will take special circumstances (exploits, bugs in pathfinding, bad navmesh, etc) to create a true bottleneck. It would be better to catch and handle these root causes. For example: count the number of incomplete paths generated in SelectHostileTarget - if there are more than 5, log an error with information about what map, location, creature, etc. Additionally, we can give a time slice budget to SelectHostileTarget. If it goes over, just use whatever target was best so far. Many video games do this so that other important tasks, like rendering the scene, get time to finish. Probably 99% of units which call SelectHostileTarget use TargetedMovementGenerator: SelectHostileTarget calls AI()->AttackStart(). All core AI implementations of AttackStart() call MoveChase. I'm not familiar enough with scriptdev2's AI implementations to know what to do to allow them to skip pathfinding. I'll post more on this after I look into it.

Here: simple c# ra client It's not perfect, but will get you started.