Ishtvan

I liked Moon and District 9, haven't seen Avatar or A Serious Man yet. I read the Road and found it to be good (it's by Cormac McCarthy who also wrote No Country for Old Men), but saw no need to further depress myself by watching the movie so soon after reading it. I also liked "Up in the Air." The dark comedy and drama elements were handled well, with good characterizations and performances. Have to inject a minoriy report on Book of Eli: I came in with very low expectations, pretty much limited to seeing some machete ballet, and that is what I got, plus some nice desert wasteland atmosphere. Also, woah spoiled the one real twist of the movie (not the obvious one, the other one). Although that twist was so nonsensical that I'll just pretend it didn't happen. If we're counting movies that just came out, I saw Youth in Revolt, and thought it was terrible. A few funny moments in there, but mostly terrible.

Yes, those are famous last words, I've found.

I'm looking at an oil painting now, and the wood frame that the canvas is wrapped around has no back, it's just a rectangular frame. Depth-wise, the wood frame is about 3/4" thick. So the thickness of the frame offsets the front part of the canvas with the image on it from whatever is behind it. There's a little hollow space behind the front.

Okay, attachments to the head are now treated the same as attachments to the body, so the same spawnargs apply. With the exception of melee weapon attachment-related spawnargs. I was too lazy to add CMeleeWeapon dependencies to idAFAttachment, but I figure we won't have any AI with a dagger stuck to their head, or any head butting with lethal pointy helmets any time soon. (In the code, I added a DropOnRagdoll function to idAFAttachment class, and had the AI call it on their head when their own DropOnRagdoll was called). Ragdolls with helmets now WORK. This was another reminder of how a 5 minute fix (make the AF file refer to the correct joints) turns into a 2 hour fix. Can of worms opened, and closed (mostly closed, attachments to attachments that aren't heads are still an issue for the future).

Okay, added code to also set attachments of attachments nonsolid, but now I realize that the head isn't even in this list of attachments that's effected by drop_set_nonsolid, because it's handled differently than other attachments. Double-ARGH!

Oh, Duh! This isn't working because the helmet is not attached to the AI, it's attached to the head that's attached to the AI. Argh.

I take that back, it's not getting added to the AF because its CM is not a tracemodel, so that's not the problem. Something else weird is going on. The only thing that's worked ragdoll-wise so far has been setting it to only CONTENTS_RENDERMODEL from the beginning.

Nope, even with that fixed, it's already too late by the time drop_set_* stuff is called. The AF representation has already been added, and that's what is causing the problem.

Actually, drop_set_nonsolid doesn't look like it works in this case, judging from the code: if (ent->spawnArgs.GetBool( "drop_set_nonsolid" )) { int curContents = ent->GetPhysics()->GetContents(); ent->GetPhysics()->SetContents(curContents & ~(CONTENTS_SOLID|CONTENTS_SOLID)); } It clears the solid flag, but it leaves the CONTENTS_CORPSE flag in place. I might add a new option like drop_set_corpse_nonsolid that also clears the corpse flag. Or just drop_set_contents_rendermodel. That should be good enough for now.

Hmm, I have another solution I just tried. I got rid of CONTENTS_CORPSE in their clipmodel contens and just set them to CONTENTS_RENDERMODEL. I teste this and it worked. They shouldn't have to be CONTENTS_CORPSE. Only reason is for the melee initial collision. If they're not CONTENTS_CORPSE, the initial collision will hit the head model, but then the next trace should detect the helmet. This is more iffy in principle, because you can hit the CM at a weird angle such that the next trace sometimes doesn't hit the surface. I'll try your solution of setting nonsolid. It would mean that arrows/blows will react as if there's no helmet on a KO'd AI, but maybe that's okay. Ideally we would have a drop_set_contents_rendermodel as well, not sure if we have that already. The real reason that CONTENTS_CORPSE is a problem is: It adds the helmet to the AF, which is fine, but it sets AF self collisions to 1 by default on anything added to the AF. This works for swords and arrows, but on the helmet, this is bad, because the head is constantly colliding with the helmet and stopping it from moving. So ideally, what we would want is a spawnarg to control whether self collisions is 1 or 0 when we add the item to the AF. That's a more complicated fix though, that I don't think we should try right now.

Argh! Now the ragdolls of guards with helmets are messed up. The helmet seems to be solid to the AF, so it stops the head from falling down as it should. We've probably always had this problem, but fixing the AF head physics made it more noticeable. Can we try setting the helmet nonsolid on death or to CONTENTS_RENDERMODEL or something?

By extension, the team of scientists who worked on this project diligently for the last 18 years find it extremely pleasurable to force people to "toil at boring, repetitive and even painful tasks in a very cold environment," and are therefore sadists.

Okay, I changed it to Spine2 in the AF file and it looks like it is working again. The ragdoll looks more believable now.

I just noticed that when ragdolled, our AI's heads aren't following the ragdoll physics, instead they just stick straight out stiffly from the torso all the time. I tested Builder guards specifically, believe it also happens to pro guards. I'm pretty sure it worked correctly at one point. The heads should flop around when you hit them. It's not an AF physics problem, I can see the head CM flopping around, but it's not modifying the visible head model. This probably means the AF file has to be updated for new joint names in the new skeleton. The old skeleton AF and new skeleton AF both have this same setup for the head: body "head" { joint "Head" mod orientation model box( ( -4, -3, -6 ), ( 4, 3, 3.5 ) ) origin ( -2, 0, 75 ) density 0.4 selfCollision 1 containedJoints "*neck" } Are there still "Head" and "neck" joints on the new skeleton? More importantly, what joint is the head actually def_attached to? Perhaps this joint is the one that's not being modified by the AF physics? It should be whatever's in the head_jointname spawnarg, right? Is it not "Head" for all our AI?

I'm sure someone doing 3D FDTD simulations (finite differences time domain) could fill up that much RAM, and much, much more.

@Spring: Okay, a blood spatter would work, as long as it's different enough to distinguish it from the flesh one. I guess we shouldn't assume that everyone's armor is dusty. @Tels: I was trying to go for some realism with the spark not happening every time. In RL if you hit a fencing mask with a sabre, you get a spark maybe 1 in 100 or 1 in 50 times. So already having it happen 60% of the time is already very exaggerated. The player also hears the different sound every time, so there's no need for a crazy lightshow every time there's combat. 60% probability is still enough I think.

They could have saved a lot of money by leaving out all post-processing and instead shipping with it a dead fish to beat yourself about the face with while you were playing.

I was wondering if there's any particle effect that would be appropriate for the sword hitting chain mail armor. Plate mail gives a spark (sometimes, it's random), cloth and leather give blood, but right now chain gives nothing. Realistically, it wouldn't necessarily give off anything, but it helps a lot to aim your attacks in melee if you can get feedback by seeing where you're hitting. It also makes it seem more real and not just like we're arbitrarily playing sounds. Would a small puff of dust be appropriate, like when people get hit in kung fu movies? It could be randomized like the plate mail spark, so it doesn't always appear, but enough times to give you the feeling that you're really hitting stuff.

I couldn't find these reported anywhere else, so I tracked them here: Loud click in the grass crouch-running footstep http://bugs.angua.at/view.php?id=2107 Moderate squeak in the shallow water crouch-running footstep http://bugs.angua.at/view.php?id=2108

I reported some non-directional sounds before we released (believe they were AI alert/combat vocals), but when we checked they were all encoded in mono. It's probably worth doublechecking, but might be some other weird thing going on.

Yeah, that makes sense to me as well. Maybe what looks bad is the empty list of things to buy on the right side? Would it be better if we just hid the right-side list in the event of no shop, or put up some GUI image of a closed shop?

I had this problem also in both Return to the City and Business as Usual. I set expert at the start, then a little into the mission I checked my objectives and they had gone back to hard or possibly easy. I read somewhere that doing a non-quicksave save before checking objectives would fix it, but that didn't seem to work either. Apparently it also broke the final objective of the map in Business as Usual, but not RTTTC.

Does it matter what resolution/graphical options you have selected, or does the demo set its own when it runs?

timeDemo ran through the demo at a fast-forwarded speed (15 sec total), not sure if that's what it was supposed to do. But it did report results: Avg FPS: 197.8 Hardware: CPU: Intel i7 920 GFX: 2x Radeon HD4870 512 MB, Crossfire RAM: 6 GB OS: Win7 64 bit [EDIT: Graphical settings for this run were:] Resolution: 1920x1200 Vsync: off AA: off Anisotropy: 8x Ambient: Standard Interaction: High Quality (Don't ask me how the settings got this way, they're not what I thought I had set ) I had Catalyst AI on, and the skybox in the demo was even crazier than what it usually does (display sky with spinning). It just displayed a bizzare reflection of whatever was on the screen in the sky, no sky to speak of. Might get better results with Catalyst AI off, but I have to go to sleep for now.