MirceaKitsune

Like I said I don't even use Steam, have an account but haven't even logged in for over an year I think. To me this would have been good solely as a way to get it to more people and further increase our player base. It sucks if this isn't possible, though I wonder if there are any alternatives to Steam which are more friendly to FOSS content. I don't remember if other open-source projects like Xonotic or 0ad are on Steam too, I believe at least Red Eclipse is... we could consider asking their teams how they did it if that helps.

This is really great! Any noticeable difference in loading time too? That's one of the main aspects I was interested in, TDM still has some really long load times compared to many other engines.

Which is kind of the point: If you were the player hiding from a guard, you wouldn't be eating chips next to them. Granted chips existed in the TDM universe, I'm sure the Inventors Guild figured it out This should be thought of similarly to VR support which is a good comparison... on that it would especially make sense with VR. Fair enough: Like I said I don't expect there to be an engine developer willing to work on this, especially unless many players express wanting it. It's in the same boat as VR again: Few people will use it, but some will seek it out for the sake of added immersion, and at the end of the day I think the effort spent on creating a VR branch of the engine is very much worth it. Hard to say how many would end up using it in the end, could be more depending on how it works. I can add one thing on that: If this were implemented in the engine, I'd offer to code the AI functionality, granted it's as a script. I'm not an engine dev but good with scripting: If I had one $player1.getMicVolume() call exposed to the script engine, I should be able to do everything as far as AI responses go, including the mic calibration settings based on just two extra cvars... my code could be integrated into core after first being tested as an addon. This way devs and mappers could come up with more innovative ideas to use the microphone in their FM's.

That sounds awesome! Can we have a reminder of what the cvar is to test the new implementation? Though I assume all existing normal maps in the assets need to be converted, so I take it the next dev snapshot might not benefit just by enabling the setting unless someone batch-converts every normal texture as well.

Yeah I don't go that far, as much as I don't like proprietary either. AAA stuff I typically hate, I'm into some indie games which are closer to home. But the #1 OS for both servers and desktop is Linux. And no, the fact that most people still fall back to Windows out of habit doesn't change that

The suggestion revolves around both uses: Taking to distract guards or not talking to not alert them. It's similar to existing in-game sounds: Sometimes you want to cause them to get guards out of your way, at other times you choose your path and surfaces carefully just to not be loud. Usually the later, the former tends to be the exception. Forcing the player to stay quiet is the more primary intention then. Not to introduce an annoyance but to include more suspense, in a way that brings added realism and makes you feel more integrated into the world like you're really there and your actions manifest. It would offer a new type of mistake the player can make if they forget to be silent... if you did and spoke too loud in the wrong place, you now have to stay silent for longer until the guards calm down to not alert them even further. I can imagine this being quite a fun challenge especially in cramped indoor areas. As an estimation of the difficulty level behind considering such a feature: May I ask how much work would be needed in the engine to support measuring microphone volume in and of itself, potentially hearing your self as well? As in how much is this made easy by the libraries we use like OpenAL and EAX. Is there a simple "access the microphone" call the engine can make to the audio system without needing complex code just for this purpose?

Nice I managed to find an old video from Markiplier from one of the games I kept remembering does this (Lurking). It's more oriented on echolocation which isn't as relevant for us, but it shows how creative and ingenious some of those features can be when done right. More relevant to our functionality and atmosphere is a silly horror game called Escape the Ayuwoki: It's not obvious since there isn't a HUD indicator, but when you talk you make it more likely for the monster to find you. It's fun to watch streamers struggling not to speak when they hear the creature is near

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.