MirceaKitsune

There might be another way, or at least it's what I thought of as a non-developer: Use a different way to transform mouse movement into camera rotation or viewport offset. Is there no alternative to calculating the distance from the pointer to the window center before resetting the pointer to the middle? There must be other mouse look implementations that could work. Most obvious alternative: We can detect how much the pointer moved on the screen compared not to the center, but to its previous position wherever that may be. While of course still trying to lock it in the middle, but if that fails at least it doesn't cause the view to go crazy: The only issue then will be the cursor reaching the screen edge and having to be re-engaged so you can keep scrolling in that direction, which is also a big annoyance but comparatively less bad and not as noticeable unless you do long-range movements in one go. Any reason why we couldn't give this option a try?

I manually integrated and tested your PR. There is good news and bad news: The good news is that when running with the "GDK_BACKEND=x11" flag, using the clipper tool no longer breaks the window forcing me to restart DR afterward, the model / entity viewer no longer experiences the issue either. The bad news is that flag is still required, every viewport retains the problem if running Radiant in Wayland mode, we still have a big problem Linux users will increasingly run into as distros adopt it (KDE Plasma 6 now uses Wayland by default). So please integrate the PR if it doesn't break anything, it makes life much easier in the meantime! But this should remain open until either DR or WxWidgets or Wayland solve the core issue that exists when running in native mode.

Oh my gosh, thank you for this! After reading what you just said, I realized I've in fact noticed the same thing in another program, but assumed it must be something completely unrelated: I've been working on creasing a CPU based voxel raytracing engine in Python, for which I settled with using PyGame. When the time came to implement first person camera control using the mouse, I noticed it did not work initially... however if I told my code to hide the mouse pointer first, locking it in the center of the window started working. It must be the same thing here in some form, Wayland likely has some very particular expectation on how the mouse pointer must be set in order to be locked. In fact just a few days ago, I tried a virtual worlds software called Vircadia / Overte again to see how it's been progressing. I activated mouse look mode and guess what happened: The exact same behavior of the view spinning endlessly as the cursor drifts away from the center due to lack of locking. So it's clearly happening to many things and not just GTK / WxWidgets related... but no all of them, most games (including TDM itself) work perfectly fine and mouse control never breaks. I'll try your solution later and mention the results, likely tomorrow as it's late now and I need to head off. If it works that would be incredible! At least as a workaround, we could simply not hide the cursor on Wayland, which will look ugly but at least allow using DR without needing hacks until they can solve whatever is happening on their end. Also Plasma 6 was just released, my distribution (Manjaro) will likely be getting it a couple of weeks or at most months from now. I'm curious how that will affect it: Hopefully it won't make the issue worse, but just in case I'd be happy to have a solution in Radiant before then.

Yes please: I've wanted something like this for a long time! One thing that always makes me sad in TDM is when a mission just... abruptly ends: Obviously every FM has an ending, but I never liked just transitioning to a stats screen as if nothing you did in the world mattered. I'd absolutely love a debriefing GUI just like the briefing one, where you can either have text or an image slideshow with music and voice-over which would be even better! Maybe some old FM's can be updated to use this too, I'd totally replay them just for that. One additional idea: Since FM's with multiple endings are something I always wished for and would love to do myself, support for multiple debriefing GUI's would be ideal, so the kinds of objectives you completed can execute a different one or skip / add certain passages. Absolutely hope the team can consider this, should be just a GUI execution hook to implement it so why not

Yep... just what I was thinking of, except it's even worse than I remember now that I see it. Biggest limitation with stencil is you can't have alpha texture shadowing, so stuff like plants had to have their shadows turned off. I'd say this is the most important reason why enabling map-only effects was a good decision, followed by other improvements and potential future features like transparent / colorized (stained glass) shadows.

If shadow maps support more detail that stencil shadows can't offer, I'm absolutely in favor of enabling them: It makes sense to use them for obtaining new details and effects that weren't possible previously. Geometry based shadows are technically a legacy thing anyway, I imagine that once every player and their hardware work well with shadow maps then stencil shadows may someday be deprecated.

As with every other mod, sure! Thank you for the help and I hope that makes good mods more easy to find.

Absolutely! Thank you for checking it out and hope it helps others discover and enjoy the mod.

So I thought whether to mention this here, in the end I guess it makes sense as it's now technically a bug report. The discussion started out as a feature request, or rather a set of them... then it was mentioned that one of the functionalities I described should in fact exist, but an error is causing it to be overridden. We aren't sure when it was introduced but since I've always observed the broken behavior it might be years. You can read the full conversation here: https://bugs.thedarkmod.com/view.php?id=6436 What I observed and initially requested: When the player shoots at an AI, the AI shouldn't go searching in a completely random direction, and instead go somewhere toward the player as they should have a general sense of where the arrow came from. Currently guards completely ignore the direction of an attack and will cluelessly run to a completely random spot when hit which is very unrealistic: If an arrow hits you in the back, you aren't going to sprint forward looking for the perpetrator there. How this turned into a bug report: Someone investigated the issue and discovered that when attacked, AI should in fact be picking a search area between their own position and that of the players. I understand the pain event mistakenly overrides that decision, causing the guard to pick random locations within their own radius when attacked. Now that this is known, maybe this can be fixed in time for 2.12 so we aren't stuck with the broken behavior for the whole release?

Something I was thinking of: Even if some assets are non-commercial, are all assets at least accounted for to make sure they're credited accordingly and can be distributed? I ask following an issue in another great project I work with called Red Eclipse: They don't have NC assets but did have a few texture packages they had to remove because they later found out their clauses were incompatible with the project. If this hasn't happened in well over a decade it's very unlikely anyone would complain today and request removal for any reason, but if any resource had its license misunderstood that could destroy existing FM's unless perfect replacements were found. Obviously I presume the team never included any asset randomly found on the internet without verifying their explicit requirements in detail, but it doesn't hurt to check. I think the best that can be done otherwise would be to have a list of which assets are libre or have the NC clause: That way a map can choose to use those models and textures that are free if the author wants their FM to be fully libre, albeit this would handicap an author in what packages they can use. If core assets like character models or textures are also NC, the idea is likely pointless as you can't make a FM without those, at best you can skip a few texture packages... not sure about other things like core scripts or defs, since they're technically code I presume those are GPL?

https://bugs.thedarkmod.com/view.php?id=6436 I have this one which started from a similar observation, might make them for the other details too later on.

In that case they seem to go in the right direction and attack accordingly. What you could have expected to see for instance: If you only activated the lantern for a few seconds as to make the AI lose you, it's possible the guard may have instantly went searching in the opposite direction as if having no recollection of what (or rather where) caused it to become alert.

That is true, which is why slowly widening the search area over time would be even more realistic, just don't think instantly picking random locations everywhere feels right. As my video shows though, the guard was hit directly in the back and immediately went searching down the stairs right in front of him: That's like someone who got his foot stuck in the floor looking up thinking something is hitting them over the head.

Obviously they should know the general direction it came from, the AI would feel where the arrow hit and how it pushed them: If an arrow struck them in the back, it's clear that arrow wouldn't have come from the front... if it hits them in the right arm, obviously it didn't come from the left. TDM disables arrow sticking for living AI, probably since it would look too silly as guards don't have a wounded state with custom animations to match that up... realistically though you'd look and be able to tell from the angle of the arrow where it hit you, it's not like bullets where you can't be expected to analyze a bullet wound in real time and feel which direction such a tiny and fast projectile hit from.

Thanks for mentioning this: I did not know that and it explains some things, though I didn't imagine a +10 year old bug that got forgotten would be involved. I did mention it in my report about being able to beat up clueless guards by standing in total darkness, not as a primary focus though so this should probably be reported separately. https://bugs.thedarkmod.com/view.php?id=6436 The functionality you describe would be even simpler: Have a virtual box between you and the attacked guard and pick positions only from there. That would be hardwired to a 90* angle on every axis though: The best solution I can think of is using an AI awareness setting to trace a cone from the AI to the player and pick positions within that virtual cone, the smaller the cone the more accurate the guard's prediction so give it enough space to be fuzzy but accurate enough.

Existing maps wouldn't be compatible then: New FM's would need to be designed with knowledge in mind as to which asset is libre and only add those that are to the map. It would probably end up being a new project, which alone might be more effort than it's worth: Most likely this would go well with an initiative to upgrade existing textures to higher resolution versions.

Technically a good way to justify it is him suspecting the attacker may have changed position, though that should happen slowly over time. A solution then might be to widen the search radius with each iteration: First he'll run to a location close to the player, next time it may be one further away, etc. It's not too bad the way things work now, just think there's room for some improvement: In my example which is easy to test on any map, you can tell the pattern is completely random and the guard looks silly with his search. He clearly picks random spots within a radius of himself run to, which don't have any intelligent decision making behind them.

Okay: I replayed a few missions with difficulty set to Hardcore which is the maximum setting. Nothing obvious changes: All of the same issues persist, including the ability to beat up a guard with no reaction by climbing on a table in total darkness. All that changes is guards running to your location a bit more accurately when seeing you from a distance, attacks however don't count as sight. I decided to record a video for this thread to show my point, Crucible of Omens: Behind Closed Doors. What's happening here: While standing on a ledge that should be reachable by a stair, I shoot the guard in the back as he's walking away. His first reaction is to run down the stairs in the completely opposite direction. A few seconds later he comes running back up, only to go in a crevice at the other opposite end of where I was located. By sheer chance he heads somewhat toward my initial position, after which he runs down the stairs again. He finishes his alert state far away, looking for me far at the bottom of the stairs where I clearly wouldn't have been located. How this could have been better: The guard was shot in the back, it doesn't take a genius to tell that's where the arrow came from. He should have picked random positions in a cone originating from his view and facing toward me at the moment of the shot: He shouldn't come running to my exact location which would be both difficult and unrealistic, but should have searched in my general direction such as the wooden door to my right.

Great take on it and solution from what I understand! Will the normal Beta 6 contain this patch? If so it's easier to wait till then, otherwise if it's important I can of course give the test build a try given it doesn't mess with my normal install.

Wasn't sure what blind and deaf actually mean to the code: I thought they only offset the alert level increase rate, not what AI does afterward. You're right that it's kind of silly I didn't think to check on higher difficulty settings as they didn't come to mind as a possible factor. I'll do that as well and see which of those points it improves: #1 might be offset by that... I think the others aren't difficulty related and just not implemented, I'll actually check before presuming though.

Oh yes: I have both sight and hearing set to Forgiving. I didn't think that would be related: IIRC it only affects the multiplier for how much being seen in light or heard while making noise increases the alert level per event. I should test on a higher alert level too just in case: I tend to be sloppy and impatient thus I used that for years so I wouldn't get caught all the time on more difficult FM's (lots of guards in tight areas with lights you can't turn off). I have noticed an aspect that does work well: If you're making noise by running even in darkness, alert AI will head toward your direction while searching, they won't go around randomly but actually care where the impulse came from. The problem is that this doesn't seem to scale over larger distances: If they briefly see you in broad light at a distance enough to draw weapons, AI won't head toward your general direction but begin searching their own vicinity... and at least on Forgiving the same happens if you shoot a broadhead arrow at a guard's helmet: I still think the guard should actively run toward your location instead, not exactly where you are but they should go to that road or barge into the same building.

I saw this was updated today so good opportunity to replay. I remember why I liked this FM: Very fluid and immersive and full of surprises! I also remember the biggest downside I felt it has... Regarding the bug with being stuck at the mission start, I got that too in the latest version of the FM with TDM Beta 12-05: I started stuck and had to noclip to be able to move then everything worked well. I presume 12-06 will fix it so maybe I'll test again then. Also I was wondering something: I always wondered if the original ship model had a version with the interior, but wasn't sure where I had once seen that. Is the ship itself a generic asset, as in is it okay if someone else uses it on their own map if they need it? The exterior is a standalone model but the version you can actually enter I never found separately in the prefabs.

It's easy to imagine how #1 can be solved fairly: When the player or an enemy AI shoot an armed AI, the AI that was hit should be given a random destination near the attacker to run to. The further the player is from the target, the larger the radius around the player in which a random node may be picked; If you're far away the virtual sphere should be large, meaning AI may run to a room or passage near you but still in your general direction . This new behavior should be influenced by AI acuity and difficulty settings though I'm not sure which ones... also toggled by one, for those who prefer the old way and abusing clueless guards as they wonder what force of the universe must be hitting them. By the way, and I just realized this now: The problem doesn't only affect attacks, but also spotting the player before attacking. Think of the last time a guard standing outside spotted you on a balcony before you hid, enough to draw their swords and start searching but not attack you outright; The guard was alerted by something in a building, yet he draws his sword to search the area near him. If I'm standing outside and think I see a burglar in my house through the window, I'm going to go near my home if I plan to confront the possible intruder, not start looking around the road next to me and say "I know you're here somewhere" which would imply I have a serious problem Main reason I mention #2 is when I helped with transcribing the subtitles for the drunk voice, I noticed there are voice lines for AI returning with an ally. Two in fact: If the player is still there the AI has a voice line for telling the other person "that's the one let's get him", if the player hid there are lines such as "you were too slow now he got away". Those voices in particular are never played, or at least I don't remember ever hearing them in all those years: It occurred to me while I wrote this post that they're likely designed for a mechanic that was never implemented... or was but broke very long ago? Curious what its history is.

Thank you for the fix! I played a FM using the latest beta and it seems to be working great. Wanted to ask about my other point regarding the toggle states, whether you think that should be changed as well: When both running and creeping are set to toggle, shouldn't toggling one instantly disable the other? Unlike crouching the two can't be used in combination with each other, at the moment creeping happens to override running; It would be easier to know that when you exit running or creeping, you're always back to normal walking instead of the other mode if you forgot it turned on.

As someone who tends to alert guards often and occasionally stir trouble when going through a FM, I noticed some major issues when it comes to AI realism and awareness during combat or when guards face difficult situations. Everything's fine when AI go about their usual patrols... once trouble takes place however, the illusion falls apart as guards act like they're less self aware than a toddler. Indeed AI realism can't be improved past a certain point as there's a limit to the effort the team can put into something so complex... yet I do believe a few improvements can make AI behavior much more realistic and exciting. After analyzing this issue for a long time, I decided to put it all it into a few main points... I apologize for their length as I wanted to go in a bit of detail on each one, hope folks have the time and patience to read them. Biggest issue is AI are unaware of where attacks are coming from. I recently made another thread on how I climbed on a table and blackjacked two guards to death as they sat there doing nothing, something that also happens when shooting them with arrows as guards only explore the nearby area. The issue seems to be that AI don't account for the direction a hit comes from, they only know something hit them but act as if it must be some mystical force of nature: If you're sitting in a parking lot and an asshole neighbor throws a tomato at you from his balcony, you aren't going to cluelessly investigate the road in front of you when the projectile clearly came from behind and hit you in the back of the head, instead you'll storm into the building and start looking for which of the neighbors facing that side of the road may be the culprit. Despite voice barks existing for this exact scenario, we never see AI running to get help from other AI. NPC's will do one of two things: If armed and with enough health they will attack or search for you nearby, if hurt or unarmed flee to a random location. I've never seen an AI consciously run up to another AI asking for help and bringing them to where they spotted me, even when fleeing the AI seems to go to a random location. They don't share knowledge with each other generally speaking: The only awareness AI spread to other AI is alert level, meaning NPC A becomes alert if it sees or hears that NPC B is alert too... beyond that there's no coherence or actual cooperation, the voices may indicate some form of searching together but friendly NPC's are never seen actually engaging. Another big issue is voices being played (or not played) in disconnect with what's actually going on. There are AI voices for most important circumstances but they're very rarely activated: It's a miracle to hear a guard say "someone's been hurt" or "there's a body here" when noticing someone who's unconscious or dead. What seems to happen is if AI was already alerted by another peculiarity such as a noise, they're no longer surprised by anything else and won't play the voices designated for that scenario, so they'll only mention a body if that's the first thing to alert them in any way. Furthermore AI don't actively talk with each other while searching together, everyone acts as if they're on their own and not a team. What happens after a conflict is over. For this discussion I won't focus on better permanent alerts, that has greater difficulty implications and I think I made a separate thread on it a while back. The problem I noticed is once the immediate alert has gone down, AI return to full normality and act abnormally calm: The idle voices change from saying things like "it's a quiet night" to "we've got an intruder" but that's about it. In any realistic scenario even a trained guard would be shocked after being in a fight or finding a body. Below I'll list the immediate improvements I see to those problems, which without having an understanding the code myself am presuming can be changed without too much effort: When an enemy hits the AI with any weapon, the AI should be alert to the estimate location of the shooter. If you're standing atop a tower and fire an arrow at a guard, the guard shouldn't draw his sword and look around their nearby vicinity like a fool, but instead run up to the tower where you're standing granted they can pathfind their way to that location. If the player is far away the destination should be fuzzy and a random location nearby, thus the guard won't run to your exact location but will still climb the stairs and enter a room near it. AI need to learn how to ask for help instead of fleeing to random places when not attacking. If an ally who isn't already alert can be found nearby, the scared AI should explicitly run to their location tell them where you are then have the ally either run to your location (if armed) or go to another ally to get them to your location (if unarmed). Even if an AI is already alert, finding a body or dropped weapon or broken arrow should result in the AI speaking the voice line for that circumstance, only being engaged in combat should suppress it. I'd go further and support repeating those voice lines: A guard yelling "we have a dead body" several times during the first seconds of discovery would make them appear more shocked. Similarly talking to a nearby guard shouldn't be done just once when the two first meet: When multiple AI are searching for you, they should constantly alternate between single voice lines (eg: "I bet you're right over there in those shadows") and looking at another guard to talk to colleagues (eg: "I know I saw him here keep searching"), this would be a huge improvement since guards currently act like they're completely unaware of each other during a coordinated search. Making guards permanently affected after an incident is a trickier one but a few tweaks could improve it. The most immediate solution would be changing the idle animations: Instead of stretching or blowing their noses or eating candy, AI should be seen randomly cowering or face-palming or even playing the scout animation to look around carefully. One suggestion I'd absolutely throw here: If the AI found a dead body from an ally, have them cry occasionally... I think that would be an interesting and unexpected detail, that will also get players to think and feel more about the consequences of their actions and how they affect the world. There are other ones I could get into, but some would be more difficult and likely not worth trying to solve. Most notable and worthy of at least a mention is how AI walk over the bodies of fallen friends as if they're doormats: Obviously there's no way to have them drag bodies to the side, but maybe an avoidance mechanism so they don't look like jackasses trying to profane their dead friends by literally stepping all over them could be a fix for that as well! Let me know what you think of those points and if there are other AI issues you've noticed yourself or better solutions you can think of: I'm not sure if I got everything here but I definitely believe the problems exist and we could make the world more natural and immersive with some simple fixes.