MirceaKitsune

I remember I got it working last time but had one issue left: The UV light doesn't cast shadows. That's because being on its own spectrum, it doesn't interact with anything on the normal spectrum any more... this means it will illuminate only the special materials I want it to, but at the cost of only those materials existing to the light thus being able to cast or receive shadows too. Let me know if there's any known solution or potential fix for this so the UV light doesn't reveal objects through walls.

It seems to happen with either, yes.

Static lights only, lights should be cutting through the portals by far, however one is rotated by 45* on the wall which could perhaps be related. Here's a DarkRadiant screenshot for now, showing the setup best as it can be seen... I selected both the interior and exterior light entities that might be involved.

I'm seeing the weirdest thing on my map, not public yet but I have the case for testing: Not only does the light leak, and it does so even as I've textured the walls with shadowcaulk... a light actually leaks only while the door is closed, once I open it the undesired light goes away. It's the glow on the left side of the door and little triangle it casts on the floor in front of it. I think it might be the light at the right shining through though, not sure if it's the light in the newly opened room. The interesting thing is opening the door makes it go away, also using shadowcaulk over mere caulk doesn't seem to matter which is quite odd.

Replaying CoS1: Pearls and Swine on latest dev. If I kill one of the guards with an arrow and he falls in a particular position as he dies, TDM crashes. Reproducing is tricky but I managed to catch the crash message in the qconsole.log at least:

Usually I reload the save since I quick-save often: If I use cheats in a run not destined for it I feel like I broke my run by cheating. Then again I often noclip to go somewhere then reload, technically I didn't use the command during the continuation of my run but did to gain new knowledge, so it depends how you look at it

Yes I hope that can be improved in the physics engine in time, though if it hasn't until now I presume more can't be done. The biggest issue is you can still get stuck very easily and have to reload a save since the player can no longer move after you touch certain corners or slopes.

You can't frob and pick them up either then right? I'd rather leave them as is since I prefer as many moveables as possible to make the world feel interactive, I'd actually like if it more FM's allowed moving any small stuff around. Though I can fully confirm everything starts flying across if you alert AI in the area... then again seeing them climb on tables as food flies all over the place only makes for more fun even if unintended

Which do you mean? The architecture itself is func_static of course, the tables are based on the AI eating / gambling prefabs so the only physical things are cutlery and food.

Does it make sense to have the plate as a mirror, if asking that doesn't go beyond the scope of this issue? It's so small that it could easily use the default reflection cubemap like some windows do. Namely considering that mirrors cause a second render to be produced and thus use up a lot of FPS.

Sorry about that, I missed it indeed: I just noticed the command and my only thought was to use it from a console. At least I discovered a little bug by doing that Perhaps the key bind could be added by default, I'm not aware of F11 being used for anything else so it would make sense to just default that. That further explains it as I've had mirrors glitch on me like that. Typically horizontal mirrors or ones placed on brushes, I haven't tested thoroughly enough to know for sure especially recently. I remember trying to make a shiny floor using realtime mirrors, it would only work when seen from some angles then disappear or turn white like that once you looked from another direction or too parallel to the surface.

Oh, I understand now: I just opened the console typed screenshot_viewpos manually and pressed enter, didn't think of binding it to a key. It doesn't always work so just reporting so it's known, it is a good idea to have this command to share issues or map spoilers easily once it will work in every circumstance.

Wasn't sure if I should still post this since the mystery was somewhat solved, but just to confirm this case can be found in the wild with FM's other than mine: Yesterday I played Chronicles of Skulduggery 0: To Catch a Thief. There's a door up on a terrace (I can reinstall it and go there to get a viewpos if anyone's interested) which upon picking and opening will cause the light on the back of the wall indoor to slightly shine on the floor outside through the entire wall. Exact same camera position / angle in both images so you can just overlap the two screenshots to see the difference, though if you look at the bottom left ground it's pretty clear what happens once the door is opened. It's still a bit weird: The wall module model should still be casting a shadow, even if the wall brush uses caulk and not shadow caulk. Whatever the case a few FM's out there seem to have this problem, even if it's not an issue the engine or building modules can resolve I wonder if mappers can be better put on notice about it since like me most are likely not aware this is a thing or what causes it. Looked at the first post again and the video attached to it: Definitely seems like the same thing. Most importantly it wasn't doing this in earlier versions which I didn't realize... I'm seeing the clarification by Stgatilov as well which I initially missed, I definitely prefer the performance optimization but now I do wonder if something can also be done about this eventually.

I noticed the plate has that issue in every FM... strangely enough I didn't think to report it and my brain just accepted it as being a normal occurrence, especially since I think this one has been the case since TDM existed. Basically if you look at it from certain angles, that plate becomes fully bright. No idea if it's the reflection or something else. May be related to another little anomaly I noticed: When a frobable item is located in front of a mirror and you look at it to make it bright, the reflected version is twice brighter. Here's a screenshot where me looking at the lock box is highlighting it and that's making it abnormally shiny in the reflection:

I beta tested A Night in Altham again and found a few engine related issues. First off the new "screenshot_viewpos" command doesn't actually show the viewpos, it makes the console appear in the screenshot but the view position doesn't make it in in the frame. Here is an image taken with this command: It doesn't seem like a clean solution to make the whole console appear anyway: I wonder if it's possible to make just the viewpos appear at the top of the render in a special display with this command. Also this FM was a good occasion to test peeking. Thankfully it no longer crashes the engine on Linux or what the old problem was. Problem is that everything's black instead: You see nothing while peaking, just parts of the keyhole overlay and that's it. Thus peaking remains broken, whether this issue is also Linux only or not.

Thanks: Did that and more yesterday. Found most of the loot and roughly half the secrets, a few of them with the hints here; The thing that seems to get us in those FM's is knowing which windows are openable and which are just decorations, there are so many you can go through in areas I didn't imagine the player could climb to till I traced back the steps and saw how it's done.

I know, it's just the only easy way I can think of. Fixed script names is what we have now, tdm_custom_scripts.script or tdm_user_addons.script: Every mod will use them up and thus take them away from other mods. We need something that's dynamic and unlimited. A better alternative is a prefix to indicate you want auto-running of that script: Anything called "scripts/include_*.script" would be a good one, just use an unique name and call yours "include_mod_something.script" which will work if no one else names theirs "mod_something". Even better: Have a keyword at the beginning of the script! Like how scripts in Linux start with #!/bin/bash so file managers know how to preview them: Similarly we could add something like #autoexec at the beginning of ours, though this approach requires the engine looping through all script files to detect this keyword. We could imagine making tdm_user_addons.script unique per pk4. But I haven't even mentioned this one as it goes against how the file system works: You can't have multiple files with the same name and different contents, the latest archive in alphabetical order must always override a file loaded by an earlier archive. What gets close to that is a special text file in each pk4 like a package.txt which references the inclusion script as a flag. FM's kind of do that with darkmod.txt: When each pk4 is iterated by the engine at startup, it could read a script name mentioned there and execute the file referenced. But this seems more complicated than necessary unless this configuration is used for more stuff, maybe to list loaded mods in the main menu with their title / description / author / version the same way missions are?

I'd like to ask a (hopefully) easier favor from the DR devs on this, considering it's such an issue and making me struggle to keep mapping normally. I know the root issue seems to rely on WxWidgets and may not be solvable on our end, but at least one part of it I consistently run into should be. Like I said I can initially avoid the problem by exporting the "GDK_BACKEND=x11" variable in my shortcut, this makes it go away for the 2D and 3D viewports and only persist in the model viewers which I can care less about. There's just one exception: The moment I press X to use the clipper tool and cut a brush, the 2D view starts experiencing the issue and becomes impossible to drag normally. Because of this I need to avoid using the clipper as much as possible, and whenever I have to in order to get a triangle brush I must restart Radiant immediately after. Would it be possible to figure out what the clipper does that's so unique to triggers this? Does using it reset the 2D views and somehow gets them reloaded by Wayland? If yes could this be avoided so in the meantime it doesn't break that workaround? If at least this can be solved and the GDK_BACKEND workaround keeps otherwise working, it will be a lot easier to wait for the proper full fix. Sorry for the annoyance with this... just want to make some good FM's and using DR this way is running on a handicap that makes the already complex process of mapping even slower.

Yeah, that's what I was thinking of. When FM independent mods are also circulating this is bound to happen with the current system unfortunately, realized it soon after I started delving into modding. In the mods I posted so far I include the notice that you must edit tdm_custom_scripts.script yourself and watch out for it overriding or being overridden by other mods even then. Thank you lots for this, can't wait! The best solution to me always seemed like the one I suggested: Auto-execute the script with the name of the archive, so if it's "mod_something.pk4" then "scripts/mod_something.script" is automatically ran only from that archive. Only problem is if you put things like version number in the archive's name this would require renaming the script with each update, I wonder if a slightly different way is possible like pattern matching based on any part of the name, but anything among those lines will be a godsend.

Yes it's this way by default: I noticed it a FM I'm working on (not published yet) where I simply added the rat ragdoll with no extra spawnargs. I think rats and the small spider (not large ones) should disable it, unless any FM is known that relies on it and could break if we don't do this in which case I don't mind just making sure it's truly intentional. Actually there would be an even better solution, though I'm not sure if by default it would be acceptable: Turn small creatures into an item including living ones! Frob them to pick up then drop them like you would any dropable inventory item, dead or alive they would proceed from there Only obvious problem I can see is if someone made a rat or small spider patrol using path_corner checkpoints, in which case dropping them far away would make them unable to find their patrol routes any longer... though in this case they'd just endlessly stand there and not upset anyone I guess? Then again even fruit can't be picked up as items, you can only eat stuff like apples on the spot: That would need to be changed first, and like everything else it can be argued that it breaks existing expected behavior so likely won't happen.

Similar: My suggestion is getting rid of needing tdm_custom_scripts.script as a requirement. The problem is that unlike every other asset, be it a def or a skin or model or texture, scripts need to be referenced from a core script file for execution: FM's each need to contain a file with that exact name including their custom scripts. The problem with this is that no mods containing scripts can work out-of-the-box as a drag-and-drop pk4, the same way that say a custom character (just AI model or skin) can: Each individual FM needs to integrate it manually, universal mods aren't possible since the last pk4 loaded will override tdm_custom_scripts.script or tdm_user_addons.script breaking all previous mods referencing their own scripts from those files. The ideal solution would be just auto-loading scripts like everything else. But I imagine this may no longer be possible as it could break a lot of existing things like older FM's. One compromise I believe I suggested was allowing a dynamically named script to be auto-loaded by the engine, which would make it so different pk4's don't override the exact same file and conflict with each other: If your mod is named "whatever.pk4" for instance, the engine should auto-execute the script named "scripts/whatever.script" located in that archive... this would provide an elegant and equally sandboxed solution to this long standing issue.

Thanks... wasn't sure if this one was even noticed and especially intentional. Only real issue I guess is it being goofy: Imagine having to shoulder a tiny rat, both hands occupied so you can't use any weapons or items as you're forced to walk slowly... it's like trying to imagine someone needing all their strength to carry a pencil I don't believe it happened before either, IIRC picking up dead rats caused them to float in front of you like picking a vase before this change, hence I thought it's a new bug.

Wonderful, thanks! Then I can give it a try next and enjoy going to the end

Must say: I like the new hold-to-frob system. A bit confusing at first but far more intuitive and welcoming once you learn it. When I noticed normal frobbing keeps picking up bodies instead of dragging them I thought the FM overrode the behavior with a script, then I remembered this change being mentioned. However I believe I also found a bug that was surely introduced by it: You can now pick up and mantle the bodies of dead mice. Picking them up normally like a physical object makes sense, but now you mantle them with both hands and can't use anything else as if carrying a human AI's body... pretty sure the player could just put a dead mouse in their pocket it's not that large and heavy On my map I just placed an atdm:env_ragdoll_rat somewhere and happened to frob it: With the new default (normal delay) it triggered the mantling I'm describing on single click.

OMG I loved this. It's not one of the giant ultra-fancy FM's like Iris, but it did so much so well! Great in every aspect... visuals, story, gameplay, performance, even had more dynamic objectives that broke a bit from the ordinary patterns. I found less than half the loot in this one though, likely missed many optional areas and secrets... not good, will have to go back in or replay to see what I've missed. From those wonders that I did find... Managed to find two bugs worth noting, both in the same area: