grayman

And that's exactly what happens. A small amount of downward velocity is applied to keep the AI on the ground. When an AI only thinks every 16 (say) frames, that velocity is multiplied by 16, sort of in the spirit of making up for lost time. Unfortunately, there are times when this leads to "crashing into the ground", causing damage. We still want the greater velocity. What we don't want is the damage. That's probably where the fix will be.

The AI that commit suicide are all moving and using Interleaved Thinking. There are times when the code applies more downward velocity to these AI because of IT, and it's as if they're suddenly falling and hitting the ground hard enough to cause damage. It could happen at any time, but it's most common around opening doors. Let the AI patrol long enough, and they just keel over. Working on a fix.

auto-close isn't the problem. in the situation i'm looking at, the AI is being swept to one side by the door he's opening. it might be that as he approaches the door, interleaved thinking makes him overshoot his normal stopping point, so he ends up next to the door when he opens it. all theory at this point, though.

The AI is getting hit by a moving door, but that's not the problem. The code looks at whether any damage should be accrued by getting hit, which brings into play the area where I think the bug is. My current theory is that the timing differences of interleaved thinking are a contributing factor. The code assumes the physics math is happening over a 1-frame timespan, but some of the data used is for a timespan of N frames, where N is the number of frames used by interleaved thinking (if the player is far enough away). So the problem is that a force in the vertical direction is magnified by N, and the code thinks the AI is hitting the floor harder than he really is. This causes damage. Right now I'm trying to figure out what the fix is, and apply it in such a way that it doesn't screw up something else.

The overnight test resulted in one AI dying near a door. I think the other AIs getting hurt last night stopped getting hurt because I moved to a safe spot in the map where I wouldn't be found overnight, and I might have moved beyond their intermittent thinking radius. More testing today.

I ran Alchemist for an hour or so with an instrumented TDM 1.03 and saw 10 instances where damage was inflicted on patrolling AI. The damage ranged from 4 to 10 per shot. I stayed away from them, so I never was the cause of the damage. In 8 of these cases, the AI was next to a door, and their patrol route took them through the door. Is it possible that an opening door can inflict damage? Probably yes, since a door is a mover. In the remaining 2 cases, the AI was simply walking across a floor, headed for a door, but nowhere near the door. He got whacked twice with 10 damage in the exact same spot, but there's nothing there. One more shot and he would've died. I'll have to look closer at him. I'm printing out the inflictor (i.e. a sword) and the attacker (i.e. the wielder of the sword), and in all these cases, none are specified, so the code marks both as the world. Since doors are named, I would expect the doors would've showed up as the inflictors, but they never were. I'm going to let Alchemist run overnight and see who's left in the morning. Oh, and the one Builder guard who died mysteriously in Biker's new mission in this morning's testing did so in a doorway. Curiouser and curiouser.

the ai should only get hurt if there's a certain amt of momentum, so it would be odd if walking down steps was hurting them. perhaps instrumented code that reports health and location every second might show what's happening. just start up alchemist (say) with it and see what happens.

Not in my case. I had probably done a regular save perhaps 5 mins before finding the body.

I've seen a few comments about AI being discovered dead in missions. This happened to me for the first time while beta-testing Biker's new mission this morning. I came upon a Builder guard lying dead in a doorway, and I know he was alive and patrolling earlier. In previous tests of this mission, I had to dispose of this guard myself. I'm inclined to write an issue up for this, but wanted to start a discussion before I did. Anyone know what's causing this?

Biker, has someone already proofread your briefing and readables? I know this was something you had wanted to get done.

I use CoolEdit 2000 for my sound work. It has the ability to run a script of actions across a bunch of files. So I should be able to create a Normalize script that can do what you want. I'll experiment with it to see if it works (I've never used batch mode). If so, I'm open to normalizing the files for you if you can't find another solution. I'll just need to know what level you want to normalize to. CE2000 is no longer available. Adobe bought it and today it's wrapped up inside their Soundbooth software. Edit: I've confirmed that batch processing works, so I can do this if you want.

Count me in.

Sounds good. Thanks!

Yes. It'll work. Make sure you refer to the attached map if something doesn't work for you.

Shiny.

I've made changes to support 'slick' on sloped surfaces. Now, depending on the slope, you will pick up some acceleration. Less slope = less acceleration. More slope = more acceleration. After the slope rises to 1/2 (1 'rise' for each 2 of 'run') you won't be able to walk up it. (As a reference, you can't walk up regular ground if the slope is above 1/1 (roughly).) I'm not planning any further changes.

The problem you've been having with these player spawnargs is that you're using them like this: "diff_1_change_0 origin diff_1_arg_0" "200 -56 912" "diff_2_change_0 origin diff_2_arg_0" "-232 -232 912" When you're supposed to use them like this: "diff_1_change_0" "origin" "diff_1_arg_0" "200 -56 912" "diff_2_change_0" "origin" "diff_2_arg_0" "-232 -232 912" And you can change angles like this: "diff_1_change_1" "angle" "diff_1_arg_1" "315" "diff_2_change_1" "angle" "diff_2_arg_1" "135" I tested this in 1.02 and it works. Set "difficulty" "1" on any worldspawn brush and change it to test difficulty levels "0", "1", and "2". I've attached a test map.

I tested textures/common/slick and it works as advertised. There are no footstep sounds when you walk on it, though. I thought there was a default footstep. Something else to look at.

The comment on that material in the Doom 3 files is: // slick is an invisible surface that should be // used as a thin sliver brush over floors to cause sliding So I think it's okay for there to be a "shader not found" in DR. I didn't know about this one (thanks for pointing it out), and will test it tomorrow.

'Slick' is just an attribute added to the ice and ice nodraw shaders. It's not really a separate shader (like dry and wet surfaces that have different speculars), so it doesn't have a separate editor image.

Okay, okay. My white flag's up and I've ducked behind the ramparts. I know all this stuff should be there. I took a breather from learning how movement works (for the "stuck AI" bug) for a day and got this little piece of existing 'slick' code to work correctly (on flat surfaces). The next time I need a breather ("stuck AI" will take a while I think) I'll add the momentum stuff and then you can build a proper ski-jump or death slide or whatever suits you.

Friction comes into play when you let go of a movement key. It defines how long it takes for you to come to a stop. Reducing friction (via 'slick') doesn't make you walk or run faster. It just increases the time it takes to come to a stop. This gives you a sensation of slipperiness at the end of your movement. Which means sliding down a "too-steep-to-stand-on" slope will just drop you off the ledge at the end. Then it's straight down, since you don't have any forward momentum.

tdm_nodrawsolid_ice already exists. I gave it 'slick' and now you slide around realistically. The footsteps are 'walking on ice' sounds, which I think is okay regardless of what's underneath. "Slick" means: - when you're walking or running, it's like normal walking or running - stopping is no longer sudden; your momentum stays with you and falls off as you slide to a stop - it won't make you fall down I fixed the existing 'slick' code to make it work correctly. AI moving around on ice should exhibit the same physics, but there's no code in place to do that. Perhaps something to look at in the future. Thrown objects like mines should slide along the ice and bounce off walls with wall-bouncing physics. Also future work.

I've confirmed that it doesn't work correctly, and filed issue #2409. I'm looking into it. I will admit to a childish desire to bounce off walls. The ice and nodraw_ice textures would normally get this. Are you asking for an independant slick overlay that you could add to any texture? Perhaps to create a slick slope of stones near a stream?

Thanks. Looks like we don't use it on our ice textures, and it only applies to the player. I'll test it and see how it behaves.