VanishedOne

Goldwell's is a skull; Aosys wanted to adapt it for something like a Weeping Angel. @Aosys Try replacing abs(angle_x); with 0;

Presumably, but since since grayman informed us of a better way, just dispense with player_skull and run this version: while(1) { vector playerPos = $player1.getEyePos(); vector thingPos = $thing.getOrigin(); vector diff = thingPos - playerPos; vector angle = sys.VecToAngles(diff); vector rotation = '0 270 0'; // adjust to suit angle_z = abs(angle_x); angle_x = 0; angle = anglemod360(angle + rotation); $thing.setAngles(angle); sys.waitFrame(); } (Still the unoptimised code; anyone wanting to optimise it should try removing the call to anglemod360(), since it's only there to make debug output easier to read.)

It's to replace the rotation spawnarg if $thing is facing away from the player in its natural orientation, since setAngles() appears to override the angles initially set (and rotation isn't a simple vector key). Edit: though with the assignment outside the loop, maybe getAngles() would also work. It's awkward in that what's wanted isn't rotation relative to the world as seen in DR, but a modifier to make $thing face the player.

Okay: place a func_static (here named "player_skull") over the player's start point, set "hide" "1" and "solid" "0" on it, and use this updated script: $player_skull.bindToJoint($player1,"Head",1); while(1) { vector playerPos = $player_skull.getWorldOrigin(); vector thingPos = $thing.getOrigin(); vector diff = thingPos - playerPos; vector angle = sys.VecToAngles(diff); vector rotation = '0 270 0'; //adjust to suit angle_z = abs(angle_x); angle_x = 0; angle = anglemod360(angle + rotation); $thing.setAngles(angle); sys.waitFrame(); } $thing will now look right at you (once player_skull is suitably positioned) even when you crouch. It's also possible to stand on it now, for the most part.

Okay, I think I've got rid of the weird tilt. (The mantling problem still exists, but if the player doesn't need to be able to touch it then the playerclip solution should work fine.) while(1) { vector playerPos = $player1.getOrigin(); vector thingPos = $thing.getOrigin(); vector diff = thingPos - playerPos; vector angle = sys.VecToAngles(diff); vector rotation = '0 270 0'; // adjust to suit angle_z = abs(angle_x); angle_x = 0; angle = anglemod360(angle + rotation); // anglemod probably isn't needed; I added it for more readable debug output $thing.setAngles(angle); sys.waitFrame(); } Edit: hmm, I notice the skull keeps looking upwards when I move near it and crouch. Maybe you could bind something to the player's head and use its origin instead of $player1's...? Edit2: no, still not right: if I put the skull up high, it still looks upwards instead of downwards when I move near. Edit3: I've added a call to abs() which I think solves this. However, it's hard to be certain because of the player-origin-versus-eyeline question. If I noclip and fly around the skull, it looks upwards when I'm above it, provided I'm high enough. Put it near my eyeline and walk up to it, and it looks downwards.

Yes, it seems a 2D pivot will work if you add a line that resets angle_x to 0 before calling setAngles(). (However, you'll still get flung about if you jump onto $thing.)

I wonder whether the problem is just that the player's viewpoint/eyeline is higher than the player's origin... Edit: no, that wouldn't account for a sideways twist. Maybe it's a problem of rotation around the world's axis versus $thing's own axis?

I expect setAngles() overrides the rotation spawnarg. while(1) { vector playerPos = $player1.getOrigin(); vector thingPos = $thing.getOrigin(); vector diff = thingPos - playerPos; vector angle = sys.VecToAngles(diff); vector rotation = '0 270 0'; // adjust to suit angle = angle + rotation; $thing.setAngles(angle); sys.waitFrame(); } Edit: hmm, it does seem to turn on its side when I get close. Jumping increases the effect, so it must be because of the relative heights of our origins, and the script making $thing turn to face me in all three axes. Jumping on top of it is like a bucking bronco.

It's inside my map script's main(); I didn't know where you'd want to deploy it so I omitted that.

You can get the player's f.o.v. and view angles in a script; presumably the simplest option would be to get the angle, imagine lines going left and right of it at 90° and assume the player can't see anything behind those lines.

I've got a func_static model to do what you want, but the moveable I tested on falls through the floor and flops around... Here's the script I used: while(1) { vector playerPos = $player1.getOrigin(); vector thingPos = $thing.getOrigin(); vector diff = thingPos - playerPos; $thing.setAngles(sys.VecToAngles(diff)); sys.waitFrame(); } Edit: if the crow you mentioned was an AI, it probably used faceEntity() or similar: only available for AI, according to the script docs. Edit 2: maybe you could bind a func_static to an invisible moveable and make them frob peers? I suspect that trying to set the angles of the moveable itself is making its collision model clip through surfaces, and there's no rotateTo() for moveables. The bound func_static would probably either have to levitate or clip into things sometimes, though.

If it's a flat surface you could use deform sprite. For anything else I think a script would be needed.

For e.g. having an AI kneel before an altar it would be nice to have start and stop kneeling animations, which could be used with replace_anim_* and the sitting behaviour; the kneel_down animations have a fixed duration between kneeling and rising, and I think the same is true of Sotha's prayer animation.

The other link I dug up suggests the namespace needs to be declared explicitly if you want one. https://www.iddevnet.com/doom3/script_map.php seems to bear that out... http://modsonline.com/Tutorials-read-173.html suggests that namespaces are an alternative way of setting up a map script, if you want an arbitrary location for its file.

When I said 'see frob_action_script', I meant look for a snippet about namespaces; if I'd thought more clearly I'd simply have quoted it: Or maybe the bag could have a script object and maintain the counter itself? Edit: actually, that might not even need another script object; maybe just storing the counter in the bag's spawnargs would do, and the potion script object could call $bag.getIntKey("counter") and so forth.

It doesn't seem to be well documented, but I've seen mentions of map namespaces floating around: see http://forums.thedarkmod.com/topic/4946-script-editor-gui-thingy/page-2?do=findComment&comment=92086 and frob_action_script under http://wiki.thedarkmod.com/index.php?title=Frobbing#Entity_Settings Maybe that's how you're meant to reference map script variables...?

This link is dead; does anyone by any chance have a copy s/he could upload somewhere?

Just a note after looking through your materials: there are quite a lot that have an extraneous surftype15 line, usually extraneous because the same material declares a metal surface type outside the description. I don't know whether that causes any bugs when your descriptions don't actually declare one of these, but I suggest removing those lines when you next update, if only to make your intentions clearer. The models look great.

Not yet. It's a known bug.

Technically, most of the food in TDM is made of cloth.

I suppose the nearest thing to a lightmap currently is lights/shadows/shadow_canopy6, but I can't really call that 'recommended', just something to look at while experimenting.

I've known DR to fail to load assets sometimes, but then restarting generally fixes that.

Interesting effect. I hope it doesn't end up needing 'epilepsy warning!' notices.

Speed potion: http://forums.thedarkmod.com/topic/17367-custom-items/ Don't try to make an item that alters player movement via the console commands; my first prototype speed potion did that, and it killed me. http://wiki.thedarkmod.com/index.php?title=List_of_shaderParm_variables

Really? https://www.iddevnet.com/doom3/bumpmaps.php just says of heightmaps that they 'must be converted to normal maps at load time'. A search produces various old threads talking about parallax mapping mods for D3 and their desirability for TDM; was any of that implemented?