Ishtvan

That's the impression I get, too, which is a shame since we put in a difficulty slider. If people can't handle it, but don't want to reload all the time, they can just set it to medium. I probably should do this myself, because when I'm sneaking I'm not prepared for melee so it's much harder than when you're practicing it constantly fighting several people in a row. But somehow players don't like doing this because it admits weakness. I usually just try to fight and die. EDIT: But we shouldn't make it even more frustrating by changing the overhead slash to be harder to read for people who use manual parry.

Yes, some "jockeying" back and forth and side-stepping with the legs would help, but I understand it's difficult to modify the AI for this (particularly navigation, so they dont try to sdie-step into a wall or leap backwards off the edge of a cliff). Don't get me wrong, the animations do look much better and more fluid overall. I just had one important complaint, that the AI overhead attack is too hard to distinguish from a sideways slash, which makes it much more difficult/frustrating for manual parry users. Is anyone using manual parry these days? The other complaint is less important, that we changed our thrust parry from foil #4 to sabre #2. Granted, using any single parry for all thrusts will look a bit unrealistic, because thrusts can come in at so many angles, and also because in the current system, AI make the parry and wait, rather than moving in sync with a thrust as it comes in. My point is, it's always going to look a but off, but at least with the old thrust parry, you can see how it might intercept thrusts toward the head and body. What they are doing now is a parry that will block low slashes to their right side, which makes no sense for blocking thrusts to the torso/head. Spring, you've done archery... how would you feel if an AI nocked 3 arrows at once and felled three separate opponents, or if they fired at you backwards over their shoulder with some bizarre trick shot? Because that's how I feel about parrying a thrust with parry #2. It's no more believable than if they did a spinning back-kick at me that somehow blocks a thrust. A lot of games try to make swordplay more theatrical to be exciting, but our guards aren't swashbuckling pirates; they are supposed to be well trained soldiers who would never needlessly point their weapon down at the ground.

This might be the cause of the BJ animation, or it could be really out of date or just wrong information: When you cancel the swing, animation blending just takes over and tries to blend back to the idle position. When this happens, it looks like the blackjack model in the animation is getting out of sync with the hand. I'm not sure why this is happening for BJ but not sword, but here is a guess: When we added the new melee system, we _might_ have changed the sword animations to take out the sword in the player MD5, and just let it be the actual moveable sword attached to the player's hand. Thus it could never get out of sync and move away from the hand, even during animation blending. We did not do this for the BJ, which could explain why it gets out of sync? Even still, it's not supposed to, but maybe it's parented to the wrong joint (not the hand) in the MD5 mesh? Thus it would stick to the hand in all deliberately crafted animations, but not during procedural blending? Other explanation: the sword does it too but the hand-sword connection is offscreen longer so that you can't see it? Should be easy enough to test using the timescale cvar for slow motion.

On a related note, this comment is totally aeshtetic rather than gameplay related, but: The new AI parry to defend aginst thrusts is really unrealistic. This is the one where they flip the whole sword over and parry a thrust with their sword pointed down at the floor. Sure, it looks more flashy, but no well-trained person would do that, because it leaves you in a terrible position to recover from. Your point is pointed down at the ground, making stabbing impossible, and your arm is turned over in such a way that you can't really generate any power on any counter-slashes. You could manage a slash to only one side, or an awkward downward cut that takes longer than normal, but those are the only options. Compare this to the old animation that was based on the classical foil parry #4, which leaves your point pointed toward your opponent's eye ready to stab, and your arm ready to slash in any direction. I know I'm being picky, but it ruins the immersion for me to see them doing flashy, impractical stage-fencing instead of actual realistic combat techniques. The sabre parry depicted in the animation is called #2 or "seconde," and it's never used in modern sport competition because it is so awkward. It was originally for when you're on a horse and someone on the ground swings at your right leg. I guess it could be used standing if someone slashes at your right shin, but we're using it as a generic stabbing defense, which makes no sense. The majority of the time, you're trying to stab each other in the face or torso. Maybe the animation is supposed to depict a circular parry that sweeps down across the body? But that doesn't work with our "put it up and wait" system of AI parrying necessitated by the code; it would have to be timed correctly with the thrust to look right. So meh. EDIT: See what happens when you post videos of new melee animations?? I complain about them. On a positive note, this one could be kept around in case we ever implement AI fighting you on horseback. ]

Haven't been able to play the mod since the new melee animations were added, but I saw the overhead slash in Springheel's video here, at 2:38: ! I don't know if it's changed since then, but if not, it's way too similar from the sideways slash (from your left to your right if you're facing them). It's more of a diagonal cut than a downward cut, which might be realistic-looking, but makes it too hard to read for those of us who like using the manual parry mode. It needs to be easy to read the directions of the attack right from the back-swing on. If you're watching their hand, it should be moving back and up over their shoulder right from the start, to distinguish it as much as possible from the side to side slash. This current back-swing goes sideways off to your left side. It might not look as cool to do a more differentiated back-swing for the downward cut, but it's so you can read it for gameplay purposes.

I don't think I did it, but I do think it was removed. It messed with the frob code a lot, and we debated it briefly and tried to think of anything we would ever want with an ingame 2-D point & click style GUI in our setting, and couldn't think of anything. You can still script things with real moveable objects serving as selection cursors, like a quill pen on a check list, etc. Sucks for whoever's making a mod of our mod in a setting with computers, though.

Hitting the middle mouse button when the sword or blackjack is raised is supposed to "cancel" the swing (it definitely does for the sword, don't recall if it's supposed to do that for the blackjack or not). Does this only happen if you view and close a map first, or can you get it to happen at the very start of the mission when you select the sword or blackjack?

Hmm, it's been a while, but I think an objective that is invisible to the player, but still flagged _active_ should still work to get triggered. This could be a bug. Unless the "visibility" entity is set to toggle both visibility and active/inactive state?

This is a bit off topic, but we kind of want the attack animations to be easy to distinguish, if you're watching for them. You only have a fraction of a second to read the back-swing and see which direction they're attacking from, so it should be clearly distinguishable from the animation. The difficulty in combat should (and does) come from other sources.

You can try setting the swords nonsolid as a diagnostic, although I don't think that's a permanent solution because some things will break.

I was talking about the SDK code that detects if the player's "focus" is on a GUI surface or not. We took it out because it was interfering with frobhilighting and making things more complicated than they had to be.

Optimator is good. I know Leffe is owned by the huge corporation Interbrauw, so I'm not supposed to like it, but for me, Leffe Dubbel is hard to beat, and Blonde is good too. Westmalle Dubbel as well, basically anything Dubbel.

Right now you can gesture after you click. In fact, that is how the code reads: wait for click, then interpret the gesture. However, there's a very low threshold for how big a gesture you have to make to choose a direction. in TDM 1.0, it used to be a higher threshold (I.e., you had to make bigger gestures to choose), but this meant some time delay while you were making the gesture. People complained about this delay, so we reduced the gesture threshold, which made it feel much more responsive. The downside of this is that if you're already moving your mouse when you click attack, it takes very little extra movement in that same direction to "choose" a direction. You can still do "click then gesture," but you have to make sure you stop your mouse movement before you click, or have very good timing and change directions right after you click. Or, you can start gesturing before you click. It's all a trade-off, but when we used to have it easier to click+gesture, people didn't like it because the momentary delay to integrate the gesture (even one extra frame) made it feel clunky or unresponsive. @Spring: There is a reason to pick different attack directions other than the default left to right slash: if the AI keep getting attacked the same way several times in a row, they will anticipate it and parry faster than if you were to change it up. This becomes more important for better trained characters and higher difficulty settings. For people complaining about the difficulty, is the "Easy" setting really still too hard?

As I recall we pretty much removed this type of GUI support from the code base in order to make frobbing/readable code more streamlined and easy to maintain. So it's not really possible in TDM. I was skeptical of this at first, but then realized that TDM puzzles work better with real, concrete objects (e.g., moving an actual quill pen over a check box, pushing a concrete button or turning a dial). All of these things can be done with fairly minimal scripting. So we don't really need the code that we got rid for ingame guis moving around a 2d mouse cursor on a 2d display. It hasn't held anyone back from making cool puzzles thus far.

Ah, no. There are .EFX files which handle the player-audible sound settings for EAX. It would be great to make those work with OpenAL once it goes open source so that people can get richer sound environments without needing an EAX card. It would also be great to incorporate an EFX editor in DarkRadiant, I think we can do that without the map compiler source. Although, if you choose to define EFX areas by portal area number instead of idLocation, it requires some foreknowledge about what number a given portal area will get. Most of the time idLocation is fine, it seems like setting different sound properties on different area numbers would only be useful if you had like a tiny one-room bathroom that you wanted high reverb in and didn't want to bother with idLocation separators on the portals.

Those saved sound-prop files were never in vanilla Doom3, those were a system I was using very early on, but it turned out to be flawed and not useful. I'm not even sure what you'd save for the current soundprop system, probably just the area/portal tree, but it already exists as a linked list in RAM for the visual stuff; it would actually be slower to parse it from text files and re-create that linked list than it is to traverse and copy the existing one in RAM.

It would take effort, probably ~500 lines of code and a bunch of potential new bugs that could go wrong, all to save 1 second or less is probably not worth it.

I'm pretty sure we profiled that and found it wasn't worth the effort. Back when we first started soundprop we were going to compile it to a file, but then found it wasn't worth the effort because traversing the portal tree was pretty fast.

It's not feasible in current TDM, but it could work if a whole new system was added to the SDK to handle it. We talked about this a while ago but have not gotten around to it yet. As for stabbing weapons: Wouldn't these be pretty easy to parry, since you always know they're going to stab? You could compensate by making them un-parry-able I guess.

Yay! I looked into that and gave up. Congrats on getting that working! I still want to finish tripwires some day (maybe when I have grounded outlets I can plug my desktop into). The player interface for setting them is done, but the tripwire physics themselves (go off when something touches it, or when a moveable it's stuck in gets pulled too far, etc) need to be done. Was going to make them use static physics, but there's an odd case where you might have a tripwire on a moving platform or something and it could run into something stationary; for that you'd have to give them moveable physics.

http://physicsworld.com/cws/article/indepth/45840 This reminded me about our discussions of whether to model the AI's retina vs. the rest of their eye, and then introduce eyeball movement patterns - it's probably a good thing we didn't try to implement that with a simple model, because people are still discovering more about it nowadays. But this article argues about why we shouldn't use uniform, 2-d pixel arrays in artificial eyes, and goes pretty deep into explaining why a fractal search is the most efficient, and in particular a fractal with D = 1.5, then gets into what things we find aesthetically pleasing, and it's actually things with fractal dimension that match the eye's natural fractal search dimension. Quite interesting overall.

That was fun. I like the final interaction at the end. Incidentally, that also includes the TDM teaser trailer music by TYROT.

I don't know if this changed over the years or not, but I believe you also have to set a flag like "ongoing" if you want the objective to apply throughout the mission and fail the mission as soon as it is failed. Obiously it also has to be set as mandatory.

This might only refer to cases where more mandatory objectives get added at higher difficulty levels. Not ongoing objectives like "don't kill anyone," but extra objectives like "also steal the valuable spyglass." Because then you'd have to add this to the enabling objectives of the "exit mission" objective, otherwise it would let you exit/end the mission without completing this extra mandatory objective. Edit: also, what MD posted will fail the mission if you kill rats, spiders or undead, too. You may want to change to specifying by AI group and choose humans instead.

Also, as Fidcal pointed out, there are two options: being within an idLocation, I.e., a portalized zone with a name, just like you use to create zone-based ambient sounds, lighting, EAX, etc. For that you need location separator entities on the visportals, and I believe all you need for objectives is the name of the location. The other option is to be literally within a brush volume. If the objective worked better when making the brush larger, then you are using the second option, not the first where it is based on the location system and portal separators.