Frost_Salamander

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'

Does anyone know how to prevent movers from damaging the player? In my scenario, I have a set of double sliding doors that have 'auto_close_time' set so they close after a second or two. If both doors hit the player they receive damage. They are just doors so I don't really want that to happen. I see there is a 'def_damage' entity attached, but not sure how to override/get rid of it. I tried to set it to a nonsense value (e.g. 'none' or '-') but that didn't do the trick.

That's what I always do - I don't think there is a need to uninstall anything. If you look in your C:\Users\<username>\AppData\Roaming\DarkRadiant folder you'll see it has folders for each DR version which contain settings files. Every time I've installed a new version it picks up my settings. If you're worried about it, you can always back up that folder. Greebo could give a definitive answer on how all this works, but I think you'll be fine just installing 3.5.0 over the old version.

I love the layout changes - nice one However, on another note there is a difference to how commands are reflected in the camera view. It sounds really minor, but it's very noticeable when working. As an example, if you say had some objects selected and then pressed a shortcut key for 'hide', the objects would disappear immediately from the camera view. Now in 3.5.0 they disappear from the ortho view immediately but not from the camera view - you need to right-click on the camera view again before they disappear. It's the same for other stuff as well, like adding entities. If it's intentional, it may take some getting used to - but I can't say I like it. If not, I'm happy to raise a bug report? EDIT: I restarted DR and it went away, so ignore for now. I'll come back if I figure out what was causing it...

I just noticed that DR allows duplicate info_player_start entities in the map (you can just clone them). Is this intentional? If so how can it be leveraged? If not do we think this is a bug?

that's done it - thank you!

okay - I guess brushes it is then Thanks for taking the time to put that together!

I've tried that, but all that seems to do is just add more subdivisions, and doesn't affect the way the patch bends (at least for end caps). I've also tried adding/extending rows/columns but it never has the intended effect. Maybe it's not doable? I've admittedly done that before and although it's crude it's fine for a one-off, but I'm trying to figure out how to do it properly. It seems like the kind of thing that a video tutorial would help with, but I haven't come across any that do this. If anyone knows of one that shows this I'd be grateful