MirceaKitsune

I do NOT wish to revive the discussion on how useful hide_distance for lights is if possible, not because I mind but due to how hot the issue remains. However I must bring up some issues I discovered in the current implementation, after trying the latest snapshot and finding some breakage on my map where the feature is now being used. As I'm among those who wanted this the most and am actively testing it, it more so feels my duty to report anything it might be breaking. https://bugs.thedarkmod.com/view.php?id=5699 Essentially torches aren't hidden by default, their light source shows up until you enter the hide_distance then exit it. It also ignores lights that start or were turned off... a lamp disabled by a trigger will show up as lit when you get near it, instead of appearing as the unlit / extinguished model unless it gets triggered again while shown or hidden. With this occasion I noted another problem which isn't light exclusive but affects even func_static ents: If you set "hide 1" on a mesh but also give it "hide_distance #", the LOD overrides the hide parameter causing the entity to become shown / hidden with distance exclusively. Ideally the two shouldn't conflict: A model with both spawnargs set should dhow up when both within hide_distance AND not hidden. Remember that hide can be toggled by triggers.

Mappers are definitely competent people too, though often need the proper tools to do their work: We wouldn't be anywhere near as good at it if DarkRadiant wasn't such an easy and awesome map editor after all Drawn map versus generated map should indeed be a choice of the FM in this format, both are valid approaches. There are mainly two issues with the current map system: On the mapper's side, it's extra work drawing a map for your FM... some mappers might not be good 2D artists, or may not have a drawing tablet which is kind of a necessity to do such a thing right. On the player's side, you often have to guess what the map is meant to represent especially when it's not detailed enough... it's a nice mental challenge I admit, but like I said there comes a point (in many FM's) where you're stuck for more than an hour and have gotten sick of walking back and forth trying to figure out where you're supposed to go while wondering if you understood the indications right. Mind you that usually happens because a switch or door or key is well hidden and you can't find that little crevice where the item needed to progress is located... having to ask yourself "is this really that building on the map where I should be looking or am I on the other street" is a big annoyance in those cases.

Agreed. There seems to be consensus (including my own stance now that I think about it) that if anything this should be a feature the FM author enables on their level if they want to. For a minimap it would make sense to have an universal implementation, that would be a HUD component that shouldn't be intermittent between maps... for a map item however, definitely should be the mapper's choice and item dependent. This makes more sense as an alternative for authors who don't want to hand-draw the map for their mission, on top of which stuff like interactive markers can also be allowed if the author wants their map to have them.

On this aspect I actually agree with what you said. One of the things I simply can't stand in AAA games (albeit I don't play them but watch videos) is how they treat the player like the last idiot: Take one step, a big popup informs you that you need to press left-click to fire... another step and blam comes a tutorial for the skill system. Back in my day (coming from a 32 year old) games had dedicated tutorial levels which you only loaded if you needed to, you weren't covered in popups for every tiny thing. Whether a more interactive map counts as too much hand-holding is debatable. I for one find fun in the challenge of looking at a drawn map and figuring out the area I'm in, which is also more realistic since the ink of a map drawn on paper doesn't morph to produce an interactive arrow (if this was a scifi game it would make sense with electronic maps). At the same time I could see myself enjoying the added detail of a map that makes it clearer where you are, especially when you're playing a level for the first time who's layout you don't entirely grasp and you get lost figuring out what you need to do next (this does happen rather often in TDM).

Yes, there's also a more fitting middle option: We could display the map image on its inventory icon, including the arrow showing the player's location. Pressing the use_item key then opens the full map so you can see it properly. Would be similar to how the compass works. This is a solution I'd wholeheartedly support

Just updated to the new snapshot that was just made available (dev16342-9552) which contains all changes made to LOD and hide_distance recently, including the controversial light hiding but also fixing noshadows_lod_# and other fixes. Wanted to say my map's performance has improved ever so slightly but noticeably so! In a spot where I previously had some 1.300.000 tris reported I now get 1.000.000 and moving the mouse practically feels a bit smoother when looking around. New functionality is great and all the changes were worth it, cheers to duzenko and the others once more for those fantastic fixes

If any dev wants to pick this up and my help were of aid, I could try making the GUI / HUD component as I played with guis and scripts. The part I can't do is what goes beyond the possibilities of scripting... namely code to sketch a transparent image from brushes and generate a dds / tga, this needs new engine code. If it was to use an image made by the mapper, I could likely implement this on my own: It would only require a script moving and rotating the map on a GUI based on the player's angle and position. But imagine trying to sketch an image that perfectly lines up with world brushes, every single wall... not creating that for my FM's lol. Then again, DarkRadiant sketches 2D viewports for its functionality. What if we allowed it to export the top-down view to a transparent png and use that in the FM? @stgatilov @OrbWeaver what are your thoughts on DR exporting a map sketch using the existing system to render 2D views? Note that I'll be going on a trip soon. I'll be online from an old laptop which would probably catch on fire if I even tried running TDM on it

With this approach existing FM's shouldn't be affected; Image maps would remain as they are and new FM's can continue making those if they prefer. Procedural maps would be best as a new item that can be placed on the map. Whether or not the player or certain AI show as an arrow can be a spawnarg of that item (gui_parm#). Extra idea: This would definitely be implemented as a GUI in any form. We could also allow placing such maps in world, letting the player only see them on a wall if the FM prefers that approach better. This way you can go to certain locations to see where you are.

A thought on what's been said so far: Once a system to generate / render / rotate such maps is in place, it will be no problem to render it at any size or position. You can make it a minimap, a main map item only (larger version), even both of the two if we wanted to offer that possibility. Minimap is the mainstream system, a small circle in a corner of the screen; To be fair even I don't think that would be fitting to us, given how minimal our HUD is and how out of place this large circle might be. I'd also be more in favor of a system like the one in those videos, where you hold a map in front of you and can see your position on it. Which makes me wonder: What if instead we could think of an alternative to the existing image maps? Most FM's contain a map already, but they're a rough sketch created by the author which obviously don't show your position in realtime. We could have a generic map item with the same paper background, except the sketch is generated by dmap, with the player and potentially some AI showing up as arrows. This would make maps a lot more useful: I can usually never orient myself in them from the sketched image.

I spent the day configuring the mappings to something I felt I could learn and use properly: The default configuration is less than ideal IMO, this could make for a nice default if other devs agree. This isn't perfect or free of all cumbersome combinations, but it's more organized and prolly the closest you can get to perfection that with the physical design of the controller; With this setup I'm actually getting the hang of playing TDM on an Xbox style gamepad! Unlike shooter FPS's you don't need as much precision in aiming so walking and turning with the dpad is pretty fair and efficient. If other wish to test my setup, simply overwrite the contents of DarkmodPadbinds.cfg with: unbindPad bindPadButton MODIFIER PAD_START bindPadButton PRESS PAD_BACK "inventory_hotkey ''" bindPadButton LONG_PRESS PAD_BACK "escape" bindPadButton MOD_PRESS PAD_BACK "_weapon0" bindPadButton PRESS PAD_A "_inventory_use" bindPadButton PRESS PAD_B "_inventory_drop" bindPadButton PRESS PAD_X "inventory_use '#str_02395'" bindPadButton PRESS PAD_Y "inventory_use '#str_02396'" bindPadButton LONG_PRESS PAD_A "_inventory_grid" bindPadButton LONG_PRESS PAD_B "_objectives" bindPadButton LONG_PRESS PAD_X "savegame quick" bindPadButton LONG_PRESS PAD_Y "loadgame quick" bindPadButton PRESS PAD_UP "_inventory_next" bindPadButton PRESS PAD_DOWN "_inventory_prev" bindPadButton PRESS PAD_LEFT "_weapon_prev" bindPadButton PRESS PAD_RIGHT "_weapon_next" bindPadButton LONG_PRESS PAD_UP "inventory_cycle_group '#str_02392'" bindPadButton LONG_PRESS PAD_DOWN "inventory_cycle_group '#str_02389'" bindPadButton LONG_PRESS PAD_LEFT "inventory_cycle_maps" bindPadButton LONG_PRESS PAD_RIGHT "inventory_cycle_group '#str_02391'" bindPadButton MOD_PRESS PAD_UP "_weapon4" bindPadButton MOD_PRESS PAD_DOWN "_weapon3" bindPadButton MOD_PRESS PAD_LEFT "_weapon1" bindPadButton MOD_PRESS PAD_RIGHT "_weapon2" bindPadButton PRESS PAD_L1 "_jump" bindPadButton PRESS PAD_R1 "_crouch" bindPadButton PRESS PAD_L2 "_inventory_use" bindPadButton PRESS PAD_R2 "_frob" bindPadButton PRESS PAD_L3 "_lean_left" bindPadButton PRESS PAD_R3 "_lean_right" bindPadButton LONG_PRESS PAD_L1 "_mantle" bindPadButton LONG_PRESS PAD_R1 "_speed" bindPadButton MOD_PRESS PAD_L2 "_parry" bindPadButton MOD_PRESS PAD_R2 "_attack" The next / start key acts as the mod key: Hold it to operate the weapon, meaning parry instead of using the active item (left trigger) or attack instead of frobbing (right trigger). The arrows are used to cycle through stuff, long presses cycle through item categories. The A / B / X / Y buttons are used to activate items, with long presses showing objectives / inventory grid or executing quicksave / quickload. Left action button handles jumping (short press) or mantling (long press), right one does crouching (short) or sneaking (long). Lean by pressing on the dpads, both at the same time to lean forward. The back / select key clears the selected stuff, hold to enter the main menu.

Looking for more feedback on this as well, please help test it! Anyone tried the arcade so far in your FM? Found any other issues? What do you think about it and the current functionality? I'm hoping the gui / def / script at least can be included for 2.10, this would be a fun minigame to have available for mappers by default.

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.