MirceaKitsune

First of all, I'd like to make sure we're talking about the same thing here... which if so is something I actually wanted to bring up for a while: When you change the texture on a surface in DarkRadiant, its scale setting is modified based on the resolution. For instance: If the previous texture was 1024x1024 and you set the scale of your face to 0.25 x 0.25, changing the texture to one that's 2048 x 2048 will automatically modify that scale to 0.125 x 0.125. This is something that has been annoying me for a long time: It's an effect I actually do NOT want! Don't get me wrong: I can see why it exists, it helps to keep pixel resolution of a surface the same which is actually neat and handy. But I for one prefer to set the scale manually and keep it at a fixed value as I change textures... typically 0.25 or 0.125. An option to disable automatic scale conversion when changing material resolution would be appreciated so I don't have to reset the scale whenever replacing textures. I don't want to see this conversion removed nor necessarily disabled by default (I'd have a vote on that one). But please add a setting (maybe a toolbar button) to disable it when not needed and the mapper wants to keep the scale the same while cycling through textures.

If both the font size and color can be customized, I am a happy player: If I don't like the new defaults I'll write my own in autoexec.cfg. Can't wait for the next dev snapshot, now for yet another reason... the past few months / weeks have been amazing for TDM

Oh... I remember cmake suddenly asking me for something called Eigen after a git pull a while ago. Thankfully that's a vanilla package in Manjaro OS, I simply installed the library and everything worked great again (no related issues I could spot). This makes sense now that the improvements are explained. Silly yet legitimate question: Would the engine also using this lib for similar calculations result in a performance improvement?

Yes, but you also need to know the size of the AI, correct? And I believe it doesn't use a simple bounding box you can just store, but its own animated collision model... drawing this conclusion from how AI playing certain animations push the player away if they're standing right next to the AI.

Just a reminder: I don't have TDM properly set up to run from SVN, I'm waiting on the next dev snapshot to test the latest changes in my practical FM. If I see anything significant I may mention... kind of afraid to pursue the issue further Didn't think of that, it makes sense in this case. If collisions also get disabled when an entity is hidden AI obviously can't navigate. If that's the case this is one that can't be resolved, and I'm fine with that if it's too problematic to attempt. hide_distance should work on AI too, but in this case mappers should be made aware it will put the AI into sleep. Which reminds me: The dist_check_period and hide_distance parameters don't appear to be documented on AI entities in DarkRadiant, they work but DR treats them as custom undocumented values. I'd fix that if possible, while including the added spawnarg description that AI stop walking and reacting past the hiding distance. Gotta ask though: If this is the case, how do AI still navigate in a room closed to the player by portals? Does that use a special type of hiding by comparison, so AI entities still have collisions while being derendered? What if we used the same system for hide_distance in the case of AI entities?

I definitely like the later appearance better! Could be even a tad smaller IMHO, though the new version is good. Would it be alright to ask for a screenshot with the cyan font turned to white too? Was curious to at least see if that feels better. I know that's a slightly different matter, sorry if I'm conflating two similar but unrelated issues here.

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?

Just found something really funny: hide_distance already works for torch lights in the latest dev snapshot, including turning off the light source as desired! It only doesn't work on electric and standalone light entities. So we actually have this half implemented now, if anything it's an inconsistency... it just needs to be fixed for the remaining light types and that's it

They can. tdm_flowerbed_*.prt for instance is lit correctly, already using that and getting the best lighting results possible with particles. I noticed most smoke particles appear to not be lit either. In their case it's a darker texture so it's not as noticeable. Still could they be fixed too? It would result in more realistic lighting, and this doesn't seem like it affects performance noticeably either from what I'm getting so far.

https://bugs.thedarkmod.com/view.php?id=5690 One comment for each asset taken from my earlier posts here. Hope this helps and they can be fixed before 2.10: I'm on the dev snapshots and updating, thus I'll keep track and add new entries there if I continue to find problematic ones.

https://bugs.thedarkmod.com/view.php?id=5689 Done, thanks for confirming. I don't plan on releasing my FM before TDM 2.10 so if it's fixed in the next release it's all good.