Jump to content
The Dark Mod Forums

Daft Mugi

Contributor
  • Posts

    655
  • Joined

  • Days Won

    15

Posts posted by Daft Mugi

  1. 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.

    • Haha 2
  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.

  3. 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.

  4. @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.

  5. 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. 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.

    • Like 1
  7. 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?

  8. 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:

     

  9. 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?

  10. 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.

    • Like 1
  11. 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.

  12. 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.

  13. 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.

×
×
  • Create New...