Skaruts

None of the solutions is perfect, but double-clicking seems less reliable to me.

Personally, for this kind of game, double-clicking and double-tapping are the kind of things that instantly get a sour taste in my mouth as soon as I hear it, because I already know from experience that it not reliable enough and it's more prone to human error. You said it yourself: It may also happen accidentally if your fingers twitch, or if your mouse misregisters an extra click, or when you think you didn't hit the target and immediately click again, but it so happens that you did hit the target the first time; or when you're hasting to perform the same task multiples times in quick succession (not very relevant here, but I couldn't count how many times I died in minecraft tapping keys to adjust my position and accidentally double-tapping forward and sprinting off a cliff). Also, given that we're talking about the right mouse button, I'm feeling even less inclined. I can double-right-click, but it doesn't feel very comfortable. It's really not something I'm used to, so it requires a degree of effort (and I suppose it will get my hand tired, as @Wellingtoncrabmentioned). Yup. I like ghosting. To be fair, I play with my own lax rules, but I still feel bothered if I have to tamper with the natural order of things, if I think it's unnecessary or that I shouldn't be forced to. It might seem petty, but it's part of what makes the challenge interesting. You never know, the candle owner might have noticed before bed that the candle was about an inch away from a spec of dust, and in the morning he might realize that that distance has changed. So, from a ghosting perspective, when you tamper with things without needing to, you've introduced a point of failure. If the game requires it, that's another story -- it turns into "I can't work around it, so I have to bend the rules because of it". But as far as I'm concerned it still bothers me and kind of ruins the challenge. For example, TDM has been leaving a really sour taste in my mouth when it comes to dropping keys, because lots of missions don't allow it (because unfortunately they're not droppable by default in DR, and for no good reason, afaik). After Snatcher's post about the delay interfering with manipulating bodies, I was growing tempted to agree with reversing it, but then I realized both ways have issues of the same kind. If you can click to shoulder, then you can't click to drag body -- you always have to hold button, which is not great if you're dragging a body a long distance. If you can click to drag a body, then you can't hold to drag a body. You always have to click to drag and then click to release, which is also not great when you're dragging limbs for a pose or something. (I suppose this might be even more annoying than the other.) Maybe I should posting this in that thread.

@Daft Mugijust in case you missed my edits to my post, I realized just a few minutes ago that sometimes I also tend to start walking right after the initial click. So maybe that could also be considered as a potential indicator of the intention to drag a body.

I was thinking about the concern @snatchermentioned about this making the ability to manipulate bodies around prohibitively tedious. I think there a bit of truth to that. I don't think it's that bad: I just manipulated a body around with not much hassle. But I can see how the delay might end up feeling like a stone in your shoe, for someone who does this often. But as I was testing this, trying to manipulate a guard around, I noticed that most often when I want to manipulate, I have a tendency to want to not just click and hold, but to also drag the mouse (or start walking). And that's where the delay interferes a bit. So I was thinking, maybe the implementation could also detect mouse dragging after the initial click, and immediately enter manipulation mode when it detects it? (Maybe it would be wise to still have a slight threshold for this? Not all mice and hands are exactly steady when clicking, so I suppose there might be a slight unintentional movement. I suppose this would have to be better thought about and tested.) And maybe the same could be said about detecting walking right after the initial click.

By the way, to address the subject of the thread, I did test the new lean and I quite like it. The amount of view angle is small enough that I didn't even notice it at first, so, as far as I'm concerned, it feels natural. Between the two I much prefer the new one.

Yea, I think perhaps there not being a grace period, or the AI (seemingly) not having a much smaller chance of detecting you, might be the actual issue there.

The way I see it, on top of that, you should also be harder to detect by AIs, since they're not seeing your entire body. Currently I don't think that is the case at all. I've been very easily detected by AIs when leaning around a well lit corner. It's kind of prohibitive to lean in TDM, in lit areas. Iirc, in Thief there's at least a grace period. Guards will take a second or two before they notice you.

Just to correct myself a bit, there's also a 3rd kind of entities: doors and stuff like that, which you can neither carry nor acquire, only interact.

Many moveable entities are not pickable, like keys or anything that goes in the inventory, but which is still a moveable entity. There's basically two types of entities: those that go in the inventory, and those you can carry around. Bodies are actually the odd ones out, that can be used in both ways. They don't go in the inventory in the same sense, but they do still get pretty much "acquired". Even if there's an inconsistency there, from a player's perspective, subtle inconsistencies aren't really noticeable if the behavior is intuitive or expected. I personally prefer simple-click to shoulder. It feels more natural to me, because shouldering is also what I want 99.9% of the time (as do most players, I bet). And so, like I said before, it's more a matter of the most used action being the most accessible by default. A simple click is more accessible (and easy to discover) than a hold-click.

Just took a few minutes to give this a go, and I 've had no issues at all. As far as I can tell it works as intended: frob to shoulder body frob to unshoulder body hold-frob to drag body hold-frob to pinch candle It seems to prioritize highlighted objects just fine (loot bags on bodies, doors while shouldering, etc). I'm quite happy about how it works, tbh, in terms of gameplay. It's a relief to have no unnecessary steps to it. I played my unpatched game just to check everything else behaves the same, and I immediately had a bit of a hiccup with the controls. I don't often blow candles or shoulder bodies, since I tend to ghost more often, so I don't exactly have to default controls in my muscle memory. I had to remind myself I was playing the unpatched version and that there's extra steps to it, because the patched controls are so more intuitive to me that I had already got used to them (in just 5 minutes of goofing around).

There's no conflict there, though. If you're aiming at the belt-purse, you loot the purse. If you're aiming at the body, you shoulder it. Just like you do in Thief. Shouldering is the most common action when you're deciding what to do with the body, not with the items it's carrying.

No idea. What I meant was just that leaning can expose you (a lot) depending on the lighting, so presumably you won't get "invisible shots" with the new lean. I haven't tried it yet, so I could be wrong, but that's probably the case. On a side note, personally I don't like that as it is that much. Getting so exposed makes leaning so useless in so many situations... I'm always scared of leaning because of that. I think it's one of those realism vs gameplay things where I'd rather favor gameplay. So much about hiding in shadows and sneaking is hyper unrealistic anyway. But favoring the player usually makes a more gratifying gameplay. Like when you're making a 2D game and you make the player hit box smaller than the sprite, to make it more forgiving and less frustrating.

Quite like this proposal. I like being able to drag bodies and pick up candles, but I never liked having to do those things in order to be allowed to do the other thing I want to do. It's an extra step that doesn't really seem justified. The way I see it, I ought to be able to do the thing I want, directly. Especially considering that most of the time I want to pinch a candle, not pick it up, and shoulder a body, not drag it. If anything, the most commonly wanted action should be the most easily accessible.

Haven't played too much of it yet, but I'm enjoying much of it. The atmosphere is awesome, and I love the the idea that the bridge is so big that people built buildings on it as if it's just another part of town. I'm also enjoying that I'm being able to ghost it without even knowing it beforehand. Not perfect ghosting, but pretty decent for a first playthrough. There are some technical issues though. The outdoor areas are barely playable on my potato. Even some indoor areas are heavy because they have transparent windows revealing the outdoor areas. I'm thinking the performance killer may be those fully detailed buildings in the distant background. Ideally they would be very low poly models, because the player is never gonna see them up close. As it is, they have literally millions of triangles to be rendered at once (r_showprimitives 1). That the outdoor area is completely open also doesn't really help the game render less stuff at once. This engine isn't particularly suited for this kind of thing. I think fog can also weigh on performance, but I'm not sure. I've had lower FPS on foggy missions before, but they were also highly detailed (Iris and Briarwood Manor), so it may not have been the fog. I also found two minor issues so far that are probably easy to fix:

We always have to keep in mind satisfying > realistic, when we're thinking gameplay. But still, our natural tendency is to not lean our heads much, though. And on top of that, our brain does a good job at keeping our perception of the world pretty straight, up to a certain point. And we tend to avoid reaching that point because once we start seeing the world sideways we also start having trouble making sense of it (and this is true in a videogame too, and why rotating the camera isn't a great idea). You certainly don't want that if you're a thief on a mission. And peeking isn't only about seeing what's around the corner, it can also be about trying to do something about it while trying to not fully expose yourself. We could have both functionalities, but that would require more keys (at least one modifier key for leaning). Or we can just have the latter, since it naturally serves both purposes. This depends on the lighting. In TDM you can get exposed while peeking, if there's a light hitting where your heads at.

I would love to know how they did it, because if I ever do my own little thief clone, that's a feature I must include at all costs. It was just plain awesome.

I never got to thank you for adding in the layer stuff I suggested. It's been a relief to be able to work with that since. I can't thank you enough. There's still a couple improvements that I think could be made, but I'll make a post about that, eventually.

I would love this. You had me 100% at "less view angle and more slide". I've always disliked this about TDM movement. It feels very unnatural to me (as well as the rotation in the view bobbing, which fortunately can now be turned off).

No idea, tbh... To be clear, though, the thickness is irrelevant. It's just that I moved the portal face 1 unit down. Maybe it's because it's off center now? The door's origin is above ground, so it couldn't be interfering with that.

Yea I totally missed it. Thanks anyway.

Wait, I figure it out. I made the visportal thinner, so as to not take half of the door's thickness, and that fixed it.

Actually... I realize why now. If you don't cover the func_static, the visportal gets dropped entirely. That's why it makes that difference, but not in a good way. You actually do need to cover the func_static... ___ To make matters more confusing, the "manhole" prefab doesn't have this issue, and I can't tell why. I added it to the test map. ladder_tests.map

Oh! For some reason I thought visportals had to encompass the func_statics in these cases. I don't get it, thought. Why does that little detail make the difference?

I'm having this issue with a trapdoor I made, where I can't hear the closing sound when I close it from the top side. I presume this could have something to do with the visportals, but I couldn't figure it out. My test map is in the attachment below, if anyone wants to take a look. Thanks in advance. ___ EDIT: I just noticed that not being able to hear the sound at all from the top side is actually because I'm using `loss_closed 60`. But still, even if I use the default value for that spawnarg, the sound still gets a bit muffled. So the actual issue is how to prevent this? ladder_tests.zip

When you press Escape to see the main menu, the sound effects from nearby electrical lights, like buzzing and crackling, will keep on playing. Doesn't seem to happen with gas lamps and torches. I don't know if this has been reported, but it has been around for a long time. (I'm on version 2.12)