grayman

I loooove the stealth aspect. Having spent so many years with Doom/Quake etc., I was smitten with the sense of solitude and quiet that pervades Thief. Being where you shouldn't be, hiding in the dark, leaping from one roof to another, walking along ceiling beams with guards below. All of it.

Are these AI using interleaved thinking and is this happening while the player is out of range?

This is solved by lowering the interleaved frame interval. Otherwise the AI gets out of sync with the elevator movement and stops patrolling. Summary: The interleaved frame interval is reduced to 4 or less in these situations: * door handling * elevator handling * less than 8*max_interleave_think_frames units from a specific goal (path_corners, for example) The code won't check for these if the interleaved frame interval is 1. I haven't touched the vertical damage code. Unless anyone can think of any other situations patrolling might encounter, this work is finished.

Two more suggestions for the Wiki if you think they're useful: 1) If there's a gap between the edge of the elevator platform and the neighboring floor, it's possible for the AI to step into that gap and momentarily drop down. Avoid this by closing the gap. 2) Make sure the AI has room to stand in front of a fetch button. A button tucked into a corner or surrounded by other architecture that hinders the AI will prevent the AI from using the button if he needs to fetch the elevator.

LOL! I'm testing interleaved thinking with elevators. I got my test elevator working, and the AI guard set at 28 walked to the fetch button, fetched the elevator, waited for it to show up, got on, and pressed the down button. No problemo. The elevator began to drop, but he didn't, because he's skipping 27 frames. When he got to think, he dropped to the elevator and died, being dealt 462 in damage. So I guess I have to fix that falling damage problem after all.

All I was missing was an aas32_flood entity on each floor. Didn't see that mentioned anywhere. Now my map works perfectly. Nice feature, AIs using elevators. I searched for "aas32_flood" on the forum and found this quote from greebo: So the aas32_flood is only needed on floors where there are no other AI, and which are only reachable by elevators.

The AI uses a couple elevators, then stops. He's supposed to move in a continuous path, using elevators along the way. I'll need to study what it's doing, and what it's not doing.

I'll grab it. Thanks.

I would have to talk with Greebo about it. I think he was planning to deal with it at some point. I don't think it was planned for 1.03, since it's a lot of work, and I need to focus on 1.03 things.

I'm trying to get a patrolling AI to use an elevator. I've read the elevator Wiki and built a small 3-floor map with the prefab elevator at one end. The elevator is the only way to change floors. I've placed path_corners on each floor, and the AI on the first floor. His path should be from 1 to 2a to 3 to 2b to 1, using the elevator to change floors. He marches to pc 1, then marches to a spot directly under 2a, where he stops, slides forward a bit, then walks in a loop, slides, walks in a loop, etc. He never goes near the elevator. His CanUseElevator flag is true by default. This is with 1.02. I want to make sure it works properly before testing it with my 1.03 interleaved thinking changes. Does anyone know of an existing map with an elevator on a patrol route that I can examine? Or does anyone know of something else that needs to be done in addition to using what comes with the prefab elevator? Thanks.

The code changes I'll be committing soon will allow mappers to experiment with interleaved thinking frame intervals higher than 16. I've tested 1, 2, 4, 8, 12, 16, 20, 24, and 28 quite successfully. The Alchemist patrolling AI (who are set to 16) experienced door problems (the mysterious deaths) and when set to 28, became confused and stuck at path_corners. The new code drops the frame interval to 4 (if > 4) when around doors or path_corners, so death and confusion are gone. At 28, the AI can still become momentarily confused around more complex architecture (they're travelling long distances between checking their surroundings), but they work out of it pretty quickly. On stairs, 28s clip into the steps when going up, and float when going down, but they soldier on. It won't matter visually because the player never sees this. I suggest trying out different intervals depending on how tight or open your architecture is. The default interval will remain at 12.

I'd vote for a waist-deep check, since that should be sufficiently realistic. A water level check is already done each frame, where waist = the vertical halfway point of the bounding box. So the situation we're talking about only needs to check that setting, and not determine water depth on its own. This would help the lanternbot. I put one in water over his head and he eventually died. But while still alive, he was moving all his parts and spouting steam every few frames. Didn't look realistic. Keeping him out of deep water would avoid this situation. (But if he fell into water over his head, he'd look a bit silly while dying.)

Thanks for the suggestion. However, I just finished with this a few minutes ago. It's as close as I can get it. Some of the animations move the head in and out of the water (i.e. the horse) and you can see where the horse is drowning when his snout is in the water and breathing when it's out. I added a debug display over an AI's head that says "Drowning (H)" or "Breathing (H)" where H = health so I could easily tell when either was happening. This will be turned off at checkin time. We can turn it on in the future to debug new AI. The only place I cheated was with the spiders. They breathe through the bottom of their abdomens, so technically they should drown in a few units of water. But I think having spiders move through shallow water is okay, so I bumped the drown level up so it's a bit less than the vertical midway of their abdomens. I didn't test all the variations of human AIs because there are so many. I worked with a Citywatch Guard to set the proper height, which should be good for nearly all of them. Any oddballs can be corrected if/when they're found.

Thanks! I'll work with that and see what happens.

I've set eye_height and mouth_offset values for non-humanoids that define the breathing/drowning border. Couldn't simply use measurements from DR; those don't always match the idle measurements at runtime. Made small code changes in two areas. Dead bodies were still executing the drowning check to see if they should take damage and/or die. I just need the humanoid values to finish testing.

I've made estimates for the animals. At some point it would be good for the modelers to verify the numbers after they're checked into SVN. Change them if necessary. And "mouth_offset" is misleading. For many AI, it should be "nose_offset", since they can breathe through their nose even if their mouth is submerged. So when you come up with this offset for humanoids, make it for the nose and not the mouth. I've done that with animals like the horse and belcher, where the nose is well above the mouth.

Agreed, but rats aren't aware of water, so they just walk along the bottom until they die, regardless of water depth. Would be nice if they could walk into water over their head and look like they're swimming across the surface.

Done. #2421

A couple bugtracker issues involve drowning. The code uses the AI's mouth location to figure out if there's water at that spot, which means the AI can't breathe. It's expecting a spawnarg called "mouth_offset" (defined in the *.def files) to find the mouth's location. "mouth_offset" is supposed to be an [x,y,z] vector which is: * the offset from the head origin if there's a separate head * the offset from the eyes position if there's no separate head Unfortunately, "mouth_offset" doesn't show up anywhere in the *.def files, so by default it's [0,0,0]. This means: * human AI's drown if the base of their neck is underwater * animal AI's drown if their eyes are underwater I could drop AIs into water to come up with estimates for the missing "mouth_offset" values, but it'll be more accurate if anyone familiar with the models could give me the real values. I need one for the human head and one for each of the AIs that don't have separate head models. For the latter, I probably just need the Z value. Also ... A few AIs (rats, spiders, ...) are missing the "eye_height" spawnarg. So that defaults to 0 and they end up drowning if their feet are underwater, since "eye_height" is the distance from the floor. So please check your models for proper "eye_height" and provide me with that. I'll plug everything into the *.def files. Thanks!

True. The mover isn't causing the damage. It's imparting velocity to the AI and if the vertical velocity is large enough for the code to think the AI's falling from a height, damage will happen. Now, a door hitting an AI imparts all horizontal velocity, but there's some math in there that adds vertical velocity as well because the AI is moving. Okay.

Yes. In addition to getting hurt in a doorway, there were instances where an AI got hurt a bit aways from a door. When I was able to watch the action, I saw what was happening: the AI would overshoot his mark and end up in front of the door. When he opened it, he got knocked backward a large velocity all in one frame, taking falling damage both on the initial door hit and also at the point where he ended up, which could be far from the door. He'd stand there for a bit, going oweee-oweee, then straighten up and continue patrolling. The key is keeping him out of the doorway and reducing any damage he takes in the rare case where the door hits him. When interleaved thinking is 1->8, he's more likely to hit his mark and there's no damage if he misses slightly and gets hit. What I'm doing during door handling is changing his frame interval to frameinterval/4 + 1. So 16 becomes 5, 12 becomes 4, etc. Even if we cranked it up to 28, door-handling will bring it down to 8. I didn't want to go all the way down to 1 because that just detracts from performance and isn't necessary when the player isn't watching. I haven't capped damage, as was discussed above. I'm trying not to overfix things. The damage is a by-product of interleaved thinking near doors, so fixing the latter fixes the former. Now, if anyone's worried about AI taking damage from other movers, I can go tone down the damage. Has anyone ever put an elevator on the path of an interleaved patrolling AI? Maybe I should go experiment with that.

It appears that the ghostly unseen midnight ghost of TDM has been exorcised for 1.03. By increasing the interleaved thinking rate when door-handling, the AI no longer get whacked by moving doors. This lets them stay healthy, wealthy, and wise. Well, maybe not so wealthy. And maybe not so wise. ------------------------------------- While researching this problem, I found that AI at long interleaved thinking intervals (>=20) can get confused around path_corners, leading to wandering around a PC instead of continuing to the next one. A fix I'm working on looks promising, but I'm not done testing. If this works, we might be able to use higher frame intervals. It would certainly warrant authors trying higher numbers to see what happens.

Thanks for doing the loot list.

Just for the record, St. Albans doesn't use the table that crashed SATC on Shaz's computer.

ROFL! Yeah, wouldn't that be something. An episode for SyFy's Ghost Hunters. IMHO, the root cause of this mayhem is patrolling AI overshooting their marks. Getting around is done by telling the AI to go to a location. Once they get there, they're told to go to a new location. If they only think every 16 frames, then they will make stopping or turning decisions at different spots than if they were thinking each frame. If we just fixed it so the AI didn't receive unwanted damage, we'd still be left with this other problem. "So what?" you might ask. Well ... I tried interleaved thinking frame intervals of 12, 16, 20, 24, and 28 with a few of the AI in Alchemist. At 12 and 16, the AI were able to negotiate doors, but sometimes ended up standing in front of the door when it opened, which imparted a "stored up" velocity to them and they shot halfway across the room. At 12 they received no damage. At 16 they were hurt. From 20->28 they really had problems. At 28, I found one AI marching back and forth across a path_corner. Each time he thought, he was too far away from the pc and turned around and marched back toward it, trying to find it. He'd wake up on the other side, too far away, and march back. I haven't examined the proximity math, but I think that's what's happening. He never did get "close enough" to his pc, so he was stuck marching back and forth in that corner. At 20 and 24, the AI had problems with doors. They just couldn't find that sweet spot where they were supposed to be to frob the door, so they, too, would end up wandering around in the vicinity of the door, trying to open or close the darn thing. If they thought at just the right spot, then the frob would work and they'd move on. So to squash these problem, I think thinking needs to speed up in the vicinity of doors and pcs. So that's what I'm off thinking about now. Every 16 frames.