Ishtvan

Whoops, I thought timescale was common knowledge for slow motion. I just never thought to use it to watch things in fast-forward before.

That's some exciting "shooting stationary AI who do not fire back" and "jumping puzzle" gameplay there.

There are some things like the spyglass that seem hard-coded to set the FOV back to 90 when they zoom out. Possibly the bow as well. We have to fix that to read from the cvar I guess. Not sure why frobbing would do it.

I set off several mines at once and it was REALLY loud. Are we sure D3's volume clamp actually works, or can people blow out their speakers with lots of mines and fire arrows?

Yes, I'm sure you could also use this effect to make the most boring FM ever where you have to search through a lot of security camera footage of a crime trying to figure out what happened. EDIT: I agree it could be used to good effect in cinematics. For example, you could do all your 2002-era-movie slow motion rotating around effects , and it might be cool to show a cinematic at mission start that is basicaly a time-lapse of the city area you're going to be sneaking through in the daytime, with people moving around and a shadow casting sun that sets and a sky that changes color as day turns to night. Then when the mission started you'd kill the sun and people so that performance was normal. Or you could do all that on a high end system and save it to a video briefing instead of an ingame cinematic, if performance during the cinematic was an issue was an issue. Although if the frames are already time-lapse scenes, I'm not sure if low fps would be an issue. Unless it is really low like spf instead of fps.

I have a relatively small task for programmers who want to try their hand at working with our source. Many players have requested a way to fine-control door opening, so that they can choose to open them slowly just a crack, or fling them open quickly. I roughly implemented a system for doing this where you hold down frob on a door and move the mouse up/down to move the door away/towards you. This is activated by a developer console variable. But it still has bugs and is not fully integrated into the existing door code (for example, it needs to handle the door closing or opening fully, needs to know it can't open locked doors, etc). I don't have time to polish this up myself, but if an outside programmer wants to help out in some way but doesn't know what they can help with, this might be a good task.

I stumbled on this while watching some AI patrols in test maps. Say you want to watch an AI ingame to make sure they patrol correctly, don't get stuck up on things, etc. You can set yourself notarget and noclip and hover around somewhere, watching. If you watch this in normal time, it can take a long time to watch the AI's entire patrol. Instead, you can effectively set up time compression by opening up the console and typing timescale <number greater than one>. For example: timescale 2.0 This is like watching a fast-forwarded recording of the AI, and saves you some time. DISCLAIMERS: -If you turn it up too high, AI might start suffering g-force damage and physics might get strange, because in some places, I think Id hard-coded the frame time-step as 1/60 seconds, ignoring the timescale variable. If the actual frame time step is larger, causing animations to move them farther, but the hard-code says this occurred over a normal time step, they'll think they have a higher velocity than they really do. I could be wrong, though. -You can nominally set it back to normal time by setting timescale 1.0, but this never feels quite right to me. I think there might be a bug where timescale 1.0 is actually slightly too fast or something, so I usually restart Doom3 when I'm done playing with time and want to be absolutely sure I'm back in normal-time. FUN FACTS: -You can look at things in slow motion by setting timescale less than 1.0. Try watching a fire arrow blow up a breakable window in slow motion. It's pretty sweet! -You can also use g_stoptime 1 and 0 to stop and start time, and you can walk around and look at stuff while it's stopped. I bound this to a key when developing, and find it really useful. Don't forget to start time up again when you switch maps, though, otherwise the screen will stay black due to the timed fade-in, and you'll wonder what's going on until you remember that you stopped time and it always fades in from black when you load a map. If this is useful, we can add it to wiki. As usual, I'm not sure where to put it.

Someone also makes copies of that tapestry and sells them. I've seen them in peoples' houses.

I thought we discussed this once before and the D3 pk4 handler (not our mission installer that just copies the pk4 to the right directory but does not expand it) couldn't handle 7zip, and we didn't want to force everyone to download it?

Sweet, thanks.

I believe it is here, and is a lwo: models/darkmod/nautical/boat2.lwo There's a moveable version of it, boat2_mov.lwo, but I don't think we want that one because it has the moveable collision mesh in it, and we want the visible model only for md5 export.

When I look at the skeleton, we don't seem to have any joints higher up towards the head than Spine2, which is about at the small of the back. Is that correct? This leads to slightly funny AI ragdoll behavior, because instead of the head rotating around the neck, everything above Spine2 rotates about Spine2, and you end up with AI sort of bending their chests out when you grab them by the head, instead of pivoting the head around the neck. This is not a major issue, and it's probably too late to change anything skeleton-wise now, but I'm just curious if it's true that we don't have any neck-joints higher than Spine2? What joint do AI use to turn their heads?

Did we (the team) fix the mod-wide issue that was causing the objectives bug in our latest SVN build? I'm worried it might not be fixed, because I played it yesterday and still got the bug. Or maybe it requires both that mod-wide fix and a map fix?

Hmm, AFs might be a little worse at moving with something on top them than moveables are, it's hard to tell. It might or might not be a fixable problem. We have done some fixes to rigid body physics over the years, it's possible there was a fix that AF physics missed out on that maybe we could replicate.

The issue of getting blocked by objects on top of them is actually a physics-wide issue with one object stacked on top of another. It applies to simple stacked moveables as well, if you grab the bottom one, and the top thing is heavy enough. I don't think this performs any worse than any other objects stacked together. I'm pretty sure it will still be able to push two objects in series, it's just Movers that have trouble with that. But I can doublecheck.

And for reference, the smaller box: articulatedFigure env_bucket { settings { model "phys_bucket" skin "" friction 0.0099999998, 0.0099999998, 0.3, 0.5 suspendSpeed 15, 20, 10, 10 noMoveTime 10 noMoveTranslation 5 noMoveRotation 5 minMoveTime -1 maxMoveTime -1 totalMass 10 contents solid clipMask solid, corpse, body selfCollision 0 } body "bucket" { joint "origin" mod orientation model box( ( -9, -9, 0 ), ( 9, 9, 4 ) ) origin ( 0, 0, 0 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" containedJoints "*origin" } body "test1" { joint "origin" // large box: model box( ( -9, -3, -5 ), ( 9, 1, 20 ) ) origin ( 0, -10, 6 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" } body "test2" { joint "origin" model box( ( -9, -1, -5 ), ( 9, 3, 20 ) ) origin ( 0, 10, 6 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" } body "test3" { joint "origin" model box( ( -3, -9, -5 ), ( 1, 9, 20 ) ) origin ( -10, 0, 6 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" } body "test4" { joint "origin" model box( ( -1, -9, -5 ), ( 3, 9, 20 ) ) origin ( 10, 0, 6 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" } fixed "fixed1" { body1 "test1" body2 "bucket" } fixed "fixed2" { body1 "test2" body2 "bucket" } fixed "fixed3" { body1 "test3" body2 "bucket" } fixed "fixed4" { body1 "test4" body2 "bucket" } }

Success! I started with one of our simplest AFs, the bucket, with two joints. I then threw out what was there and then added a CM for each of the 5 sides, made the bottom face the parent and gave the other 4 sides a fixed constraint to the bottom. It seems to work, and it seems like only one joint was required in the MD5, the origin joint. D3 spits out warnings if you only use one joint for multiple AF-CM definitions "this body already includes this joint," but it doesn't seem to do anything bad. First I made a small box, then I made a big box that the player can jump into (shown here). It works, in that you now have a moveable object with 5 sides and a space inside. You can put other objects inside it, flip it over and put it on your head, whatever. When I tried picking it up with other objects inside, it did seem to get stuck on the inner objects, but I think that might be because I set the mass of it low compared to what I had inside. I'll try giving it a higher mass and repeating that experiment. As you can see in the image, the bounds (blue box) were weird, and this led to some rendering issues. I believe one can fix the bounds by text-editing the bounds info in the af_pose animation. Now the question is, what are the minimum modeling steps required to achieve this? We need an MD5 mesh and a single-frame animation (with one joint). Suppose we only need one joint, "origin" in the MD5 mesh. That greatly simplifies the weighting, right? Does that mean you just export the model to MD5 and you're done? As for the af_pose single-frame animation, since we only have one joint, we could probably just create that in a text editor (copy/pasting an existing af_pose animation as a reference, or we could make a template). And the real reason behind my "conspiracy" : Could a modeler please export an MD5 mesh of the rowboat model? It can have just one joint at the model origin. Then I can build a 5-sided box for it, see if it floats, and if I can adapt the existing vehicle code to give it a push when the player is riding inside. For reference, here is the modified bucket AF file that makes the 5-sided box: articulatedFigure env_bucket { settings { model "phys_bucket" skin "" friction 0.0099999998, 0.0099999998, 0.3, 0.5 suspendSpeed 15, 20, 10, 10 noMoveTime 10 noMoveTranslation 5 noMoveRotation 5 minMoveTime -1 maxMoveTime -1 totalMass 10 contents solid clipMask solid, corpse, body selfCollision 0 } body "bucket" { joint "origin" mod orientation model box( ( -50, -50, 0 ), ( 50, 50, 4 ) ) origin ( 0, 0, 0 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" containedJoints "*origin" } body "test1" { joint "origin" // large box: model box( ( -50, -3, -5 ), ( 50, 1, 20 ) ) origin ( 0, -49, 6 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" } body "test2" { joint "origin" model box( ( -50, -1, -5 ), ( 50, 3, 20 ) ) origin ( 0, 49, 6 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" } body "test3" { joint "origin" model box( ( -3, -50, -5 ), ( 1, 50, 20 ) ) origin ( -49, 0, 6 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" } body "test4" { joint "origin" model box( ( -1, -50, -5 ), ( 3, 50, 20 ) ) origin ( 49, 0, 6 ) density 0.05 friction 0.0099999998, 0.0099999998, 0.4 selfCollision 0 // containedJoints "*origin -*hand" } fixed "fixed1" { body1 "test1" body2 "bucket" } fixed "fixed2" { body1 "test2" body2 "bucket" } fixed "fixed3" { body1 "test3" body2 "bucket" } fixed "fixed4" { body1 "test4" body2 "bucket" } }

Exactly. The fire arrow: Anti-personnel incendiary weapon, or utility for lighting hard-to-reach torches? Both! It does it all. Purchase one today from the Inventor's Guild representative in your neighborhood market!

Yes, the md5 mesh itself does not have to be solid. You are adding all the solid parts in the AF file, by combining multiple convex CMs into a concave whole, like Tels said. Our AI also work this way when unconscious. The mesh itself is not solid, but the physics is being approximated by the CMs defined in the AF file. (You can see this with g_showcollisionmodels on, or af_showbodies). I don't think the MD5 mesh needs more than one bone/joint, since you could go into the AF file and define multiple AF bodies relative to the same bone/joint, just with different offsets. (I think, have to confirm that). All the MD5 mesh needs to do is render the model correctly. I'm not sure how much weighting is involved in that? I can use our exisitng AI meshes as a test for now, I can just pick a single bone and try to build up a 5-sided box around that in the AF file, and see what happens. EDIT: There might be some weird effects if the md5mesh does have multiple joints and you have some joints not assigned to any AF body in the AF file.

I would like to document something, but I need some help to research it farther: As you may know, traditional D3 moveable entities have restrictions on their collision model, one of which is that they can't be concave, such as a bucket, or a crate that's open at the top. Traditionally you have to make these things static, if you want the concave shape to be modeled physically. There is a trick to get around this, and have something that is both moveable and concave, (e.g., a moveable box you can put things in): Use a ragdoll entity. Suppose you want a moveable box with no top: 1. Make it a ragdoll entity (this requires that it use an MD5Mesh for its model, more on that below) 2. In the AF file for it, set up the collision models (called "bodies" in the AF files) for all 5 faces you want to be solid (bottom and the sides) 3. Finally, add "fixed" constraints linking all of the sides together rigidly, since you don't want them to flop around (I'm not sure this last step is actually necessary. If you have no constraints, it might just assume a fixed constraint with the origin body. Will check that now.) EDIT: It is definitely necessary, otherwise they collapse into a bizzare heap. Which is not useful unless you are creating "crazy jellyfish-man." You should then have a moveable box that you can put things in. Frobbing it and carrying it around will work a little differently, because in the current Grabber code, you cannot rotate ragdolls (usually, grabbing a body by the arm and trying to twist it off doesn't work very well). I could modify this to let you rotate about the origin body if a special spawnarg is present. Remaining Questions (for modelers?): Now you may have noticed the hard part: A ragdoll entity needs an MD5 mesh, and they need that single-frame animation, af_pose, just like our AI have. I'm trying to figure out the simplest way to do this, for this application. Do any modelers know the simplest way to take an existing model and make an MD5 mesh out of it? I think there is an export script for Blender? What about weighting, and making that single frame of animation? Since it's not actually going to be animated, is there any shortcut, like copy/pasting coordinates from the mesh into the md5 animatin file?

That ragdoll hand issue sounds like an old skeleton / new skeleton difference. The nobleman may need the ragdoll var changed to whichever skeleton it actually uses.

That was the case in all the Thief OMs, T2X (replace male with female), probably 90% of FMs. Are those all badly designed? Beyond that, how can someone tell a good story with a completely gender-neutral protagonist? I have read novels where the main character is female, and those where they are male. A main characer that's a different gender from me is not nearly so disturbing as a main character so poorly defined that they don't even have a gender. In an ideal world, we would have vocals for both male and female parts, and let the player choose. If we can't have that, then I trust the author of the story to pick a gender and record vocals for that, to tell a good story with their player-character. That is better than playing a completely mute character. Besides, our player grunts are decidedly male. We would have to have to provide an option to silence all those (and lose all that feedback) for your gender-neutral protagonist as well.

Yeah, having them be optional would also complicate beta testing. If the author wanted to put some puzzle-hints in the form of player vocals, they would have to have people test both with and without the hints, to see if they could figure out the puzzles. Letting the author fully control what vocals to play sounds reasonable to me. If their player character is female, they can choose not to put in player vocals, or add their own female ones.

You can also try using the mantle key if you get stuck and there is something nearby to mantle on.

Also keep in mind that when you make patch floors, AI need help navigating them in the form of extra monsterclip brushes.