MirceaKitsune

Oh wow: EAX has builtin support for this? It's what we're using for sound processing so that's promising! Being able to hear yourself in-game would be welcome with such an addition, especially if it's already there in OpenAL and this isn't asking the devs to code a whole new system from scratch. Should be an independent feature but under the same category... I'd see this stuff having a microphone section at the bottom of the Audio settings menu. There would need to be a customizable volume threshold on both the low and high end: Sounds under a certain intensity are ignored, the system only activates once the input is significant enough. On the other end the player shouldn't have to scream to produce an alert, just talking loudly should be enough. The setting should probably have two sliders to adjust the minimum and maximum range, ideally one slider with two dials if GUI allows: Mixed with the volume controls in the OS this should allow each user to calibrate the range to their liking. Normally I'd suggest a volume bar in the menu for preview, like what recording apps have to see the microphone as you talk... I assume people already think I'm crazy for discussing even this entire feature, I shall not exaggerate. But yeah, talking is the point. That is if we're talking about a way to distract guards, this shouldn't require actually talking to the game just saying a simple "hey" once... if we're looking to not raise an alert not talking is the goal then. And yes this option is not for players in noisy areas or who expect to be disturbed. Using it assumes you're alone in a relatively quiet room.

There's a bit to unpack here, but I'll ask that you please read this post and my motivation before giving a verdict. At the moment I'm just opening this thread for debate: If the idea isn't shot down as absurd and we agree it's possible to consider, I may proceed with a bug tracker entry otherwise forget I said anything. Also this post does NOT imply we have developers willing to work on it, if no one in the team considers it an effort worth investing time in I'm not going to beg. It would be a major change that takes time to test, so even if it does happen it would likely be next year at earliest (TDM 2.11 or later). Lastly this is intended solely as an OPTION... as the person suggesting it I don't believe it should ever be enabled by default due to how it would alter the gameplay, only offered as an extra component for players who want the mechanic. That being said, the idea occurred to me yesterday and I've been excited thinking about how it could work, it actually kept me up last night and I'm getting this off my chest to hear some feedback so I can fall asleep more easily tonight Let's get into it. The idea is partly inspired from some horror games I watched Youtubers play a while back. They had a mechanic where the engine accessed the player's microphone to read the volume: If you made too much noise, monsters would hear you and come after you. The player had to stay silent else they'd be in trouble. Last night it clicked with me how perfectly this mechanic would fit into TDM with our AI and gameplay. Imagine if any noise you made IRL risked alerting nearby guards... whereas oppositely you could use your voice to distract them to your location and move past. I'll discuss both uses below, first let's go into some technical aspects. This would obviously require engine changes: The engine needs to learn how to access the default microphone device from the sound system, enough translate the volume into a to 0 - 1 float. The game reads this volume at an interval balanced between accuracy and performance (eg: 0.5 seconds). Based on the loudness it captures that call, the same signal emitted by sound sources to alert AI is propagated from the player's view origin. The effect tapers off with distance in a fashion similar to s_mindistance (full effect below this radius) and s_maxdistance (fully ignored beyond that radius), reasonable defaults might be min 4 / max 16 measuring with the radius of a speaker in DarkRadiant. Multiplied with that distance and the AI's acuity factor, the mic volume determines the alert level being generated. The ranges I'm suggesting for this would be: 0% to 20%: Ignored, doesn't generate any alert. Ambient noise and insignificant sounds are usually in this range for all microphones. 20% to 40%: Can go up to the 1st alert level, makes the AI mumble and say "did I hear something" but move on and ignore you. 40% to 60%: Can produce 2nd alert level in guards, making them stop in place to look around. 60% to 80%: 3rd alert level allowed, guards realize something is up and start searching the area. 80% to 100%: Loud enough to make your presence in the area known, 4th alert level is possible making guards draw their weapon and dare you to come out. 100%: So loud that your exact location is clear to the guard as if you bumped into them, 5th alert level activates and the AI proceeds to attack you. So what is the point of this? Some would see it as an annoyance and the player sabotaging themselves, though just like selecting a higher difficulty level it's a controlled form of making your run more interesting. I for one am in it for the immersion and ingenuity: It would offer a new way to integrate the player into the world, using hardware almost every player has: A headset with a microphone, a mic on their desk, even one in their webcam. This has been done in small games but never attempted in a full stealth game for my knowledge, TDM could be among the first project of this genre to use the idea which would be an extra selling point to make it more interesting and appealing. The first aspect is fear of being heard. Imagine you really are the player in a typical FM, hiding in the shadows as guards are walking past or running around looking for you. The last thing you want to do in such a circumstance is make any noise: You'd be careful about your breathing, and god forbid you need to cough or sneeze. This mechanic would emulate just that: Players have to be aware of their breath as an enemy walks past them... if for any reason you feel like sneezing or coughing, you better hold off or the guards will become alert in-game. To me this sounds super neat... I can already imagine playing TDM with the added fear and adrenaline The second part is how this can be used to attract guards in a controlled way. Jumping in place works but it's hard to make guards come and investigate, with this you'd do it using your voice. The fun here is learning how loud to speak to get the desired alert level: If you whisper to the guards they won't hear you and just walk past, but if you scream too loudly they'll know where you are and attack you on sight! You'll want to say something like "hey" at just the right volume to make them investigate. As a bonus to end the idea, why not introduce this for friendly AI too as a fun detail? You know how some FM's have pubs the player can enter where the maid and party-goers won't attack you; Whenever the player says something in their mic, friendlies and neutrals look at you and use the generic response bark! Imagine how much fun we'll have taking breaks from the objective to say all kinds of stupid things in the mic and each time someone responds with a "hello there" or "you said it" or "yeah yeah"

No but some of us don't agree with the mainstream on everything, and by modern standards that makes us terrorists so it kind of counts

Yeah what's done is done, changing existing functionality would be very risky to break FM's. For the future though, we could maybe add a boolean spawnarg for entities to require line-of-sight check for frobbing. Most shouldn't need it anyway, and this may cause extra checks that can be hard on the CPU: Probably useful for well hidden secrets primarily.

I definitely support a "floor selection" version for walls: That feature should at least be turned into a 6 button set for all axes (+ / - for X / Y / Z). I just opened a bug tracker entry for that, combined it with my laser-pointer projection idea since at the end of the day it's kind of the same improvement in different forms. https://bugs.thedarkmod.com/view.php?id=5714

It should be remembered that you can only frob-highlight one item at once, must do so from up close and will usually stare at a wall while doing it, and will only do it for a brief amount of time to frob the item; A rare and temporary performance impact caused by one model for a second wouldn't bother even me, unless it's massive enough to truly notice a slowdown. And I've actually been a bit obsessed with maximizing my FPS in TheDarkMod. Like I said my main issue with occlusion for the highlight is that it looks bad in some circumstances: Objects will also hide the highlight when it would be bet not to. Try looking at a drawer in a stack of drawers from a desk: The drawer below / above hides the highlight of the currently selected drawer which makes it only show on the sides of that drawer. Idea: If we do add a menu option for this, we could give it three values; Off, on, on with occlusion.

Oh that's correct actually, meshes have varying rotations. For most the front appears to be +Y but some may point toward -Y / +X / -X since there was never a common standard for this, it would be an unpredictable mess then. And we'd want this to work for prefabs too, orientation differs even more there. Something else we could do then is implement only projection for the active selection? This would still offer the most handy part of the automation: With an entity or a group selected you'd [modifier] + [click] on a surface in the 3D viewport to move it to the grid unit closest to that spot. We can allow the surface detection for models other than just brushes... the algorithm would have to deal with more complex geometry, but it would then cover actions like positioning items in shelves. Speaking of flooring I just realized: The "floor selection" feature is already doing half of what I'm suggesting here, its code may be possible to reuse! In the -Z axis currently but same concept: It brings the selection to the nearest surface in a given direction. With what I'm thinking the code would only do two additional things: Teleport the active selection to the origin of the camera first, then use the same call but in the camera-to-pointer (where you clicked) direction instead of one axis.

DarkRadiant already offers a lot of features to make things easier for mappers by simplifying and automating certain tasks. Even so creating a map takes a huge amount of time due to how much there is to do overall. When mapping I noticed a huge amount of time is spent on positioning stuff: You right-click in a 2D viewport, go in a menu to spawn your entity, then need to find it and drag it around from at least two different views to place it where it needs to be in all three dimensions... often having to search in a mess of overlapping lines to even find the selection you're working with. Some shortcuts like "floor selection" offer limited help afterward, but even then you usually need to select the wall so you can see the red outline and be sure on how much you need to move that item so it correctly rests against the surface. I was thinking of a method that could make this a lot easier: Allow placing entities from the 3D viewport as well, based on the distance and direction projected from the view to the spot where you clicked. So let's say you're looking at a brush wall: You click on its surface and get the same menu as in the 2D viewport (eg: Create entity). Once you insert that item, it's automatically positioned so its back rests against that wall (total bounding box), the item also rotated to face toward the camera (in 90 or 45 degree increments). Every wall will need to be accounted for if you're placing your item over an edge or in a corner, ensuring the object fits neatly against all brushes its model's box intersects. This could help a lot by not making the mapper need to move and rotate everything manually except for small adjustments. In the 2D viewport it's difficult to guess where an item will appear since you don't know its size, plus you still need to go in another 2D viewport to position it in the 3rd dimension not covered by the viewport you spawned it from. This will require math to do line tracing as well as calculating surface / box intersections, but I'm hoping it's doable and some of the code may already exist. One obvious thing worth pointing out: A normal right-click in the 3D view is used to grab the camera and go into mouselook which we wouldn't want to change. This would need to be implemented as a combination, prolly either control + right-click or shift + right-click. What do you think about this idea?

Does the engine support using svg as a graphic or texture? That would be cool now that I think about it. If not though the mapper can simply convert to png and include the svg as a source, given those are usually tiny text files anyway.

I still think an automap as an option for new FM's would be good though. Like I said not everyone who can do great things in Darkradiant is also a trained artist or has the tools to draw, whereas most FM's do require having a map in some form. It would be neat if for starters we could allow DarkRadiant to export the top-down view to a transparent png, so mission authors can then include it without having to draw their own by hand.

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.