-
Posts
655 -
Joined
-
Days Won
15
Posts posted by Daft Mugi
-
-
- Popular Post
- Popular Post
Some folks have been asking about the new tdm_show_viewpos cvar and screenshot_viewpos command, so I thought I'd make an thread about it as a reference.
The purpose of the cvar is to show the viewpos on the player HUD, and the purpose of the command is to add the viewpos to screenshots in order to help with troubleshooting and beta testing.
Bug tracker: https://bugs.thedarkmod.com/view.php?id=6331
tdm_show_viewpos
tdm_show_viewpos is a cvar to show/hide the viewpos on the player HUD, which can be set to the following:
0 --- hide 1 --- gray font color 2 --- cyan font color
screenshot_viewpos
screenshot_viewpos is a command that takes a screenshot with the viewpos added to it.
screenshot_viewpos screenshot_viewpos <gamma>
screenshot_viewpos can be typed at the console or bound to a key. The "gamma" is an optional argument, which as of 2.12 Beta is the r_ambientGamma value.
Some mission authors prefer to have screenshots (from players) that are brighter, so they can see what is in the screenshot more easily. Setting the "gamma" argument is a convenient way to temporarily adjust the gamma just for the duration of the screenshot.
For example, I have the following bound:
bind "F12" "screenshot" bind "F11" "screenshot_viewpos" bind "F10" "screenshot_viewpos 1.3"
- 3
- 3
- 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
- 1
-
Thief 1
-
24 minutes ago, chakkman said:
I'm completely confused now. I was sure that original Thief Gold had those objective complete notifications (at least the sound).
Thief 1 does have the new-objective notification, though.
-
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
-
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".
-
- Popular Post
- Popular Post
6 hours ago, MirceaKitsune said:Interesting Was sure it must have been something that either broke recently or was never discovered until now. I actually discovered it as I changed some of my default keys, then forgot what the key was to cancel my shot so I pressed escape hoping that would put the arrow down, then I returned from the main menu and noticed this occurs.
Now fixed in code rev 10543.
- 1
- 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.
- 1
-
I fixed "screenshot_viewpos" so that it hides the console correctly before taking a screenshot (code rev 10532). The fix will be in the next dev build.
@MirceaKitsune Thanks for reporting it!
-
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.
- 1
-
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:
-
Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523
- Writing code for these rules would be a huge undertaking.
- Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487
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.)
- 1
-
Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523
-
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.)
-
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.
- 2
-
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.
-
- 1
-
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
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.
-
4 minutes ago, MirceaKitsune said:
Oh my, it's already there?
Yeah, it was originally part of the Doom 3 engine.
-
@MirceaKitsune Have you tried the following?
recordDemo <name> stopRecording playDemo <name>
It does work to a degree, but I don't know how extensive it is or if there are bugs. Plus, FPS drops considerably -- at least on my machine.
- 1
-
3 hours ago, AluminumHaste said:
The picture shows normal textures
Are the nails in the boards supposed to look solid, bright orange without any texture?
-
-
3 hours ago, datiswous said:
Yeah could you do that? I don't think it hurts to have that cvar.
I've updated the non-TDM installer builds with that added cvar.
Set "tdm_frobhold_drag_body_behavior 0". Please let me know if that works well for you.
The updated builds can be found here:
- 1
-
Just now, datiswous said:
Yeah could you do that? I don't think it hurts to have that cvar.
Sure, I'll add the "tdm_frobhold_drag_body_behavior" cvar in the next update. The code required for that is simple.
- 1
-
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:
- 2
-
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.
- 1
-
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.
- 1
Beta testing 2.12
in The Dark Mod
Posted