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 it blocked the switch from getting frobed from side B.

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 the target of a trigger.

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. I notice that Dragofer just released a mission today. I hope I'm not violating an unwritten protocol by releasing another mission on the same day. Download The mission is available in the in-game downloader. As well as here: https://www.dropbox.com/s/jah5svj5eagnhs8/heartstmattis.pk4?dl=1. (<-- NEW LINK. Per grayman's request, the name of the pk4 and map have been changed). Place the PK4 in your \fms folder. TDM will recognize it as a new mission. I18n I have not done the work required for internationalization. OpenAL EFX This mission uses it (version 2), so I recommend turning it on in the Audio Settings. Thanks Many thanks to the beta testers, who really helped me get this mission into shape: Cambridge Spy, Shadow, Jedi_Wannabe (who also did some performance work on the map), SuaveSteve Thanks to Mike and Chloe for their outstanding voice work! The cathedral in this mission was inspired in many ways by bikerdude's excellent St. Albans Cathedral. I haven't played all of the DM missions, but to me St. Albans is the gold standard of cathedrals. Music includes Cantus Firmus Monks by Doug Maxwell/Media Right Productions (royalty free) The video series by Springheel and Sotha were helpful and energizing. Thanks to the entire Dark Mod community for building an amazing project. Hints and Tips (warning: contains progressive spoilers)

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 the location of the emitter. Not just the flames, but cast light. Here's what it looks like. Light from the light_center shouldn't reach that wall.

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_showlightcount dropped by one as well. So, partial success. But this 'fix' did not work for other interior rooms.

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 visportals (or anywhere else). If I isolate the interior room, so that there are no other light sources, then the problem goes away. That is, even when the outdoor light is lit, it doesn't contribute to shadowcasting/lightcount, but only if the indoor room blocks all other light sources. I tried setting the outdoor light to noshadows, and that reduced the shadowcasting counts, but you could see the light through the walls (in the interior), which I guess is expected? I've spent a lot of time trying to figure this out. I'm ready to release the mission - it is playable, but there may be performance issues in this room for certain hardware. It would be nice to resolve this, but unless someone has a brainstorm...

I'm about to release a new mission, but I've got a performance issue that I'd like to resolve. I've got a building with a torch light on the outside wall. The light is causing performance issues inside the building, even though the wall blocks the light from getting inside. On the interior surfaces, the shadowcasting calls ('shdw' when doing r_showprimitives) are high. If I extinguish the outdoor light, the shdw count drops way down, and "r_showlightcount 1" drops by one too (on the interior surfaces). Any ideas on how the light is getting through? It doesn't show as light - the walls (brushes) are blocking the light. But somehow the engine thinks the light is there. There's another building with the same kind of light on the outside wall, and it all works fine. I keep experimenting with the walls, but so far I can't figure out what the issue is. Does anyone have any suggestions?