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: