MirceaKitsune

I don't like the black outline personally. It's actually cool in its way, looks like a void field... not as a default though it looks off, good as a custom option.

A bit dimmer it can be, agreed with trying that. I'd keep the color white, IMO no default color will match all environments, otherwise a little less alpha could do.

Only thing I care about is for the frob outline effect to remain on by default, it's a beautiful and modernizing addition that needs to stay. As far as the menu goes, am okay with whatever... would recommend one setting if possible though, to have both outline and frob helper together in some form.

Keep in mind though this will cause the highlight not to appear correctly for some items and be covered when you don't want it to, such as doors where it will be obscured by the doorframe when closed. I preferred that option myself but upon testing I agree with the current default for the majority of frobable items.

Or make it a single menu entry with multiple options? 1 = "Off", 2 = "Frob helper", 3 = "Frob helper and highlight". Or something among those lines, whatever works best.

I'm in favor of keeping the menu clean and only having popular and necessary options: IMHO that's the softest approach especially for less technical users. As far as the obscure settings go... just a thought: Many games now have a menu that lists all vars and lets you edit them, as seen it in both Xonotic and Minetest. It's a list that dumps all cvars, their value, and their description... you can click on any and set the value manually, just from a GUI instead of having to search from the console. With some category grouping added to the mix this might make some users happier to have. To offer the actual example:

Exactly. Like you said though, running the engine on Wayland requires the X compatibility layer, which is a just that: A compatibility layer. Being able to use the features of Wayland natively is the safe route for the future, and from my understanding it may result in better performance thanks to the improved rendering pipeline. But I wish to clarify I didn't open this thread to say "do it now"! Also Cabalistic said he doesn't want to bother with it which I respect, if other developers want to let us know. I wanted the discussion to be existent and kept alive for now, since at least in the future this will likely become important depending on which direction Linux goes. From articles I remember reading a few months ago, some Linux distributions already went Wayland exclusive, meaning they offer the WL session by default when installed. So it replacing X11 is already happening for some distros, we are still in a transition period. X11 should of course remain the default base, that's still the standard for a long time: If the team figures out the process to compile the Wayland engine, it should remain a secondary option especially for now when we'd do initial early testing.

This was discussed briefly on Discord some time ago, I wanted to bring it up here as well for consistency. I don't believe it's an emergency but do consider it an important change especially later down the road, as Linux is slowly moving away from x11 with many distros already going full Wayland by default. In my case I'm pretty much waiting for KDE Plasma to fix a few bugs left with the DE before permanently switching from X11 to wayland too, I might be able to make use of it rather soon if they do. With the new input and rendering system introduced after 2.09 and available for testing in the dev builds (GLFW) we're on our way to having a Wayland compatible build of our engine. Meaning the engine is able to render natively to the WL pipeline, without having to go through the fake x11 server simulated by the Wayland session for compatibility with X exclusive apps. This not only offers proper compatibility for Wayland users, but may improve performance on various fronts which was one of the goals of the new rendering framework. From what I remember @cabalistic telling me, we can't have the same engine for both x11 and Wayland: It must be compiled against different system packages to produce one version or the other. For Linux users the installer may need to offer two engine binaries in this case, or an option to pick which version you'd like to install if that's better. Other than that I understand it should be able to produce in theory, as SDL2 and GLFW both offer Wayland compatible libraries to compile the engine against. I'm not familiar with the C++ code in the slightest so I'll let the experienced developers complete this with the proper technical additions.

Yes, likely too early of a target. 2.11 might do hopefully. Hope to have it stable enough and tested to use in FM's soon.

Didn't know anything I said came out as a troll style post. I did try to move on and keep to the discussion best I could, though some things felt I should offer a legitimate reply to as they were addressed to me. Personally I tend not to care that much about those things any more: I get upset in the moment then move on. peter_spy looks like he can handle it too, doubt these arguments keep him from sleeping at night. Was worried about others being bothered by this, or getting the wrong idea about the community like you said. All in all this community has always been cool in the end, including now over this situation... if everyone else isn't falling into a long depressing sigh whenever it happens, I'm fine with whatever really. I know what real issues look like on and off this internet... only thing that can truly upset me is real malice crossing a certain line, which is in no way the case here, albeit stubbornness has its role. Guess I've got to accept a feud has formed. No idea how, over what was supposed to be a mere code change of all things... not something that happens every day (someone who does development for a living is so gonna correct me on that). Only time something similar happened was in Nexiuz (now Xonotic) over a decade ago, where me implementing an universal reload system for all the weapons made one developer passionately hate me for the rest of their lives for reasons I never fully understood to this day Now that I got these thoughts off my mind, this thread feels like it needs to go in a long night's sleep to recover xD

TDM is in an interesting position world wise: It's meant to take place somewhere between the 1600's - 1800's but not in a historically accurate version. Apart from having undead which don't exist in real life (as far as we know ) there are many technologies that didn't exist at their time, envisioned as they would have been if they did. One thing that inspired me for this was the inclusion of the automaton AI, along with other beyond-their-time inventions like the steambot or camera: I figured another exception wouldn't hurt... long as it matches the style, hence why I decided against a retro background or 8-bit music but left it looking more like an interactive paper (who knows how they built the device). Though as a mod for this mod, I might make one with custom assets such as pixelated graphics and 8-bit tunes, for just those FM's that wanna go there. Including it with a FM first sounds like a good way to test. I'm working on one which will likely feature this asset by default, but it's still got a long way to go and will be released later after 2.10. Only FM I actually got around to releasing was Scroll of Remembrance, which I've been thinking of redoing due to the horrid performance and the fact that I didn't monsterclip anything as I didn't know I should at the time; Maybe I should take the opportunity to throw one of these machines in there? In the meantime, if anyone's working on a FM where they feel this might be fitting, do feel free to include it!

He has a way of provoking me to respond sometimes, doesn't matter any more really. Wanted to be sure you and the devs following this are aware of the bugs I found today... no emergency on my end, it's just so 2.10 doesn't come with any obvious breakage especially from a change I also supported and have part of the responsibility for, IIRC the next release is still months away. Should have followed my intuition and sent you a PM instead, oh well. I hope there's nothing else I have to report or say on this matter again: It should be the last issue with hide_distance I'm aware of, the LOD code seems sparkly from what I'm seeing. I'm kind of in favor of closing this thread now or letting it die for a long time, I'm not aware of any other major issue that requires it, unless anyone thinks it may be useful in the future.

Yes: A limitation in the hiding code was lifted, the bug was that it was ignoring light entities entirely, now it allows the functionality of hiding those too like literally all other entity types. You aren't even making sense any more... now you're nitpicking at words to find a reason why I must be stupid because I supported a change you don't like. How much longer do we have to keep doing this? Because I'm not interested in entertaining it whenever I try to have a discussion here. Again I ask that you please let us discuss the LOD system without trying to start drama each time this comes up in some form, before this thread is gonna need to be closed over it. Thank you.

Please. I literally found a bug and wanted to make sure the team is aware so we don't have a release with broken functionality that would be brought up later. I was thinking of not reporting those issues because I knew you're going to see it. You don't need to respond if this doesn't interest you, but let us discuss bug reports at least.

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.