MirceaKitsune

Mouse look is essential so no. We should use whatever behind-the-scenes solution of messing with the pointer will work... once Wayland or WxWidgets or GTK3 will offer one, it's kind of on them that they haven't up to this point. Until then Jonri's PR works by forcing the X11 backend, which isn't a real solution but in practice solves everything for now. Here's a modified snippet of what I did in PyGame which works. Obviously this code has no effect, just an example to show what works in my project, just in case it's a similar situation here: Maybe Wayland expects us to hide the mouse pointer at a core level before it allows locking, and the reason it doesn't work is DR only hides it visually at top level? pygame.mouse.set_visible(False) x, y = pygame.mouse.get_pos() pygame.mouse.set_pos((x, y)) pygame.mouse.set_visible(True)

It might then be best to add it to new light models designed for the purpose. The visual cue should be making them more glassy and fragile looking: Existing lamps look pretty solid, we can argue those were made of reinforced glass built to withstand powerful impacts, something something Inventors Guild... in contrast we'd have a few lamps with very transparent glass that show the light bulb inside, their design shows their fragility and makes it clear those are meant to be shot.

It's okay! I'm down with any option hence why I asked. But I agree: Most players would likely not approve of such a change being done retroactively and affecting all old FM's, so it would likely be best as a derivative entity for mappers to use in the future based on new or existing lamps that can provide one. In any case it would likely require engine changes, not something you can currently do with a script: Lights already use their own hardcoded script classname which can't be overridden. Even if it weren't for that I don't think there's a way to intercept broadhead arrow collisions and check what kind of surface they hit, even with the Stim / Response system. There should probably be two new spawnargs: A breakable boolean enabling the feature on an entity, and a skin_broken to specify the skin used when a light was smashed.

Yeah, that is a true aspect. Which is why I think there could be one of two approaches if this happened: Either make breakable lights a new entity for some lamps that want to feature them, so just as you have "atdm_lamp_1" and "atdm_lamp_1_unlit" you'd have an "atdm_lamp_1_breakable"... or if we implemented it for all lamps retroactively, it should come at the cost of AI becoming suspicious whenever they see a broken lamp just like when they notice a rope arrow, in which case the player choosing to go down this route comes at the cost of attracting attention and possibly ruining their stealth score.

I couldn't help thinking of another realism related suggestion, don't know if it was discussed before but it seemed like an interesting idea. If this were to be changed on existing lights by default, it would have minor gameplay implications, but the sort that make missions easier in a fair way. So... electric lights: Like the real ones of the era, they're implied to use incandescent light bulbs... the kind that in reality will explore and shatter upon the smallest impact, and which like real lamps are encased in glass or paper. In any realistic scenario, shooting a broadhead arrow at a lamp or even throwing a rock at it would cause it to go through the glass and break the light bulb inside. Is it wrong to imagine TDM emulating this behavior as a gameplay mechanic? Just as you can shoot water arrows at flame based lights to put them out, you'd shoot broadhead arrows at electric lights to disable them... you must however hit the glass precisely, there's no room for error and it must be a perfect shot. As a way to compensate for the benefit, AI can treat this as suspicious and become alert if seeing or hearing a lamp break, or finding a broken lamp at any time if that's deemed to provide better balance. A technical look at implementing this: Just as broadhead arrows can go and stick through small soft objects such as books, they should do the same if you hit the glass material on a lamp, while of course still bouncing off if you hit metal: Lamp glass would need a special material flag that sends a signal to the entity upon collisions but allows arrows to go through, unlike glass in other parts of the world which is meant to act as solid and changing that everywhere would break a lot of things. When pierced by an arrow, the lamp should immediately turn itself off while playing a broken glass sound and spawning a few glass particles. The glass material should be hidden if the model is a transparent surface, or replaced with a broken glass texture in case the glass is painted on a lamp model without an interior... obviously this would be done by defining a broken skin for the entity to switch to. This does imply a few complexities which should be manageable: Existing lamps supporting this behavior will need new skins and in a few cases new textures, the def must include a new skin variable similar to the lit / unlit skins in this case a broken skin. Any electric light may be connected to a light switch, we don't want toggling the switch to bring the light bulb back to life... as such a flag to permanently disable triggering the light from that point on would be required. For special purposes such as scripted events to reset the world, we should allow an event to unbreak lamps, setting their state back to being lit / unlit while re-enabling trigger toggling. What do you think about this idea and who else wants it? Would it be worth the trouble to try and implement? If so should it only be done for new lights or as a separate entity definition of existing ones, or would the change be welcome retroactively for existing missions without players and FM authors alike feeling it makes them too easy?

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.