Search the Community

I know of no reason why it wouldn't - the xray glasses are really the only thing that does any kind of screen effect. There is no FOV slider in the game so it was not tested admittedly. I am not recalling anything really that interacts with the players inventory directly in the mission. Dropping the glasses with "Drop Inv. Item" and reacquiring them doesn't restore the item to the players inventory either I am guessing?

That bug has been around for over a decade though. In some missions, changing FOV in console would only work when frobbing an item. I always assumed it was a bug in the game, but it's possible it's a bug in certain missions due to scripting. But I've definitely encountered it a LONNNNNNNG time ago.

If I understand correctly it sounds like something is basically removing the actual glasses entity from game so the inventory item points at nothing? Looking at the scripts this is the area where I see handling of the xray glasses overlapping with with other inventory items - basically it keeps the current inventory item as glasses after picking up other inventory objects so you don't have to constantly scroll through the inventory to to enable/disable them. Not sure if something is going haywire here: // dirty workaround to stop the inventory from changing away from the xray glasses if the player picks up loot or items while wearing them void playertools_xray_glasses::loot_loop() { string frobHighlighted; string selectedCurrent; string selectedPrevious; while( wearing_xray_glasses ) { selectedCurrent = $player1.getCurInvItemEntity().getKey("classname"); if( $player1.getFrobbed() ) frobHighlighted = $player1.getFrobbed().getKey("classname"); // has the inventory switched away from the xray glasses? if ( selectedCurrent != selectedPrevious && selectedPrevious == getKey("classname") ) { // has it switched because the player has frobbed an item or some loot? if( selectedCurrent == frobHighlighted || selectedCurrent == "atdm:inv_loot_info_item" ) { sys.wait(0.65); // if the player still has that item selected, switch back to the xray glasses if( selectedCurrent == $player1.getCurInvItemEntity().getKey("classname") && wearing_xray_glasses ) { $player1.setCurInvItem( getKey("inv_name") ); //switch back to the xray glasses } } } selectedPrevious = selectedCurrent; sys.waitFrame(); } }

does not work at all it turns out the game even warns about it just did not notice that part when i first fired it up. lowering the resolution does not get you much either i went as low as 640x480 and got 1 fps whaaaat!. there is a vulkan mod that alledgedly nets you a whopping 2 fps improvement at 1080p but it does not work for all... well atleast i can play it but its quite laggy on the 1080 ti, the 2080 ti runs it quite ok at medium but any higher and things go very very badly.

hmm with FSR in performance mode i could boost it to 25/30 fps at the lowest setting on the 1080 ti so from slideshow to barely playable at 1080p . strangely FSR does not seem to get this old card a whole lot of extras in this game, compared to the callisto protocol where i can actually keep it above 60 fps with raytracing on at 1080p, it is a whole lot more detailed compared to the latter though so that might explain it to some degree. also the 1080 ti does not fully support dx 12 ultimate so the mesh shading might not work all to well with it.

interresting got some of those games and i pretty much agree with his assesment. the talos principle ??? wow thats an old title to get the DLSS treatment. now for alan wake 2... the can it really run crysis crysis game. mesh shaders sound interresting but i think they kinda shot themself in the shoes making a game that litterally requires a 4080 just to play on high settings and if you still got a 1080 ti like mine runs at 15 fps at the lowest setting hehe. my 2080 ti can atleast play it at medium with around 35 fps but DLSS is a must even at 1080p.

After we were green-lit in just a couple of days, we were informed that we would have to form a legal entity, so that somebody can be held liable for potential copyright claims, and that we'd have to guarantee that there is no copyright infringement in the game. Since we are not 100% able to guarantee the latter, the prior poses quite a risk to the legal representative of the mod. So, we decided to drop this endeavor.

Why? Can you explain? Personally I see nothing wrong with that, looking at that function is obvious that they made it to not return anything, it just writes a float value to a file, and in C any function that doesn't return anything returns void. And those inner write functions may have error handling of some kind, so no need to return a bool for success or failure by the main function. The only potencial problem I see with it is they pass the file handle by pointer and there's no guard there for a eventual null pointer being passed to the function and it will crash if that happens but the fact this worked for years tells me they made sure that never happens.

I looked closer at the problem in Dragon's Claw, and this is caused by some kind of precision issue in dmap. The .proc file contains imprecise BSP plane: /* node 18377 */ ( 0.0399680398 1 0 1202.8780517578 ) -38 18378 And also there is a visportal stored there: /* iap 62 */ 4 37 50 ( -96 -1200 -488 ) ( 304 -1216 -488 ) ( 304 -1216 300 ) ( -96 -1200 300 ) The game loads the visportal polygon and computes portal plane from it, which is: plane (a=-0.0399680398, b=-0.999200940, c=0.00000000, d=-1202.87805) As you see, the plane normals are different by 0.2%. The visportal plane computed from polygon is almost perfectly unit, but the BSP plane is not unit (length slightly greater than unit). This makes the game think it is on the left of visportal in one place, but on the right of visportal in another place. I tried to re-dmap but the data is the same. I'll try to see what is going on. Indeed, making the portal axis-aligned would have most likely fixed the issue.

Playing Tears of St. Lucia, I noticed really bad framestutter in the church. It seems to happen around the builder guards. The game starts to micro freeze at a short interval (every second roughly). I don't know if this a beta or a mission issue.

Regarding worldspawn "forceAllShadowsBehindOpaque" set to "1", it doesn't seem to get restored on game load. To reproduce (works with any fixed mission using "forceAllShadowsBehindOpaque"): Add "forceAllShadowsBehindOpaque" "1" to the worldspawn in the map file. From main menu, "Start this Mission" or "Restart Mission". setviewpos Notice that the light leak is fixed (not present). Save game. Load game. Notice that the light leak is present (not fixed). Example 1. From main menu, "Start this Mission" or "Restart Mission". 2. Run setviewpos. 3. Save game. 4. Load game.

That's one way to not spoil what this game is actually about! Absolutely excellent game and so meta.

It's amazing people still make those, and this one is really good. Also, probably the most British point & click adventure game as of late.

I tried to debug this. It turns out that "global variables" includes all immediate values (including string literals which take 128 bytes each) and all global function declarations (4 byte per function, including even engine events). I see 119240 bytes before starting Iris, and 124924 bytes after starting it. On Bakery Job, I see 109680 before starting game, 109700 bytes after starting it. So It seems that core game takes about 110K, but Iris itself takes only about 10K, and the limit is at 196K. Does not sound like a big problem for missions. With addons, you have to compile all of them at once, and perhaps there is a lot of code, so you reach the limit. Ok, let's double MAX_GLOBALS for 2.12.

@lowenz @chakkmanit's not a bug, it's a helmet that protects against blackjacking. From the wiki: blackjacking: That's why the bj doesn't rise. Though if it still doesn't hit the guard, then that's a bug, I suppose. I think the game lacks a proper way to inform players about these helmets. The Training Mission doesn't include any guards with protective helmets, so currently the wiki is the only place one could learn about them... In my opinion, the "low back" can be deceiving. The guard in the screenshot doesn't have it, and some guards have it but can still be blackjacked.

TDM is already a niche genre. If we release it to a niche platform, it will be niche²! Since we would have to strip TDM off all its assets, recreate some and build a demo FM around it, it wouldn't be more than a tech-demo, i.e., there is no game, which would be niche³. It's just not worth it! We even did not release on Steam due to licensing issues and on that platform, we actually could have gained a huge player-base. No TDM dev has ever showed interest in doing such a thing and that also goes for most of our community. It's not going to happen unless you do it yourself. Be prepared to put at least 2 years of full-time work into this project.

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download: Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

Antialiasing mostly affects some backend logic, while the commit changed data structures in frontend. It is very hard to believe they are linked in any way. Maybe the bug is not reliably reproducible? Maybe antialiasing is an important condition when it happens, but otherwise it is timing-specific, so accelerating frontend made it pop up. Or maybe antialiasing is just one way to slow gown backend and using maximum soft shadow quality or r_fboResolution 2 would make it happen too. Maybe the particular behavior is driver-dependent (e.g. NVIDIA masks the error away). Which GPU do you have? Which drivers do you use? Which CPU do you have BTW? I cannot reproduce it myself, even on Linux VM. Does it happen in the very specific viewpos and goes away if you move away slightly? Maybe someone else can reproduce it?

It's an asset flip, the same face, nose, lips, even marks around the eyes, just the different hair https://duckduckgo.com/?t=ffab&q=heather+from+silent+hill+3&iax=images&ia=images&iai=https%3A%2F%2Fi.pinimg.com%2Foriginals%2F0f%2F20%2Fcd%2F0f20cdfccec60eab127aff236c63b3de.jpg I played the game ages ago and recognised her immediately, so others will too. Just remove it, it's cringe.

With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around. I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission. Same as: https://forums.thedarkmod.com/index.php?/topic/18054-fan-mission-the-accountant-2-new-in-town-by-goldwell-20160509/&do=findComment&comment=458491

How about using TDM automation framework (and maybe pcem/qemu)? More info see: https://forums.thedarkmod.com/index.php?/topic/19828-automation-features-and-discussion/

Thanks. Linux user and I play TDM at least weekly: Never noticed any physics issues myself, whatever happened in the FM must be a relatively rare scenario... that's a FM I haven't revisited so I was lucky to miss the bug then. There is in fact a little problem in latest Beta, though it's so small I didn't bother to document it carefully, but I'll share the idea of it at least: If you climb into a tight space between an object and the ceiling and turn on the flashlight, jumping may cause the light to phase through the floor and disappear temporarily. Say you have a crate pressed against a ceiling where you can only climp and go in while crouched... if the surface is high enough to allow a jump but just low to force you to be crouched, you'll see the light source of the lantern disappear temporarily in mid air. Think I saw it in The King Of Diamonds, if it's important I'll boot it up again and noclip to get a viewpos. Just to make sure you've seen my mention: Please check my message a few posts above where I attached a log, we have a crash where killing AI with a broadhead arrow can cause the engine to go down with a "tried to free uncached trace model" error... not even a main menu crash but one to the OS. It's pretty rare but if you fatally shoot AI often enough it will occur eventually.

You're right, libxml2 can't be fundamentally broken since it is such a core dependency on Linux, plus the exact same XPath queries work perfectly fine even within our own XmlTest, so it must be something specific to how XML is being used within the registry setup. I found a couple of online sources which suggested that XPath queries might fail if the DTD doesn't validate, but we don't have any DTDs in our XML files and the XML_PARSE_DTDVALID option is not set by default in any case. Encodings are another possible culprit (especially since the problem seems to be OS-specific), but as far as I know encodings wouldn't change the parsing of characters like "[" or "@", and if the encoding was so fundamentally wrong that even regular 7-bit ASCII failed to parse, then how would "//game" ever be found? It seems that whatever the cause of the problem is, it is very well hidden within the API and would probably require building libxml2 from source and diving into it with the debugger to find out what is going wrong. Right, that sounds like the best approach. I'll set the HEADER_ONLY flag on Linux too then for consistency, and integrate it as a header-only dependency like libfmt.

I think the game treats everything inside "fms" as "mission assets", and everything in game root directory as "core assets". You can check it at the start of game console, where all the paths are listed.

Since it's a one-off problem, only for the first ambient at game start, then the way you fixed it is really the right way, because the system-level alternative would be whole a little subsystem (a specialized fidelay and mandatory _z soundshader) just to handle the first 0.1 seconds of game start, and then the old system for all the maps already out there, which is a bit much. And I think it's not even that common because many ambients start quietly to begin with. That said, there might be an easy bit of code that could make sure the fade in always works for the first ambient that doesn't mess with anything else in the system, like a hardcoded initial 0.1 sec. delay only for it, and that may be worth doing. But it'd need experimenting and testing to make sure it works as intended and doesn't have unintended consequences. Anyway, it's good we have this documented for now as the way to fix the problem for other people in the future that run into it searching for a fix. In fact it'd be good to put in the wiki to make sure the fix doesn't get lost.