Search the Community

I also found instances where it would show the dot, but there was nothing to frob (for example showing while pointing at an empty wall), making it entirely unreliable and thus pointless.

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 all items - Fade In Fast Always off

finally beat forbidden west but jeez that stearing scheme is atrocious... so you happily stroll along at a mountain side then want to steer past a big boulder but instead of strafing it does a dodge move throwing you a gazillion kilometers from the mountain side fallling to your death yeah well... the shield shute sometimes fails to inflate when jumping down so pretty much the same as above ouch... then when you need to dodge an incomming attack the damn bots cheat and hit you anyway groan... nice story though, but they need to do something about the steering on PC we do not use force sensitive mouse and keyboard ffs .

I hope that is not the new TDM version. https://forums.thedarkmod.com/index.php?/topic/20784-render-bug-large-black-box-occluding-screen/

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.

I changed blinking frequency to 0.015 now but I can't see a difference. I have another question though: is it possible to have the new tools or skills listed on the inventory page right after Unarmed? I have no idea how sorting is determined there and while changing their category to "weapons" works, it also creates duplicate entries on the inventory page...

I have numbered your suggestions because I find it hard to multiquote here. As for calling blow and whistle tools and not skills, this was just done to not confuse the player with another inventory class. Also what would the Numbers scroll be? 1) Is there an advantage of your method vs mine? If the result is the same, nothing needs to be changed. 2) I don't know what you mean with blinking being out of sync. Should all loot blink in the same rhythm? 3) It removes the need for slow matches and flints which mission authors might provide for their stories. 4) This is what it looked when I copied it from you, but I had to rename it to avoid duplicate definitions!

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.

The project to round up viable orphaned translations is mostly complete now. https://bugs.thedarkmod.com/view.php?id=4726 Since Darkfate has their own translations it took awhile to merge the older translations with the darkfate formatting since they generated new string numbers from scratch. A few missions are so radically changed that the old translations are practically worthless now ( and some Darkfate translations are also incompatible with the latest mission versions ) but most of the work was salvageable. I added a "Translation Pack" column to the Missions wiki: https://wiki.thedarkmod.com/index.php?title=Fan_Missions_for_The_Dark_Mod all entries marked with "Yes" are working translations that use Darkfate's translation design ( includes xdata, GUI and Map files if the author didn't perform localization changes in their own mission pack ). Sadly, these changes do not show in the mission downloader list. You will need to delete mission_l10n.pk4 files from the darkmod/fms/mission_name folders to acquire the new translation packs that "actually work". Not all mission packs contain all languages. Mostly you can count on Russian being in there, but a good percentage have German and Italian strings too. French, Polish, and a few other languages are represented but not very broadly. Hopefully now that the packs work other contributors will add more language strings. Mission administration details: Going forward, it would be courteous if the mission admins ( like myself ) would diff the map files when new mission updates are supplied and replace all the objectives, inv_name, pop-up messages, and shouldered names in a copy of the new map file with the previous string codes then copy that file to the map folder in the translation pack folder. Ideally, authors will be encouraged to run their missions through the converter so only new strings need be added to the packs but not everyone likes that workflow and how cumbersome it makes future edits to the mission.

It would be nice to be able to create your own EFX presets, this will solve that issue. https://github.com/kcat/openal-soft/blob/master/include/AL/efx-presets.h lists all the presets. Here they can be seen in the tdm source file. I think these could be read from an external file instead of inside game code? If TDM reads the presets from an external file, anyone could easilly make their own presets by overriding that file and these could be used inside a spawnarg when that gets implemented.

Do you really want to try? I'd suggest looking at idSoundWorldLocal::MixLoopInternal. That seems to be the only place where effect is found by area index, then by area name, then default. If you manage to add a member like idSoundWorldLocal::listenerEfxPreset and ensure it is set properly, then you most likely can pass the preset name here (perhaps via something like idEFXFile::FindPreset). In my opinion, the location spawnarg should get top priority. If missing or empty, then the ordinary approach with .efx file works.

I wasn't aware that you changed the whistle so I am probably using an old version which I like pretty much. I just renamed the internals in the vain hope that our mods can be mixed that way, but there are too many other overlapping definitions. P.S.: I looked closer into it and it seems there was only one other overlap which I fixed by renaming, so now the patch and your modpack can be merged with each other ! As you use x_ as prefix your features will override mine though ...

I would say sound propagation was built mainly thinking of player footsteps and while it works very well for this purpose it is unsuitable for one-off special events.

The script might not be too far off what I was thinking anyways, because one of the reasons I wanted to be able to do it in DR is because you could then have a test script like 'Check for missing EFX on info_location entities'. So maybe we can just have a script called 'generate EFX file' or something like @datiswous is suggesting. The problem is that if feels a bit like a halfway house instead of a proper implementation. Also I think we all could probably agree the EFX file will never go away in case people want to do more than just presets, so we would have to support both the info_location method and the file method. Just thinking out loud here, and good discussion

This should definitely be possible. The python scripting API has functions to loop through entities and read their spawnargs, and then you could use standard python file functions to write the EFX file. It would be cool to have a proper EFX editor in DR, but writing a script would be a lot less work. @Frost_Salamander if you decide to write a script like this I'd be happy to help you out if you get stuck. You can check out count_loot.py for a minimal example of looping through entities.

Maybe it's possible to make a script that extracts all the info_locations from the map file and creates an efx file from that in the correct format (run again to update). Then you can simply fill it in. Possibly you could also edit in DR the efx-data as a fake spawnarg for that info_location entity and make the script write that to the efx file. This might also be possible via a script/plugin inside DR.

If you wanna put together a prototype implementation, we could provide assistance. I think it mostly just requires adding EFX parser parts to the entity def parser. The big wrinkle is what to do if a mission has both EFX and Entity Def args?

A new "trick" to cover up a security camera using moss arrow and broadhead arrow : This is a huge leap forward from previous old tricks : - using rope arrow and pickable book bug: - the other random bug: But carrying all of these things throughout the mission will weigh down your time....

I made a small update including the fixed fonts by Geep and also brought Snatcher's Whistle back, because a) I noticed that hitting something with blackjack or sword has not the same effect and b) the name now doesn't look bad anymore because of the font fix .

@stgatilov @nbohr1more I'm wondering if it would be possible to get this implemented for 2.13? I'm really not loving the EFX files - it's way too easy to miss/forget locations and just a general PITA. I am even considering offering to help implement - any reluctance on my part is purely down to lack of confidence. But with some hand-holding I could possibly accomplish something that isn't a total disaster. Maybe an alternative is to have a feature that allows DR to manage the EFX preset in the EFX file? Basically what I'd like is to be able to manage everything related to a location entity in the one place, preferably in DR. Not sure if that's ever been considered? @greebo?

Thanks for the replies, particularly the reference to the embarrassingly-obvious "Music & SFX" subforum just below this one. I just like the music: I don't have any illusions about creating a fan mission. I messed with Dromed way back in the day, and I remember what a black hole of time and sanity it was.