Ishtvan

How far down are you looking when you say you're shooting the ground? Like straight down between your feet? AFAIK, there is still a lightgem issue that makes particles invisible within a certain cone that extends downwards around the player. Maybe that's the cause?

sound_loss only affects AI sound, not player sound you can hear. Forcing a portal open or closed presumably uses D3's "door loss" to affect audible sound, which is a value we can change, but it's the same for all portals across the map (until the sound engine source is released and we can change it).

The double sword could be the melee physisc test sword that's supposed to be put in the same place as the first person sword, and set to nodraw. We never fully transitioned to a system where the animations have an empty hand and the code puts the sword in there, so we ended up with two swords, because the player sword isn't a real object. The test-sword is supposed to be set invisible, but maybe going in and out of a cinematic while the sword is drawn is somehow un-hiding it? Does it go away if you sheathe the sword and draw it again?

If normal is too easy, I would set it higher. AFAIK, on the higher difficulty levels, only very weak AI like the armed commoner die from a single hit to the head, when alert. The rest should take two hits. It does a lot of things, as Aprilsister posted, although those are the skill sets for different AI (e.g., an unskilled brawler vs a professional guard). The player difficulty setting modifies these values as well. It increases hitpoints and damage, attack time, reaction time, predictive ability (you have to attack them from different directions or they get used to the same attack and react faster to it). It also makes them more likely to counter attack and remise, rather than parry your attack, which can throw a wrench in the strategy you posted above by causing a simultaneous hit after you parry and try to riposte, instead of you parry, they parry, you parry, etc.

I would just set that ko immune state to 5. What makes you think the larger head model would be more accurate? If anything I would think it would make it worse, because it's longer in back, and when the AI tilt their heads down, this will make the back stick up even more. If you want to test this, you could go into the AF file and temporarily edit their head box to be the same as the extended head box. I don't think it will help prevent the front-KOs on alert 4 (is the head box even swapped to the smaller one on alert 4? I thought it happened in combat?), but you can try.

Just a cautionary note, we didn't go to great lengths to support multiplayer in all the additions we made to D3 (things like frobbing, for example). So having multiple bots at once may be tricky. But a single bot that takes over the player might be more feasible.

I did some testing and the problem is that D3 physics really does think you hit the back of the AI's head from standing in front of them. Sometimes the D3 collision testing isn't all that accurate. The AI head is modeled as a rectangular prism that's flat on top, and to make matters worse, the combat animations are all tilting their head down slightly, which puts the back verts of the rectangle higher up than the front ones, making them the first to touch if you were to bring a flat thing down toward their head. If D3 tracemodels for the head and blackjack could be perfectly rounded, we wouldn't have this probleem, but they can't. In the images below, I blackjacked from the front and then stopped time and rotated around to the side so you could see the impact point on the AI. The red arrow pointing down at their head shows where D3 thinks the collision took place. In the first case, things work as intended, I hit them in the front of the head and they didn't get knocked out. I was standing fairly far away. In the second case, shown first from the front and then from the side, the collision was registered at the back vert of the head, knocking them out. Standing closer to them and hitting them while they're attacking and looking down makes this more likely. Now, the blackjack CM is not flat, it's angled up a bit (from the player's perspective) which is intended to improve accuracy here, by making sure it hits the vertices of the rectangle-head on the side you're facing first. But it's clearly not enough. The change of moving the blackjack CM to the center of the screen may have made this a bit worse, because when it was off-center before, the corner of the box came down on the head, so collisions were tested along the edge of the box, and it seems like tests with the verts and edges of CMs (at the corner of the blackjack box) are a bit more accurate than tests where you're colliding one face against another face. It tends to put the collision point at the verts, which in this case are erroneously the ones at the back of the head. I can't think of an easy way to fix this. If you make the blackjack CM shorter so it can't reach around to the back of the head from the front, people complain that they can't KO from far enough away when standing behind the AI. If you added an extra vert to the AI head sticking up in the center, the somewhat crappy collision system would probably always detect a collision right at that vert, regardless of whether you're in front or behind. The old blackjack CM position seemed a bit more accurate for these tests, but it was off-center left-right. The helmeted AI don't have this problem because they're immune to KO in combat. Maybe we should just make un-helmeted guards immune to KO in combat as well? They'd still be a little easier to KO from the front than they should be in the searching state, but at least in that state, compared to combat, they're typically not as close to the player and not looking down as much. I can't think of a reason we want to allow KOs in combat, unless the AI is fighting someone else and we sneak up behind them? Adjusting the combat animations so they don't bull-rush you with their head down would help a bit, too.

The larger head bounding box is intended to make it easier to KO AI when not in combat, and also make sure it goes outside the helmet as Spring said, but in combat it gets reduced to the normal head box. You don't want to leave on the larger head box in combat, because it could extend beyond the helmet and let you kill them with the sword as if they had no helmet. I forget how this ties into attacking an unalerted AI with the sword from the back... might have put in a specific check against that. I don't know why swapping to the smaller, normal box could be letting you KO un-helmeted AI from the front. Unless something with the AI skeleton changed and the normal box wasn't updated but the larger box was? You can confirm this with g_showcollisionmodels. You sometimes get KO's from the front due to collision detection issues, if you're leaning forward and the AI is running into you, and as soon as the blackjack collision test starts, it's already at the back of their head. Also, I said this ages ago, but the latest combat animations make the AI run with their heads lowered, staring down at the ground. Not only does this look a bit silly, but it also opens them up to KOs from the front, because they are pretty much presenting the backs of their head to you when they run forward at you like that.

It would be nice if we could edit the AAS database in memory (since we don't have access to the AAS compiler) such that AI who can drown don't walk in water deep enough to drown them. With monsterclip, you can't differentiate between, for example, undead who can sit around underwater and live humans who can't.

I think someone added some other method of doing it, and might have temporarily disabled the worldspawn target method. This happened a long time ago, don't remember well.

In case that doesn't work, you could also try not setting his path node until after he's teleporte in, using a target_set_target entity (or something like that), which is used for example in St. Lucia to bring guards running in.

Okay, I will attempt to communicate as clearly as possible. When several people said: They were referring to the fact that the title of the thread (which is what you see before you click on the thread to read it), was not that descriptive of the actual contents. Note that the phrases "thought," and "was hoping," are all written in the past tense. These people did in fact read the description of the add-on, and do not still think it is something else. Speaking for myself, I was attempting to lightly poke fun at a thread title I thought was a bit pretentious and non-descriptive. This is not an attack on you, personally, just the comical situation of having a non-descriptive thread title and wondering what it might actually be before one clicks on the thread. If I were to hypothetically release a training with more involved melee training, I would call it "Improved melee trainers," and not (unfortunately) "Blue Steel."

Also a planned playertool addition: The sarcasm detector. EDIT: We could copy/paste the code I wrote to launch a particle effect when the sword hits something, it should be pretty generalizable. Or just do it in soft-code with scripting. There is an option ot run a script when things are picked up, I believe. But we're still missing a wood dust or splinter particle effect. Stay tuned for my upcoming update, "Blue Steel."

I put in a request way long ago for a wood splinter effect when you hit something wood with the sword. But I agree it's not a high priority compared to other things. Re: Black Light, I thought this was going to be about UV lights and using D3's "spectrum" lighting effects to make certain things flouresce under UV light. AFAIK that is possible right now with light/material keywords. It seems a bit modern, but might be fun for all those "investigate crimes by finding evidence of bodily fluids" FMs, or undead rave parties.

To make that look natural, you really need a model of muscles and skeletons like these full-body IK animation codes have. You also have to deal with what happens if some physical object is blocking them from getting back up. Do they get up partially and then crawl out from under it? (GTA didn't handle that very well, they usually just got up partially, then flopped back down if something was blocking them from getting back up)

There are games where ragdolls get back up using IK animation. GTA IV, for example. We looked for an open source version of this but haven't found anything satisfying so far. Integrating it with the D3 animation code would also be challenging, as some of it is closed and none of it is well documented.

I believe there is a string list of "new" surface types that is initialized in gameLocal.cpp. Spawnargs for sound properties have to be added on an individual basis for propagated sounds. Otherwise if it sees a surface type, but doesn't find a spawnarg for a propagated sound for that surface, it will just use the default soundprop volume.

You weren't able to in vanilla D3 (pressing jump while crouched just made you stand up), but we added it. It actually helps a lot when you're clambering through low-ceiling areas and want to hop-then-mantle somewhere.

I enjoyed this mission a lot, and was also reminded of Life of the Party. My only complaint is story-related:

In the script above, why do you need to play the "put away" animation? You should be able to blend back to the idle animation directly, and the animation blending will do the lowering for you. I thought that's how the sword worked, but it's been a while since writing that script.

It definitely works for the sword (abort a held swing by hitting "block"). To get it to work for the blackjack, I believe someone just has to copy those elements from the sword script over to the blackjack script.

I like the idea in general, and could see myself using this occasionally. It's definitely less immersion breaking than exiting out and going on to a forum when you're stuck! However, an easy way to turn it off would be key. I'd not want to be spoiled even by knowing that there IS a player clue in a particular readable. Maybe that could be another option: Do collect the notes, but turn off any sort of "note added" notification unless the player goes and looks for them (e.g., by opening a single "player notebook" readable, described below). That way they can draw their own conclusions unless they really get stuck. As for each note being a separate inventory readable: I can see why you'd want that to have the three levels of hints / pages put together for one clue. However, I think the pain of having more stuff to cycle through may outweigh that consideration. I'd probably prefer to have them all in one readable to avoid the extra cycling. That makes it a little harder to organize the clues, but perhaps they could be numbered or titled, and the stronger hints would be in a later section of the readable, but in the same order and maintaining the same labels/numbers. The level-of-hint sections could also be separated by a one page title, so you don't accidentally scroll into them. For example : Section 1. Suggestions [Next Page] A. Glove of the Scarlet Pimerpnel [text], B. Who Spiked the Mustard? [text], [Next Page], Section 2. Strong Suspicions, [Next Page], A. Glove of the Scarlet Pimpernel [text with stronger hint], B. Who Spiked the Mustard? [stronger hint] We may have to write some specialty code to show things in the readable on multiple pages in the order that the player finds them, but I think it would probably be worth it to avoid having 10 extra notes to scroll through. Accessing them all through a single readable also makes it easy to do the "add to notes, but do not notify the player" option, if the player wants to remain unspoiled until they're really stuck.

Not currently. At one point we wanted to make armed mines be disabled by frobbing them with the lockpicks. I looked into that and it was more work than it seemed, though, due to how lockpicking is internally implemented to require certain classes. Those two things aren't really related. The speed of the mantle is a design decision, not a bug. Why should whether you started out running forward or not have an effect on how quickly you can pull yourself upwards? There is a faster mantle that happens when the thing you mantle starts out around waist height, but otherwise it assumes you start out hanging from your arms, which is slower by design. Don't know about that one. Sounds like it could be a visportal problem with the map?

That sounds interesting, but you'd have to add multiplayer support to TDM first. We didn't make maintaining D3 multiplayer support a priority, and therefore many TDM things (e.g., frobbing) would be broken if there were more than one client connected.

I forgot to mention that I also really appreciated the full outdoor perimeter around the building and the different ways to get in.