snatcher

Find v1.2 attached to this post: Capitalization of names consisting of multiple words, which kind of looks better Other minor changes Remember you need the Core Essentials for the mod to work. EDIT - The latest version can be found in the opening post.

My apologies, @STiFU. I am working on a prototype (mod) that will soon see the light. It isn't about one parameter but about all elements working together, as you well know. You can't see what I see and it is unfair that you base your responses on my comments alone. We will soon be able to compare models and carry on with the discussion in fair conditions.

I am going to go with four options: Always Hover Delayed ("Fade In" and "Fade In Fast" will do the same) No

Regarding "Fade In" and "Fade In Fast" I think I know what these two visions were going for. "Fade In" wants to delay the help as much as possible (not to spoil the fun, I guess) by making use of an initial delay - where nothing happens - and a slow fade in. "Fade In Fast" takes a more direct approach (in disagreement with "Fade In", I guess) and goes for a shorter initial delay - where nothing happens - and a faster fade in. In my opinion the fade in speed (tdm_frobhelper_fadein_duration) must be discarded. Players should not be waiting to see if they can detect the helper but should wait because they know the helper is about to popup in its full glory.

Nobody? While working on the mod I noticed that while "Fade In Fast" parameters apply it does not stick in the menu from session to session and it reverts back to "Fade In". The preset is missing in game/game_local.cpp: int frobHelperPreset = 0; // Off if (cvarSystem->GetCVarBool("tdm_frobhelper_active")) { if (cvarSystem->GetCVarBool("tdm_frobhelper_alwaysVisible")) { frobHelperPreset = 1; // Always } else if (cvarSystem->GetCVarInteger("tdm_frobhelper_fadein_delay") == 0 && cvarSystem->GetCVarInteger("tdm_frobhelper_fadein_duration") == 0) { frobHelperPreset = 2; // Hover } else { frobHelperPreset = 3; // Fade In } }

The peek will be reviewed by the Devs at some point, and not because of the 32bit, but because it apparently does not work in Linux. This requisite is in your head and while legit, it is not what I was going for. I have yet to find one of these!

Operating System, please?

Well done! Thank you.

Probably (?)

I don't make videos but I just shared a copy with you to cure your curiosity. Feel free to share videos with the community if you have the skills and the patience.

Mod complete. Comprehensive testing in progress...

I have changed the subject to "Frob Helper discussion". Here are some situations where the frob highlight falls short: - Pick up items inside containers (frob fighting) - Pick items from KO/dead bodies (frob fighting) - Manipulate KO/dead bodies (am I aiming at the arm?) - Detect frobs (large and small) in some conditions, specially when it is bright: Frobable vent door or window Frobable painting Frobable book in a bookshelf ... Questions for everyone: Should an optional frob helper help in all the above situation or in some only? Do you detect any areas of improvement for the current Frob Helper?

Join us Taquito, we need modders in all areas! (no, no excuses )

Another issue is that in Always On mode the helper turns into a static crosshair and it no longer helps detect frobs. Let's mod the Frob Helper.

You could perhaps expose all presets for players to toy with them.

It goes without saying that I appreciate your comments and I respect your work, eh. We all want the best for TDM. The frob highlight doesn't work well in some situations: difficult to detect in small objects or in large objects in some conditions, frob fighting in bodies and containers... The frob outline initiative failed to provide an alternative and the Frob Helper was supposed to complement the frob highlight but it did it partially, and we ended up with blinking mods, container-disabling mods, auto search bodies... and a questionable Frob Helper. Perhaps madness is the better word. I know people don't like the idea of corsshairs in TDM but a Frob Helper with tdm_frobhelper_ignore_size = 0 would have settled many things for good from day one. I think we agree.

I would attribute that to excusable map-building little blunders. Nothing / nobody is perfect.

EDIT: This topic was initially named "Frob Helper madness". ----------------------------------------------------------------------------- While working on something I analyzed the Frob Helper. The Frob Helper was enabled by default in 2.11. The options were: Show Frob Helper: Yes [Default] No [Tip] Makes interacting with small objects easier by temporarily displaying a white dot. ------------------------------------------------------------------ In 2.12 the Frob Helper remains enabled by default but things changed: Show Frob Helper: Always Hover Fade In [Default] Fade In Fast No [Tip] Makes interacting with small objects easier: Always = Show crosshair dot at all times Hover = Instantly show dot on highlight Fade In = Gradually show dot on highlight Fade In Fast = Same as Fade In but faster ------------------------------------------------------------------ If I was new to TDM I would expect a "Frob Helper" to help me identify frobs: you can interact with this, here is the helper so that you know it and you know where the center of the screen is in case you need it. The Frob Helper however was designed to compensate for the shortcomings of other mechanics of the game, and as such, the Frob Helper is flawed by design: it only shows up if the size of the object is smaller than the arbitrary value of 40. I will say at this point that I am well aware of the tdm_frobhelper_ignore_size cvar but this isn't the point. This game isn't a shooter and "Always on" is not required unless we are talking motion sickness, in which case it belongs in a hidden cvar, for the few that may need it. The starting point of the Frob Helper should have been: On (the helper shows up whenever you can interact with something) Off From this point we can expand with more options, of course: Always on (not recommended based on the nature of the game) On for all items - Hover On for all items - Fade In On for all items - Fade In Fast [Default] On for small items - Hover On for small items - Fade In On for small items - Fade In Fast Always off

Our journeys began at the exact same place

A Readable? I invite you to read the documentation, experience mods first hand and draw your own conclusions. It's ok. You did the right thing. Fair point but the Blow removes the need for Water Arrows which mission authors might provide for their stories. Justifying our decisions is a tricky business. Ok. No idea but I can tell you item sorting, except for weapons, is messed up: you have 4 keys and pick up another one: the 5th key gets listed first in the inventory but last in the inventory menu. Why? Who knows.

If you want to keep the Whistle in "Tools" an alternative can be this: You just change the icon and the sounds and voilà, new exclusive mod

Regarding the Blow I would argue that if you need a backup plan perhaps the main plan isn't that good after all. Maybe the main plan simply needs a little more work and maintenance. Besides, players using the Unofficial Patch can extinguish almost everything with their hands except that element there, for which they need a tool? Odd.

The question is, what do you want the Unofficial Patch to be? Then do just that. Players shall judge. I am fairly sure, yes. What's wrong with some free virtual relighting ? Since you are interested in some skills what we can do to avoid duplicates is to adopt the same basic entities with the same basic properties. That way players using only the Patch will get your version but players using both the Patch and the Modpack will get a single instance (whichever mod that wins). Here is an example for the Whistle. tdm_playertools.def Go from: // Whistling sound to distract enemies, added by wesp from snatcher entityDef atdm:playertools_whistle { "inherit" "atdm:playertool" "editor_usage" "Don't use, gets automatically spawned at the start of the map" "scriptobject" "playertools_whistle" // changed by wesp "inv_category" "#str_02394" // Tools "inv_name" "Whistle" "inv_icon" "guis\assets\hud\inventory_icons\whistle_icon.dds" // changed by wesp "inv_map_start" "1" } To: // Whistling sound to distract enemies, added by wesp from snatcher entityDef mod:playerskills_distraction { "inherit" "atdm:playertool" "editor_usage" "Don't use, gets automatically spawned at the start of the map" "scriptobject" "playertools_whistle" // changed by wesp "inv_category" "Skills" "inv_name" "Whistle" "inv_icon" "guis\assets\hud\inventory_icons\whistle_icon.dds" // changed by wesp "inv_map_start" "1" } tdm_user_addons_wesp.script Go from: void user_addon_init_wesp() //If any of your addon scripts need to be initialised at map start, add their init function here. See the line that has been commented out with // for an example. { entity blow = sys.spawn("atdm:playertools_blow"); // added by wesp entity whistle = sys.spawn("atdm:playertools_whistle"); // added by wesp statistic_message_init(); // added by wesp thread frob_details(); // added by wesp tdm_frob_lock_init(); // added by wesp tdm_chest_sounds(); // added by wesp tdm_unlit_lamps(); // added by wesp sys.waitFrame(); // contingency in case no addons are specified } To: void user_addon_init_wesp() //If any of your addon scripts need to be initialised at map start, add their init function here. See the line that has been commented out with // for an example. { entity blow = sys.spawn("atdm:playertools_blow"); // added by wesp entity whistle = sys.spawn("mod:playerskills_distraction"); // added by wesp statistic_message_init(); // added by wesp thread frob_details(); // added by wesp tdm_frob_lock_init(); // added by wesp tdm_chest_sounds(); // added by wesp tdm_unlit_lamps(); // added by wesp sys.waitFrame(); // contingency in case no addons are specified } See if that does the trick, and if you like it.

WOW, what a pleasant surprise! I expected this day would come but not this soon. There they are :) Here is an initial, quick assessment. Currently the Modpack loads last, therefore it takes preference. We can test the other way around at a later stage. tdm_frobactions.script No conflict detected. The Modpack's version takes preference and it apparently works as intended. The Patch changes some chest sounds in a separate script at mission start but then the Modpack overrides these sounds on the fly. Blinking items Threads from both the Modpack and the Patch run in parallel throughout the mission. I don't notice anything unusual except that sometimes the blink is out of sync. The reason is that something fishy is going on between milliseconds 16 and 17 in Uncapped FPS mode. In v4 of the Modpack I set the wait time to 15 milliseconds to avoid the issue and you should do the same in the Patch: tdm_froblock_frobability.script > mod_frob_highlight_blinking() > sys.wait(0.015) Containers Threads from both the Modpack and the Patch run in parallel at mission start. I honestly don't know what the game is doing in this case but the outcome apparently is not negative. No issues detected. Body names Threads from both the Modpack and the Patch run in parallel throughout the mission. I don't notice anything unusual but most probably names are being displayed twice. Shock / Electric mine No conflicts that I can detect at a glance. Whistle No conflicts that I can detect. Players however end up with two different versions of the same feature in different categories. Blow No apparent conflicts. Players however end up with two different versions of a same feature in different categories. This one is interesting because the Patch introduces "extinguish on frob" on small candle sources and players are spoiled by options now.

This shows willingness. I will check where we stand today. The goal: players.