Ishtvan

Awesome mission! This back that classic mansion heist feeling, and I agree with Sotha that not every mission needs a sinister plot twist. The story here was just right. Played it tonight in a Thomas Porter double feature, right after the Glenham Tower.

How often does that happen? Are mappers going to be frequently creating ponds/lakes that can be drained and re-filled? If they are going to go to the trouble of creating dynamically raised water, they can put in an AAS blocking entity as well to dynamically block the AI from walking in there. A pre-check at the start of the map would work for the great majority of situations where AI would otherwise walk into deep water and drown.

I'm having some SVN problems but maybe I can update just the animations folder and take a look. We talked about it over PMs and it sounds like the sword is staying in the same positions over the period of time that counts. I did have some concerns about animating the head/waist. When Domarius tried this, it overrode the code that made them look at you, so they stared off into space, and it also overrode the code that made them tilt their body up/down at you, so they could no longer hit you when crouching because their spine was stuck straight upright. I don't really have time now to do a full re-tweaking. So if an animation doesn't work gameplay-wise, we may have to revert it back for now. @Noisycricket: The problem with pre-calculating when the sword would hit the AI's sword is that it assumes everything is pre-determined, but it's not. It's physics based, so the AI could be running at the player who is running backwards while jumping on to a moving train. Then there's the chance that another AI could jump in front of the swing and get hit by it instead. The system doesn't use pre-canned animations that play based on a calculation the moment the swing starts. Whether or not the block succeeds is determined at the instant when the player's sword hits the AI's block, but not before. I realize this looks kind of bad for the thrust parry (the others all actually make sense that they would close out a line of attack as long as they're held there). But we can't realistically model all the different ways a thrust could be blocked (is the thrust coming in to the left of their sword, to the right, up, down?). So we're kind of stuck with this fake-looking thrust parry that just puts the sword out front and leaves it there. EDIT: I think what you're describing is called a "circular parry," which works in some cases, but not in others. For example, the player can hold their thrust back for as long as they want, the AI circular parry would have already finished. That's why we went with a "parry #4" which looks okay when held in place for a while, then returns to the starting position.

SneaksieDave did a test of this very early on in the mod. I don't think it exists anymore but it was something like test/city, a bunch of buildings on a city block, all enterable with visportals, and it ended up running better when the visportals were turned off. That was also the first map we eventually put working AI into, and the first AI was the Revenant. Ah, the memories.

I don't think the AI will throw in that case; they know they can't hit the player on the other side of a solid, and brittle fracture will stop a CONTENTS_SOLID trace.

Maybe I missed something said in the thread, but have you tried turning Catalyst AI off? That's how a lot of people (including me) have fixed this problem.

Yes. And turn off auto-parry!

Great! Now all we need is an AAS modification so that AI know not to walk into water deep enough to drown them.

The more visportals you have off of a single vis-area, the more calculations have to be done to check occlusion of all the visportals. At a certain point, this extra calculation outweighs the benefit of visportals, so you're better having no visportals at all rather than a lot branching off of one vis-area. Fore example, if you had a huge manor with 50 windows, all connected to a single "outside" vis-area, performance would almost certainly be terrible.

Don't forget about MyFace. People in the Law & Order universe deserve to know about TDM as well!

You could try a debug display (or an attachment at the same point) to show you where a given offset is ending up on the head, then adjust it ingame by doing reloaddecls and spawning a new AI, until it appears in the right place.

I was just able to play this recently as well (it came out during my nomadic period last year). This was a great mission, and made all the hard work we put into TDM well worth it. I got a bit fatigued with searching for things after a while, because I started at 8 PM and didn't finish 'till 4 AM, but that's the sign of a good mission! Had to look things up three times:

It's already on the tracker that AI aren't aware of deep water that they can't walk through. It might be possible to create a new "swim" movement type that's like the existing "fly" movement type (using a 3d grid of AAS points), but constrained to stay within the water. The AAS compiler is not in the SDK, though.

Last time I think it was somehow a combination of the run animation and the attack animation. Like maybe they bent over a little in the run and then bent over more in the attack? I don't know but it looks off when they're slashing, and I think it's also causing their attacks to go through player parries sometimes.

I noticed that with the new "run with sword" animations, or maybe new attack animations if there were any, the AI are leaning forward and staring at the ground when they swing their sword sideways. This not only makes them look silly (trained fighters don't bull rush looking at the ground while swinging blindly), it also exposes the back of their head and makes it relatively easy to KO them with a jumping blackjack swing. I notice this in particular on the builder guard. We had this issue with the old animations too, but fixed it somehow. I forget what it was, maybe giving the swing or run forward animation less rotation on the hips, or something. It seems like the new ones need the same treatment.

You could also look at how the horse is set up, physically. I'm not sure if that's exactly what you're looking for, but you can climb and mantle on that without the need for extra bound player clip entities.

Did you also briefly consider running away with a big bag of gold pellets someone gave you to refill the evaporator? I thought about it for about a second before I realized that gold worth a couple months vacation in Mexico wasn't worth throwing it all away and living as a fugitive.

Yeah it should be up, unless I'm committing to the wrong branch, but I checked the dates of the last updates to make sure it was the right one.

Okay, rotating objects like those in Swing will be able to be mantled in the next release. Mantling moving things still has some issues with clipping into other solids while you're doing it, but it's improved a bit.

I just got around to playing this as well, and now I can't wait to play Glenham Tower! Excellent overall, really liked the readables and gameplay. Some minor/major bugs, probably mod-wide but I put in spoilers since they deal with specific situations here: EDIT: Also pretty cool:

Huh, mantling translating things works fine (except for the possibility of clipping in to stuff while doing it). It's just rotating things that don't work. You'd fix it in idPhysics_Player::MantleMove(). The way mantling tracks moving objects is kind of simplified: if (m_p_mantledEntity != NULL) { idPhysics* p_physics = m_p_mantledEntity->GetPhysics(); if (p_physics != NULL) { newPosition += p_physics->GetOrigin(); } } It only takes into accoun translation, but if it's a large object that's rotating, the origin doesn't change, but the point on the surface where the player started mantling does change. There might actually be a quick fix for this: store the vector from the entity's origin to the point on the entity's surface that the player started mantling, get the current coordinates of that point (taking both change in origin and orientation into account), and offset the mantle by that current surface point instead.

Awesome mission! Makes me want to try to fix the physics of mantling moving things, but that's a major undertaking.

Just FYI, AI can also be damaged by horizontal acceleration, but the threshold for damage is higher.

They're not taking damage directly due to the mover spawnarg that deals damage (not active on doors), but rather acceleration damage from being knocked around by the door. @grayman: I agree it's not a good idea to cap damage, if the problem lies in the interleaving and can be fixed there.