MirceaKitsune

As the song goes, YOUWANTEDTHIS! Please move all discussion about minimap support there. I shared my thoughts more in depth on how I think it can be done, feel free to complete them or add your own. Let's please talk about the flash arrow here and what you think about the last pk4 I posted.

A few days ago in the thread discussing the flash arrow I implemented, someone uttered the word "minimap". Since that day my thread has been off-topic discussing the pros and cons of such a thing, as I struggle to find anyone willing to test and offer feedback on the mod in cause. Though this isn't a feature I normally intended to bring up, I'm opening this to move the discussion and get mine back to its original subject... and admittedly because the debate got even me intrigued in the idea. You wanted minimap, let's talk minimap Let us begin with the possible implementations as I see it. There's an easy way which is less than ideal, and a hard way that would be far better. The easy way is having the mapper draw the minimap image for their map, only enabling it if the FM includes this asset. That would require the least development effort, but moves the burden of minimap support to the FM creator who already has a lot of work to do. A small plus is the author has full control over the style of their minimap... this would however result in inconsistent styles, while the mapper needs to carefully trace every wall and building so it lines up with the brushes in the map which would be tedious to say the least. The biggest downside yet is none of the existing FM's would support it: It would only be a feature for future maps or updates to old ones, IF and WHEN the author chooses to use it... this makes it intermittent and even in the future only some missions are likely to benefit. All in all this solution feels pretty meh, though better than having no support at all? Then there's the harder way: Automatically generate the minimap image. The engine learns to scan for walls and sketch them from a top-bottom perspective, including both worldspawn brushes as well as every static entity that never moves (everything func_static at a minimum). This would be harder to code but takes the responsibility off the shoulders of mappers. Best of all it automatically works in every FM, no need to update old maps to include minimap images! The style would also be consistent across missions, the player able to customize the colors and appearance for all missions to their liking (via cvars). Another bonus is we can generate multiple minimaps for different locations and switch between them as the player enters / exits certain areas, possibly based on zones separated by info_location delimiters, which helps avoid overlap and confusion for different heights and floors; You see the minimap of the city when outside, then switch to a minimap of the building when entering a home. The ideal solution would be dmap generating the minimap image(s), but one problem then is dmap would need to be reran for all existing FM's. If precompiled the minimap image(s) should probably be stored in a "minimap" subdirectory in tga or dds format (eg: "darkmod/fms/myfm/minimap/info_location_1.tga"). As trivia I can point out this is what the game Xonotic does, with its own map compiler q3map2 generating a minimap.tga file from brushes. With either approach the minimap should be a menu option the player can disable and at least adjust the size of. I'm also thinking of making it item dependent: It should be possible to make it show up only if the player owns the compass item, or possesses a map readable meant to represent the map for that area... on this I'm kinda neutral and would go with the compass option for ease and consistency. Guards and important items could show as markers on the map depending on circumstance: It's debatable what and when should have a marker for AI or items / objectives, as marking something indicates the player has knowledge of that item and its location. As I said on the other thread where this discussion was thrown, I don't consider minimap support an emergency especially if no developer has the time or energy to put into it, but would find it an interesting and modernizing feature if it happened. Since some people seemed eager about the idea, share your thoughts on it here please! An image was shared in one of the posts... I take it an edited screenshot rather than an addon someone made for a real FM, but will end this post with it to give a basic feel of what we're looking at.

The first question that comes to mind on that is how costly is the distance itself to calculate, especially at the default dist_check_period of 0.5. As far as I can tell without knowing the code, the check simply uses the origin of the entity and that of the player's view to compute a distance float, only deciding to do anything if that float is below or beyond a certain value. Should be a very easy mathematical operation on the CPU: I'd suspect even 1 million of them should be possible to calculate with ease, though that's purely an assumption not a fact and this should be tested before drawing a conclusion.

Got the controller working perfectly with TDM! The issue appears to be that joysticks based on the older D-input architecture aren't recognized by our engine: You need to use the X-input (xbox controller) architecture. Currently there's a bug in the Linux kernel module which causes the controlled to not be initialized accordingly and require a script to fix after it's plugged in; With this script I can successfully use my new gamepad to play TheDarkMod on Manjaro Linux

Fair enough. Anyway I got my gamepad and found a configuration that works with Linux. Am able to play Xonotic on it, including looking around with one thumb stick and gradual movement with the other! For TheDarkMod however nothing happens, it's ignoring the thumbsticks and buttons entirely: The buttons cannot be set in the menu and the dpads aren't working either. I have the in_pad* cvars set to their default values; Do I need to set a special cvar to enable gamepad support first?

You're tempting me to open a separate thread about the minimap to get this back on topic. And I warn you that if I do I'll talk about the engine procedurally sketching its image from brushes and static entity models... per portal zone to generate different maps and switch them with area. Do you want the developers to deal with knowing that someone legitimately brought up such a thing

Thanks for the extra clarification. Yeah, I guess separate versions might make sense considering all this. Just so many light types that there's going to be much duplication... then again it's just text so it's not like it increases pk4 size or anything noticeably. Honestly I'm just happy we'll have this by default next And yes, that's one thing I should have pointed out: The default flame particle textures are colored yellow by the image. Even the colored flames I made were essentially applying extra colors on top of yellow, which kinda looked bad if you paid close attention. We'll need a grayscale flame particle which is white by default.

Seems gamepad support was first added in 2.09 and there's an article about it on the VR branch. I'm assuming this isn't a VR version only feature: Such gamepads have existed for ages for standard games. I actually have one that's 15 years old, stopped using it because some buttons aren't making proper contact any more and it otherwise felt too ancient... USB and even has force-feedback! I got it before Doom 3 was released if I'm not mistaken, so I'd imagine support for gamepads might have existed in vanilla idTech 4.

So this online store I bought a pair of headphones from decided to gift me 12$ today. Since the voucher would expire in in two weeks unless used and I had nothing else to get, I decided to spend it on a 17$ gamepad so I'd have one of these as well. I understand they should work fine under Linux these days, plus it supports both dinput and xinput so I'm not concerned. I never played any FPS or most games using something other than the keyboard and mouse, this feels like an interesting opportunity to try it out. TDM is one of the games I might enjoy playing with such a thing, especially since it doesn't require super-fast reactions till I get used to it like a deathmatch shooter. So until the device arrives tomorrow, I figured I'd ask how well I can expect TDM to run on such a thing! Especially now that we have a new rendering and input management system for the upcoming TDM 2.10. There's a few things I wanted to know. One is if both looking around as well as movement using the finger pads is supported. I remember some games allowed walking more slowly if you only pushed the pad slightly; Does this mean it's possible to sneak by only moving the pad a bit, in a way that affects how much guards hear you? Otherwise I was curious if force feedback (vibration) is implemented and used. For TDM this mainly makes sense when you take damage, are in radius of a sound that has the shake effect, and other potential situations I might be missing now. Is gamepad vibration a feature in the engine at least?

Likely network connection. TDM updates are pretty fast for me, however FM downloads for anything over some 30 MB take a long time... hence why I prefer downloading large FM's while playing TDM actively, the download process doesn't seem to cause any conflicts with an active game being played simultaneously.

I see your point. Only part I may disagree on is that someone forgetting the _color spawnarg on a torch should keep us from properly implementing this: Did anyone even do that in existing FM's, and if they did would it count as breakage to assume it was intended and just let it work all of a sudden? Would like more opinions on that. But even so we have another option: You clarified the new functionality requires setting the additional spawnarg "propagate_color". What if we simply don't enable that on the default light entities but configure them so they're compatible with it? That way, in order to colorize a torch or candle, you need to set both the propagate_color and _color spawnargs... if you set the two of them though they would work without requiring additional defs and it wouldn't risk changing existing FM's either. As for brightness, isn't it possible to adjust it from the color? So if you want a blue light that's as bright as possible that's "_color 0 0.5 1" but if you want half the brightness you can set that to "_color 0 0.25 0.5" instead. I love the appearance in that screenshot still, that feels very right and pleasant to me!

Oh... there is the option of having the mapper draw a minimap image, which the engine then knows how to position and rotate based on the player's orientation in the world: This shouldn't be hard to do with a script and custom GUI definition. The true nightmare would be the engine learning to generate it automatically using brush and model information on the map, which would obviously be the only way to have it working universally in all FM's including existing ones. My take on that is "this would be cool but good luck getting anyone to do it". But yeah this discussion needs its own thread if anything. Right now I'd appreciate it if someone could please test the pk4 I updated again, potentially share some screenshots or a Youtube video of how the arrow looks in a complex map and how it's helping the player gameplay wise. As a reminder, the new functionality turns this into a flare arrow as well, usable to light dark spots at a distance without turning on your lantern and alerting guards to your location. Don't want to be pushy but I don't like feeling that work with potential (be it mine or anyone else's) might go to waste and be forgotten in a corner, even if I started some addons out of my own initiative. If I could spend hours creating and tweaking those changes I'm sure someone can spend 10 minutes relaxing with the pk4 to see how it works and share suggestions See my previous post on how to spawn the ammo in any FM without even needing to edit a map to place it manually.

Interesting: I was sure this must be a deliberate decision and feature. Wouldn't have thought a bug would cause such an effect on its own. The question is what shouldn't change: The X and Y scale of a surface should remain the same if you only edit the texture on that surface. Currently when setting a texture with a different resolution on a brush face, the scale automatically changes based on the difference in resolution between textures. In screenshot 1 I have the texture textures/darkmod/stone/brick/blocks_brown set on the selected face, at a scale of 0.25 x 0.25. In screenshot 2 I change this texture to textures/darkmod/stone/brick/blocks_sandstone01. I did not edit the scale though: The vertical scale became 0.5 on its own.

Not necessarily a bad idea? Probably easy to implement with a particle effect. That might make everything too simple and lazy for the player still. Anyway it's kind of its own feature and discussion which would involve all of the arrows. Minimap doesn't sound like a horrible idea in theory, I just don't see anyone struggling with the effort of implementing something so hideously difficult from multiple points of view. As for icons above AI, those would only make sense if complex dialogue and interaction with AI is ever implemented... something I maaaay do as a mod now that I'm such good friends with the scripting system, I had certain ideas in mind such as trading with AI But this too is its own separate discussion... might open a thread since it would be worth talking about it before I'd decide to spend time working on another addon.

Yes, I played with particles a bit and noticed this: If you give a particle paragraph the parameter "entityColor 1" it will ignore the default color and colorize based on the _color spawnarg. That's obviously what we want to use in this case. The limitation is that particles are produced by the flame entity, thus this ent must take care of coloring them. TDM defs are configured so a candleholder entity spawns and attaches a candle entity, which in turn spawns and attaches the light entity: The entity at the base of the chain is placed on the map thus it must send its color setting to the top ent. So I'll need to wait on the change you mentioned... great idea BTW, thank you and @Dragofer for working on it! And you know... I have to wonder: Should my pk4 really be needed any more in that case? Once the change you mentioned is ready, setting the color on a torch will automatically colorize its light, correct? Only other thing needed to allow colored flames is letting the default flame particles be colorized as well! If that extra change is acceptable, we should simply let all existing flame and gas lights be colored by default, just as electrical ones can be already, no need to bloat the defs with extra _colorme versions! Obviously their existing looks shouldn't change, all candles and torches should look the same as now by default... just that once you add the _color spawnarg to them in your map, both the light color and flame particles know to use that instead. Now that's an exciting thought, would be so convenient and encouraging for mappers to use then

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.