Dragofer

Thanks grayman, you're not the only one who has wanted this kind of functionality.

Ah, then a color fade script should work on that. Thanks Destined for sharing that, though what I actually meant was how to point to a def_attached entity in a script command or S/R window. Something like $guard(key).trigger(); for example?

@STRUNK the tile trap's mechanism is that the tile starts the map slightly above the ground with its physics disabled (nodrop is set to 1). As soon as anything touches the tile, its physics get enabled and it drops to the ground, where it comes close enough to an invisible entity to trigger a stim/response effect. Setting the colour on a lamp model should only affect the model, but not any lights that have been attached to it via def_attach. The model should only be affected if it has a colorme texture on it (recolourable), though IIRC the only actually working way to change the colour of a model is to use a colorFade script command (see Down by the Riverside for examples). Btw, I've always wondered how to target a def_attached entity in this game - anyone know the syntax for this? For the fire arrow effect you described you'd have to add a response to fire stims on the target that gets hit by the arrow, with an effect to turn the light off.

IIRC there's a spawnarg relating to boundaries of fog. I don't remember how it goes, though, and whether it achieves what you're looking for. Another idea is to adapt a script fragment from Obsttorte to fade the fog's density over time as the player changes between locations. But it doesn't seem like fog entities respond to their shaderParm3 getting changed, unfortunately, so this wouldn't work. Had a test map where I just flat out called $fog.setShaderParm(3,10000); on a dense foglight. void fade_fog(entity location_name) //reduces the density of a foglight with the name 'fog' by increasing shaderParm3 when entering a location with the name 'location_name' { float i; for (i=0;i<100;i++) //for the next 100 frames (i = iteration)... { $fog.setShaderParm(3,1000+(i*10)); //add 10 to shaderParm3, from a starting value of 1000 sys.waitFrame(); //repeat next frame } } //this is a start - would require variants to increase & reduce density and be called by moving to specific locations

The tricky part is that he wants both the ship and the world to be playable space. What he's settled for is to move the ship's interior to another part of the map and delete all exterior AIs so that the whole exterior can be made into a moving entity. Teleportation takes place when entering transition zones around the entrances to the ship interior. Though personally I'd have used Skyrim-style doors that open just a crack before fade out & teleporting, because it'd seem a lot of trouble to get a correct representation of a constantly changing scenery beyond the transition zones to avoid jarring visuals when the player is teleported.

You'd need to trigger the speaker once for every time it should ring, don't think there's a way to make a speaker loop for a limited number of times. The sound file is almost 5.5s long, so you'd need to wait at least 5.5s between each trigger. One way to get that timing is to make a trigger_timer and a trigger_count. Give the trigger_timer the spawnarg "wait" "6" and target both speaker and trigger_count. Give the trigger_count the spawnarg "count" "3" and target back to the trigger_timer. To start the ringing trigger the trigger_timer, after 3 rings the trigger_timer will be stopped by the trigger_count.

Lamp entities and particle lights (i.e. light_oilflame) can toggle hide on targeted models if the models have "hide" "1" enabled. One light targets one model: as one light is off, one model will remain hidden at map start. Could try my above suggestion of giving your plain lights a scriptobject, otherwise maybe reconfigure a light_oilflame entity to act like an electric light (= no particle model, no extinguish sound, all stim/response disabled).

@Amadeus as far as I can tell TDM doesn't do skin toggles on models via simple/electric light entities, only if the light entity is one of those with a particle, scriptobjects etc. Well, maybe you can get a simple light entity to exhibit that behaviour by giving it the spawnarg "scriptobject" "light_ext". Then target the lamp model from one of the lights and give the lamp model skin_lit and skin_extinguished spawnargs. @STRUNK there's a script function and a stim/response effect to change spawnargs - setkeyval - but, from what I know, changing spawnargs ingame rarely does anything because they're read at map start (when everything spawns). There are some exceptions, for example adding a target to an AI will get it to start patrolling if it didn't have a patrol previously. Changing spawnargs ingame can also be handy for scripting, as scripts can read spawnargs and respond according to what the spawnarg is at that moment.

It's possible to let the skybox camera follow the player's movement , so that it flies in a miniature representation of your map and its boundaries in your skybox. This way the trees won't rise with the player when climbing the tower, and the player would be able to climb up and look out over the tree canopies (advisable to use fog to limit the amount of trees visible). Also, you can get the trees to look quite near by placing them closer to the centre of the skybox. Grayman is the expert with this kind of skybox, he's used them in Home Again. Might also be worthwhile to look at Exhumed's Skybox, because it contains a landscape that's contiguous with the play area. An issue I had with this kind of skybox is that you can come close to the ceiling of stars. Binding the stars to the camera to keep a fixed distance isn't suitable because the stars will rotate with the player. This remains an open question for me - only way I see is to use a repeating script to move the ceiling to a fixed vertical distance from the camera. If you want to make textures from screenshots you can use F12 to save a .jpg of your screen, saved in darkmod/screenshots. After that you can with the help of the wiki convert it into a TDM texture (you only need to make a diffusemap for this kind of texture). You'll need GIMP and a plugin for it that can export to .dds. Edit: what is it with this new forum's autoformat........ quotes, urls, formating, pictures all screwy

@STRUNKit sure is easy, that's how I did it in Down by the Riverside, if you need an example. I haven't merged the vegetation into a single model there though because that DR feature didn't exist yet. @Amadeusnot at all, it was just a trick I used to turn the vegetation in the skybox into black silhouettes. When the skybox was still lit up the vegetation looked very off in my opinion, you could see all the details and all the colours even though it was night. @duzenko as a mapper you can do it by slightly translating the textures on the various brushes so they're no longer aligned with each other, or making some of the brushes a little thicker or thinner than their neighbours. Preventing brush merges is necessary for very large areas because gigantic single-piece brushes tend to delay dmap massively.

@STRUNK a skybox is just a map area in miniature (1/16th scale) with a camera in the middle. You can take one of the existing skyboxes and add a forest floor as well as downscaled trees and bushes. My suggestion in this case would be to give the vegetation models the spawnarg "rotation" "0.0625 0 0 0 0.0625 0 0 0 0.0625", this is the so-called rotation hack that'll reduce their scale to 1/16th (0.0625) in all 3 dimensions (normally you'd use the model scaler but in this case I'd imagine it to be less cumbersome). Another suggestion is to place the forest skybox outside of your ambient light so that the vegetation is dark like in Down by the Riverside or Vitalic Fever. When you're happy with your skybox you can export all the vegetation as a single model to save drawcalls.

@STRUNKI'm a mapper first and foremost who's literate in Blender, which I'd say has made my life easier. Not only because some modelling steps (i.e. punching a hole in a cylinder for a door, working with mirrored meshes, or modelling by tracing a reference picture) are considerably easier in Blender, but also because I'm able to modify existing models to fit my map. Blender also offers more advanced features, like a proper UV tool for custom model textures and baking from high-poly meshes, so that you can make 'real' models. However, I found that kind of work to be time consuming and distracting from my actual mapping (at one point I was so busy modelling for my maps that I was given the 'Modeller' title in the forum), so in my experience I'd advise a mapper to stick to 'simpler' modeling that just reuses existing textures. You don't need Blender for that kind of modeling - DR can in most cases get similar results, just that DR would usually be more time consuming. You can make fairly elaborate stuff in DR: ERH+ has made multiple gigantic highly detailed submarines, while I've made carriages and ships entirely out of brushes and patches. I think a good basic level of Blender skill to aim for as a mapper would be to make a wheel from scratch and get it ingame. That'd put you in a position where you've got a feeling for the various ways to manipulate vertices and can make or modify models on that basis. Blender is typically considered difficult to learn, but I found it was alright when I focused on it for a week or two, watching tutorials and noting down all hotkey combinations I come across. What I used personally to get a foothold in Blender was this very generic teacup tutorial (don't need the renderer stuff at the end), then numerous short videos on various aspects as I needed them (how to mirror, how to set a reference picture as background, how to restrict editing to an axis, how to change the origin etc.). One video I remember quite well was this sword timelapse, showing how you can draw irregular shapes by hand - that possibility really got me motivated to learn more about Blender.

@Amadeusthat looks packed full of things to explore, great work! Did you make that glass/wood display case in the shop yourself?

That's one way, another way is to hit tab to cycle through the individual brushes and patches. A 3rd method to handle it is to group them instead of converting to a func_static. This way they can be modified but are still selected together. When you've reached the final shape you can convert to func_static.

@Spooks I'm glad to see you say that it's worked out for me to capture that mood. @Bienie Didn't think I'd ever see someone call this ship spacious, especially with this much cargo lying around. Well, I did spend quite some time with the clipper and vertex drag tools to get every last bit of internal space. And yep, no knockouts is my preferred style too for the challenge it brings. @Melanthere's still plenty of Wrecker's Reach left, and it's a place I'd like to see more of. My aim with this one was to make a more focused adventure, based around my new ship asset, that could be released within a moderate timeframe. Also my first city mission and adopted map, so I was looking to make experiences with that. Let's see where things go from here.

Thanks guys for your kind words! @Kerry000regarding the aspect you wanted clarification on:

@Bienie start with writing down the names of your 2 levers + the machine as well as the coordinates of where the 2nd lever needs to be on the machine. Give the machine the spawnarg "frobable" "1" and then at the top of DR's window select Entity -> Stim/Response -> switch to Response tab -> add a response to frob -> right-click in the response effects box & click add, right-click edit the new effect, repeat for these 3 effects: 1) "teleport (set origin)" the second lever so that it ends up on the machine 2) "set frobable" "_SELF" and leave frobability unticked so that the machine is no longer frobable 3) "run script" "remove_lever" for this simple script to remove the first lever from the inventory (technically the above 2 steps could be in this script too, but just to show what S/R can do) void remove_lever() { $player1.replaceInvItem($lever,$null_entity); } To make this response only occur when the player has picked up the first lever, right-click on "frob" in the left of the machine's Response tab and deactivate it. Now use the above steps to give the first lever the effect "Activate Response" "Frob" on the machine.

Here are my thoughts on the 2 ideas: 1) A sultan's palace wouldn't be a problem from an architectural perspective. TDM has an incredibly large selection of stone and marble textures, and patches are very well suited for architectural details like arches and domes. The main problem may be the props: idk how convincing i.e. a sturdy wooden bed with linen bedsheets would look in the Orient. You'd also have to be creative with getting more diversity in the AIs because we only have 1 Moor, maybe by making tan skins for other AIs. 2) A desert temple is very feasible with TDM's assets (stone textures, rock models, zombie & skeleton AIs). Could look to Penny Dreadful 1 for inspiration, because this one already goes in the direction of an ancient temple.

Thanks krrg and Goldwell, I'm really glad to hear you enjoyed the mission as much as you did! Hehe, it looks like my missions have a tendency of playing out that way, even if it's not intentional.

Congrats! Having 2 FMs in one day is something I'm sure no one's bothered by, very much on the contrary in fact

There isn't much that draws an honest man to a place like Wrecker's Reach. Once a well-known port under a name no one remembers, it was a hub for lucrative trade in colonial wares and a warm shelter for those crossing the great oceans. Now it's just another stinking hole, like all the others I've been scratching out a living in. The ale is poor, a knife awaits you down every dark alley, and the rich folk have long since abandoned their crumbling residences to petty barons. Imagine my surprise, then, when I saw a grand merchant ship arriving in the dark of night. It's anyone's guess what brought it here, and more importantly what lies in its cargo hold, but I intend to be the first to find out. Not that this will be easy, though: a vessel like this will be sure to draw plenty of attention, and I've made something of a name for myself around here, so I'll have to be cautious the moment I step out into the open. Well then, it seems holing up at these wretched docks is finally paying off. Notes This is a standalone harbour mission set in Wrecker's Reach, taking a smaller section of a former Crucible campaign map as its starting point. My stated aim with this one was to create something a little simpler than what I did previously, with most of the weight on exploration and looting. Simply an unexpected nighttime excursion in a locale that hasn't been visited before. Changelog - v2.1 Changelog - v2 Download Google Drive Simply place the mission archive in your darkmod/fms folder and start TDM. The new mission will appear. Credits Beta testers - Amadeus, Cambridge Spy, lowenz, VanishedOne, Boiler's_hiss, acolyte6 Harbour building exteriors - bikerdude as part of the Crucible Campaign Team Editorial consulting - Amadeus Custom environmental ambients - AugustSandberg, jimsin, deku, kangaroovindaloo, all of Freesound, dario Custom wooden floor texture - judith <dr.judym81@gmail.com> Prescott Stahl's writings - Spooks Painting in splashscreen and briefing - John Atkinson Grimshaw Painting in briefing - Ivan Aivazovsky Boiling water sound - Kyyrma Improved animated flag - Arcturus Improved nautical models - Xendrox

@Boiler's_hiss@acolyte6 Sure, you're both welcome to try it out. I've uploaded a 2nd beta build of the mission earlier today.

Springheel is the only one here who has an explanation for that issue, that multiple nearby visportals on the same X/Y plane may start misbehaving.

Thanks Springheel, but that wasn't it. I've altered those visportals and their surroundings numerous times without any effect. In the end I just deleted them because they were only minor visportals. @Jedi_Wannabe an alternative explanation for void-showing doors is that your visportal surface (the pink-cream one) is slightly in front of the door instead of fully within. The door is still linked to the visportal, but the visportal's position gives you a view into the void. The solution remains the same as Springheel already described, to move the visportal surface a little (until it's inside the door).

Here’s my next mission, ready for beta testing. This one is a standalone city mission taking place at a harbour based on a section of a former Crucible campaign map. Any beta testers are welcome to go over to the beta testing section of this forum for the thread I opened there.