sullium

@snatcher @thebigh just making sure you two actually get notified lol, take your time of course

I would still welcome more testers, but even so I think now is a fine time to open the beta thread! Anyone else who wants to try it, feel free to reply here first and make it known. Link to the thread: Thanks and Merry belated Christmas!

Hi, I have a unique little mission to share soon for beta testing! It's an obstacle course, hidden within the city, to teach movement techniques that some players may not have tried yet. It's meant to be mostly easy, the "advanced" in the title just indicates to all that it's not a required tutorial before other missions. I've chosen a few tricks to teach that are useful, but hopefully still sensible and not too glitchy or game-breaking. This is my first mission and the visuals are quite blocky at this point. However, I did put some thought into the layout and textures, and I tried to write the readables "in-universe" while still clearly explaining things. Anyone will be welcome to try it out, give any feedback, and maybe weigh in on what the future of this kind of mission should be. If you're interested then please reply here for now, and soon I'll make/link a thread in the Beta Testing forum. (Obviously this is a busy season for many, don't worry if you reply and then end up not playing for a while, I have no deadlines in mind.) A few screenshots (in spoiler):

Hi, so my FM's map file is currently just named "j.map" for quick command typing. However, as I prepare to pack up the mission to share with others, it seems cleaner to rename the map file to something a bit longer and more specific. To rename it I think I just need to do the following: 1. Change name of j.map (obviously). 2. Change name of j.xd to the same new name. 3. Within that xd file, correct the path "maps/j/mission_briefing" for the briefing data to reflect the new name. 4. Edit startingmap.txt to replace j with the new name. 5. Dmap, test, then eventually clear out previous files from the maps folder. Is that all that should be needed? Or maybe I'm missing something? Thought I'd ask now instead of barreling ahead and having to fix something later. Here are screenshots of the folders if it helps (in spoiler): (I also want to rename the jump_training folder to something else before packing and sharing, but as far as I can tell that shouldn't be an issue at this stage.)

Hi, it's been 4 months (and change) since I posted about my tutorial jump map. Real life got in the way, as did my overthinking of things that shouldn't matter at this stage. But I have good news! About a week ago I dusted off DarkRadiant, scaled back my goals a bit, and got back to work. Now I have a full course built with 9 climbing tests implemented. It even has a tricky secret that came about organically, almost by accident. At this point I'm taking the opportunity to finally actually try some of the "housekeeping" tasks of mapping: visportals, location settings, objectives, etc. I imagine I'll finish cleaning up and have something nice to share in the Beta Testing forum within a week or two (for real this time!). Some screenshots: (The character above is set to Team 5 so he isn't hostile. No one to fight or sneak past here, just a couple of supervisors.) (That last one defies screenshotting but it's actually the final challenge. The rest of the tests/tutorials before it are made to be easy and simple, but this one could potentially take a little while.)

That's actually done with the Next/Prev Inventory Item binds, not the Parry/Manipulate bind (unless I'm missing some other way to use that).

Yes but it's a little vague. When I came back to the game from a break, I initially thought it might be for secondary frob-esque actions like snuffing candles. Of course, snuffing candles is actually an extra function of "Use Inv Item" but that's not obvious from reading either so it took a bit of testing/deduction to figure out what does what.

The binding to rotate objects is Controls -> Actions -> Parry/Manipulate. I forget if it does anything else besides that and parrying, if not then maybe it should be renamed to "Parry/Rotate Object" or something like that so it's less ambiguous.

I think default TDM's standing walk in particular is a bit off. The quick step rate feels unnatural and also seems to make it worse for sneaking then I would expect, especially considering the visibility trade-off for standing vs crouching. The rest of the footstep rates and the movement speeds in general feel okay to me in default TDM. Not that you shouldn't experiment to improve them, just adding my two cents on that part of the discussion (I haven't tried the mod yet).

Thank you @Bergante! My plan is to finish this rough playable version eventually and post it in the Beta-Testing thread. I have hopes to make it resemble an actual mission fit for the downloader, but feedback will help me decide if that's really desirable and how best to go about it if so. I wonder if a post in the general Dark Mod section that acts as a "climbing thread" might help with this instead. People could reply to it to share climbs for any FM. A potential downside is that, if the climber only posts in that thread, the FM author may not get notified of some glaring skip or issue that ought to be fixed. Tricky... The shop description for moss arrows actually says they can "cushion hard falls", but I didn't notice a difference in fall damage when I tried testing it just now. That would definitely be a cool feature to fix/add.

Hi, I'm working on a tutorial "jump map" with written instructions to teach movement tricks. I'm aiming to show techniques that are helpful, but not too glitchy or immediately game-breaking. So far I've made 4 tests, with plans for more. The first two tests deal with high jumps. Basically, a moving jump from flat ground launches you either 52 units or 60 units upward, based on some logic. My jump map tells a few useful ways to do the higher jump on demand (jumping while creeping is the simplest, the rest would be a bit wordy to write out here). Here are the two high jump tests, one mainly vertical and another which calls for a running start: The next two tests relate to slopes. Moving down a slope reduces jump height, but on the flipside running up a slope lets you jump higher. Also, landing on a slope reduces or even negates any fall damage you would have taken, as long as you don't have too much momentum moving in the uphill direction of the slope. Pics of the two slope tests, one for jumping and one for landing: I also plan to make tests involving leaning mantles and anything else I find/learn that would fit. Some ideas have occurred to me for why this may exist in-universe. Maybe some faction wants to train advanced agents, so they set up a training course running through an abandoned/ruined city section ("built over" like in the FM "Pinnacle: A Test Of Talents"?). And maybe, if word got out about it, a thief would get hired to find and sabotage said training course...

I noticed a comment on my video about fixing this in the future, as in, removing the ability to blast jump. (Not sure who left it exactly but I think this is worth discussing here anyway) It's understandable to want to remove it, as it surely allows skips, exploits, and out-of-bounds routes that mappers haven't accounted for. It's also unrealistic and thematically odd that Corbin survives a fire arrow blast which kills most NPCs instantly. However, I say blast jumping probably shouldn't be removed. I think it's one of the "good exploits" that does little actual harm while adding fun and depth for those who think of it and choose to abuse it. The self-damage, loudness, and cost/rarity of fire arrows all make it very situational, almost balanced in a way. And the basic game logic is sensible: explosions launch things around, including the player. Compare to another existing exploit, where you can stick arrows into surfaces and then stack objects on top of them to climb on. Similarly "game-breaking" and slightly unrealistic, yet it has survived this whole time and I wouldn't strongly advocate for removing it either. These aren't things a new player will think of and confuse for intended progression methods, they're just fun things to try in a game with physics and climbing. Curious to hear others' thoughts on this. I admit I haven't been active on the forums forever, so I'm not sure how many here would agree or disagree.

A quick demo video of using a fire arrow to blast jump up to new heights. It may be loud and harmful to the user, but it's still a fun option! Done on the mission "Tears of St. Lucia" on Expert... which thankfully doesn't seem to affect the self-damage.

I believe I know the bug you're referring to, which was fixed in 2.13: I never thought it was a very fun bug, actually I thought it was a strong enough exploit to make the game more boring. Dead simple to do, regularly turned you invisible in completely bright areas. Also hard to avoid abusing it unless you just stopped leaning in general.

Hi, I actually noticed this behavior and reported it in the Training Mission thread a few weeks ago, thinking it was specific to that mission: Of course, if you've noticed it outside the Training Mission then it's probably better that it's also posted outside of that thread as you've done here. An important thing to note is that not all keys can be "surfed" or elevator-ed, in my experience. Several of the keys in the Stealth section of the Training Mission don't have this problem, and when I tested keys in another mission (can't remember which now) I also failed to reproduce it.

I see a light leak through this shelf in the Objects And Handling section, but only when using stencil shadows: When using shadow maps instead, the light doesn't leak through the shelf anymore: Also notice the odd lighting under the bed on the left. It seems the wooden frame is the only part of these beds that casts shadows, so light goes right through the blankets, mattresses, and pillows. ALSO also, the keys in the Keys And Lockpicks section have funny collision when I "drop" them from my inventory and hold them. If I jump while holding one of those keys below me I can hover and fly around on them. This doesn't happen with the Guard Post Key found in the Stealth And Shadows section, so it seems some but not all of the keys in the mission have this physics issue. I'm running TDM 2.13 on Windows 10. Nitpicks aside, I very much appreciate the new equipment tutorials and lighting effects from the recent update, well done!

I climbed Glenham Tower without rope arrows in 34.42 seconds: I used a more direct route than the way @Twitch demonstrated here before. Route details (in spoiler): - I have watched many speedruns but this is my first time actually doing one and posting it. When I realized this route was possible, I figured making a new "category" out of it like this would be a fun way to share it. - It might be faster to knock the bricks down from further down, which could be done by "dropping" and then throwing an inventory item such as the journal or spyglass. - The video is 60 FPS, but I was actually playing at 175 FPS as I use my GPU driver to cap it there. Maybe this is easier or harder at other framerates, I didn't take the time to test. - The timecode on the video counts recorded frames in the right-most field. Converted to decimal, it rounds up to 34.42 seconds.

Hi, sorry to say but I just got the "Multiple entities named 'PercyQuill'" error that was reported here before. Percy stands up from his desk to investigate a disturbance, then as he gets in position to sit back down I'm booted to the console/main menu. It isn't consistent, but I got it to happen twice: the first time when I was playing casually at 170 FPS, and the second time with the original "capped" 60 FPS mode after a while of testing from my most recent save. I'm also seeing another, more consistent issue with Percy and his quill: if I jump and land loudly a few feet away from him, his quill almost always flies out of his hand, and after this he becomes completely unresponsive. He just sits there, pretending to write with no quill in his hand, as I jump around and throw candles at him. I'm running TDM 2.12 on Windows 10, and the menu shows I'm playing version 4 of the mission. Otherwise I really like this mission so far! Next time I play I might try the script provided by Obsttorte above and see if it helps.

The issue doesn't seem to happen at all for me on version 2.03. Leaning towards a nearby light usually brightens the light gem as expected and never darkens it the way it does in 2.12. Tested several lights in both the Training Mission and St. Lucia.

Yeah I'm seeing this too. Also running TDM 2.12 on Windows 10. Here's a decent spot to test it in the Training Mission, near a light on the path to the "Stealth and Shadows" tutorial building. Position is (-441.6 -2420.27 221.35) according to the screenshot filename. Crouched, normal: Crouched, leaning forward: It seems to work to some degree on most or all lights, but the strength varies. I feel like it's something to do with the elevation of the light compared to the player, not sure though. Definitely quite abusable to hide where one shouldn't be able to, getting nearly the minimum light gem value despite being very close to a light source.

Alright, finally reporting back with progress and screenshots. I made a custom ambient light material, identical to the default "ambientlightnfo" except that it takes its cubemaps (diffuse and specular) from a file path: lights/ambientlightnfo_custom { ambientLight lightAmbientDiffuse cameraLayout(env/lights/gradgDiffuse) lightAmbientSpecular cameralayout(env/lights/gradgSpecular) //lightAmbientDiffuse _ambientWorldDiffuseCubeMap //lightAmbientSpecular _ambientWorldSpecularCubeMap lightFalloffImage makeintensity( textures/lights/ambientlightnfo) { forceHighQuality map textures/lights/ambientlightnfo_amb colored zeroClamp } } Then I generated gradients in GIMP and exported square TGA images of them for each cubemap face, to be placed in the file path and renamed so the material would recognize them. My placeholder cubemap was just six copies of a white-to-black, top-to-bottom linear gradient image. It looked like this in-game: This did give contrast to grid-aligned surfaces but it butchered everything else with nonsense lighting and artifacts. Clearly something more subtle and reasonably "directional" would be needed. To that end, I experimented to make cubemaps similar to the default (bright floor, darker ceiling) but with slightly different gradients and brightness values. Here are the custom cubemaps I ended up with after some trial and error (stitched into cross formation for viewing): Diffuse: Specular: Note that the four "wall" faces are the same for these cubemaps, so I only need to export three images (up, forward, down) each and then copy-paste. Now for some comparisons between the default material and the custom material that uses the cubemaps I made: Courtyard: Default: Custom: I like how the shaded floor, wall, and ceiling on the right get progressively darker with the custom cubemap. Default had the wall and ceiling looking almost the same, and thus the floor's brightness stuck out more to me. The stone wall/floor look a bit closer in color with the custom cubemap too. Guard: Default: Custom: The armor looks shinier, because the custom specular cubemap has high brightness/contrast on the "up" (floor) face. There's also a noticeable difference on the guard's hands, which I think look better with the default diffuse cubemap due to stronger shading. Dark Room: Default: Custom: Lost some contrast and depth on the walls, in exchange for a more even/progressive brightness shift between surfaces. Finally, the Protruding Bricks: Default: Custom: This brick material is extra bumpy so it reacts very differently to each diffuse cubemap. I guess the default must fade quickly near the top from bright to dark, so the light comes from almost straight down to give depth to the nooks and crannies on the wall. By contrast, my custom cubemap's fade is gradual, resulting in a less sharply vertical light direction and thus more smooth/flat shading on the wall. Most of the changes are pretty subtle and some may be negative, but my material does address the issue I saw before and I think it could look nice in the right mission. Overall this process seems like a decent way to globally adjust a mission's ambient lighting beyond the settings provided in Dark Radiant. It could get tedious to keep making and then testing different cubemaps though, especially if you change the "angle" of light so that every face needs a unique image.

Thanks, changing the cubemap sounds promising! So which cubemap is the ambientlightnfo using by default? I see cubemaps are stored in tdm_env01.pk4, but I don't know which set to look at.

Hi all, so I've been playing around with doing daytime lighting in a global fashion (ie. not carefully placing/sizing new lights for each outdoor space). The ambient light will be unusually bright, so I figure I should be picky about it to make shadows look as nice as possible. However, the existing light textures look a bit off here and I have no idea if/how it can be improved. When I use the "ambientlightnfo" texture for my ambient_world light, my sunlight test map looks like this: The walls in the dark indoor room look perfect, they seem to be lit from above which gives the bricks depth. But the floor is way brighter than the other surfaces, and both the floor and ceiling have quite flat lighting. The long shadow in the center of the outdoor image looks oddly darker on the wall than on the floor, due to the brightness difference. Even in directly lit areas the floor is noticeably more blue than the wall (since the ambient light is bluish). The main other texture I found that worked independent of the light's position was "zol_nofalloff". This one doesn't have the floor/wall difference but it's totally flat and "fullbright" so it looks quite bad at this brightness: Would it be possible to tweak the ambient light to make most/all surfaces look nicely lit like the walls do when using the "ambientlightnfo" texture, with fewer inconsistencies between surface angles? Or perhaps this breaks the laws of physics and I should pursue other options? (Side note: I did find this great Doom 3 outdoor lighting article through a link on the TDM wiki. However, I want to see if I can get by with just the sun and an ambient_world light, for simpler setup and hopefully better framerate than that solution.)

It works like normal for me when I cap to 144 fps. Seems like there's a cutoff somewhere between 150-170 fps where it suddenly starts to become a problem. Also thanks for reminding me, I just edited to add those details.

Hi, I tried playing TDM on a 170 hz monitor but there seems to be a problem with the footstep noise rate and camera sway speed when creeping at very high framerates. I tried a few searches in this forum and couldn't find any posts about it so here goes. With the Max FPS setting at 150, creeping footstep noise and camera sway seem similar to capped 60 fps behavior, possibly a tiny bit faster. With Max FPS at 160 and then 166, the footsteps slow down such that creeping feels noticeably floaty. With Max FPS at 170, I've recorded a whopping 1 minute and 20 seconds between starting to creep and hearing the first footstep noise. The camera sway is slow and smooth enough that it is hard to notice at all. My specs: Windows 10 64 bit, Nvidia RTX 3060 Ti, Intel Core i7-13700KF. I'm playing on TDM 2.11 and have experienced this issue while testing both the Training Mission and Tears of St. Lucia. On a possibly related note, the "Max FPS" setting in found in the game's menu seems highly inaccurate. According to the game's own fps counter as well as my external counter, "Max FPS 180" actually caps the fps to 166, "Max FPS 200" actually caps fps to about 180, and so on. For this post I used the numbers shown in the game's menu, not the ones reported by the counter.