joebarnin

#1 - I found this in tdm_events.script: /** * Initiates a translation back and forth along the given vector with the given speed and phase. */ scriptEvent void bob(float speed, float phase, vector distance); So maybe that's a way to get things to bob or stop bobbing? I tried a few experiments but couldn't get it to work, but maybe you'll have better luck.

Here's something I did - maybe it'll work for you. Create a thin no draw brush (e.g., tdm_nodrawsolid_wood) that lays on top of the door (in front of it). Convert it to func_static. Set frobable=1. You may have to set frob_distance to a value too. This will 'catch' the frob and prevent the door from getting it. At least, that's what I think happens. Anyway, it worked for me. Specifically, I was having trouble with a user frobbing a switch from the other side of a wall. The switch was on side A of the way, but the player could frob it from side B. So I put the frobable brush on side B, and

Here's a possibility:

Thanks for your detailed comments - I'm glad you liked it. For the two items mentioned, the readables could be more explicit. Specifically, and As for that turns out to be

One of the things I struggle with is how hard to make things for the player. I wasn't sure about this mission; that's why I put the hints in right from the start. Still, I was hoping that the main objective could be done without hints. Just had an idea - the difficulty level could actually change the readables, so that the text in the books is more explicit at easier levels. For example, on the hardest level it reads but on the easiest level is reads Has that even been done? Funny thing is, as a player I'm not particularly bright and I usually need hints. ?

VanishedOne

krrg - thanks for you comments. D'oh! Good catch. If I ever do version 2, I'll fix that.

boylag,

Building on what VanishedOne wrote, there are a couple of ways to mark an objective as "invalid". It still shows up in the objectives list, but with a "crossed out" symbol in the checkbox. You can do it with script code: $player1.setObjectiveState( objNum, OBJ_INVALID ); where objNum is the objective number, e.g.: $player1.setObjectiveState( 8, OBJ_INVALID ); Or with an atdm:target_setobjective_state object with the following spawn args: "obj_id1" "8" "obj_state" "2" (once again, assuming the objective is number 8). Make the atdm:target_setobjective_state th

Jedi - Thanks again for your testing, especially highlighting the performance issues. Let me know how the released version performs inside the cathedral.

Excellent mission. Worth exploring to find all of the details. You've created a satisfying vignette of that location. I second Kerry000's comments, the atmosphere, sound, and details are superb. I love some of the little touches, like Thank you! Edit: forgot to mention, I loved .

Done. The new pk4 is up on Dropbox, and I changed the link in my original post. The pk4 is called 'heartstmattis' and files have been renamed to this as well (e.g., .map and .script files).

There are rumors that a legendary ruby, the Heart of Saint Mattis, actually exists. Break into the the Northgate Cathedral, find it, and steal it. Background This is my second Dark Mod mission (Mission of Mercy was the first). This is a small-medium mission, with some extras. See below for hints. My wife just gave me an idea for mission number three, so look for that next year.

Congratulations! Downloading now. When it rains, it pours: I'm about to release my mission too.

Thanks everyone for your ideas. I decided to avoid the problem, so I adjusted the lights at the front of the building so that they no longer cast onto the front wall. Works like a charm, shadowcast counts inside are down to reasonable numbers. “Problem avoided” rather than “problem solved”, but it was time to move on. I’ve save a copy of the map from before these changes, so I can always go back and try “one more” fix, if something comes to mind. Thanks again.

Good idea, but I just checked for this situation, and no luck. It was worth a shot.

I gave this a quick test, and I'm seeing strange behavior. I created a light_torchflame, and offset the light_center, similar to your diagram above. First, the particle emitter is at the origin, not the light_center. I suspect I can figure out how to fix that. Second, the light that is cast has a few issues. There is light at the light_center, broadcast to the 'left'. But it uses the 'biground_torchflicker' texture, so it doesn't quite look right. The wall doesn't get any light, and I guess that's what is intended, but that looks incorrect too. Finally, there appears to be light coming from th

Nope, Jedi, you are innocent ?. This problem has been there all along.

Shoot, forgot to try that. I'll give it a go now.

I spend a lot of time this weekend trying to do this, without success. I probably wasn't as systematic as I needed to be. It's a fairly complex area to redo. One thing I forgot to mention in my previous post: I did have some success in one interior room. The boundary between inside and outside consists of two walls, worldspawn brushes, each 8 units thick, adjacent to each other. As a test, I expanded one of the walls by two units, so that the two walls overlapped. E.g.: In one interior room, that effectively 'blocked' the outdoor light - the shadowcast count dropped, and the r_s

Springheel & peter_spy - Good idea. Today I checked to see if there were any internal leaks, and I didn't find any. I followed the technique described by Springheel in one of his videos. There were no obvious leaks. I've spent a lot of time trying to isolate the problem, but every time I think I get close, it gets more complicated. Here's what I can say for sure: The outdoor light contributes to the shadowcasting calls (and to the light count) of nearby interior rooms. Dousing the light brings the shadowcasting/lightcount down. As far as I can tell, there are no leaks in v