Search the Community

Using the newspaper gui definition (guis/readables/sheets/newspaper_bridgeport03.gui) on a readable creates multiple warnings in TDM console. It still works fine, but there is a wall of text: The same is true for the other newspaper guis. Full info: to create a readable newspaper I used the model newspaper01.iwo and then changed the class to atdm:readable_immobile, then edited the info using the Readable Editor - I assume this is the correct way to do it. I also tried using one of the other readables such as atdm:readable_immobile_paper01 and selected the gui definition of a newspaper, but got the same result.

I'm looking for some beta testers for my new mission, A Night in Altham: This is a large mission - not gigantic like Iris or The Painter's Wife, but bigger than anything I've done before. Content warning: In the next day or so I'll put up a thread in the beta testing forum, with a link to the pk4. Thanks!

Demonstration Video I wondered if I could implement an improved lean for The Dark Mod. How was the result? Please see for yourself by checking out the video. The video shows: Leans from multiple games that show less view angle and more slide. Comparison between Thief and this lean proposal. Comparison between TDM 2.11 and this lean proposal. Aiming and shooting arrows while standing and crouching. Tap lean ability. Motivation There is something about the original Thief game's lean that feels really good. It feels close to actually peeking around a corner while not jarring the view. In an interview with former Looking Glass Studios developers, the interviewer asks them how they got leaning to feel so good while other FPS games have not. In a tweet by NamelessVoice, the author of the widely used Thief FM script library called NVScript, he said: New Lean Proposal Provide a lean that is more similar to Thief-style lean. Less view angle, more slide. Feels more natural, less awkward. Easier to aim and shoot arrows. Unlean more quickly. Feels like snapping your head back after suddenly seeing a guard. Improved lean during crouch. Compared to TDM 2.11, this lean can be used to see more around corners while crouched. Tap lean ability. Compared to TDM 2.11, this lean allows pressing the lean keybinding in rapid succession. Other: Fixed "lean getting stuck sometimes" bug in TDM 2.11. Fixed "lean getting stuck after saved game load" bug in TDM 2.11. Technical Details Bug Tracker https://bugs.thedarkmod.com/view.php?id=6320 Cvars At the moment, the new lean is toggled on via the tdm_lean2_mode cvar. Other cvars include: pm_lean2_time_to_lean (default "400") pm_lean2_time_to_unlean (default "300") pm_lean2_slide (default "200") pm_lean2_angle (default "8") pm_lean2_angle_mod (default "0.5") However, I didn't know how to proceed with this section. Does the new lean replace the old lean? Does the new lean become the default while keeping the old lean available? Code TDM 2.11 uses a sine easing function. Instead, this new lean uses a cubic bézier easing function. For a 2.11-Like Lean For a lean that is similar to 2.11, its cvars can be set to the following: pm_lean2_slide "100" pm_lean2_angle "18" pm_lean2_angle_mod "0.8" The following video shows a comparison between 2.11 and this new lean proposal with those cvar settings.

It took a while, but I'm very excited to finally make it to this stage! I'm hoping for maybe three volunteers to beta test. Best regards, Groden.

I tried to add a custom collider to a pot so you could, for example, hide a key in it that would fall out if the player tipped the pot upside down. This doesn't seem possible - any collider that isn't a single solid polygon gives me an error on map start. For example, something like this doesn't work: Is this just a limitation of the engine or is there a way to do it? It's not super important, I just thought it would be cool to do.

Currently readme's are txt files, but when they're longer, they can't be displayed correctly in the Notes section of a mission listing. If they would be xData files, scroll-buttons can be added so that the whole file can be properly read. This is under the asumption that it cannot be done with unformatted txt files. My idea (if possible) is to support both formats, so readme's of current missions still work correctly. Otherwise I don't see it happening soon, because all the txt based readme's have to be converted, so a program has to be written to do that job in a non-painful way. I orinally posted this idea here:

Hello everybody. The Beta Testing subforum said to recruit testers before making a thread there, so I'd like to recruit first and then make a thread there if anybody's willing and interested. I've just finished work on my first Fan Mission, "The Threepenny Revue" and I'd like to get outside opinions on it. I have a zip file with the directory and files that can be dumped into the /fms/ directory and it should play, but it hasn't otherwise been packed up properly yet. The files will be available on my own site, and I'll post a link to it in the Beta Testing thread if there any takers here. I'm still finding my legs with the process of sharing FM files, so I might mess things up but hopefully it works. Thanks in advance.

Though this is related to PBR as a component in getting it done right (like reflection probes) I thought it's an improvement of its own that's worth discussing. I don't know if this is implemented or estimated in some form, but working with light entities in my own FM's I haven't seen any spawnargs for it so I presume it's not. At the moment lights in TDM act as zero-scale points, light sources have no actual radius. I know what you might be thinking: Of course lights have a radius, it's the box that decides how far a light shines and what it affects! What I'm referring to is not the range but the emission radius, representing the scale of the bulb itself: Think of it as a minimum radius... at the moment lights only have a maximum radius, the minimum is currently a point. In modern engines this affects both specularity and shadow softness as well as how the light is distributed. Like most engines we shouldn't need anything more than a float describing the size of the bulb, a simple sphere ought to be enough... given we already work with radius boxes, we could instead use a separate box which would give us better control with unevenly shaped bulbs. Every default light entity should of course be updated to use this: Torches / candles would set it to the average size of their flame particles, gas / electric lamps should have it represent the scale of the light bulb or the lamp head. If done right this can greatly improve our graphics and add more realism, but as with most things it's not going to be that simple. Also this would create changes to the lightgem in all FM's but very minuscule ones that shouldn't even be detectable. There's 3 different components I presume we have to tackle independently. Soft shadows: Shadowmap softness is probably the easiest, just add the average bulb radius to their value. Specularity: At the moment all lights seem to produce specular orbs of the same fuzziness on shiny surfaces. What we probably want is for lights that keep their min radius 0 to produce a fully sharp orb or dot, softness is added to each light's ball based on this radius. Light projection: The biggest aspect is changing how light is distributed, the projection texture / falloff material would emanate very differently. Everything inside the bulb would shine at the intensity of the center pixel and should start fading from the min radius toward the max, the projection texture would get slightly inflated like a balloon. The best solution (which also accounts for blur) seems like a 2D shader that copies the light texture onto itself at slightly different offsets to make it fuzzy: There's already a blur filter that does just that when you're underwater for example, we could to get away with doing the same thing to light textures using the min radius as the offset parameter. As lights typically don't change scale, this should be possible to do only once at map start rather than every frame including for moving lights like torches, this way we should have no performance loss.

I hope I'm not proposing some unfeasible idea that was already imagined before, this stuff is fun to discuss so no loss still. Riding the wave of recent optimizations, I keep thinking what more could be done to reach a round 144 FPS compatible with today's monitors. An intriguing optimization came to mind which I felt I have to share: Could we gain something if we had distance-based LOD for entity updates, encompassing everything visual from models to lights? How it would work: New settings allow you to set a start distance, end distance, and minimum rate. The further an entity gets the lower its individual update rate, slowly decreasing from updating each frame (start distance and closer) to updating at the minimum rate (end distance and further). This means any visual change is preformed with frame skips on any entity: For models such as characters animations are updated at the lower rate, for lights it means shadows are recalculated less often... even changes in the position and rotation of an entity may follow it for consistency, this would especially benefit lights with a moving origin like fireplaces or torches held by guards which recalculate per-frame. Reasoning: Light recalculation even animated models or individual particles can be significant contributors to performance drain. We know the further something is from the camera the less detail it requires, this is why we have a level-of-detail system with lower-polygon LOD models for characters and even mapmodels. Thus we can go even further and extend the concept to visual updates; Similar to how you don't care if a far away guard has a low-poly helmet you won't notice, you won't care if that guard is being animated at 30 FPS out of your maximum of 60, nor if the shadow of a small distant light is being updated at 15 FPS when an AI passes in front of it. This is especially useful if you own a 144 Hz monitor and expect 144 FPS: I want to see a character in front of me move at 144 FPS, but may not even notice if a guard far away is animating at 60 FPS... I want the shadows of the light from the nearby torch to animate smoothly, but can care less if a lamp meters away updates its shadows at 30 FPS instead. The question is if this is easy to implement in a way that offers the full benefit. If we use GPU skinning for instance, the graphics card should be told to animate the model at a lower FPS in order to actually preserve cycles... does OpenGL (and in the future Vulkan) let us do this per individual model? I know the engine has control over light recalculations which would probably yield the biggest benefit. Might add more points later as to not make the post too big, for now what are your thoughts?

I don't know if the forum has a looking for thread, i couldn't see one. I am looking for a mission where you go in to a mansion it is normal at first until on the upper floor you follow a glowing mouse in to a room and all of a sudden it is over run with undead.

Last night we chatted on Discord about Vulkan support and PBR, bringing up a system for adding proper reflections once more. I suggested screenspace reflections but it was argued reflection probes would still be better than SSR in our case, a ticket for that is already open but I'm uncertain whether it's the best way: A manual approach would need new entities to be placed by the mapper... this requires extra effort and would exclude old FM's that are no longer updated, while the result will also be inaccurate and static meaning you won't see an AI reflected as they walk on a shiny metal plate for instance. If PBR with realistic graphics can be a hope for 2.12 or later, we'll definitely want to do it right rather than using a limited / limiting system. A technique came to mind that might just work for our engine and setup. I wanted to share it here before I forget the specifics; This might already be a common practice and even have a definition, for the purpose of this thread I'll just describe it as I originally imagined it and feel this would work for our engine. The idea is we'd use reflection probes but in an automated fashion: A probe is automatically spawned in every valid area (within bounds) in the player's view, at a given grid unit size. For example: If the grid scale is 16, a probe may exist at position '0 -48 16' another at ''0 -48 32' and so on. Every point projects its result on all surfaces in its radius which contain a specular channel masking it, the best alternative presently available till we were to convert all textures for PBR support. The cool thing is the same cubemap can also be projected as a light source, allow for global illumination in addition to just reflections! This would be similar to how the Irradiance Volume works in Blender / Eevee except each dot renders a little cubemap from its perspective. I already know what everyone is rightfully thinking: This is going to kill performance! After all each probe needs to produce a render from its perspective, and being a 360* panorama it will open portals in all directions. Normally that would be insane, but I thought of various ways in which the impact could be greatly minimized to very bearable amounts. The frame buffer of each probe will be at a very small resolution by default since much detail shouldn't be needed. Even 64x64 per cube face might do. Each probe only needs a draw distance double its grid size, given it only has to see as much as is necessary to fill the gaps between it and its neighbors. So if the grid size is set to 64, each probe would only have a draw distance of 128 to cover the space in between its neighbors, nothing beyond that would exist to it. Only probes the player can see would ever be spawned and calculated; If the view frustum doesn't overlap the virtual cube who's corners touch that probe's neighbors, the probe is dropped from memory. Probes are also only spawned in a valid visible space, never out of bounds including rooms culled by portals. A draw distance after which probes are removed or not spawned can also be included. This would further help by making any probe further than X distance be ignored, slowly fading away as to not noticeably pop in and out of existence. Reflections / GI are a discrete effect you'll only see up close. Similar to lights and shadows, the result of a probe should be cached and not calculated unless necessary. This means that unless something moves within radius of that probe its cubemap won't be rendered again. Probes would only be updated either when they first come into the player's view, or if something touching their cube has moved. Note that particles and lights with animated textures would have to count as you may see them in a detailed reflection, candles and torches would force constant updates per-frame for probes they intersect. If with all that performance is still affected, frame skipping is also a solution: Reflection probes can update at a lower frame rate to further decrease their impact. If you have a 60 Hz monitor and are running TDM at 60 FPS max, reflections could run at 30 / 20 / 10 FPS without looking out of place. They could in fact be defined as a fraction of your average framerate, so for the FPS you get you can decide whether it's going to be 1/2 or 1/4 or so on of that... this would have the added advantage of exponentially gaining back FPS the lower your FPS goes. There are several reasons why I believe this would be better than mappers manually placing new probe entities: Extra work is required for the mapper, who needs to figure out how to cover each area in probe lights. Every piece of the map would need to be encompassed in a reflection / GI probe otherwise you won't get shiny surfaces or bounce lighting which will look out of place. Most existing FM's will never be updated to use this: Only maps created or updated after the feature is introduced would benefit, anyone playing old missions will get boring visuals without reflections / GI which will be inconsistent to new ones. I strongly believe this should be done as an universal effect like SSAO. Single large probes will produce inaccurate results; The larger a cubemap is, the more drift and a fake results you get with distance from its center. This can be mitigated by using parallax corrected cubemaps which should be used for automated cubemaps too... none the less you get a single point of vision for a large room which makes the result inaccurate the further you go... with an automated approach you could have many probes in a dense grid (if your hardware allows it) for a much more accurate result at any position and angle. What are your thoughts on this solution, do you think it's realistic and can work out? I do believe it should be either this or screenspace reflections the way they're done in Godot or Blender / Eevee. If SSR isn't the right choice for our engine, reflections and global illumination alike could be captured using a global grid of capture points shining within their respective areas.

Does anyone have the latest version of the md5 import / export scripts for Blender, for both importing and exporting md5mesh and md5anim with the latest Blender release? I last attempted to rig a custom character ages ago, the scripts are long unsupported and I couldn't find new ones. Blender is now at version 3.5.1, do we have md5 scripts for that?

I wanted to bring this up for a while and am sorry I took so long. As such this thread is based on an old observation, I didn't retest recently but from what I know this limitation still exists with the latest code. If others confirm it and the issue is considered solvable I may post it to the bug tracker as well. EFX for spatial sounds are an amazing addition we had in recent years, however they suffer from a noticeable limitation: Reverb only accounts only for the location of the player and not that of sound. Sounds originating from a place with reverberation will not cause any echo if the player isn't standing in that room... oppositely sounds coming from outside will be heard with the full extent of the reverb effect in the room you're hearing them from, they should be echoing less due to not originating from the reverberating hallway. Example: Let's say there's a Builder church with a large hallway containing a reverb definition, inside there's an ambient sound of chanting. If the player is standing in front of the church door, they will hear the chanting without any kind of echo: Only once they step through the door and walk inside the echo suddenly makes itself heard. In a realistic scenario you'll hear the reverberation of any sound coming from a room that causes it, even if you're standing far outside that room hearing this noise in the distance. The simple solution would be a mixture between the location of the player's camera and that of the sound source: Each sound gets 75% the reverb defined in the room it's originating from, then on top of that all sounds being heard by the player anywhere have 25% the reverb of the room the player's standing in (current functionality). The more realistic but also more complicated option would be to use the portal tracing already implemented for sound attenuation and make each sound pick up reverb from each EFX room it passes through, accounting for the room of origin the room the player's standing in but also the rooms it's passing through; That way a noise emanating on one side of a building and passing through open windows in a corridor to reach the player on the other side would still echo, even if both that sound and the player are located outside in an area without reverb.

Time for a new contest eh? This contest will almost be a speed build contest since we are shaving a few days off the typical 3 month span of a standard contest. TDM has no shortage of horror themed missions but since we missed the chance to have a Halloween contest this is a "gift" to the large contingent of TDM fans who enjoy some horror in their life. I wont go crazy with bonus points in this contest but there will be a few incentives... The overarching theme of this contest will be placing the player in dangerous locations. Having to climb down into elevator shafts, narrow caverns pits, etc to acquire loot or trigger objectives. This theme is meant to be paired with an incentive to use vine arrows to escape (etc). There is no hard requirement to adhere to this theme but players can judge your theme score using this concept as a baseline. Bonus incentives: 3 Perfect votes added for creative Vine Arrow usage 1 Perfect vote for creative Mine usage 1 Perfect vote for creative Flash-bomb usage 2 Perfect vote for EFX audio 1 Perfect vote for Subtitles 1 Perfect vote for adding Translation string support As with the previous contest, we may need to add a scaling factor if there is lower than expected participation from voters. Standard Contest Scoring: Total Points = (gameplay * 3) + (Appearance * 2) + (Story \ Theme * 1) Max Possible = Total Votes * 5 (Outstanding) Category Score (%) = Category Points /Max Possible * 100 Total Score (%) = Total Points /Total Max Possible * 100 The vote count was equal in all categories for everyone so: TotalMaxPointsPoss (TMP) = AllCategoryVotecount(ACV) * 30 Full Weighted Score (FWS) = (Gamescore*3 + Visualscore*2 + Storyscore) / TMP Pre-existing maps: The contest will be for newly created missions. Authors can use modular assets and prefabs and limited pre-made map sections. If you wish to use an existing WIP mission, you will need to declare this in your release thread and other participants will need to agree that your mission should be allowed to compete. Otherwise, if multiple authors with WIP missions decide to join we can create a separate scoring for those missions. The submission deadline will be Christmas Day ( but we can extend the deadline if all participants agree to the request. ) Please declare you intention to join in the fun!

Hey folks. For the month of May I am running as great a distance as I can to raise money for one of our local Canadian children's hospitals, the IWK. Today all donations are matched dollar for dollar by a corporate sponsor. If anyone would like to support my efforts, it would be greatly appreciated. https://www.millionreasons.run/fundraisers/timgormley Thanks!

Beta Testing: "Seeking Lady Leicester" As most people here know, grayman, longtime lead coder and mission designer (best known for the "William Steele" series), passed away in the spring of 2021 from cancer. According to grayman's will, his son has subsequently donated two unfinished missions to our community. These two projects are completely independent of each other and there is no relation to grayman's well-known "William Steele" series. The mission "The Black Mage" was completed by me last fall and released on Christmas 2021. Bikerdude along with Amadeus and Dragofer have worked for almost 18 months on the second incomplete mission "Seeking Lady Leicester", ready now for beta testing. This is a mansion mission, but it also includes outdoor areas. The playtime is about an hour if you run through it quickly, but if you want to see all the locations and secrets, you'll be busy for several hours. From the feel of it, I would say that this is an advanced mission, so it's surely above "The Black Mage" in terms of difficulty. I haven't played it myself yet, but I've looked at it, and it looks damn good, just like everything else Bikerdude has produced in the last few years. Please sign up here for beta testing, if you can test on 2.11 b4 or higher as this will be a 2.11 release. I then will provide you with details for testing via PM which will take place via Discord. It would be very nice if we could get a lot of testers for this mission, because this release will be the last one that will include graymans name in the authorship. He was very meticulous about testing, so let's not let him down. Jack

Hello, I have some roles to distribute for: - builders - mages - pagans - inventors - regular guys (you know which type of guys, the bad watchmen guys) Any new voice talents around?

Just gonna leave this here, saying support for the women in Iran fighting for their rights from being treated like lesser beings, and also support for those men who choose to stand with them against the Ayatollah's madness.

Hello, I think I have done a mishandling (I remember I have tried something to run "Vitalic Fever - Hidden Hands who worked slowly by the time) So the problem is that I see every line on an object or character as showed on the picture below. And I don't remember how to remow that Thank you for your answers