Jump to content
The Dark Mod Forums

Daft Mugi

Contributor
  • Posts

    655
  • Joined

  • Days Won

    15

Posts posted by Daft Mugi

  1. 1 minute ago, chakkman said:

    So, it doesn't play sounds when an objective has been completed?

    I was sure that it at least plays a sound when you meet the loot objective. But, again, totally confused about that now.

    • Thief 1
      • "New Objective" Notification: YES
      • "Objective Complete" Notification: NO
    • Thief 1 (TFix Full, not Lite)
      • "New Objective" Notification: YES
      • "Objective Complete" Notification: YES
    • Thief 1 FM
      • "New Objective" Notification: YES
      • "Objective Complete" Notification: NO
    • Thief 1 FM (enabled via scripting)
      • "New Objective" Notification: YES
      • "Objective Complete" Notification: YES
    • Thief 2
      • "New Objective" Notification: YES
      • "Objective Complete" Notification: YES
    • Thief 2 FM
      • "New Objective" Notification: YES
      • "Objective Complete" Notification: YES
    • Thanks 1
  2. 25 minutes ago, chakkman said:

    So, if I understand you, no Thief Gold FM does sound and text notifications of completed objectives?

    An FM, such as The Black Parade, can enable objective-complete notifications via scripting.

    It's objective-complete notification script is at:

    thief/FMs/TheBlackParade_1_0/sq_scripts/victory.nut

     

  3. 1 hour ago, chakkman said:

    Somehow, I didn't get the "Objective complete" sound overlay and text display when I completed an objective with both the Between These Dark Walls and Endless Rain missions. Is that normal, and maybe a side effect of these missions having been developed for older versions of New Dark? I definitely got those in The Black Parade, so, it can't be a general thing.

    Only Thief 2 has that feature, but it can be enabled via scripting on Thief 1 and Thief 1 FMs.

    Personally, if I want the notifications, I add it to a Thief 1 FM after checking that it doesn't have objective-complete notifications. Otherwise, you might get double notifications.

    dbmods/objective-notify.dml

    DML1
    
    #script "squirrel"
    
    // Enable objective-complete notifications
    ObjProp -2099 "Scripts"
    {
    	"Script 3" VictoryCheckAux
    }
    

    To enable them on Between These Dark Walls, add the above file as "thief/FMs/darkwalls/dbmods/objective_notify.dml". The mission needs to be restarted from the beginning for the DML to take effect.

    By default, TFix (Full, not Lite) installs it globally for Thief 1 and Thief 1 FMs in the "thief/OSM/gamesys.dml" file. I don't recommend that, because it can conflict with FMs.

    EDIT

    I forgot to include the requirement of the "sq_scripts/victory.nut" script, which comes with TFix (Full, not Lite).

    So, either the "victory.nut" file needs to be put the FM's "sq_scripts" directory, or it needs to be included in the global script path, such as "thief/OSM/sq_scripts/victory.nut".

  4. 3 hours ago, MirceaKitsune said:

    I accidentally found a bug that's easy to miss but likely also to fix: Select an arrow, in my case I was using the water arrow. Hold down the fire button to charge your shot, wait until it's fully charged but before getting tired and having to abort it. Press esc to enter the main menu without letting go of the left mouse button, then press esc again to resume. If you look and move around, the position of the hand and bow will no longer update until you let go to fire, you can see your first person hands floating in mid-air from a distance till you release the mouse button which will fire and update the hands again.

    Looks like this has been a bug since at least 2011.

    https://bugs.thedarkmod.com/view.php?id=2758

    • Like 1
  5. @stgatilov

    I'm curious why this solution was chosen:

    • "forceShadowBehindOpaque" "1" on an entity means it will always cast shadows from any light, even if it is fully behind wall/opaque brushes.
    • "forceAllShadowsBehindOpaque" "1" on worldspawn causes all entities to get forceShadowBehindOpaque flag automatically.

    This requires all of the missions to be playtested to discover issues and then updated. A seemingly impossible task.

    Why not the following solution?:

    • "enableShadowOptimizations" worldspawn

    This is something that DarkRadiant could add automatically to new missions. For existing missions that could benefit a lot from the optimizations, such as The Painter's Wife, Written in Stone, Iris, etc., they could be edited to include the optimization worldspawn.

    • Like 1
  6. 1 hour ago, STiFU said:

    As posted in the "Hazard Pay" thread, my idea for a save restriction mutator is that you pay for each save with some resource like a water arrow or a health potion. Something that hurts, to make players who seek the tension think twice about saving.

     

    1 hour ago, STiFU said:

    Another mutator idea was "Ghost", i.e., mission fails as soon as stealth score turns non-zero and blackjacking is disabled. I wonder why everybody jumped on the save restriction topic, instead of this mutator, which would be really useful for quite a few players, wouldn't it? 🙂

    If the "mission fails as soon as stealth score turns non-zero," that would not be good for ghost players. They might need to find out "how" they failed and experiment to avoid alerting guards. They might need to take those score points as a "bust". They might need to take those score points to complete an objective. Then, mission authors would need to encode exceptions into their missions, which would be a lot of work (if they decide to do it at all). However, part of what makes ghosting challenging and fun is when mission authors do not create their missions with ghosting in mind.

    Please see:

    Creating an official mode could alienate these dedicated ghost players, because it would clash with what is considered ghosting in the community. Including the Stealth Stat Tool mod in the official release would be more useful. Or, making the audible alert states of guards quick and easy to recognize could help as well. For these reasons, I don't agree with an official "Ghost" mode. If the dev team were to do it, we should consult with @Klatremus so we get it 100% correct or not pursue it at all.

    (This ghosting bit should probably be in its own thread.)

    • Like 1
  7. 1 hour ago, STiFU said:

    Entity type

    Short Press

    Long Press

    Junk

    Toggle-Grabber

    Hold-Grabber

    Food

    Toggle-Grabber

    Eat

    Loot

    Pick-up

    Hold-Grabber??

    Bodies

    Shoulder

    Hold-Grabber

    Lights

    Toggle-Grabber

    Exstinguish

    Tools

    Inventory

    Hold-Grabber

    Players might hold Junk while moving it and be surprised when it is suddenly dropped on frob release, because there is no way the player can know which mode they are in. With bodies, there is a noticeable difference right away between dragging and shouldering. With lights, the light does not move on hold and will extinguish/toggle, so there's also a clear difference for the player to notice right away.

    (Edit: It seems that a lot of the reasons I was '@'ed have been answered already, so I'll skip those.)

  8. 2 minutes ago, MirceaKitsune said:

    It doesn't always work so just reporting so it's known

    There shouldn't be any issues with it bound to a key. If you find any, please let me know.

    During the beta phase, I'll take a look at it again to see if I can improve that issue with "screenshot_viewpos" being run at the console.

    4 minutes ago, MirceaKitsune said:

    it is a good idea to have this command to share issues or map spoilers easily once it will work in every circumstance.

    Indeed. I've long wanted this command for those reasons. I hope you all enjoy it.

    Also, I added "tdm_show_viewpos" cvar to toggle on/off the viewpos on the player HUD.

    • Like 2
  9. 9 minutes ago, MirceaKitsune said:

    It doesn't seem like a clean solution to make the whole console appear anyway: I wonder if it's possible to make just the viewpos appear at the top of the render in a special display with this command.

    Yeah, it's not a perfect solution. I added "screenshot_viewpos" to TDM, but I'm no graphics programmer so my solution is subpar. If it is typed in the console, it doesn't work properly. It really must be bound to a key to work properly, and then it is acceptable and great. I use the following:

    bind "F12" "screenshot"
    bind "F11" "screenshot_viewpos"
    bind "F10" "screenshot_viewpos 1.3"

    The "1.3" above is the "r_ambientGamma" value.

  10. 16 minutes ago, MirceaKitsune said:

    Must say: I like the new hold-to-frob system. A bit confusing at first but far more intuitive and welcoming once you learn it.

    Great! Glad to hear that you're enjoying the change.

    12 minutes ago, MirceaKitsune said:

    However I believe I also found a bug that was surely introduced by it: You can now pick up and mantle the bodies of dead mice. Picking them up normally like a physical object makes sense, but now you mantle them with both hands and can't use anything else as if carrying a human AI's body... pretty sure the player could just put a dead mouse in their pocket it's not that large and heavy :P

    Yeah, I expected this to be found at some point. Some rats have the "shoulderable" spawnarg set to "1", so those rats are meant to be shouldered by design -- perhaps. There's even a rat in Seeking Lady Leicester that has a given name for when the player shoulders it. 😄

    If you find anything else that you think is a bug, please let us know.

  11. 2 hours ago, datiswous said:

    I foted, but actually it's too early maybe. I'm pro change, but would have the possibility to change to the old way if later on I decide I don't really like it enough. Is that not possible?

    Also I am in favor of a frob-hold for body manupilation, so I don't have to keep pressing the mouse button while moving the body around. So that's why I chose other.

    Thanks for voting!

    I tried to answer your questions here:

     

    • Thanks 2
  12. 2 hours ago, datiswous said:

    Why is there no frob-hold for dragging bodies?

    I'd like to better understand what you want.

    The design of dragging bodies is to hold frob (key down) to drag and release frob (key up) to let go. That way it's impossible to walk away while unintentionally dragging a body. Plus, it's quick to grab and move several body limbs in rapid succession. This is thought to provide a better experience, especially for new players.

    Towards the beginning of this thread, I created a "tdm_frobhold_drag_body_behavior" cvar.
    https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/&do=findComment&comment=487580

    "tdm_frobhold_drag_body_behavior", default:"1"                                                     
    Which drag body behavior?                                                                                
      1 --- on frob key up, drop body (limb).
      0 --- on second frob, drop body (limb), TDM v2.11 (and prior) behavior.
    

    That cvar was removed shortly afterwards, because it was said that it wasn't needed.

    With that cvar set to 0, a second frob would be required to let go of the body. Is that the behavior that you want? If so, I can add that cvar back.

    Also, I saw elsewhere that you want the ability to revert back to the old way. If you mean that all of the controls match TDM 2.11, that can be done with "tdm_frobhold_delay 0" and there will be a menu setting to disable it as well.

    • Thanks 1
  13. Regarding a slider for the "Hold Frob to Use" setting, my main concern is that players would have trouble knowing what it represents and what a good value would be for them. Sliders are pretty good for things that require fine tuning to a small degree, such as mouse sensitivity or head bob. But the hold-frob delay doesn't seem to require that level of precision.

    For a while, I played with a display that showed how long I pressed frob. I very rarely went over 350 while trying to be slow on purpose. I was usually at 80-180. Sometimes I'd make a mistake and hit 230-280.

    With hold-frob delay, three values -- 200, 300, 400 -- are likely enough to cover most players. A delay of 300 by default, 200 for those who want it more responsive, and 400 for those who want it slower.

    Given that, how about using presets with descriptive names in the tooltip and UI options?

    Quick, Normal, Slow: the delay before performing an
    alternate interaction when holding down the
    (frob/interact) key.
    
    Disabled: Original TDM behavior.
    

    With hidden delay values:

    • Quick - 200
    • Normal - 300
    • Slow - 400

    This will save the player from having to overthink it. If they are having trouble, they can choose the slower one. If they are frustrated by it being slow, they can choose the faster one.

    hold-frob-menu-setting-v8.thumb.jpg.f2275fe108419cb3006300f741a1d11a.jpg

     

    • Like 1
×
×
  • Create New...