SteveL

EDIT: Just spotted I forgot to texture the wall in the middle! Well, at least now I know how to produce a plain black surface, which is something I have been wanting for a few spots like the inner recess of my sash window and a couple of other unlit holes where I want the bottom to appear further away than it is, and invisible! I never thought to leave "no shader found" in my map, but that's what it looks like EDIT to EDIT: Ack, I keep messing up edits! I apparently get confused by having 2 text boxes on offer

It does work... here's a 2-minute test map. An ordinary light def_attached to the back of an AI's belt, which is why his shadow casts forwards as he patrols round the wall. Nothing else in the map, so you should be able to spot the difference with your setup. test_def_attach_light.map.txt

+1 An easy-to-find walkthrough for making a first conversation will be useful. The current article is more of a reference. If your audience is people who haven't set one up before, perhaps name some specific shaders right there in the article and add a couple more example specific actions so a first-time user can simply follow your steps and have a working conversation that they can then play with and adapt. Tutorial-style, that is. One more suggestion: I think you should mention the "Actors must be within talk distance" setting. It's the top one, and fundamental to the set-up, and I reckon it could easily be misunderstood. The wording suggests to me that the conversation will not be triggered unless the actors are close, but in fact it means the actors will be made to approach one another when the conversation is triggered.

Not sure why it's happening, but have you checked the spawnargs? Worth double checking the light/entity doesn't have noshadows set. You could try using def_attach instead of bind too. The lights on lanterns and torches that AIs carry are def_attached, not bound.

Will it be possible to make that furniture with separate models for the drawers so we can turn them into mover_doors and hide stuff inside? Whether that works or not, nice job.

I was about to ask you what your blend options were but I'll wait for your final post. Thanks for sharing. NB you probably have fixed this bit already but if blend filter/add are having too much of an effect you can modulate that stage by adding rgb 0.5 or whatever value to the stage. I don't know anything more about open gl blending btw, but I did spend one evening studying it last week when I wanted to get windows to look right both from the lit side and the dark side. The rgb and blend src/dest were the options I twiddled till I got the effect I wanted :-)

Works for me in 1.8.0. Oddly enough I didn't know about it until your post yesterday so I tried it last night. NB I tested it with shift+ alt+ click, not multi select.

Until you get used to a way of working. After reading this discussion I paid attention to what I was doing in DR last night. Unless I'm working with a small layer, I do most of my selecting in the camera view, which I have on a separate monitor. I'm sure others have their own preferred method. By the way, the camera view does allow for easy quick precise movement without going anywhere near the menus. CTRL+ALT+mouse strafes smoothly after you right-click to direct your mouse movements to the camera view, and you already have your non-mouse-hand over those keys if you're selecting stuff, so there's nothing awkward or slow about it once you get used to the system. Big and small movements in any direction are both only a gesture or flick away. EDIT: and smooth/small zoom is CTRL+SHIFT+mouse.

I'll keep an eye out for it

Sure, but what's easy depends on skills, knowledge, and time available. More models and prefabs are a good thing, especially to help out beginners. For architecture models, extra skins make them useable in lots more situations.

+1 for either of the solutions proposed above. Editor descriptions will overcome any confusion over duplicated or inconsistently named spawnargs. In the meantime I think I'll stitch two sounds together in Audacity to make my sash window clunk when it finishes opening. For closing, I've added the wooden chest close sound to one of the door opening sounds using spawnargs and it works. It's be nice to be able to fix up the opening sound with spawnargs too.

And there's a toggle button for switching between selecting whole group and group members. I have it hotkeyed. Some good suggestions above. ps I wasn't entirely convinced by my own argument for the selection method either!

Yeah, I agree what I outlined above would be massive overreach. That was my "I bit off more than I can chew and now I'm putting it down" speech. I think you're right though, the tool could have some uses. It turns out that off-grid was a red herring, and like you say we don't need another leak detector, but it could perhaps become a general script to check for problems that pops up a report like this: Found: 6 slivers 1 duplicated brush 2 nearly-aligned brushes 2 overlapping brushes With a "Select" button next to each item on the report. Clip textures, nodrawsolids, ladders and the like could be ignored by default, by the same method that DR filters them. If people think that'd be useful, it'd be easy enough to write, although what constitutes "nearly aligned" might run into the same problem as "off grid". Last night's script only took an hour -- admittedly, minus some essential testing that should have been done . The problem with it was the concept not the difficulty of writing it, so we could try it out if you want to help test.

Ok thanks Obsttorte, I'll try it when I get home from work. Not heard of a trigger_hurt before but it sounds very apt. Re the stim, if I find I already have the interval set and it doesn't fix it, I'll post back as I'd still like to know what I did to set my stim up wrong. EDIT: Adding the time interval didn't fix my stim_damage, but the trigger_hurt does the job fine. Thanks for the tip.

Damage stim not working... What's wrong with my extremely basic setup here? It's again the first one I've tried so probably something extremely simple. My test map is a cube with a bonfire model in the corner. Above the model I've placed a light_fireflames_typical entity. I want the player to take damage if he stands on top of the fire. I've added a damage stim but nothing happens. I've been messing with the distance and magnitude, so the spawnargs I'm about to paste might look a bit extreme, but none of the options I've tried does anything to the player. The light_fireflames_typical comes with a fire stim and a (disabled) visual stim. I've added just a damage stim. I've not duplicated the S/R number. My spawnargs are: sr_chance_7 1 sr_class_7 S sr_magnitude_7 50 sr_radius_7 67 sr_state_7 1 sr_type_7 STIM_DAMAGE I see the player already has a STIM_DAMAGE response in his def file, so I've not added one. In fact he has two identical responses, but removing one of them doesn't help either. What am I missing?

Just the sealing geometry you mean? It already filters to world spawn. I woke up with a few more ideas -- I could import some of DR's filters to ignore clip etc, and distinguish sealing caulk from caulk being used as clip by ignoring faces that aren't near-parallelograms -- but I've also got the feeling that whole approach is misguided. It was based on the observations of many people that something off grid causes glitches. But like grayman said, dmapping has no grid. You might well fix a glitch by moving something back on to grid, but it would have been fixed just as well by moving something else off grid. The point is you need to twiddle something to break a conflict, but the grid isn't the issue, and presumably conflicts in the math can arise from perfectly grid snapped geometry. So instead of being a trivial problem of finding something off grid, this becomes the problem of doing a better job of working out how a map should be dmapped than dmap does itself.

Thanks, that clarified the problem a bit. I ran the script again, this time counting up textures on the faces that have a vert off the 1-grid in that specific range. The vast majority of it is caulk, monsterclip, and nodrawsolid_stone in that order. Caulk can be sealing or non-sealing of course. Even if I used the same technique over a lot of maps to compile a list of non-sealing textures, it's getting hard to see how this technique could *ever* reduce the false positives enough that it'd be a useful tool :-/ Ho hum.

Another thought: Pehaps the "?????" range is monsterclip and other stuff where you cut freely with the clipper tool and don't worry about grid alignment. I could try re-running the test excluding clip textures... what else should I exclude? @RJ: True, I don't know what the min grid in the texture tool translates to in the normal grid, but the results do back up the theory that dmap has a threshold of some kind.

EDIT: cross-posted with you grayman. I'll think about that now... Can you make any sense of my results on your map when it comes to picking a threshold value?

I did find another thread where grayman was trying to tackle that problem. Admit I haven't read all 7 pages yet. Like most bright ideas I have for adding something to the mapping process, it turns out that the reason no-one's done it before is that it's not anywhere near as simple as I first thought! The results are in. Based on a sample of 420k worldspawn verts from a working map, the count of verts that had a given displacement from the 1-grid: < 0.000000000000001 394444 -- all the perfectly-grid-snapped stuff < 0.00000000000001 0 < 0.0000000000001 142 --\ the floating-point < 0.000000000001 279 --/ errors < 0.00000000001 0 < 0.0000000001 0 < 0.000000001 0 < 0.00000001 0 < 0.0000001 0 < 0.000001 7 < 0.00001 228 --\ < 0.0001 1170 --| < 0.001 1572 --| ????? < 0.01 4363 --| < 0.1 3108 --/ < 1 16907 -- the 0.125+ grid-snapped stuff Not what I was hoping to see. Yes there's a range where the count is 0, but what is the stuff in the 0.00001-0.01 range? I was hoping to see lots of verts with 0 displacement, and lots in the range 0.1-1 (which is the stuff snapped to the 0.125 grid and above). But there's a whole load of verts with more than the "trough" range that are also technically off grid. Clearly dmap is coping with those (the sample was from In the North by the way -- I thought it apt since grayman had worked on a related problem before). It's still not clear what threshold should be used by a script that's designed to find off-grid stuff. I am going to let the problem rest for now. My brain needs a rest. Time to go make a pretty window

Wizards out there, what does "on the grid" mean for dmapping purposes? Background to this question is a post I made in Springheel's "gap" thread re dmapping problems. I did a quick DR script designed to search out and select all worldspawn brushes that were off the grid, meaning to extend it to find slivers and brushes that don't quite touch (=possible leaks). Unfortunately it highlighted a load of brushes cut at angles that were apparently gridsnapped. At first I thought the library code was at fault because I was getting odd results like "grid coordinate 224.0 is not on the 0.125 grid". Turned out that the 224.0 wasn't really 224.0, it was 223.99999999999997 and that when printed to screen by python's str() method, it was getting rounded. When I select the verts of the brush that had that x-coordinate and snap them to grid 16, the offending vertex still has the x-value 223.99999999999997. So it seems there's really no concept of verts being absolutely "snapped to grid", even though all grid sizes are in base 2 and so you'd hope not to have to worry about floating-point errors. All is not lost... Presumably dmap has a tolerance for TINY differences else every map would leak. In tests the other day, I found that it tolerates texture misalignment of up to 2 min grid units (in the texture tool) and will still re-stitch brushes. Does anyone know what tolerance it has for brush alignment? In the meantime, I will try to estimate a good threshold to make the tool useful. I have a script running right now that's churning through a couple of big FMs and spitting out how far all worldspawn brush verts are "off" the 1-grid. I'll tot up the results and I hope to see a huge spike at 0 followed by a trough followed by a second spike at some very small fraction. The idea is, the threshold at which the off-grid detector will kick in is in the middle of the zero part of the chart...

I'm working on the false positives. Damn, they didn't show up in a test map, my fault for posting before trying it in a full map. What's happening is arithmetic weirdness. I thought there'd be no floating-point errors to worry about since everything is in base 2 (grid size 0.125 upwards), but I'm seeing results like 352.0 mod 0.125 = 0.125, and occasionally 1.42108547152e-13. Apologies, I'll take this to a new thread after trying to fix the arithmetic, implementing it manually rather than relying on the library function if need be.

EDIT: Please wait for an update in another thread before trying this script (unless you want to help debug it:) ) We have arithmetic weirdness to deal with. It strikes me that finding off-grid worldspawn and slivers and the like is an ideal job for DR's scripting capabilities. Using a script to find problem brushes would mean you can treat them individually, either correcting them or converting them to FS, without having to snap everything to grid and then go looking for leaks. Unlike the PatchSplitter script I did last month, this one can be completely menu-driven. I've spent the last hour doing a proof of concept script that does one thing: it selects all off-grid worldspawn brushes in your map, after popping up a box where you can choose the grid size to use. If people think it's a good idea, it can be extended to include options to find slivers, overlapping brushes, duplicate brushes, distant faces aligned with VPs, etc. I'll paste it here (hope you don't mind Springheel) since lots of experienced people who have been thinking about the topic are already gathered in one thread And it might help you find the irregularities in your map. grid_check.py.txt What it does Pops up a box asking you to choose a grid size, then clears your current selection and selects any worldspawn brushes that are off-grid at that scale. It ignores brushes that are part of an FS. How to install Save the attached .py file to Darkradiant/scripts/commands, where Darkradiant is your install folder. Remove the .txt extension as usual. For Windows users the default path is: C:\Program Files\DarkRadiant\scripts\commands Then restart DR. How to use Under DR's Script menu, you'll find a new option: Select off-grid worldspawn brushes Quirks The script has no way to tell whether a given brush is currently hidden or not, so if you have part of your map hidden, it'll get checked and some brushes might be selected anyway. You might see the origin of the selection floating off to the side, because of distant hidden brushes that are selected. Shouldn't be a problem if you fix the brushes by selecting vertices, but probably best to use it to find the brushes, then clear and re-select before converting one to a FS or dragging it.

I'll be 40 this year too. I don't agree with the "life gets worse" sentiments. I remember people telling me that too, and thank goodness they were wrong! I had no idea how to be happy in my twenties. That was fun, but life is much more rewarding now.

Thanks, another good suggestion. This thread is becoming more useful by the minute. I'm hoping to have more transparent windows so I want as many tools in my box as possible. I loved the windows in Kvornig's FM whose name temporarily escapes me, and the way they changed gameplay by allowing you to be spotted from outside. I'm doing a smallish mission for my first FM so that my inevitable newbie errors don't make me run into problems of scale, but I want it to feel unenclosed. Two tactics are transparent windows looking out on the exterior plus a custom skybox that'll let me make windows at the edge of the map look like they have a view. When I've got the first FM out the door, if it's well received the plan is to expand the location and make some of those skybox areas accessible.