MirceaKitsune

To make testing even easier, I found this technique will work well (thanks @Dragofer for the suggestion): Just place the pk4 in any FM you're actively playing, then in-game open the console with the ~ key and use the following cheat code: spawn atdm:ammo_flasharrow inv_ammo_amount 50 This spawns an arrow in front of the player which gives you 50 flash arrows when picked up. No need to modify any map and add ammo items to test it.

Moving on: I did in fact find another glitch with the spawnargs, which I reported a few days ago but forgot to share here as well. noshadows_lod_1 will not work unless you also set hide_distance, despite the two being separate LOD functions. This seems to affect every func_static model, it won't stop casting shadows unless you also give it a hide distance. Edit for clarification: This refers to lod noshadows on model entities, it has nothing to do with those lights! I was setting lod parameters on func_static models and noticed the noshadows property wouldn't work on a window mesh until I also set the extra parameter, the window was still a shadow caster after the given range. https://bugs.thedarkmod.com/view.php?id=5691

Okay... let me try putting this in a different way. hide_distance was created with the idea that mappers should be able to set a distance limit on all entities that have a visual component, particularly ones that can affect performance. This can include meshes, particles, lights, AI, etc... anything except worldspawn for obvious reasons, or objects in the skybox. This is the normal and intended functionality for this feature, to hide whatever you set it on. Right now you're essentially upset because a limitation was lifted and a bug was fixed. As this was never a desired limitation, no one at any point said "we mustn't allow the hide distance to work on lights"; It's just that no happened to add those few lines of code that preform the check on light sources as well. duzenko was awesome today and provided a bugfix closing the gap. Indeed I highly support the change... not because I have nothing better to do, but because now I know I finally have the ability to customize my map and optimize large spaces to the best extent possible as I see fit. I believe this is a good thing and we should move past it. With light hiding now working and out of the way, we should see if LOD remains broken for any other entities. The hide distance seems to be working almost perfectly right now with only tiny side issues, I'll further investigate those that I find and share them.

If a mapper sets hide_distance on a light, it's because they want that light to be hidden and feel that works best. If anyone doesn't like the functionality they just don't set the parameter: There's no reason to make it do nothing or remove a model without its light which is incomplete functionality (hiding a part of an entity without the rest). Now that we have the feature at last I think this side of the issue can be put to rest: Mappers have this added possibility if they consider it necessary, as is right IMO. Of course it will be interesting to see how much it improve FPS in different setups from here. One thing I can add: Small lights popping in and out after a certain distance don't feel very different from medium-large meshes doing so (including the default setup in some prefabs). At least on the lowest LOD setting which is what I use, both are as visually disruptive or as acceptable to me. Lights should use a slightly higher hide_distance than meshes of the same size of course, their disappearance is more noticeable... nothing that can't be made to work out though. Support for fadein / fadeout range on lights too would be nice for this reason. Of course I am NOT that greedy to suggest implementing that too right now: I'm happy with how things are as of today, even if there's no transition this is good.

I'm not getting into this again. I understand you didn't want the feature and can respect that, albeit I don't see a reason: The only thing it does is complete an existing feature and give mappers proper control over their map's functionality and performance. Unless the default light entities are modified to use this (unlikely) nothing is going to change for existing maps, unless any added hide_distance on lights preemptively in the past in which case it was desired. You do NOT have to use it... if others get an improvement from it though, let them use it instead. As for hiding putting AI into sleep, I noticed and can confirm that. I tested it on rats since they're a small detail, indeed they don't move while outside the player's hide_distance range. Technically this shouldn't happen if the spawnarg "neverdormant 1" is set... if that spawnarg is 0, AI should sleep while hidden then. The fix here would be to decide based on that setting.

Wonderful! It's finally there at last. Thank you I think this is the best way in the end: Light hiding as a feature is good to have, especially when we already got it for meshes and all other entity types (it even seems to work on AI which is great). Then it's up to the mapper whether they feel this improves performance without being too visually disruptive, as it depends on how the map and lights are set up.

New version available! This beautifies yesterday's release with proper particles and dedicated sounds: There's a smaller but stronger glow in the location touched by the arrow. It contains a subtle bloom effect pointing in the direction the arrow hit from, with little fireflies slowly flowing in the same direction. The light texture was changed to look prettier and project a slightly detailed pattern. Audio wise there's a new arrow hit sound in place, as well as a sizzle sound which makes the light flicker for a second when spawned. The flare now lasts for 30 seconds, in exchange I reduced its light radius to 256 which feels most decent for such a lamp. New arrow hit sound: Ice & Electricity Magic, by qubodup flash_arrow_1.3.pk4

No worries. If me providing some basics to test this is okay: Open any working map in DR, in which the player can spawn and is large enough to test distance. Right-click in any 2D viewport and choose "create entity". In the menu go to "The Dark Mod 2.0 (Standalone) - Lights - Model Lights, Static - Torches - atdm:torch_gothic02_wall" then click add. Click-drag the entity around in the 2D viewports so it sits against a wall. With it selected (Shift + Left-Click in 3D viewport if it got deselected) press the N key to open the entity inspector. In the two editable fields at the bottom, set the spawnarg at the top and its value at the bottom then press enter: You should see it get added in the list just above. Save the map and open TDM. In the console use "dmap mapname" followed by "map mapname".

I agree: Making them as customizable as possible is ideal, as well as using as few definitions as we can along the way. I believe last time I de-hardcoded the color from the particles and made common particle definitions. To create colorme versions anyone can colorize with a spawnarg would be perfect! Yet I can already see one problem with that; Let's say you have a candle holder, which attaches a candle, which attaches its flame light entity. The candle holder is the entity you place on the map. How do I configure its def so it passes its "_color" spawnarg to the candle, which in turn passes it to the light? The last version works because I still colorize the flame entity only then tell each candle which one to attach... I'm not aware of a way to propagate the color along a chain of attachments instead. Any thoughts?

I'm seeing it with atdm:torch_gothic02_wall: Give it "dist_check_period 0.5" with "hide_distance 1000" and it will pop out together with its light source. Electric lights though, like atdm:streetlamp_round_lit, will not... it likely has to do with how their light source is defined or attached by comparison.

Screw waiting: I went ahead and did it anyway, the idea instantly seemed promising and so far it seems rightfully so. The flash arrow now acts like a flare arrow as well! This comes with new and more fitting light / particle / sound effects that better suit it. I still like the sound of "flash arrow" better so I kept the name as is. Still no custom script required, all is done from the def which is just 135 lines now. How it works as of the new version: The arrow spawns a dim blue light in the spot where it hit, lasting 15 seconds. If the arrow hits right in front of an AI (256 units) the AI becomes blinded just like the flashmine / flashbomb, being incapacitated for a few seconds then becoming alert. Separately from that, the AI will treat the flare as suspicious if seeing it without being blinded instead (1024 units) and will walk to its location in order to investigate. This makes it a dual-use arrow with more purpose: If you want to blind AI in order to run past them, it can be used as a long-range but less effective version of the flash bomb. Separately you can also use it in dark areas to light them up, in case you don't have the lantern item or need to see what's in a dark spot at a distance without walking there... the arrow will illuminate that area without triggering sound alerts, however AI will investigate flares if they see them directly (no alert still). This is similar to how the fire arrow can be used either to do massive damage to AI or to light torches that start off or have been put out; For a flare arrow it makes perfect sense to have these two effects in one Now I find this even more promising and interesting. Please give the updated pk4 a try; The discussion itself is interesting, but since I've been able to create and adapt a working version it would be nice to have it based on actual testing, I'm sure a mapper working on their FM can find a moment to give it a go. Perhaps share better screenshots or videos too: I don't have a screen capturing setup ready to do that. I know for sure I'll want to use this in some of own FM's now, and I'd rather not have to include it as a separate mod in each one, which includes redefining the player class which isn't a very good idea. Feel free to share further suggestions, like how I should tweak the light or ranges and maybe I should customize the particles next to make them more fitting. pk4 and obligatory screenies: flash_arrow_1.2.pk4

IIRC that's already the case: When I tested it wouldn't blind the player if you shot it at a far away wall but would if the wall was close enough. The flash bomb is limited in how far you can throw it. That's one of the points of this arrow: It's basically a way to use this feature at a distance. I like that idea actually. You raise an interesting question here: Do you think this arrow would be more interesting if it also spawned a light source that lasted some 15 / 30 / 60 seconds to act as a lantern, apart from the blinding functionality on AI? Making it a flare arrow could give it an extra use and further make it unique! If you can spawn multiple results per arrow in the def (let me know how) I'll add a limited time light source as well, but I'll only work on that if others think it's worth it. There was also the point of making it temporarily disable electrical lights like an EMP field. This would require a custom script which would then need to be integrated into TDM. But it would conflict with the idea of turning it into a flare light so that's a possibility I'd dump then.

I can see the point and comparison. One thing I'd point out there is that flash arrows are meant to be very different from gas arrows or knowkouts for that matter. They only blind an enemy temporarily so the player can sneak past in a window of a few seconds. No damage dealt to the AI, only a way to incapacitate them for a few seconds. If anything I'd find it more similar to the noisemaker in that regard. Though different from that too: This incapacitates the AI instead of drawing them away, though also for the purpose of helping you sneak past them. The flashbomb and flashmine by comparison are tools of escape when you get caught, not usable to get an AI out of the way at a distance which is the gap having an arrow version of it is meant to fill.

It's been a while since I received any feedback on this feature. As it's an addition created with the hope of being included in TDM by default, I'd like to ask if a look can be taken at this pk4 again please, and let me know if and how anything can and should be changed. From what I remember this patch was pretty much final, implementing the arrow just as desired. It should not affect existing FM's in any way: It just introduces this arrow type for those creators who want it on their map. It's a very logical arrow to have IMHO, I see no downside to integrating the patch. What do you think?

It's been a while since I received any feedback on this feature. As it's an addition created with the hope of being included in TDM by default, I'd like to ask if a look can be taken at this pk4 again please, and let me know if and how anything can and should be changed. I remember that last time, we almost got everything working as intended. A final remaining issue had to do with alpha fading not working properly as the particles were colorized via common definition, due to vertex colors interfering in some form. Has this been fixed in the engine, or are there changes I can and should do to work around it?