MirceaKitsune

Yeah, it's not a feature people should HAVE to use, I'd see it getting annoying then. If this were to happen it should be a purely optional addition. At most I was thinking we could let some FM's unlock bonus areas when you speak in your mic close to a secret door. But then people will need to use the mic to get all the loot / secrets so even that would likely be too much. We could have generic sound-based triggers of course, which for non-mic users could be activated by throwing an object nearby... different feature for a different thread though.

Here's an edited screenshot depicting how I see the setting for this. Would be stylized differently of course but work the same way. The lower dial on the slider represents the volume at which noise is taken into account, anything beyond can start producing an alert level of 1+... the higher dial is the volume at which the microphone is considered as loud as possible, anything beyond will produce the alert level of 5. The entire mic effect is scaled in between these two settings, simple math I can implement in my script... no promises on the main menu Gui, though if I get support on the engine part I can consider trying that too. The black line over the colored bar is the current mic volume, used so the player sees where to set each slider as they make different noises to test the range.

Keyboard / mouse noises wouldn't be a problem: The system as I'm imagining it would ignore all sounds under a certain threshold, any ambient noises like fans or clicks... it would only react from any noise that's significant onward. If you open a recording app with a microphone preview bar you can see what I mean: The bar stays on green at the beginning as you type and do normal stuff, passes the middle point and reaches yellow / orange when you talk normally, only reaches the end and gets red if you speak very loudly. Knowing these standard ranges we can calibrate when and how the microphone should have an impact. And of course allow the player to do so by changing the ranges if necessary for their mic... for this I'd add a slider with two dials in the menu to specify the start and end range, text showing the result in a format like "0.20 to 0.80".

That's one good point I didn't think about: TDM is more in line with how games used to be 20 years ago, back when they were actually ingenious and innovative and players didn't expect to have their hand held every step of the way. Nowadays in a world where 95% of modern games are identical consumer products with zero soul put into them, and players are used to a tutorial popping up every 5 seconds explaining how pressing a button on your keyboard works, we'd likely attract the type of player who will rage "why didn't anyone tell me I must hold the fire key to charge an arrow, I was spamming the attack button for an hour trying to shoot but the arrow kept unloading or falling to the ground".

Semi-but-pretty-related:

The question then is how they did it, what differentiates us from them. I imagine their code is also GPL licensed (at least Cube / Tesseract engine is) and they also use CC licensed assets contributed over time by different people. Only difference with us is some of our assets are non-commercial, which isn't a problem as long as we set TDM as free.

I feel it would make most sense with the VR branch: This would be very fitting with its goal of immersion and using the player's body to control the character. And if someone would bother implementing the feature for that, there would be no reason not to back-port it to the vanilla engine too as it's not technically VR dependent. If TDM had multiplayer this feature would indeed be even greater. Sadly I don't see that ever happening, huge effort to support it at this stage: Even all scripts refer to the player as $player1 and would need to be redesigned to support multiple players for starters. My mic support idea is at least 10 times easier to implement.

Will keep it in mind. IIRC though that means the game will stutter whenever an object with a previously unloaded texture comes into view, so I'd likely get slowdowns during the game instead.

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.