Dragofer

@Amadeus I can only recommend that as a mission idea, very fun to make.

Confirming that one's yellow, because it's being rendered ineffective by the open visportal next to it.

I've got a couple instances of strange visportal behaviour in my map: Staircase visportal becomes closed when too far away or viewed too directly. In the 2 shots I slightly turned my view, the defunct visportal is the one in the top right corner: Large square visportal inside a defect in the wall. It should always be open, but instead it acts as if it were closed. r_showportals 2 claims it's open when viewed from one side: I've excluded that there's anything intersecting with the visportals, and I don't use func_portals. If I extract these segments into a testmap they work normally. Any ideas what can make visportals go funky like this?

Just give the lamp the spawnarg "set light_radius on flame" with the desired light radius. It works this way for all entities that are def_attached, like a sword to an AI or a flame to a lamp. You can find what the original light_radius was by temporarily creating that entity in your map. In this case, "flame" is the name that's given to most lamps' def_attached entity via a name_attach spawnarg; some use "light" instead - look into inherited properties to find out which it is. A name_attach is always required if you want to set spawnargs on that entity.

@jaredmitchell you're welcome, and I think VanishedOne was thinking of something similar to this. Re monsterclip floors: the way it works is if you have a freefloating monsterclip platform AIs will sink down ~34 units as they walk across it. If there were a solid func_static surface (i.e. a grass patch) within 34 units above the monsterclip platform they'd instead walk over that. I'd do the vertical movement in the locks by having the ship make 2-3 small 'jumps' accompanied by a very brief fadeout (if the player's outside), with monsterclip at each stage. The horizontal movement from lock to lock could be done via the sequential AAS obstacle wall method described in my first post. An alternative is a cutscene, but can cause problems if it happens just as the player was making a dash across a brightly lit area.

Could look at the _selflit variants of window textures for examples of how to use that blend add stage.

A far easier option would be to show a short cutscene each time the ship moves and have a set of permanent monsterclip at each position of the ship's journey. The ship would spend most of its time in the water elevators anyway, and the water level doesn't really change perceptibly here. You'll need to combine this with the interior-exterior split described above.

It's not just the pathfinding, it's also the visportalling. I don't see any way to move the latter especially. There's possibly a way to make your idea work: I'm also making a ship mission, in which I've split the exterior from the interior and transfer the player between them via script. The great advantage of this is you can build your interior without being restricted by the exterior; a further advantage in your case is you can turn your ship exterior into a func_static. You have 2 options to transfer the player: A ) frobbing a door teleports the player. You may want to handle what happens if the player is being pursued by an AI (level 5 alert). The easiest solutions by far and away are to either make an objective not to get spotted by ship AIs, or to do nothing. Most people quickload anyway when they get spotted. B ) use rooms in which the teleport happens. It's very tricky to teleport AIs without disturbing their behaviour, so these rooms should be AI-free. I'd recommend option A therefore. That leaves the issue of pathfinding on the moving ship exterior. I've experimented with dynamic pathfinding while setting up my stagecoach and came to the conclusion you can only have dynamic walls, but not dynamic floors in pathfinding. On the horizontal plane this should be easy enough: you can use a very long (permanent) monsterclip brush for each deck as well as for the ship's sides (east-west). You can then then use AAS obstacle to limit north-south movement: depending on what works either bind it to the ship or toggle a series of AAS obstacle walls. The vertical plane is an issue, because to my knowledge you can't have dynamic floors. My suggestion here would be to use only archers on the ship exterior as they don't need to move between decks to attack the player. Archers will also come in handy when the ship is moving downwards, as they'll have to stand still in this phase. Edit: An issue that remains is how to move the AI forward while they're patrolling on the ship. You can't bind AIs to something, so in my stagecoach I've used a func_mover monsterclip brush to push the AIs forward (named stagecoach_pusher, see either mission in Down by the Riverside). You may need to use a script to continually update the position of such a brush behind each AI as they move around. I haven't tried if this works.

@Bienie You can append more nodes to a NURBS curve, like the one used in the spline, by using the curve-related buttons at the bottom of the left pane of DR's interface.

@Bienie to get the script to repeat you can insert a while(1){} so that your 2 mover5 lines are within the curly brackets. You'll need to add a 3rd line sys.waitFor($Mover5); so that the script doesn't try to repeat the script an infinite number of times per second ('runaway loop'). There's a finished example in Down by the Riverside's Invernesse map, look for wisps. If you want it to go back and forth you'd have to extend the spline path to retrace its path back to the starting point. Or duplicate your spline path, mirror it in all 3 axes and extend your script to use 2 spline paths.

I've used grayman's cutscenes tutorial, which includes a section on binding a camera to a spline to make it move. http://wiki.thedarkmod.com/index.php?title=Cutscenes_Part_2:_Splines_and_Camera_Movement If you're not that familiar with setting up scripts you can go one page back in his tutorial for instructions on that. This tutorial is actually what I used to get my first foothold in scripting. The script there, called roll5, has a few extra lines pertaining to the camera that you won't need, and acceleration/deceleration may also be inappropriate in your case.

You can create a curve path (spline) and copy paste a simple script to make an object move along it. It can go through walls, and you can bind a speaker, light, particle or anything else to it. If you want it to pause movement now and then (like a path_wait) you can use several successive splines with a delay inbetween. Regarding AI pathing, you can use an aas flood entity to instruct dmap to create pathfinding for an area if there are no AIs of that type present there at map start. Humanoids need aas32, rats need aas_rat etc

Haha, I hadn't thought of them like that before. The set could actually be expanded in both directions if unfinished ships are counted: on one side a 1-man sailing boat featuring everything needed for a longer, solitary voyage (though construction didn't go just as smoothly as with the barquentine). On the other side there'd be the tanker I attempted to make in 2014 shortly after releasing One Step Too Far. If I remember right it was an 8000x1000-dimensioned ship (barque: 3000x500), so something like 8 galleons could fit into its hull. It had a rusty industrial theme to it and some fancy elements like a ship-wide camera surveillance system and an internal bay with a deployable submarine, but it was of course wildly unrealistic, at the time at least.

I actually have just the thing to get this thread back on track. Here's a lineup of most of the ships I made in DR over the years, including the most recent addition, 2nd from the left. That one was this week's weekend project, a galleon-sized steamship sharing a lot of elements with *that* ship all the way to the left. From left: Barque, Barquentine (new), Merchantman, Schooner, Sloop, Brig, Yacht. The 4 to the right are available to other authors already now; the Merchantman is done and will be made available after release of its respective mission; the Barque will probably stay unique as I think its size makes it unlikely to be reused. For the Barquentine I have no real plans at the moment as it was made as a fun side project. If someone's interested in using this ship now they'd be welcome to do so and I'd then prioritise getting it finished. Otherwise I'd probably make a simple stowaway mission like Pandora's Box out of it sometime down the line.

You can use a target_relay as your completion target instead, which does have the ability to have multiple targets.

If I wanted to have a 'reusable' lute player I think I'd build a script that periodically checks the alert state of the AI and performs various actions depending on how the state evolves (script load would be ok if it's just this 1 AI). But this seems like a lot of work when considering it's a small cosmetic feature that players may not encounter. I don't think anyone would count the stock lute behaviour against you.

This is what I've used previously. You'd need to do it by clearing all targets, then adding a different target. There are entities for these 2 functions, or you can use Stim/Response or scripts. Personally I'd use a script so that you can add a sys.waitFrame() inbetween the 2 steps to ensure 100% that the new target doesn't become cleared as well.

That atdm_puddle entity is merely a patch-like model that fits to the shape of the lake and bears one of the 2 water textures. You can just as well use only patches, as I have done. Regarding what's under the 2 surfaces, it might be that the water brush top is very close to these so you might not see it just by zooming the camera in. Maybe you could try shift-clicking + hiding one thing from the lake at a time in your orthoview until you find an entity that could be the water brush?

The double surface sounds similar to what I have for my ship showcase map, where one layer displays the reflection while the other layer blurs (lifted from Arcturus' castle & pond demo map for animated grass). The easiest replacement would be to delete all traces of Bikerdude's water and then duplicate your own water from the other part of the map. If you can't see Bikerdude's water box, maybe you have the filter for nodraw or visportals enabled? If you sometimes fall out of your water I'd have two possible explanations: A ) the water brush doesn't reach all the way to the bottom B ) your water entity consists of multiple irregular shaped brushes, i.e. triangles. This was problematic when I custom-fitted water brushes around my ships because I'd keep falling out of the water. I got it to work by, step 1: recreating the broken brushes from scratch (copy-paste does not suffice), step 2: giving each brush its own water entity.

This was leading up to Halloween in 2015 so details are fuzzy, but IIRC an AI will start patrolling if it's assigned a target after having had none. So I had to clear all the AI's targets and then add an inaccessible path_corner node as a target. There were almost certainly more steps involved, it was all very fumbly and I settled for a simpler solution. I consulted with grayman at the time to find out that there's no clean way to stop an AI patrol. I'll put that into the bugtracker. Edit: bugtracker (bugs.thedarkmod.com) still seems offline.

This is something I used for a custom AI script in an early alternate version of Down by the Riverside (Tales of the Riverside), which you can find [url=http://forums.thedarkmod.com/index.php?/topic/18402-fan-mission-down-by-the-riverside-by-dragofer-20160925/&do=findComment&comment=407828]here[/url]. The script is able to make an AI stop patrolling upon reaching its next path node. If you want the AI to stop immediately it would involve teleporting the path_corner to an inaccessible location, as I recall it. (I was aware of the StopMove event but in my experience it only caused the AI to twitch while carrying on with its patrol. Might be good for a free-roaming AI like a zombie though?)

@Hagatha When I played the mission I also tried to get past there to no avail, ended up noclipping past only to realise that you're not supposed to go this direction as it's a one-way path. I don't remember the correct route anymore unfortunately, but if I remember correctly you should look into some of the openable windows.

Technically speaking what you want to do is very simple. All it takes is to open DarkRadiant twice to open both maps, then select & copy-paste (via ctrl c & v) between them. Names get updated automatically, so if both maps have func_static1 to 100 then the new arrival's func_statics will get renamed 101 to 200. If there are spawnargs referring to these names they conveniently also get updated. What you'd have to watch out for is that you'd probably have multiple ambient_world lights, location setting entities etc. Whether this is advisable at this point is another question: 1) For your first map you could reasonably expect to have your hands full just getting a feel for how all the parts of a complete mission work. The generally advised practice on these forums is therefore to aim to get everything to work on a smaller scale, as each step already takes longer than usual if it's your first time and mistakes are easier to correct, before moving on to more ambitious projects. 2) Each mapper works differently. I've taken over a harbour map from this thread but spent considerable time figuring out how the map's been put together and then reshaping it into a state I personally can work with. For example, rooves and subterranean brushwork were highly irregular, both requiring a redo before I could add attics & basements without getting confused. This kind of work is something I'd recommend putting in if you find a map idea here that you want to see to fruition (i.e. I have a high affinity for maritime environments and also had a large ship looking for a new home). But if you just want to have some more content in your map then I'd say it'd probably be more wholesome for you to use (mostly) your own work. This is just my personal opinion based on my own experience, though.

Personally I find torches to be a crude form of lighting that would feel overwhelming in places where people live and work, with their bright light, crackling sound and open flames. That's a matter of aesthetics, so there'll surely also be mappers to whose taste it would be to employ torches in a more versatile way. What I wouldn't do - anymore - would be to let realism be a major factor in the decision. In my early days I went to some lengths to ensure my map was realistic enough, for example only adding moonlight to rooms which had windows actually facing the moon. At some point I realised that such striving got into the way of building my maps in the best possible way, seen from the gameplay, aesthetics and time-efficiency perspectives. In that particular example, the poor lighting in the non-facing rooms would be much likelier to be noticed than the more realistic portrayal of the moon's lighting. Realism does do a lot of good - TDM and Thief arguably simulate stealth and industrial society fairly realistically - but it can be taken past a certain point where small improvements come at a cost in other areas. Thus, if a mapper's intuition is that a torch would fit best in a certain locale, then I wouldn't want to interfere with that.

The dilapidated old house at the western waterfront of Wrecker's Reach. A local glancing upwards as he hurriedly walks past in the dark of night might notice a window lit up brightly from within, but he would rather not think about how this could be. (This is also the same house that'll feature an excerpt from an eerie short story written by Spooks.)