-
Posts
655 -
Joined
-
Days Won
15
Posts posted by Daft Mugi
-
-
2 minutes ago, ChronA said:
Skyrim uses a single button called Activate/Use. A short click of the button always activates the target object's primary function if one exists (i.e. shoulder body, put out candle, put item into inventory, etc.), and holding down Activate/Use for a long click always makes the PC manipulate the object (if it's not too heavy). This is our solution!
This was actually the inspiration for the current design. It was considered months ago, but matching Skyrim exactly wouldn't work well in TDM.
2 minutes ago, ChronA said:I bet Daft Mugi can knock this out in a jiffy.
I am an old, tired, broken man at this point. This feature has aged me 14 years already -- at least.
- 2
-
7 hours ago, wesp5 said:
Does this mean you will revert frob and long-frob for bodies like snatcher and myself have asked for?
There's no change regarding that. I would have already created a cvar to switch the behavior if it were simple. The code would almost double in size, become very difficult to read and understand, and it would be very hard to test all of the possibilities. I'm sorry this is the case. I spent time on it for you, but the code results were not good.
7 hours ago, wesp5 said:Or what do you mean by "a body like that"?
At the risk of causing some confusion to some folks, here is the technical reason.
Both the rat and the body in Heart of Lone Salvation have their body entities set as (shoulderable 0). The "fix", or tweak if you will, is to only allow "hold frob" on body entities set as (shoulderable 1). The result is that regular guards and bodies use "hold frob", the rat and other non-human creatures get grabbed on regular frob, and that body in Heart of Lone Salvation gets grabbed on regular frob.
-
On 9/27/2023 at 5:17 AM, thebigh said:
Also, this would ruin a mission like Heart of Lone Salvation, where you have to drag a body some distance because the ceiling is too low to shoulder it.
Thank you for pointing this out! This will be fixed in an update. A regular frob will initiate drag with a body like that -- just like TDM 2.11.
-
5 hours ago, snatcher said:
@Daft Mugi I just found a
deadsleeping rat. The mechanic goes in line with the design but, is this the optimal result for players or do we make an exception?Good find! There will be a fix for this.
- 1
-
13 minutes ago, wesp5 said:
The screenshot shown here adds FOUR!
The recent dev builds include the work from:
- 1
-
@stgatilov When will the test build for hold frob be updated?
Currently, players cannot fairly test the builds and choose one.
-
@stgatilov Also, perhaps we should change the build names and voting choices from our names to the solution names instead?
- test-build-holdfrob ("Hold Frob")
- test-build-doubleclick ("Double-Click")
As it is worded now, it sounds like it is a competition between the two of us rather than between the solutions. I cannot take full credit for "Hold Frob", because several people were involved in its creation. It was a group effort.
-
1 minute ago, stgatilov said:
But could you please attach source patch?
Same patch link as before: https://gist.github.com/daftmugi/41d0324107e8734f364bb3e50ff00794
Can it not replace the current test build name?
-
3 minutes ago, stgatilov said:
Not yet.
Ok. Please let me know when it's updated.
-
@stgatilov Also, could you please change the wording from "long-click" to "hold frob"?
-
Was test/daftmugi updated with the latest patch (the one posted yesterday)?
-
- Popular Post
- Popular Post
Updated patch along with new test builds.
- Windows: https://drive.google.com/file/d/13lQig7Yzfc_jovU2zZklxLV1QOKAjkXe/view?usp=sharing
- Linux/Ubuntu: https://drive.google.com/file/d/1j7DoWBKuBAFdVH2Y-2LcYsgdtJNBabmn/view?usp=sharing
@stgatilov Could you please update test-frob-daftmugi?
Changes in update:
- Bodies can be dragged instantly by holding frob and moving the mouse.
- Food can be eaten the same way as extinguishing a candle.
-
(Pending) Add menu setting "Hold Frob to Use", with options:
- Quick (200ms) - short delay before use
- Delayed (400ms) - long delay before use
- TDM original
Current design:
-
Frob
- Pick up body and shoulder it (carry it) / Drop body
- Pick up candle/lantern and carry it / Drop candle/lantern
- Pick up food and carry it / Drop food
- Pick up an item and carry it / Drop item
-
Hold frob (for special action)
- Drag body or body limbs
- Pinch out candle (also, pinch out candle while carrying it)
- Toggle lantern off/on (also, toggle lantern while carrying it)
- Eat food (also, eat food while carrying it)
- Hold frob and move mouse to instantly drag body.
Addressed concerns from initial design to current design:
- Changed the candle behavior to pick up on frob and extinguish on held frob.
- Added @AluminumHaste's suggestion to allow un-shouldering a body on frob.
- Added @nbohr1more's suggestion to allow extinguishing a candle while holding it.
- Added @Skaruts's suggestion to allow instant dragging of bodies on mouse move.
- Tried to address @snatcher's suggestion of making the extinguish candle delay 500ms instead of 200ms. There's a planned menu setting to set it to "Quick" (200ms) or "Delayed" (400ms). Also, I hope the "instant" body dragging will work well for you.
I think this is finally in a good place. It's evolved quite a lot since its initial design. I've tried to address as many concerns and suggestions as I could. Thank you everyone who gave feedback! It's much appreciated!
- 3
- 2
-
On 9/30/2023 at 11:33 AM, Skaruts said:
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?
I implemented this for bodies. It's working well. Thank you for the suggestion!
-
-
6 minutes ago, snatcher said:
I am impressed by your capabilities to detect these issues @Daft Mugi! How do you do it? Do you somehow sense where or what to look for?
I guess I'm highly sensitive to visual and auditory distortions.
I found these while testing code I'm writing for something entirely unrelated to graphics rendering. I test my code in several scenarios in several missions, so sometimes I find other issues along the way.
- 1
-
9 hours ago, stgatilov said:
Perhaps first see how many missions are broken.
Here's another instance found in "The Painter's Wife" at viewpos:
688.45 -205.07 -127.75 57.2 -124.4 0.0
The following video compares 2.11 and 2.12-r10451:
The new optimizations are a good thing as they allow mappers to build more, so I think they should be kept. Also, I've heard that some missions are currently being built with the assumption that the optimizations will be available.
Without knowing much about this, would two code paths be doable: one for old missions and one for new missions? Perhaps DarkRadiant can add a flag by default for the new optimizations when making a new mission?
If that doesn't seem like a good strategy, what other solutions can be tried?
-
2 hours ago, stgatilov said:
No idea how to fix it in engine (aside from disabling all the optimizations).
What are our options?
- Let old missions be broken.
- Find a workaround for old missions, such as disabling the optimizations.
- New missions set a flag for the new optimizations.
- Other?
-
The lantern in the Training Mission has a shadow casting issue. The lantern is at viewpos:
1550.89 -2142.79 354.25 26.8 36.3 0.0
Sometimes it casts a shadow, and other times it does not. Which is the correct behavior?
The video first shows it NOT casting a shadow and then shows it casting a shadow:
-
There's a lighting issue in "William Steele 1: In the North" at
-1153.92 3523.22 -955.75 29.8 -145.6 0.0
There's a candle on the other side of the wall. In 2.12 dev, that candle's light leaks through the wall at the base of the door as seen in the video, comparing 2.11 and 2.12-r10451.
-
On 10/6/2023 at 11:23 AM, snatcher said:
With the Modpack enabled if "Uncap FPS" is set to "Off" two mods slow down considerably: Loot Animations and Blinking Items. None of these scripts do anything that I can detect and tag as special or irregular and missions could perfectly make use of similar scripts for other purposes. What puzzles me is that mods are ok when "Uncap FPS" is set to "On".
Everything is fine in the current TDM 2.11a regardless of the Uncap FPS setting. My Max FPS is always set to 60.
@stgatilov Could this be similar to the book animation lag/stutter issue?
-
8 hours ago, stgatilov said:
Your implementation just falls into the following category: "you delay all single-click actions until you are sure it cannot turn into double-click/long-click".
I considered stating that this is false, but it's only potentially misleading. And, this description of long-press frob has indeed caused confusion.
7 hours ago, wesp5 said:If this is the case, I certainly didn't notice a 200 ms delay ;).
If I'm understanding wesp5 correctly, he now thinks quick-press frob always has a 200ms delay, which is not true.
7 hours ago, stgatilov said:And increasing the duration threshold to reduce this chance will also increase delay of single-click actions, which is hard to notice on 200 ms.
Ok, yeah, this is false.Actually, here, you were talking about the double-click feature and not long-press frob, I guess?Quick-press frob (single-click action) happens on frob key up. So, yes, there is a "delay", but that delay is not 200ms. Frob key down is instant. Frob key up has a delay, because it's key down and then key up. The quicker the player releases frob (key up), the sooner the quick-press frob action happens. If one considers pressing frob quickly, then there is practically no delay in quick-press frob.
Long-press frob acts like an override. When the player holds frob down long enough, the special action (extinguish candle / drag body) happens instead of the regular frob action (pick up), and to be clear, the regular frob action never happens if the special action happened.
- 1
-
6 hours ago, stgatilov said:
That's the same for all versions, for both double-click or long-click.
This is false.
The quick-press frob action never happens before or after the long-press frob action. The single-click action always happens before the double-click action.
You stated the following about double-click:
18 hours ago, stgatilov said:Also, the double-click action always continues the single-click action.
Long-press frob to extinguish a candle never moves it. Double-click frob to extinguish a candle always moves it slightly.
Therefore, long-press frob works well for ghost players whereas double-click frob does not.
-
47 minutes ago, wesp5 said:
Also if you managed to not move the candle with long-frob, stgatilov should be able to mimick that with double-frob too...
The fundamental design of double-click is to always perform the single-click action before the double-click action. The single-click action of a candle is to pick it up (and move it). That'll always happen before extinguishing a candle with a double-click. There's no way around that unless its fundamental design is changed.
-
2 minutes ago, datiswous said:
Ah ok I get it. Yes then it's a problem. I guess they have to keep using the old method.
With the old method, ghost players would definitely have better luck not moving a candle, but it's a pain.
One of the pros of long-press frob is that ghost players have a quick and guaranteed way to snuff a candle without moving it.
[2.12] Which frob change?
in The Dark Mod
Posted
Details at the link: