Search the Community

Had a go of this last night (all three difficulties) and enjoyed the changing seasons. Anyways, it was the perfect length to retouch with the mod again. Thanks for all your hard work.

I recently played The Last Offering on expert and had to start over 2 times because I forgot to save and accidentelly knocked out the 4th person.. It's so easy to slip into habbits.

They can always do it if they want to. Some people always do it. And some people blackjack of kill every A.I. in the map. Isn't it great that you're free to do either? By the way, I played a gazillion of Thief Gold and Thief II in the last year or so. None of them had a restriction in form of a no KO objective. Quite a few had a no kill objective though. Which perfectly makes sense to me. Of course, many featured the undead, and most didn't offer any way to deal with them. But, that's a different story. And, frankly, canon with the original games, as they did the same.

It looks bad with or without the bloom, as you can see in my last video. With bloom set to half it looks only slightly less bad than with bloom set to max — but still bad. Yes, there's no consistency to anything in darkmod because it was made by a bunch of amateurs. What's your point exactly? That nothing should be changed until the game is completely refactored to meet some nebulous standards of physical and mathematical correctness? Because I was told that is never going to happen (and I agree). So at the very least we can make the game look slightly less bad for now.

r_bloom_weight is set to "0.7" both in my 2.12 installation and in main repository. I never touched those values which means the default must be 0.7. Troy Sobotka is the original creator of AgX. He was active on Blender forums where he had long philosophical arguments about color with people. Also on Blender developer forums. I don't know if there's much more beyond those and his github page: https://github.com/sobotka Edit @stgatilov AgX however is a direct continuation of Sobotka's earlier 'Filmic', so there may be more about that: https://github.com/sobotka/filmic-blender https://blender.stackexchange.com/questions/164991/are-the-technical-details-of-filmic-available

I played 3 missions with this mod in the last couple of days. From small (The Wizard's Treasure), to medium (Volta 3), to large (Behind Closed Doors), and it works pretty well. I like it. Not being able to easily safe anytime and having to deal with your mistakes adds a lot of tension. Backtracking to the safe spot wasn't too annoying even on a larger map, and the extra safe you get on progress kept it from getting frustrating. I think I will keep using this.

Played this tonight. Great mission! It had a lot of Trail of Blood feeling from Thief 2. Relatively easy side, because there was plenty of darkness and plenty of space. Easy, well, if one doesn't take too much jumping risk. I did and of course fell to my death, last save million steps away, serves me right. Next time I was much more cautious and made good progress. As soon as I saw Yet another masterpiece among TDM missions, good work!

I'm certainly against including any AI-generated code. Remember: we don't change shaders just because they look more beautiful, there should be reasoning for a change and explanation of the math going on. As far as I understand, the main complaint is that colors over 1.0 are simply clamped to 1.0, right? And bloom is the only thing which depends on the values above 1.0. This is usually fixed by using "c / (1 + c)" function with some coefficients. There are a lot of existing tonemap formulas around this principle, we can probably choose some. The current tonemap consists of: gamma correction: C := C ^ (1 / gamma) (gamma = 1.2) brightness: C := C * brightness (brightness = 1) something: C := 1 - exp(-5 C) The first two came from original Doom 3, the last one is remnant of "HDR lite" that was an ancient attempt to make TDM look "HDR-ish" without even any extra precision. There are a few other corrections, but I believe they are disabled by default. Also, there are some technical stuff (dithering, sharpening) which are unrelated to the tonemapping itself. It is possible to look through existing popular tonemap shaders for games, and replace what we have with some of them.

The last Mac build we had working was 2.05

@kingsal Now it´s time (for the so long ago announced statement) a commentary I just wrote to Sotha´s “The last Offering “ reminds me to write my Resumee for Kingsals´s “HazardPay” as said there : the best Mission I ever played – for many and some private reasons ! In my opinion this mission should be a “ must know “ to all new and older mappers . What else to tell ? Nights In White Satin, Pt. 1 I used this at the ending of my video Walkthrough as a greeting dedication for you

I had an interesting idea in regard to how the TDM engine handles Z-fighting. It comes after my last FM where people reported terrain patches that were too flat causing visible Z-fighting with the ground brush: It seemed weird as both surfaces had the same shader and their mapping lined up, therefore even if the surfaces overlapped the same pixels should have been fighting with no visible artifacts. Turns out the engine makes it so even if the material and its relative mapping is identical, the surface also becomes brighter whenever there's overlapping. I was wondering if unless we're stopped by deep limitations in OpenGL, there is at least a way to get rid of this brightening effect. If we have the ability to control how Z-fighting is handled, I had an idea which could turn it into a great feature available in other engines: My suggestion is to mix the colors on all material maps, so instead of randomly adding them together we settle for the average of all Z-fighting surfaces per pixel. The reason this would implement an useful feature is if we could do it per map, we'd have support for mixing the albedo + normal + specular maps on multiple surfaces in realtime, something not currently possible unless done by the texture or material. Imagine a graffiti drawing on the wall: We could deliberately have the decal perfectly overlap the surface of the brush instead of having it suspended a bit in front... doing so would cause both the albedo / specular / normal maps to be combined, lighting would then follow the bump map of both the brick as well as the decal so both produce depth on top of each other on what would still appear to be a single surface. Even if my particular idea isn't possible, it would be nice if we could at least get rid of the brightening; Z-fighting would still occur, but at least it wouldn't be as obvious if you don't look closely.

Well If I want to go to the last mission in the list, I only have to click that button. Pretty neat I say. It's not relevant what is needed in the future. When that moment comes we can think about it again. Currently there is space for those icons, so it's good that it's used.

Every material consists of global keywords and stages. Stages are classified into ambient stages and interaction stages (diffuse, specular, bump, parallax). Interaction stages are partitioned into interaction groups. Each group is rendered as single draw call with interaction shader, its stages supply various settings (e.g. diffuse texture is taken from diffuse stage, specular texture from specular stage, etc.). Ambient stages are all extracted into separate list and rendered in their respective order. But this always happens after all interactions are rendered. In 2.12 and earlier, interaction groups were detected dynamically during rendering. There was some preprocessing code which was static (sorting stages, adding implicit bumpmap) and some additional detection in rendering code which was dynamic because it checked conditions. In the recent TDM version (hopefully in 2.13 too), the old approach is replaced with two new ways to detect interaction groups: implicit and explicit. Both ways are fully static and implemented straight during material parsing. Implicit detection. We go through stages in their definition order and add each new stage into the last interaction group. If the last interaction group already contains a stage of same type, then we finish that group and start a new one with the current stage. For instance, if we see interaction stages DSBBDDSBSD (abbreviated by first letters), it will get split into [DSB][BD][DSB][SD] groups. This should work fine for simple materials with one stage of each kind. It should also work fine for vertex-blended materials because they should have each group starting from bump stage (and hopefully they don't have duplicate diffuse stages). Explicit detection. There is new material keyword: interactionSeparator. If at least one such keyword is present in material, then explicit detection is used. Each interaction group consists of all the stages located between two consecutive interaction separators. The stages before first separator are put into a group too (if any), same applies to the stages after the last separator. Note that disabled stages are ignored during runtime, so it is possible to have several stages of the same kind in an interaction group, as long as at most one of them is enabled at any time. Explicit approach can be used for non-trivial cases, especially when stages are enabled by condition (like e.g. animated textures).

For glass, these might be shader limitations in this model, I wouldn't have my expectations too high. Last time I was working with glass, I managed to get semi-consistent results with transparent colored glass, but the cubemap reflection would still glow in the dark, so it was toned with shaderparm3.

Here's my playthrough of The Last Offering:

Oh, so if a path_corner targets an entity other than another path_* node, the AI reaching this corner will trigger this entity like pressing any button? This should be good perfect in that case, just never had to use this circumstance before so I wasn't sure. I generally only use scripts for complex circumstances when I really need to, there are ways without one in this case. Also for this particular FM, I'm challenging myself to see how much complexity I can achieve without using any custom scripts, mostly to try something new and see / showcase the power of the default entities when used right. That would probably make the AI complain about an item having been stolen, the goal is to have them look for the player... also it would rely on them seeing that exact spot. The alarm approach seems best now that I know how it's supposed to be triggered by paths. Edit: Can confirm the path setup works! If you have a guard walk across a series of path_corner's then connect the last one to a light, the lamp turns off then the guard gets there.

well the old unreal tournament games were just fun especially with some of the mods made for them. unreal was a pretty good single player game in itself focussing more on the conflict with the skarr and the impact on the na'pali aliens. sadly unreal2 was the last singleplayer game in the unreal world, while not as successfull as the tournament games it was quite fun.

Hello! To celebrate 15 years of TDM, and because so amazing missions have been made in my absence, I felt compelled to made a small mission for everyone to enjoy: The Last Offering! Mission briefing: Build time: roughly 30 h darkradiant time during october-november 2024. AI has been used for initial mission brainstorming, proofreading and polishing readables. Thanks: *Whole TDM community for everything. *Betatesters: thebigh, datiswous, Shadow Other: I challenge you to play this short mission without saving or loading! The player gets plenty of gold for gear: buy a good thieving kit and enjoy the mission without saving! It is quite possible it is more exciting that way. Let me know what you think replying to this thread: I'd love to hear about your experiences and opinions. Enjoy, and I hope you have as fun playing as I had making this! Download link: https://drive.google.com/file/d/1HthqgoeBKf7kgYTRm5ice5t31_90_PRu/view?usp=drive_link

Near mirror-image of the last contest we had. Top three places very hotly contested, and two fairly distant also-rans XD.

Dev snapshot. Semi-latest: My main internet connection is still down until we get it repaired, I can't transfer a lot of data on mobile so I haven't updated to the latest one yet. To my knowledge nothing in the last snapshot changed that would affect this so latest development makes sense. Printed version is #10890. Let me know if others can reproduce this or I need to try compiling my own test map. The steps are simple: Have a set of path_corner entities going through an unlocked door, put an AI with the "drunk 1" spawnarg on. For me the AI crosses fine without drunk mode on, but will just sit in front of the door forever after opening it otherwise. Slightly modified screenshot for emphasis.

grimm was properly ported by daniel while mine worked in x86 it kinda broke in x64, should be up now on github. as for my dhewm port i need to setup a github account again and diff the changes made but then daniel sees no problems with admitting it. changes since last time disabled the GLSL backend renderer, can be enabled in the imgui gui. if GLSL backend is enabled it also disables daniels shader based hardware gamma and softparticles as the GLSL backend lacks shaders for these (should also be disabled if using sikkmod as they break SSAO and DOF).

A great little map! I always love it when simple missions have a story twist in the end and I liked this one. Like STRUNK I didn't find the intended way out though and used the same trick, so maybe you should add text to the priest's journal to hint at the lever? Also if you are going to patch the mission, I found a lot of floating rats and I agree with others that the flowing water is cool but should have a puddle at the bottom. Last not least there are some text issues unless it's intended that some notes are missing several words...

Of course it is going to be my last mission.... Until I make the next one! Anyways, thanks everyone for the interest! I chose a few testers and let the testing begin. Everyone else gets to enjoy the polished product hopefully really soon!

Hey there Sotha, I'm a big fan of your work but I don't like the name of this mission. This isn't going to be your last mission is it? The name, The Last Offering sounds a little ominous and possibly foreshadowing... Say it isn't so.

This is the call for betatesters for a small and simple FM, I've been working on during the last month or so. The mission is called The Last Offering. Two or three, preferrably experienced, betatesters are needed. Volunteers?