SteveL

They can be stitched automatically... let's have a think how that would work. I do want to add to the patch toolkit. Yes the verts getting added at one side is a pain. It's less painful when you get the hang of moving pinks only first, but still a pain. You just caught me making notes about how a script could do it. Take all the verts of a cylinder or circle, redistribute them, at the same time fixing a perfect circle, then fix the texture stretching. DR's python API can easily handle all that. Haha, cheers grayman

I have it ready but I can't figure out how to embed it! For now, here's a link: http://youtu.be/R1FdElYIjnk I did pick up on that suggestion of yours for the vid... EDIT: Ah, THAT'S how you embed a video!

There's a copy of the script reference (same as that file) on the wiki: http://wiki.thedarkm...cript_Reference setOrigin() probably isn't the function you want. It moves the entity in an instant, with no transition time or rotation. For your gramophone arm, you probably want to make it a mover_door entity, move its origin to the pivot point (go into vertex editing mode to do that with the entity selected), and set the spawnargs so it rotates the right amount and in the right direction. Then it'll move naturally and you can trigger it to open or close with any of the methods you can use for a door. I will happily help you set this up if you want to send me the test map. The problem with answering your question in the forum is that the right answer could be different depending how it's set up already...

UPDATE 29-Mar: Latest script version in this post: http://forums.thedar...post__p__341896 Demo video (original) in this post: http://forums.thedar...post__p__340566 Development discussion is in the thread on cutting patches with spreadsheets. I've done a demo video for this with use cases but I'm having to figure out how to get it onto YouTube (not done it before). With luck, I'll add it to this post this afternoon. To install the script: Save it to your DarkRadiant/scripts/commands folder, in the dark radiant install folder. Remove the .txt extension from the file name. Then click File > Reload scripts in DR, or just reopen DR. You can set up a keyboard shortcut using the normal menu. The tool is called "SplitPatch". To use it: Select one patch, enter vertex editing mode, and select 2-3 adjacent verts on the same line, including at least one pink vert (selecting 2 nearby pinks like I do in the video wherever possible will help the script run fastest). Then click Scripts > Split patch from the menu, or use your shortcut. Save the map beforehand and don't rely on Undo. You *can* undo -- press it twice -- but the verts you originally selected will be on grid but a bit out of place. Another side effect is it leaves your orthoview in top-down view no matter where you started. Please watch out for bugs. Most of this code was written yesterday! I've used it for a few hours without problems. There's sometimes a couple of seconds' delay using the tool. There's a lot going on under the hood. If people find that's a problem on bigger maps, I'll look for ways to optimise it. attachment=patchsplitter.py.txt (updated version linked above) EDIT: Updating the instructions to reflect what I currently think's optimal.

Final update from me tonight: It works as advertised! I'm now adding code to handle situations where the user asks the impossible: cuts on the existing seam of a sphere/cylinder, cuts at the edge, diagonal cuts, green-line cuts, that kind of thing. After 15 straight hours though I'm going to take a break and a beer and finally go and play A Noble Home! I'll be back in the morning with a demo vid and the script.

I've not tried it but I think that's exactly what "Save Region" does in the DR file menu. (Is that the one you meant RJF?) I did read somewhere that it even adds the caulk cube for you.

Haha. Thanks for the vote of confidence guys Better deliver on time now, hadn't I? So far, so good. I agree! Patch stitching should be easy if the patches are similar enough. Vertex painting, I wish, but I had a look and I don't think patches hold any vertex color data. I don't know what cordon bounds are...

Testing so far so good... Some time this weekend if nothing goes pear-shaped. Wish me luck, I'm not leaving this spot to eat or drink or anything until it's done! I still have some testing to do and I'll have to do some tidying up like assigning the new patch to the right FS and Layer... and anything else I haven't thought of. Suggestions please guys if anything else that'll need fixing occurs to you. The code that actually does the patch splitting is tested and works great, which is why I sound confident. I've been using that myself for 2 months now. I couldn't have made that fancy well cover for the moonlight demo without it. This is just about finding a way to make it usable without typing in code. If the above works, you'll just have to select 2 verts along the line where you want the patch cut and click "Split patch".

EUREKA!!! You can't find out which patch verts are selected directly, but a script *can* move the selected verts around using the standard ALT+arrow key bindings. And that has an effect on the patch's overall bounding box, which you can test in the script. So with a bit of jiggery pokery you can work out what the bounding box of the selected verts was at script start, or in other words, it'll tell you where the user wants the patch to be cut. It won't matter that the patch gets twisted up: it can be put back again exactly. EDIT: @ungoliant: Sorry, I missed your last post in Feb. Agreed, that's the better way to go about it. I'll try to get this method working as a stop-gap until we can come up with a fully fleshed-out proposal for an API tweak. The horrendousness of what's going on under the hood with the method I'm about to test should be invisible to the user...

Is the texture the same? You won't have set solid 0 on the FS, but it could be in the material file. It's definitely not a general problem. *All* my exterior floors are fs noshadows patches with monsterclip or nds under them and I have test ai exploring every corner.

Wow, can't wait to see it! +1. Great job on the voiceover.

Interesting. You have a very keen eye!

I've used these to damage the player because I've never yet managed to get a damage stim working. They are handy for positioning over bonfires because the default behaviour is to apply 10 points of damage per second. I've not had to change those settings, but there's a couple of clues in the entity def: "editor_usage" "Damages the activator. Can be turned on or off by other triggers." "editor_bool on" "Whether or not it is active." "editor_var delay" "Delay between damage in seconds defaults to 1" "editor_var def_damage" "Damage def to use, common ones are damage_painTrigger, damage_triggerhurt_100, damage_triggerhurt_1000" "on" "1" "def_damage" "damage_painTrigger" The damages are defined in tdm_defs01/def/tdm_damage.def. Looks like there's no difference except in magnitude. The default damage_paintrigger is: entityDef damage_painTrigger { "damage" "10" } All the bespoke damage_trigger_hurt look like this with nothing set and only the magnitude changing: entityDef damage_triggerhurt_75 { "damage" "75" "kickDir" "0 0 0" "mtr_blob" "genericDamage" "blob_time" "0" "blob_size" "0" "blob_offset_x" "0" "knockback" "0" "kick_time" "0" "kick_amplitude" "0" "dv_time" "100" } But there are plenty of more interesting damages in that file, which could presumably be used with a trigger hurt too. This looks fun: entityDef damage_HugeExplosion { "damage" "500" "radius" "256" "push" "10000" "knockback" "200" } Yes that worked. I didn't quite splat against the skybox as hoped, just against a nearby wall.

I agree. I remember that room! Made me resort to a very rare blackjack. I'm hoping I didn't cut the Gordian knot

It's not obsolete! There's the occasional point that could do with updating. I can't check the grid default behavior right now, but note that you probably won't rely on it at all when you get used to using DR. If this is a general bug, that'll be why many of us haven't noticed. Changing grid size to a suitable number is something you do automatically before manipulating anything in DR, using the hotkeys 1-9.

Wow those are really good. Both the collection you made and the in-game artwork. I bought and downloaded T4 on release day but I haven't got round to looking at it yet because I've been busy with TDM -- either playing or messing with scripts -- every evening since. Guess I should give it a try one of these weeks

I posted before I saw yours. Cheers for copying the image. I've nothing to add though, you covered it.

Hi and welcome! When that instruction says "main ambient light" it doesn't mean the global ambient light, it means the light that you just cloned to make the pool fog. That wording could be clarified a bit. Shift+drag does the first. I'm not sure whether you can filter your selection by entity type. There are toggle buttons for selecting only group parts, only surfaces, vertices etc, which are handy. In general, don't worry about a few extra tris. Personally I do sometimes tidy up the tris around staircases by one of several tactics: Move the stairs 1 unit away from the wall If AI don't need to use the stair, make it a func_static so its not wordspawn any more If AI do need to use them, make them a FS anyway and give AI monsterclip to walk on instead. but I doubt the difference will ever be seen in game. A few dozen extra tris won't ever be what makes the performance difference in any map. Avoiding crossover between visible brushes is generally a good idea as it avoids z-fighting and and makes it easier for you to see what you're doing, but it's a rule you can break whenever you have a reason. Can't see the image for (4) I'm afraid. Server declining. 5) Kind of, but it's not useful in most circumstances because it's only the visible model that gets scaled, not the shadowmesh or the collision model. I think you do it by adding a "scale" spawnarg but I'm not sure. Someone will correct me if I'm wrong.. Not sure about 6,7,8. I've heard reports that non-regular visportals, or those made up from several brushes, can cause irregular sound propagation. Sound is funneled from one area to another via visportals which sounds more realistic than sound coming through a solid wall. The usual advice is to keep VPs single, rectangular and not to rotate them because it's sometimes tricky to get them to seal if you do otherwise. Again, that's just a rule of thumb though. If you have an interesting situation you can try portalling at any angle, but make the angled portal by cutting away parts of a unrotated brush so the sealing edges remain square on. Best to avoid rotating a brush that's to be used for a VP as it can be hard to get them square and flush again. EDIT: Crossed with Lux

One way is to use an atdm::target_callobjectfunction. Give it the door as target, and add the spawnarg "call" "Open" Or "call" "Close" It'll have no effect if the door is already in the position you're asking for.

Are these console commands documented anywhere? I haven't found anything. EDIT: Ah, it's the list of key bindings in the preferences menu isn't it?

Why didn't I think of that? :-) Probably because I've never done it. Can anyone recommend a piece of software that makes it easy? I'd better add a few of those missing walls.

I agree there could be a job for a script somewhere here. I've often wanted to do this to an entity light and have ended up replacing it with separate model, light, and particle. I hadn't realised you could offset the particle. That makes sense but would still be fiddly to do manually. I'm not sure whether it could be so automatic. Imagine doing this in a squarish room with several torches. You'd end up with every torch hitting every surface but without illuminating any walls because of falloff. I'll try out a much less ambitious version to start with, and take it from there. One that moves the particle on an entity light to where the light vertex is, which is something I've wanted to do before now and didn't realise was possible. Edit: just re read it and see you already have overlap covered. The script wouldn't enlarge the volume. What about falloff though?

Morning nbohr1more. When you mentioned this yesterday I thought "impossible". Now you've elaborated it a bit I see it probably isn't impossible... I'm still not sure whether it would be used though. Let's see what use cases people can think of. The only way I can think that it might be implementable would be to trace the path and at each point find the closest wall. Extend a normal plane from that wall and see whether it can seal as a rectangle. At the end, choose the smallest sealing rectangles. There'd be maintenance needed unfortunately. I think the script would need to maintain a list of solid textures unless the python shell can access the engine path variables and the material files. That script would seal doors but would be hopeless at most exteriors. I have absolutely no idea whether your bonus points are possible!

I'm always up for challenges but my goodness you know how to set the bar high! If you have ideas on how these might work in practice, let's take it to another thread. At first glance, these sound tough. I think a script might run into difficulties deciding what a "room" is, at least without duplicating all the work that goes on during dmapping. And with portals, I can see how a script could work out optimal places to put portals to maximize the amount of time they spend closed (assuming the player will be standing in all parts of the visleaf for the same amount of time), but I fear no script could portal an area well unless the area had been designed with specific portal positions in mind. Re lights: Is that because the lights would be non-shadowcasting, and therefore prone to leaking into the next room? An easier fix might be to generate location settings to switch them off as the player leaves. That would still need a script to somehow work out which lights are in a given location. Hmm.

Aha! Yes of course I remember that now. You must have planted a seed in my mind.