Ishtvan

We've had problems like this before, and Angua fixed a lot of them. First, within the code where AI take damage from accelerating (or decelerating), we have to make sure the "time" denominator is set to the time since the last interleaved think-frame, not a hard coded 1/60 seconds value assuming they think every frame. This is already fixed though, AFAIK. I would think that would also apply to this "shove them down on the ground" velocity, since the damage code would know to put a larger time in the denominator, the time since they were last checked for interleaved thinking. But maybe something weird happens, like due to order of execution, the damage code thinks this extra downward velocity was applied all in one frame. I'm not sure. It sounds like Grayman has made some progress fixing the problem with doors, though, so that's good.

This political refugee's fieldcraft is all kinds of awesome! http://www.cnn.com/2010/WORLD/americas/11/04/canada.disguised.passenger/index.html?hpt=C1

It seems like there should be some IK settings for this. Maybe we could look at how they did it with the D3 Pinky demons? Or do those also have this problem?

Okay, not what I would have done. Our setting includes industrial steampunk factories, and you think no one would ever want a crane that can pick things up in their map? But I don't have time to help out at the moment so I can't level too much criticism at people still doing work .

Just saw this in that wiki quote above. I would recommend against removing idAFEntity_ClawFourFingers. First, someone might want to use that in a puzzle for their map, like the original one that was in D3 except perhaps with more appropriate levers/knobs rather than a GUI. Second, we can learn a lot from how these various AF classes are put together, as we continue to fix bugs and expand the functionality of AFs. There's no sense taking it out and making people go back to the vanilla D3 SDK to find it when it could still potentially be useful.

Carbon fiber already has an excellent strength/mass ratio. There are metal foams, but I'm not sure if they're as sturdy. They use them for things like high surface area electrodes on batteries.

Converting the units, 0.179 g/L = 0.179 mg/cm^3. So the answer is that Helium is still much less dense than currently achievable aerogel, by a factor of about 6. The weight of outer skin to hold a large volume of helium is pretty negligible, since the outer skin is a thin surface, and surface area goes as R^2 while volume (total amount of Helium within a container of that size) goes as R^3. You could imagine trying to build a skin out of a sturdy material like carbon nanotube fibers or graphene, and evacuating the inside. That's going to weigh much less than a porous material. But as others have pointed out, even if it could withstand the 14 psi pressure differential, you only get a boost of 14% going from He to vaccuum. And having a huge volume ready to implode at any time doesn't sound very safe to me.

Sounds good. But now we have to add "bag o' sand" or "ice axe" to the list of player tools, to overcome that icy 27 degree incline.

I'm very late to the party here (June), but there is something that does this. Not a surface, but a clipmodel contents flag, CONTENTS_OPAQUE. This has to be set on a solid object with a clipmodel, like a door. The way to set these is not very userfriendly, you have to set "clipmodel_contents" to an integer that is the result of summing all the binary CONTENTS_* flags you want. The values of the CONTENTS flags to add up are listed in tdm_defs.script. Even then, on certain entities the clipmodel contents can get reset from what you set originally, so no guarantees.

1 or 7% is a big deal in terms of saving money on fuel, but probably not a big deal in terms of lifting orders of magnitude more like you'd need to do in an airship. The crazy airship idea in fiction that I liked involved type II superconductors excluding the magnetic flux of the earth, but that's also pretty crazy. Very light superconductors only levitate a few inches away from an extremely powerful magnet, so you probably wouldn't be able to levitate thousands of feet using the relatively weak magnetic field of the Earth.

Moveables rotate about the center of mass, which is calculated separately from the origin. However, you can still have problems with non-standard collision models.

Only the kill arrow is supposed to stick in at all. So if the other, non-lethal arrows are sticking in, it's probably a bug.

For an Arx-like magic cast system, they might be able to use our mouse gesture reading code that we added for combat. Combat only uses four directions, but the general code can read 8 directions. It might be useful for determining what direction someone wants to draw when they are drawing each rune-line or something. In fact, back when we added the gesture system for combat, I was wondering where else we could use it, and the thought of some crazy FM author adding an Arx-like casting system was all I came up with.

They just kick them out of the way, unless they're really big like crates. They usually know to navigate around those things they can't kick, but it might not kick in until they get pretty close to it.

If you want to do both a back-swing and a forward swing, you don't have to swing around with your mouse, you can either look forward and tap back when you press attack to swing backwards (but this has the disadvantage that you move slightly down the rope during the time you pressed back), or you can face sideways to the direciton you want to swing and hold the left and right buttons while pressing attack to swing side to side, then turn back forwards and jump when you're ready.

No. They are only active as long as they're moving, once they come to rest they're inactive until something collides with them again. The only times where they could remain active is if they keep moving because energy is entering the system unrealistically. This can happen in badly designed ragdolls and stuff floating in water with bad parameters. There is a console command to hilight active moveable objects. I forget what it is, but it's probably "rb_showactive 1". You can check the console commands.

"As close as possible" is a tweakable number for each item. It's quite possible that the closest distance needs tweaking on a lot of items so that you can hold them closer.

Do you know that you can pull things in closer/push them out farther using next/prev weapon/inventory keys (mouse wheel by default)? I don't have much trouble turning around if I pull the object in close, first. Just like in real life, if you are holding something with your arm straight out as far as possible, it will bang into things more when you turn around. So hold it in closer if you want to walk around with it. We considered a system where this was done automatically for you, but decided it would take away too much control and end up being frustrating. Re: Knockout to the face bug I believe this is a combination of a melee bug and the failed KO animation that tilts their head down a lot (making it easier to hit the back of the head from over the top, which registers as a KO).

Sometimes if the FM author binds an object to the head and doesn't ser it nonsolid, the ragdoll becomes stuck on the object and you might get behavior like what you saw. We tried to fix that in the update.

What ATI card do you have? I used to have a similar problem with an R9800, depending on the drivers.

Yes, the block is a physical object being put in their way, and their attacks are coming in at an arc so if you get it up in their way sooner, the blades will meet sooner. You can see the collision objects in red wireframe if you want by using "tdm_melee_debug 1" in the console (the collision objects for parries and AI attacks are significantly bigger than the swords, for gameplay reasons). There is a slight delay in the controls that will be removed in the upcoming release, which might also help with what you're experiencing. However, there is still a certain amount of waiting involved. That's how sabre parries work IRL, you pretty much put up the parry and wait. Thrusting weapons like foil and epee are more like what you described, you can move your weapon forward to meet the opponent's blade, then deflect it as it comes forward based what side of your blade it's on and what the pressure feels like. But sabre attacks are slashes coming in at an arc, so you can't really chase after them trying to meet them earlier on in the arc, or you will end up in a weak, over-extended position, from which you can't riposte very well. You end up reading the attacks by eye, and putting your weapon in a good position where you know it will intercept the arc of the attack and leave you well positioned to riposte. It's already assumed that your parry will not be valid until it is very close to being in its final position (you can watch when the wire-frame turns on with tdm_melee_debug on). If you are blocking your right side with a sabre parry #3, for example, it only really blocks after it's 95% or more in position, I'd say. Before that, your arm or flank will still get hit. This makes sense when you think about it: You want the final position to be at the minimum displacement needed for it to work, because that lets you recover the fastest. I don't really see a reason to have a randomized failure or success before it gets to the "valid" point. I think it should definitively go from not working to working, so that players can get used to that timing and know how early they need to parry to be in position when the attack comes. Randomized success would just lead to confusion ("You mean I need to parry earier?? But it worked last time!).

I'm not sure what you mean by that, do you mean you must wait for your attack to complete before you can block? You shouldn't have to wait for anything with regard to the AI, you can block whenever you feel like it. I'm not really in favor of a random chance of having a block collapsing depending on how soon you put it up, but you do still get benefits from blocking earlier on in their attack, because it usually means you're more prepared to make a riposte right away, and can mean that you intercept them while they are still extending, meaning you get more time to riposte while they're still recovering. I agree more advanced AI footwork would be nice, but it requires a lot of work work in both programming (so that the AI know if they have room to jump backwards, for example) and animations. No one has had time to do it, but if you know any programmers willing to work on it, send them our way.

"Stander," the true-ish story of the most famous South African bank robber. Most of the parts you think are too insane to be true turn out to be factual. Some reviewers described it as "flawed," but I liked it. Also has a sweet score that was unfortunately never released.

When you hold an attack and they stand there parrying it, you don't actualy have to wait for them to drop their parry to attack. If you let go of attack and hit it again rapidly in a different direction, you're effectively performing a feint attack (or "one-two" in boxing). Often you will hit them. It works better if you change direction while they're still starting to parry. Sometimes, they decide to stab you instead of parrying your second attack, like real people wearing heavy armor against some unarmored guy who keeps feinting. @Mr. Lemony: As for the mouse moving all around when you attack, that's nonsense. It locks the view in place for 120 milliseconds as soon as you press attack. Any longer feels wrong. Also, you do realize you can still aim the attack the whole time it's swinging out, right? Anyway, for people who want easier combat, that will be in the update. For people who don't like it, here's a hint: You're not supposed to be able to win at combat all the time. That would make the stealth pointless. What you're really supposed to do with the sword is swing at them long enough to make them pause to defend themselves, then run away before they can recover and chase after you. I agree the combat tutorial is not that good because there's a huge jump in difficulty between the first and second opponent, and he can take too many hits before he dies. Taking too many hits before death will be changed in the update, and hopefully I will have time for a future update of the tutorial that ramps up the difficulty more gradually and also includes some skill-building excercises. Combat was quite WIP in the last release... that's why we said that all over the readme. It was one of the last things we programmed, and thus did not get as extensively tested as other things, because guess what, we wanted to focus on the STEALTH elements.