Dragofer

This is true, that's what this one was designed to be. My thought was that several of its stylistic elements may be suitable for our own concept, such as the colour scheme, the smokestacks, the use of cylindrical structures. Perhaps we'd even get fairly close to a usable design if we took out the middle segment of the bot and thought up a new design for the legs.

Well, if you're content to basically make TDM missions, but with different assets and more puzzles then I don't see much of a problem for someone who's a lay-person in programming. There's plenty of documentation available on our wiki on how to go about implementing the various kinds of custom assets, and we have easy to learn visual interfaces for achieving scripting effects (such as stim/response and premade script entities). The aforementioned interfaces are, however, designed for use in normal TDM missions, so if you want out-of-the-box effects you'd most likely need to get some programming training in order to supplement the existing systems with real coding where necessary. This applies especially if you want to modify the behaviour of AIs.

How about this kind of optic for our steambots? Steam Walker by Keithwormwood

Sure, using S/R is usually not as complex as the A-Z makes it seem, which teaches a more unusual usage case than what you normally need. Here's a test map, stepping onto the platform's trigger gives the lantern a lit skin, frobbing the crate gives it an unlit skin. For recreating the crate setup (takes 10s when you've done it a few times): 1) Make the crate frobable 1, note down the name of the lantern and its skins. 2) With the crate selected open the S/R interface and go to the Response tab 3) Use the bottom left to add a response towards frobbing 4) Right-click in the right table to add a new effect, then right-click edit that effect. Choose 'set skin', type in the lantern's and skin's name. For the trigger response setup it's virtually the same, just that the S/R gets edited on the lamp itself because this is the entity that receives the trigger in this setup. sr.map.txt

Could use a nodraw skin to make it invisible & nonsolid when that's needed. To trigger the skin change you could set up a trigger response on the rope via S/R to change the skin, then trigger via the multistate_position entity. The buttons to the lower floors could have a frob response to change the rope's skin back to visible again.

Excellent, that's just what I was looking for. Just replacing candle_01 with stormtable already comes very close.

Actually at a second glance it looks like can be interpreted as 'let the intensity follow the pattern of candle_01 at a speed of [time * 0.5]. If I knew what kind of asset 'candle_01' is, then it'd be possible to create new patterns for electrical flickering. Any ideas where it's found?

Alright, so this sounds like making a kind of lightgem calculation to find out how bright the exterior window should be. It's an interesting idea and I think it'd be especially useful for doors with windows in them, though for my usage a simpler solution can indeed be used because most of the time you can't see the light source and the exterior window simultaneously. In those cases where you do see both I can use a good light. I'm thinking now of just using a fast-acting fading script that's called at random intervals on certain windows, if nothing else.

Multiplying the speed by 3-5 looks fairly decent and I can work with that, but still it's constantly going up and down a sine curve. The ideal would be to make it blink off every now and then. Alright, I could think of a way to script it, but can it be done via a material?

In my mission I have a lot of flickering electric lights, but at the moment it somewhat stands out that the windows have a constant light intensity. They're lit up by those same electric lights from the interior, so they should be flickering in a similar way too. So far Ive found 2 methods for making something flicker: 1) adding 'rgb candle_01 [ time * .05 ]' to the material, such as in diamond_pattern02_flicker02. 2) making the _color intensity depend on the sound volume, which is what the electric lamps use. The problem with #1 is that it's more pulsating slowly than flickering, while #2 requires a sound to be played at an audible volume. Isn't there a better way to make a texture flicker in an electric kind of way?

I'm glad you enjoyed it! Regarding the writing, it's been enjoyable to adopt stylistic elements from the works of authors of earlier centuries because I find they fit really well to this genre, but I agree that writing like this is not ideal considering TDM's international community and that non-native speakers are normally used to modern English. This is a point I've taken on board for my future missions.

Normally it's enough to rotate every 2nd or 3rd pothole to conceal patterns in the grime, though the rectangular portholes may benefit from having a mirrored model variant because they can't be rotated as freely. I've left that step for later though because most of the work I'm doing now is on the interior, churning out modules for the different environments, so the exterior parts will undoubtedly be shuffled around to accommodate the new interior when the time comes. Speaking of interiors: making the soundscape for this is really being a blast, experimenting with layering all kinds of shorter local pieces on top of the base ambients.

Thanks very much Bikerdude - regarding the time period, I've really started to take a liking towards the pioneer ambience, replete with its paraffin lamps, whaling stations and rugged individualists. And this is what their ships looked like: straight hulls, steam-powered (this is what the new steam_engine_003 was for by the way) and ever more functional design. Maybe this era could be considered as the upper end of TDM's timescale? Also, personally I found it quite interesting to alternate between working on a 16th century ship like the merchantman on the previous page and a barque like this one. On the matter of lifeboats: they used to get stored on the deck itself. Later they moved to the rooves of deckhouses once ships started having those, and after that they were suspended off the sides. The advantage of the latter is that it saves a lot of space.

A mysterious ship, perhaps the grandest the world has seen, looms in the nightly mist. What could have brought it here to this frigid bay, of all places? Should one come to venture deep into its hull, this would be one of many sounds one would hear.

Just did some more detailed proof of concept testing with option A I mentioned earlier: having the pad suspended in a pool. I have to say, at face value it behaves just as one would expect. A big crate will push it down to the bottom, while a feather will just bounce off. A medium-sized object will only push it down if it was dropped from a height. And you can use a grabbed object like a pitchfork to push it down from afar. And it can be reused. Now to the difficult part: it works nicely when the pad is in a big open pool. But when I put the pad into a tight gap in the floor, one of two things happens: 1) the gap leaves too much space, allowing the pad to noticeably jiggle around endlessly. 2) the gap is too tight, either preventing the pad from moving (tried lowering friction) or causing it to explode into the air. With enough fiddling it may be possible to find a sweet spot where this will work. Well let's see how the nodrop concept works out.

Yes, it measures between origins - though you can also use the selection bounds instead. (Strange how my setup didn't work at first. I was changing one thing at a time, and only downsizing the brush solved it. Now it's back to 8x8 again and it still works.) The light responses are specific, yes. Lamps and 'lights' get toggled while flames use 'turn extinguishable light on/off'.

I suspect the stim wasn't able to reach the origin of the brush. Seems unlikely considering how small it is, but I vaguely remember a similar problem in 2014 with a custom lamp. Speaking of robust, I anticipate that sooner or later one of the pressure pads is going to fly off with great force due to a physics glitch. It might be better to use: 1) an invisible moveable pad textured with collision_stone that gets deleted as soon as it triggers the trap. 2) a visible non-moveable pad that translates down a little when the trap is triggered. More complex, yes, but it must be as robust as possible if it's an official trap.

I've made a small test map and also initially encountered problems with making it work. In the end I solved it by downsizing the nodraw brush down from 8x8 to 1x1. I've attached the result. The trap causes the guard to start walking. An observation I'd have to offer if you're new to S/R is that most of the time you only need the Response tab, i.e. 'When this is frobbed, do the following'. The Stim tab is for when you want to assign special properties to objects i.e. giving the 'flame' stim to a matchstick will make it ignite unlit flames. Thanks for the hint Biker, I've taken a look at Gatehouse's traps and far as I could tell they're all set off by a trigger_multiple brush. That's one option, but it's something Springheel already tried out. pad.map.txt

Hm, you might need to use stim/response to make a proximity trigger between two entities if the trigger_entity doesn't accept moveables. It'll still be possible to package as a prefab afterwards. The A-Z tutorial describes how to set this up using a scroll and chest as an example: A-Z. A real example can be found in Grayman's Home Again in the form of his audio sticks. I've done some testing for option A (having the pad float in "water"). The pad responds correctly to weight being put on it and can be modified in its sensitivity via the density spawning. But at map start the pad falls down to the bottom before slowly rising back up, so it should only become armed 20s after mapstart.

Supplying an idea: if the pad's origin comes closer than x units to an invisible entity underneath it, the trap will activate. The improvement in this is that you can use physics instead of a button or trigger brush to set the trap off. For making the pad move: Option A: Make invisible water in which the pad freely floats, I.e. like a floating crate. Option B: Make the pad a moveable with the nodrop (?) spawnarg. As soon as it's touched by anything at all it should drop. As for the projectile, Sotha recently published a properly shooting crossbow trap.

An idyllic small manor enclosed by a moat, a little more emphasis on the vertical dimension in the small space available. It'd be suitable as someone's first map.

Exciting, can't wait to see what we'll find in that safe

Great, that was just the reply I was looking for, I agree with your plan of releasing them as they're made. A dolmen, you say? That has quite some Stonehenge vibes, I can imagine that being ideal for rituals by bonfire or moonlight. It'll be quite a mysterious forest that's made with all these new nature assets the TDM community has seen in recent times.

I'm reminded again of how much fantastic work can be found in this thread. One can really get lost in the details of these last stone pieces, thanks very much for making it happen. (By the way, I've got a ship bringing home such a dolmen in its hold from a journey to a faraway land.) This is tantalising. That tree in the dolmen image alone is already brimming with potential (especially for bordering off open natural environments). This, together with Dram's recently submitted forest and rock assets, would have transformed Down by the Riverside and many other missions besides, had they only been released earlier.

If I'm reading this right this map no longer needs to be a part of the campaign? I can in some ways understand if you prefer the official campaign to be made entirely by the team, if that was the thought behind it, but regardless I think there should still be the option of continuing it as a campaign mission.