Wellingtoncrab

@snatcher can’t say I prefer yellow or the grey - but I will say all these mockups I have seen from you are a definite improvement over the placeholder art - very nice work! To everyone involved this is a very cool feature.

Exactly the point that is made in my post:

@Frost_SalamanderIf it is helpful, I have express permission from Marcel of cgtextures/textures.com that packaging his assets in a .pk4 is acceptable and at the time he was fine with packaging them in TDM projects: Also you mentioned not being able to use your images for just textures - do I take it this means you can use them as textures and within materials in the context of a mod - you just can’t package and release them as only textures correct? Lastly idtech 4 is an engine old enough it’s package files (.pk4s) can be opened with any archive software (would be difficult to mod otherwise). I will include your license information in my documentation if I ever get to release, but is there any special consideration I should give to packaging assets derived from your images in older game engines which lack modern security? The main thing I hope is to just ensure you include his license and that you do not distribute the textures themselves outside of the context of the fm. There is a bit of a slippery slope in that terms on the site have changed a lot over the years. The current licensing model finally seems to state that the photo ref textures are ok to use in "Scenes" for example, but for many years it stated it was only acceptable to use them specially in models. There are many many assets in core which are from this site, which were licensed under these much older terms: https://web.archive.org/web/20100818122748/http://cgtextures.com/content.php?action=license Ultimately if something is licensed, the terms can change. So buyer beware.

@Näkkialready looking great!

Folks please let’s not necro a lengthy discussion on the merit of save restrictions in general in Kingsal’s release thread, when it’s well represented elsewhere.

If TDM were an RPG with an inventory system like CP2077 or a bethesda game yeah I imagine the primary function of interacting with a body might be related to inventory management. Again the developers of that game had a context sensitive input, they prioritized what it should do based off of their game and what the player is mostly likely to need. This is not making a stronger case we should not do the same thing for our game. You have never bothered to explain why in this game a player would need to prioritize dragging and manipulating a body over shouldering it beyond it being being “inconsistent”.

You are correct in that is a partially unfair example in that dishonored 1/2 use a lot of “modern” gui conventions like text elements, progress bars, etc for a lot of it’s interactions and telegraphs pretty clearly to the player what context sensitive action will result on frob. There is a delay on some interactions, including picking up bodies, but this is to prevent unintended inputs, not to enable something like multiple control layers. The primary function of using frob on the body is to “pick it up” ie shoulder it. No idea why this is material to an an argument that this should be the result of frobbing a body? No one is even suggesting removing this kind of manipulation from the game. The examples I can think of this kind of drag mechanic: the modern deus ex and hitman games, both of which are interactions exclusive to bodies and don’t feature shouldering as a mechanics at all, and the fine grain physics manipulation modes you see in Bethesda games starting with Oblivion, which requires long pressing the interact key on a physics object to allow you to move it around. Incorrect: TDM does not have the ability to move “anything” as physics object and all of those games have physics systems which include objects the player can move around. Also not material as to why a fine grain limb manipulation and dragging mode should be the primary function of the frob key. No one is advocating removing the feature from the game, and you can get the exact behavior you seem to want by disabling the hold commands in the main menu.

@wesp5 Make sure you skip thief, thief2, deus ex, dishonored, dishonored 2, etc. Not sure what military grade hallucinogens they were smoking but they all have physics object you can pick up and bodies you can shoulder - tied to the same input! It was quite the scandal - all anyone could talk about at the time is “why don’t the bodies just float in front of my camera when I pick them up just like this potted plant does?” What they didn’t have that the current build of TDM does was the ability for players like you turn this troublesome development off in the main menu. Thankfully I am absolutely certain you’ve been spared the pain of playing of these games, as it is seemingly the only explanation I can come up with for you to still be posting the same comments over and over and over again in this thread. Seriously though these interactions in the game were never really the same thing, you do not drag most physics objects in the game slowly along the ground, you pick them up kind of like how shouldering the body is a non goofy way to display you have picked it up, so no idea how it is inconsistent and even why that matter so much.

Yeah, I do see some benefit to being able to pass items to the grabber with less inputs so I think it’s worth trying and getting a feel for. That mix of some inventory items being moveables and others being static without collision meshes will kind of inherently make it hit or miss depending on the item, but it seems like a potentially nice addition.

Unless I am missing something the only really difference in this table vs the current implementation would be inverting the shoulder/grabber behavior for bodies (I guess it also removes the fall back on long press to do the default action on things like junk - not sure if it is actually preferable for some reason to just do nothing in these cases). Switching the body interaction to shoulder on frob is one of the foundational elements of this change and judging by the polling information is supported by a majority of players. The reasons for this change are well articulated in this thread, but the short version is that this has been confusing new players for years who actually think there is no shouldering mechanic in the game at all. The first thing the game shows them is fine manipulation of bodies via the dragging mechanic, and they must learn to use an unfamiliar key combination to actually carry one. This is only described in a easy to miss readable in the training mission. I am myself only learned of this mechanic after playing several missions and by accident. You can read accounts of players literally giving on the game elsewhere in this thread. I imagine they would potentially support this change as well. Which is the more common action a player must undertake in the game - shouldering a body or manipulating limbs and slowly dragging it around? So if that is the only element of the implementation which is “inconsistent” (again I don’t think this is actually important - shouldering is the primary interaction with bodies in almost every other similar game and this confuses no one) then I think it’s a pretty small tradeoff for a pretty big pay off.

It is quite litigated in the thread already whether it is particularly important or common in games for a context sensitive input be "consistent" or whether this inherently means something is intuitive - so I won't repeat my thoughts on it. I will say It seemed like it was quite difficult to get this change as it is into the game, so while I think anything can be improved I am not sure anyone wants to go through another 10 pages, polls, etc. So I hope I don’t sound short or dismissive, it’s really not my intention, it’s just been a very long thread. I will say if an object is frob highlighted, ie subject to an interaction prompt, if frobbing it then does not do anything or provide any feedback the game immediately feels very strange and broken. I do not think it is good a idea to have objects which can only be interacted with via long press. The current design is around primary interactions being on short press and the secondary more situational actions being on hold, while also retaining compatibility with all legacy interactions. There is some disagreement as far as what is a "primary" interaction, but I find it pretty intuitive in practice as it is today. There are some exceptions that did not work out in testing. I will the example of candles/lanterns - having extinguish as the primary interaction makes a lot of sense, but in practice didn't work very well. The game is full of extinguished candles, empty candle holders, etc that are now simple physics objects that require a long press to pickup and have no primary interaction - see issue above. You also have to handle lanterns differently, which can be toggled off/on. You could code in the TDS method which is extinguish a lit candle on frob, then it becomes a physics object (“junk” in the parlance of your table) so the primary interaction should then be grabber. There seemed in general to be a lot of concern about keeping the code clean. Being able to grab moveable inventory objects on hold without having to do the current dance of bringing them into inventory first and then “dropping” them - like keys and tools - could be a nice addition. Many loot objects are not moveables so these might be a bit of issue?

@STiFU thanks for playing! If you really want to see some tricks using some special eyewear - I recommend you check out Written in Stone! @MirceaKitsune Also thanks for playing! The behavior you a describing regarding AI not reacting to player sounds in restricted city areas should only occur on the “nostalgia” difficulty. As far the remaining SotV:

Yes by default nearly all of the ragdoll entities you can find in Create Entity > Ragdolls > Bodies all have shoulderable set to 1 in their definitions - including rats and spiders. This probably was not intentional - but this means in a lot of missions if an author has placed a dead rat or spider these have always been shoulderable - its just rare anyone bothered to try.

Let us know how it goes!

What will appear in the mission downloader as "version 3" of Seeking Lady Leicester is available for download at the link below: https://drive.google.com/file/d/15928fkRigw20310G5EtZ7h4Vngf9-sk-/view?usp=drive_link This includes a collection of minor bug fixes: the hard to reach/frob loot under the manor stairs is easier obtain the difficult to reach health potion in the canal is easier obtain fixed nonsolid building next to the bookshop that players fella through/into. Lots of small fixes and polish

You’re count of the purses seems to be correct - so I am actually not sure what is causing the aberration in the pick pocket statistics beyond something like the bug bigh is describing. There isn’t anything meaningfully different in how the attachments are setup that I can see. Will talk it over with the other devs and see if they have an ideas.

Hey @Klatremus - Thanks for the bug report! Looks like this was added after release and did not get properly tested. We doing some bug fixes now and a patch should be forthcoming shortly.

Actually it’d be great for you to clarify “what kind of players” you are talking about so dismissively?

What and incredibly rude and unhelpful response to an attempt to make sure you and other players have some access to tuning this feature directly from the main menu to accommodate their needs. Not a few pages back in this thread: The fact that these types of comments which do nothing but promote stagnation and inaccessibility to the game get liked by arguably the lead developer of this game is disappointing to me.

The issue with the bounds of visportals "glowing" has been quite apparent in my WIP: If it is helpful in resolving the issue they are only visible when soft shadows are enabled. Using the "Maps" lighting mode also seems to reduce how visible they are. The performance improvements are quite significant so it would obviously be good to keep as many of the optimizations as possible.

It does not - the single click action is performed on key release. If key release occurs before the delay time is over it is instantly performed. There is no perceivable delay when doing a normal frob action, though I guess this would be slightly “slower” than doing it on key down. You can set the frob delay variable to 5000ms and still get an immediate feeling response when just “clicking” the mouse button. I assume this is how long press also works with the darkmod controller config, as there is much a longer delay there to perform an long press action and there is no perceivable delay when simply pressing a button. Just like click to drop body, door switch handling, and other things you have brought up this is just not a description of how that patch works. Not sure if something went haywire with applying the patch?

Unfortunately in playing an actual mission I find I like this even less. Just replayed a bridge too far and the double click to drop a body was quite troublesome. Maybe it’s a “me” problem but when multiple inputs are a required and I am in any kind of hurry or under pressure (like I need to drop a body because a guard is coming) I have a tendency to over input. The result is I drop the the body and immediately grab it again. This just did not feel very responsive to me in the points of the game where it was needed. I mean this now works fine in the other patch. Some of the most popular content creators for the games are ghosters and their tdm videos can get thousands of views. I went from having no ghost testers in the release version of Iris - to some being integral in subsequent patches - to in SLL quite a few testers using this play style. I don’t get it but there is certainly no denying it. They appreciate details like this.

Played through the training mission with it, it is ok, not great. Does nothing as far as making the controls more intuitive - things like requiring a double click to drop a body doesn’t make much sense to me at all. “Consistent” does not mean it feels intuitive or natural. It really does not feel that natural imo to be double clicking the right mouse button in general - can’t think of many examples of this. Maybe I need to work on my core middle finger strength as it actually felt a bit fatigued putting this through the paces (probably not representative of typical use in game). Registration seemed mostly good - sometimes I would double click to drop a body or extinguish a candle but still be holding it - I am guessing that is the result of just accidentally registering a third input. Since candles are still picked up on double click, this is maybe a little better but not ideal solution for ghosters who don’t like to pick up or move objects at all - doesn’t describe me but I know from the missions I have worked on there are at lots players who have adopted this play style. All in all “long press” clicked (get it) for me personally as far as how it feels to use. I guess in the end they both are ways to make certain clunky and unintuitive actions in the game faster for existing players.

Checked this out - good chance to replay the mission which I hadn't in some time (good one!). There is an optional objective involving moving a body (the optional aspect might be difficulty related?). The body has the shoulderable spawnarg set to 0 because yes while the area is large enough to still shoulder body - it's small enough if it were shoulderable it can softlock you because there is not room to drop the body. Dragging the body with the patched version seemed totally doable, but yeah in the patched version players would not be able to complete this optional objective unless the have learned to drag the body. This is definitely a nice addition! If the simplified interactions don't make it to core my only suggestion would be to make the gui text a little more specific to press "Use Inv Item" instead of just "Use" to shoulder the body.

That honestly sounds a description of the current patch to me - you never responded to my question as to why you view it as “radical”, why you feel like there is justification for you to redefine the scope of the patch at this point to not address the concerns of these players, and way there is cause to not consider expanding the test base by including the patch in an actual dev build? You mention the code has been this way for a long time - it takes a very shallow glance to see how long players have also been posting on this forum asking how to shoulder a body and getting some frigid responses about reading the wiki or playing the training mission. It has been consistent since at least 2009. The idea that a game that is still in active development can’t strive to improve these things just does not resonate with me at all.