Frost_Salamander

I just gave them a quick try. Pretty neat. One thing though - if you fire multiple arrows they have a cumulative effect (i.e. the area gets progressively darker or brighter), I guess by creating a new light each time? This causes the framerate to tank. I suppose as a player you wouldn't really need to do this, but just thought I'd mention it regardless. Also if there is a concern they are overpowered, maybe consider lowering the time the effect lasts - I didn't time it but it seemed much longer than you'd need to just slip by a guard or whatever.

okay - that's all fine. For this particular feature, I think it would be a good one to offer mappers instead of a mod because it seems like it could be suited to a particular map/theme and reagent placement, etc. But I know what you mean - if nobody bothers including it in their map, etc.

So it happened again. I normally have the camera in its own window (undocked). If I dock it and then undock it again, the problem goes away.

Okay. I'm just wondering how it's going to work though. It looks like you are still deciding what arrow type to base the functionality on? For example, say it's broadheads and a player has 10 broadheads in their inventory. Does that mean they will be able to create 10 light arrows? Will you need 'reagents' or something in order to craft them? If so, where does one get those? As a mapper I want to understand how this will affect gameplay. Will it neutralise a carefully crafted electric lighting scene that is meant to be challenging? By the way, it seems like a cool idea though.

Will this be a part of a modpack or a .pk4 that mappers can include in their FMs?

yes - I blew away the entire DarkRadiant config directory and started from scratch. That seemed to fix it. If it happens again I'll try to be a bit more surgical about it.

I'm actually having similar issues in Windows. My mouse works fine, except in the DR camera view. If you rotate the mouse, the view gets thrown around all over the place, or keeps jerking to the right. This has happened before briefly, but a restart fixed it (I think - it was quite awhile ago). Now it's happening all the time, making DR unusable. I just tried tweaking the camera movement settings, and now it's even worse. Anyone know of any external things that may affect this? Like mouse or Windows settings, etc?

nah. I mean they are all grid-aligned anyways. Regardless I tried it and it didn't do anything. I'm hoping this is something to do with my local machine or something. I guess we'll find out sooner or later.

sorry it's hard to notice, they only appear when you are a good distance away and at a certain angle. It's just little artifacts around the edges of the portal. At some point over the last few days these started appearing. Here's another one zoomed in a bit:

I'm getting a lot of this type of thing with visportals in my current WIP. Is this a known issue, or due to some graphics setting/problem? This is 2.10 still.

Yes models (func_statics) can safely be embedded in brushes. In your case, the brush touching that roof doesn't need to be portal_sky, just use caulk. You only need to make one surface in the rendered area use portal_sky - the easiest is to just put in on the ceiling. Most of this is covered here: https://wiki.thedarkmod.com/index.php?title=Caulk

ok thanks. I definitely didn't get any reports of 100 FPS frame drops in beta or since release. Sounds like I'll need to get you to beta test my next FM

thanks for the feedback - always useful. The small rooms/cramped feel is somewhat intentional. If playability issues were mentioned in beta I likely would have made changes, but I don't recall any around that (but I get what you're saying). Regarding the performance drops, it would be handy if you can remember what areas they were in and your hardware setup? I'm aware of a couple of areas where it might drop on lesser hardware.

My advice would be to use the 'objects' if you can achieve what you want with those. Reasons being: you're not reinventing the wheel saves time they've been tested I don't know about the performance part, but I would assume performance was something that was considered when they were designed/implemented. Having said that, they obviously don't cover every situation so in those cases script away. I gravitate towards scripting as well because I used to be a programmer (and still sort of am to some extent). I've also used them when the native TDM stuff doesn't quite work as expected (bugs, poor documentation or just me being dumb). But a couple of times I've realised that I can do what I want without scripts and have reverted to using native TDM objects instead. Also, if the scripts get complicated, they require a lot of testing which you may or may not feel like doing. So in summary, my approach is to use the native tools first and keep the scripts in your back pocket for when they are really needed.

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.