Leaderboard

Good catch. If that's true, we have to fix that! That's not intended design, as far as I know.

As for my own opinion on mantling with a body. Im for it. However, I worry that this could have the opposite effect and break some missions where the author anticipated the player not being able to mantle with a body. Risky waters changing mantle rules, but.. im not against the effort. I could see allowing waist high mantles with a body, but not full on overhead grabs and mantles.

Thank you for posting both missions into this Forum. This helps me alot in writing the Music!

beta211-08 is available. This is also considered "release candidate", so 32-bit executables are available. You can download them using this link: simply unpack these two files into TDM directory and run one of them to play. As long as you don't run huge missions, please test 32-bit executables a bit, especially on Linux.

Personally I'd rather not have it, but there are missions which already depend on that, so my opinion is irrelevant. The most important thing here is to see whether the falling damage can be reduced to something players would expect and won't feel punished by.

I think we should leave shouldering while climbing as is to avoid breaking anything, but we should probably fix what @peter_spy just discovered. Maybe disallow dropping bodies while attached to climbable. Anyway, I guess we are all on the same page regarding shouldered mantling: Waist-high only. @stgatilov noted on the bugtracker that the current implementation doesn't tie in well with the existing mantling conditions. So, my suggestion would be, once 2.11 is out the door, we'll fix that and whip out a dev release. Sounds good?

Oh my, this really needs addressing. Not only can you climb a rope with a body, you can also drop it while on rope, and if it's an unconscious AI, it will take absolutely massive damage. This is dropped from approx. 192 uu:

Yes! It is mandatory that the player be able to climb those vines with a body although it is not mandatory to mantle with it. I would suggest we don't change that rule as it could effect this mission, PD3 and who knows how many others

I didn't recall this myself either. Minute 5 onwards.

Would it be possible to add a setting to adjust the gamma/brightness when a UI page (especially a readable) is on the screen? Some readables can be quite bright or blinding. Thief (NewDark) has a setting for this: ;; From Thief's cam_ext.cfg ; enabling this option allows the UI (menus, map/objectives, readables) screens to have its own gamma setting ; useful if you get blinded everytime you open the map or read a book gamma_ui 1.0 The main issue I see with implementing this is that readables within a mission can vary greatly in brightness. One mission that comes to mind is Iris. The newspapers are nearly white, so they can be very bright, but other readables in that mission can be fine. I've attached two screenshots to show the difference given the same gamma/brightness settings. Given that variation within a mission, I'm not sure if this feature could actually be implemented. Maybe there is a way to have a threshold for brightness. For example, if the threshold is set to 0.7 and a readable is at 0.5, don't reduce its brightness. However, if the readable is at 0.9, reduce its brightness to 0.7. I'm no graphics programmer, so I'm not sure if something like that can be done. I thought I'd request this feature anyway with the hope that someone with the right knowledge may provide more insight or a solution.

I guess I can do that. Note: This code is not complete. I'm not sure if this patch will apply correctly these days, since it's based on an old revision. There are my debug print statements in this work-in-progress patch that should be removed if it was complete. There's a cvar used for tracking whether or not the main menu is open. I didn't like this and wanted to find an alternative. There's this block of code used to identify readables, etc. I wanted to find a more explicit way of identification. guiFileStr.find("invgrid") != std::string::npos || guiFileStr.find("objectives") != std::string::npos || guiFileStr.find("map") != std::string::npos || guiFileStr.find("readable") != std::string::npos; Again, I got better luck just editing the image files themselves. But maybe there's something good in the patch that can be salvaged for later. Attaching here for you @datiswous and others who are curious. wip-ui-brightness.diff

Oh my, this is embarassing for me. I was sure this was not possible, sorry. I guess sometimes your mind plays tricks on you. Maybe I just never tried because I implicitly assumed this was too unrealistic to work. Your point that it is too late to change this, is absolutely valid then.

Pretty amazing! That matches perfectly with how I implemented (v3). Max Height: 41 units (controlled by a cvar) While crouched: reduce max height by 5, which is 36 units. My reason was more about feel and animation than challenge, though. Don't allow mantling while falling. Mantle phases: only push and pushNonCrouched. I based the 41 units on a table found in The Painter's Wife. Also, by chance, it matches the 40 units mentioned by @Wellingtoncrab!

It'll probably just be easier to include it in the materials folder. Thank you for all this future-proofing work!

I just saw there's an update for this mission. Nice to see subtitles now work.

So the game links to light textures that were previously in core, but were removed? In that case they could be preserved ( by loading a previous version) and then included in the mission. I just played the mission under TDM 2.06 and indeed these 2 textures work fine. In fact I also made this screenshot, that I didn't upload: This seems a similar light to that is also used for the (not working) bottom lights in the temple. I'll take a look and see if I can preserve the original look. Isn't there a cvar to see the texture url in 3d game view?

The idea of using left/right/center justification comes from captioning of pre-recorded material, but as you indicate is problematic for live action where characters move around unpredictably. A horizontal location bar could be implemented as a solid-color rect that is repositioned, I dunno, every 200 ms. The cheap and easy implementation would be just to determine the location from the origin of the source (AI, fixed-speaker, etc.) relative to the viewport. It would be more accurate but much harder to take account of sound propagation pathways. If you wanted to be fancy, you could make the bar get less-wide but more-high (thick) as the source got nearer and visible. I suppose you could even have the bar's vertical location relative to the upper edge of the slot field indicate something about the source's relative vertical location. Probably too fancy, that.

I think @Daft Mugi’s goal in exploring all of these things is smoothing the transition from thief players into the mod of which many, including very prominent fm authors, are vocally critical and dismissive of often because of these types of mechanical differences we are all used to at this point. It’s an effort worth encouraging, even if some changes can’t make it into core over concerns like backwards compatibility which could be valid in cases like this. Either way I would offer the script up to mappers as a way to extend their missions if it’s possible to package it in such a way. The example of Volta was brought up as one which might potentially break as a result of this being implemented at the core level - that is also a mission where the player movement speed, the ai damage model and animation rates, weapon animation rates, blackjack behavior, etc have already been tuned extensively by the author to be more like thief. While not as extensive I did similar things in my mission. So I would think there may be authors interested in designing around more thief like mechanics. Probably a valid argument that it also bad for these things to be inconsistent across missions, but the ship has sailed at this point and this type of extendability is also what makes TDM great. Personally I find it a bit annoying when mappers don’t design a railing or ledge to allow a clean body drop over (come on - just make 40 units please), but there is no arguing that regardless of whether or not they intended this as a consequence, they did certainly design that way.

As a player that uses the blackjack a lot, i would like to be able to move bodies over minor obstacles without the intermediate dropping.

For a particular reason yes, it probably can be added, but "for some reason"?... What exactly is the typical problem? Syntax errors of .srt of .subs files not reported? The engine has debug command com_showSoundDecoders, which displays all currently playing sounds on screen. It should be easy to add a small tag here showing which sounds have subtitles and which not.

I'd say that's not the best analogy here, because dynamic lights or moveable objects and physics are mappers tools, so they can be added or removed at will. You can create a mission with static environment and lighting only, and if you can make it interesting, more power to you. And, it doesn't affect any other maps, retroactively. But, if you change aspects of the core mechanics e.g. player abilities, that is carried over to every map you play. In other games, you don't see major updates to player abilities; noone adds wall-running to a game that didn't use wall-running before – at least not without reworking geometry of all maps. I agree with the rest of your post though, just thought that there is a certain distinction here (things controlled by the mapper vs being at players' disposal on map start at all times).

I added a few sentences to the Light Switches section of "Relighting Lights" about this workaround.

-=CONTEST COBBLER PACK=- Need a SPOOKY street for your DRACULA or WOLFMAN? Mileage may vary but we got a variety of sepia stained sooty, grungy Pavers, Kerbs, Cobbles & More! I'll probably never finish my contest mission in time, but hopefully this helps you finish yours! DOWNLOAD

@stgatilov Regarding the Hare in the Snare FM, Yes, but what it's displaying is a video for debriefing. I've already got invoking a video covered. Sure, and maybe I'll research it. Still would like to find an example of someone else already having deployed a mid-game single-slide gui, to save me from having to experiment.