Jump to content
The Dark Mod Forums

grayman

Development Role
  • Posts

    13591
  • Joined

  • Last visited

  • Days Won

    199

Everything posted by grayman

  1. Can you PM me a screenshot of the area in DR (X/Y view) and I'll try to make something of that? The architecture is more important than where the AI start out.
  2. That's one aspect of the door queuing that's always been disturbing: an AI will stop and wait for another AI that they can't see. Especially around a closed door. I decided not to make visibility part of the requirements for stopping, though, because the goal is to keep AI away from the door when others are using it. I rationalized it in the end by saying, "Oh, I guess they can hear someone else approaching the door." Sort of lame, but it's better than letting an AI get all the way to the door and block it just as an AI on the other side goes to open it.
  3. Great! Thanks. I'm not sure that would have been possible. Everything depends on everything. Even the rat stuff depends on changes made for the humanoids.
  4. As in the other, can you copy the brushes defining the area, the AI, and their path_corners, and post here? This situation seems more straightforward than the other. I assume the door is swung away more then 90 degrees on the far side.
  5. I assume there's no door where she's standing. She has to go through the opening where she is, then turn back toward the actual door to go through it. Did she walk up to this spot from somewhere else? Could she be the one that came in through the back door? The guy behind her: Is he bumping into her and then circling, or is he circling w/o ever touching her? It would be good if you could copy the relevant brushes, the door, these AI, and their path_corners into an empty map, and post the map. I'll add dummy brushes to seal the area off. If this isn't possible, then I'll try to recreate something that looks like this picture.
  6. These changes do NOT include a fix for the circling problem. I'll address that separately.
  7. For those interested in testing the movement changes, you can pick up a 1.03 Windows DLL here: http://www.mediafire.com/?y045lennd8dngeb I don't have a 1.03 Linux DLL available. If you want to use SVN, the changes are committed at revision 4472. Please test when you have time. Unreleased WIPs, existing missions, everything helps. If all goes well over the next 10 days, these will be included in 1.04. If you find a problem, post it in this thread. Thanks. Here's what's different: Reduce time needed to resolve a block when two AI collide. This means less confusion in narrow spaces. Rank is now taken into consideration when two AI try to resolve a block. If one has to stand still and let the other pass, the one standing will have the lower rank if there's a difference. Previously, two AI approaching each other would alter their paths so that when they met they could pass w/o touching (assuming there’s enough room). Now, if one AI has a higher rank than the other, the higher-ranked AI will continue straight and the lower-ranked AI alters its path to walk around the higher-ranked AI. AI of equal rank will use a secondary temporary ranking system to determine who walks around the other. If two AI are traveling in the same direction, the one behind will do a better job of passing the one in front if the one in front is traveling more slowly. AI no longer collide head-on and turn toward the same wall, only to get stuck treadmilling. In general, AI will get stuck less often. It can still happen, though, given the right conditions. Not all conditions can be anticipated. (This is a strong argument for properly monster-clipping a mission, to keep the AI out of trouble spots.) Because of their complexity and number, func_statics are ignored during pathfinding. Now, if an AI bumps into one, pathfinding won’t ignore it. This provides the AI with a new path around the obstacle instead of through it, which reduces treadmilling against func_statics. In 1.03, AI approaching a closed door queue up and go through the door one at a time, the last one through closing the door. They did not behave as well if the door wasn't originally closed. Now they queue up, go through one at a time, and the last one through closes the door. For rats ... Rats will select from more spots to go to. This reduces getting stuck in small spaces like stairs. Added a 10s timeout for rats traveling to a spot. This prevents getting stuck when a spot is valid, but unreachable. If a goal is very far away (>120), a rat will run to it instead of possibly doing a slow hop the entire distance. Added a drowning check for rats to keep them from pausing too long underwater. This reduces drowning, but doesn’t prevent it. Less chance of a rat getting stuck inside a func_static (like a wheelbarrow or under a bed). If you monsterclip a bed or bookshelf, lift the bottom of the clip off the floor and the rats will run under the beds and onto the lowest shelf. They should have no problem getting back out.
  8. Who designed the current site?
  9. One must always know what one's servants are about.
  10. I followed the wiki instructions. My door is just a simple sliding door, though. I haven't tried anything more complicated. The door-handling code determines which side of the door (relative to the AI) each door_handling_position is on. It will send the AI to the one on the near side of the door, where the AI can then open the door. As long as you use spawnargs on the door that start with "door_handling_position", it's supposed to work. I'm using: door_handling_position door_handling_position1 And each has the name of one of the two door_handling_position entities, placed on either side of the door.
  11. It's on the floor, midway on one of the ends. Normal place for a rotating door; it just slides, though. I'll try your suggestion.
  12. Has anyone used a sliding door in their map that AI needed to go through? I noticed in my movement testing that they couldn't open a sliding door, so I went back to 1.02 and 1.03 and they can't do it there either. If I open the door for them, they can walk through and properly shut it from the other side. But when they circle back to it, they stand in front of it and make no attempt to open it.
  13. That's indicative of not reaching their goal. The new code has a 10 second timeout, after which they'll pick a new goal. I had a staircase in my test map that had a low wall on one side. A rat on the steps picked a goal on top of the wall, but when he got near it, he'd fall off the edge to the ground. Then he'd scamper around to the base of the stairs, run back up, and try again, fall down, try again, etc. Funny to watch, but not for more than a few seconds.
  14. Then I will commit it to SVN as well as providing a 1.03 version. This is a large change, untested by anyone but me, and I wanted to make sure it was acceptable and stable before committing. Once we have SVN access again, though, I'll send it all in.
  15. Yes, once beta's over. There was some angst during the run-up to 1.03 regarding code that had been in SVN for months w/o anyone looking at it or testing it (my stuff included). I want to make sure the movement changes are solid (and acceptable) before foisting them on SVN.
  16. I can't release an SVN version because I shouldn't be releasing other folks' work (not right + I can't tell it it's complete). And I have no way of knowing what darkmod files are needed to keep things from crashing. So the beta will be 1.03-based.
  17. I want to start a beta test of the AI movement changes I've been working on (seemingly forever). I'm open to anyone participating. This isn't like a mission beta, which necessarily needs to be kept to a few testers. These changes will affect everyone, so the more feedback I get, the better it'll be. These changes are mostly in the area of reducing the situations where AI get stuck. It's not going to fix everything; there are too many special cases to anticipate or fix every problem. But they should (hopefully) minimize AI treadmilling into each other, or walls, or objects that should have been monster-clipped but weren't. If there's one thing I learned from this work, it's the importance of monster-clipping your map properly. The more glitchy places you can keep your AI out of, the better they'll behave. I have more situations to investigate, but I can clean them up in parallel with the beta. And better rat behavior is thrown in for good measure. No more rats stuck on stairs or under wheelbarrows. I'd like to start in a few days, so watch this space.
  18. I tried 30 on my slower computer and everything became very jerky. While it might not be noticeable if someone's framerate drops from 60 to 50 every half-second, it's very noticeable when the framerate drops from 30 to 7 every half second. I tried different values and when I reached 2, the framerate stopped fluctuating. I can't really tell if it's faster than when it's at 1. So I can't see this allowing slower computers to play the complex missions. (Darn!)
  19. Certainly makes it easier to see the brushes.
  20. Stunning. Makes me want to retreat to the safe haven of coding and leave mapping henceforth to the experts.
  21. To take an AI out of the map ... Put him on a path. Create a func_remove with this spawnarg: "target" "<AI's name>" At the point in his path where you want him to disappear, place a trigger_once_entityname with these spawnargs: "entityname" "<AI's name>" "target" "<func_remove's name>" When the AI walks through the trigger_once_entityname, it recognizes him, triggers the func_remove, and that takes the AI out of the game.
  22. Here's a test map with 3 swinging signs in it. The 'speed' spawnarg on the func_pendulum defines how far the sign will swing. The 'angle' spawnarg on the func_pendulum is perpendicular to the swing direction. Note that each sign is bound to its func_pendulum. signs.txt
  23. Cleighmoor hasn't been released yet. I'll post a working example.
×
×
  • Create New...