Frost_Salamander

Maybe you need to drag the the bottom of the widget down a bit more? Mine looks like this:

See here (v2.06 or later version): https://wiki.thedarkmod.com/index.php?title=Sleeping_AI#Sleeping_While_Sitting There are a couple of methods there - note the 'NOTE' at the bottom regarding the behaviour if the AI wakes up - because of that I would recommend the path nodes option.

The 'Natural' button is there for me (on 3.7.0). You sure it's missing? You can map camera movements to WASD. Look for the 'CameraMove' and 'CameraStrafe' key bindings.

The clipper tool supports using caulk (or some other shader) to apply to clipped surfaces. Is it possible to do the same for CSG subtract? It just seems to use the shader of the object doing the clipping (which I pretty much never want and always have to change it after), and I can't find a setting to change it. Even better would be for the clipped surfaces to retain their material, because that's usually what I want to happen. Although if the target brush has more than one I'm not sure how that would be worked out. I suppose the workaround is to make sure the object doing the clipping has the shader you want applied to the clipped surfaces, but then you have to remember that

Does anyone know what this means (from DMAP output): EarCutter: no more ears after 6/8 iterations (zone 162.592 x 7.939) Is it bad? It's not a warning, just informational it seems. I have a feeling it's something to do with some irregular worldspawn shapes, which I have but try to minimise. Also is there a way to track down what that 'zone' is?

It's been fixed for the next release it looks like. As a workaround, make sure the 'Media' tab isn't selected when you do the 'copy shader' operation: https://bugs.thedarkmod.com/view.php?id=6151

Yeah for entities, models and textures. If you right-click them there is an 'add to favourites' option. Then the next time you go to use them, you can click 'show favourites' instead of 'show all' in the chooser window, or use them from the Favourites tab in the properties window.

nah no worries, I'm probably the one overthinking it. Any and all feedback is appreciated, just want to make sure I understand it!

Feature request: expand favourites trees I'm presuming that the benefit of the favourites feature in DR is to save time and clicks by presenting them in a separate view. However whenever you click the 'show favourites' radio button, the tree view is always collapsed, meaning you have to search/expand/click anyways. And that's if you can remember what is in your favourites. Suggest that the favourites trees be expanded by default (or alternatively, an 'expand all' option). it would be much easier to see at a quick glance what's in there, and there would be less clicks involved. I don't know how having hundreds of favourites would affect it - but I'm guessing most people have a couple dozen of each type at most? I kind of realised I don't use the favourites much, and this is one of the reasons why.

ok thanks. Yeah the first point is probably too specific to that single group use case. I'll raise the other 2 things in the tracker. If feature 2 is implemented, it would make adding stuff to a group easy anyways and feature 1 would be almost redundant.

I'm going to ask about a couple of things here because they are related to grouping - feel free to tell me they should be part of a different discussion/feature instead. Perhaps they may factor into how this works. with selection focus on, grouping information is ignored. Makes sense as you want to manipulate the individual objects. But what if you want to clone one of the objects and include it in group (if it is in fact a group you are focused on)? Say you are working on a staircase and need to add a couple more steps. Could cloned objects just be automatically added to the group? I kind of wish there was an 'add to group' or 'merge groups' command in the mouse context menu. Unless you want a bunch of nested groups, you need to select all the objects, then 'ungroup' followed by 'group' to do this. (probably a separate thing but will ask anyways): Is it possible to disable drag select in the camera view? Frequently I'll be selecting objects one-by-one in the camera view to add to a group. The mouse will drag very slightly and all of a sudden loads of stuff in the background will get selected. You then have to press escape and start all over again. Gets tedious.

Did you mean Ctrl-Tab (next view)? Because that worked. Alt-Tab for me switches between windows (in Windows 11). Yes this is what I suggested above ("..automatically focus the ortho view onto the focus group"). I think I would want that - but maybe need to find out of everyone else would want that as well.

This is super-handy, loving it already. A couple of minor things: I couldn't download the release from Github until I signed in - does everyone have a Github account? ToggleSelectionFocus wasn't bound to Ctrl-F by default - it was unbound. When you enter selection focus mode, because all the colours change to white/black it sometimes hard to find the focus group in the ortho view if there is a lot of stuff in the map. I see the light highlighting around it, but it doesn't help that much. If it's an existing group of items I want to manipulate, I would probably select it using the camera view, and manipulate it using the ortho view, meaning I have to find it. Some suggestions to help might be to change the focus group items to a brighter colour (blue/red/green?), or automatically focus the ortho view onto the focus group. I'm using 'Super Mal' colour scheme as well which is grey background, so maybe that combination of black/white/grey doesn't help. I've only just started using playing around, will leave more feedback in future comments if I have any. But yeah this is great!

Well the main problem is really that it's kind of big, and I'd have to totally change the 'story' to fit with the theme. Maybe I'll 'participate' by downloading and using your cobble pack regardless

That was a critique during beta, so I went around and opened most of the openable ones. Was it really still an issue?

wow these look great! I always wished there were more/better choices for these in the base game. I have an FM in progress but there is no way it'll be ready for the contest, I'm too slow :-(. One of these days maybe the timing will be right.

Sometimes I think I learned some lessons from the feedback I received from this FM, but other times I wonder. I definitely didn't make it 'difficult' on purpose, but I certainly didn't want it to be easy or not challenging. It's hard to tell what people find enjoyable. I guess my assumption has been that players expect stealth gameplay, since, well it's a stealth game. But it seems if it's too difficult to get a perfect stealth score then that might turn some people off. The funny thing is, I always write the FM with ghosting in mind (or at least, no blackjacking). With this one I didn't really test it with going around blackjacking everyone. It wasn't until I watched some playthroughs that I realised how easy that made it

The face of the visportal with the 'Vis Portal' texture must be touching a brush on all sides. Entities and patches don't seal.

I'm having this weird issue where copy/paste shader stops working properly. It will paste the texture, but not the position/scale from where it was copied. If you copy/paste between two surfaces with the same texture but different offset/scale, the result is it appears to just do nothing. If I restart DR, it goes away for a while but then comes back. Is there a setting for this anywhere? Anyone else getting this? Because it's random, a bug report probably wouldn't be very helpful without proper steps to reproduce. I don't remember ever seeing this before 3.5.0.

ah nice - I've already overridden that script object for a different purpose (but for the arrive event). Thanks!

You can in fact make that part larger. If you hover your mouse carefully on the line right under where it says 'func_static_295' or whatever, the cursor will change to a resize icon, and you can drag it down to enlarge the panel that shows the spawnargs. It's easy to miss, I think I remember someone else noting the same thing a while ago.

Odd - it's definitely happening to me. I saw the doors Wiki page about interruptable and figured like you said it only applies to frobbing, but like I said the doors will stop (edit: the auto-close no longer works, even with blocked set to 0) when damage is inflicted, and using that is the only way I could get it to work. Actually what I really want to do is override the behavior of the atdm:mover_elevator_button entity. My main requirement is actually just to not let the elevator move unless the doors are closed (hence all the auto-closing nonsense). But pressing that button causes it to move no matter what. I just checked and it doesn't have a script object. Is there a way to intercept the call that the button makes and insert custom code there? For example have an 'onPress' event that I could customize before sending it off to do its thing...

I thought you were onto a winner here, but nope, still does damage

it might be because I also set stop_when_blocked and 'interruptable' to '0'. The reason for this is because they are elevator doors, so I want them to be behave just like the would in real life. I found that just 'stop_when_blocked' alone did do enough - they would stop but if damage was taken by the player, they wouldn't then resume. If damage wasn't taken, they would resume. When I added 'uninterruptable' as well, they closed no matter what which is what I wanted (although you can now get trapped in them if you're not careful ). Also, there are actually 4 doors - one set in the elevator carriage and one set to close off the shaft. I didn't mention any of this earlier because it's pretty complicated and I got it all working the way I wanted, except for the damage part.

Not really, no. It does indeed push the player, but because it's 2 sliding doors you just get pushed into the other one and the damage still occurs. I don't really want to change the value of the auto_close_time either for 'gameplay reasons'