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 small 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 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!

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.

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.

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 need A New Job

So path_follow_actor actually DOES work if you want it to follow the player. You just need to target the player entity dynamically in game. It doesn't work if you target the player_start entity. I can't remember if that's what people were doing (or even if that's what I was doing), but that won't work because the player_start entity and the player entity aren't the same thing. You can use a atdm:target_changetarget entity to do this, or a script: $path_follow_actor_1.addTarget($player1); Both can just be triggered by another path node, a atdm:target_callscriptfunction, whatever. Also you need to add the player target to the path_follow_actor node BEFORE the AI gets to it. If the target gets added after the AI reaches that node, it won't work. Video where the AI hits a node that triggers a atdm:target_changetarget entity: https://drive.proton.me/urls/A3DJW5EYFM#0WgYnCVOU6nv test map attached as well. EDIT: I have no idea why just manually setting 'target' 'player1' on the path_follow_actor node in DR doesn't work. I'll try to look into this. UPDATE: It appears the the player1 entity simply isn't there during initialization when the path_follow_actor's targets are evaluated. As a result, the 'actor' is null and the node does nothing. I didn't mention it before, but when I used the script method I just stuck in the map script's main function like so, and this works too: void main() { sys.waitFrame(); $path_follow_actor_1.addTarget($player1); } UPDATE 2: Wiki updated: https://wiki.thedarkmod.com/index.php?title=Path_Nodes#path_follow_actor path.map

For free ambience tracks it's as Freky said: you look around on the internet for tracks with the appropriate license to be included in your FM. Fortunately, you likely don't even need to bother doing this as a beginner as there's an entire "Music & SFX" section of the forums full of good ambient tracks for you to use if the stock tracks do not meet your fancy. You might also be interested in Orbweaver's "Dark Ambients", which come with a sndshd file already written for you.

I'm working in DarkRadiant on a new map, and I'm having something odd I've never experienced before. There's a fire in a stove model on the second floor of a building... walls, floor, ceiling, etc are all worldspawn brushes with appropriate textures, neither player nor AI have any trouble traversing the entire place, so I think it's assembled as it should be. However, if I douse the stove on the second floor with a water arrow, the water splash somehow drips through the floor brush and douses a torch in the same rough area down on the first floor. I tested it on various positions in the building, and it seems to happen everywhere, not just on that one light. Water arrows that impact on the second floor fall through the floor, and if a light is presence in the fall area it's extinguished. Is this expected behaviour? I would have through a solid brush would stop water from traveling any further once released.

https://www.information.dk/indland/leder/2024/04/ny-cheminova-sag-paa-tide-miljoeet-faar-lov-veje-tungere-erhvervet in danish so you might need google tranlate but oh boy... and it is not the first time they ended with a shitstorm either. In essence an old firm with a history of serious pollution turned out to have a state mandate to flush several 1000 times the amount of arsen (basically the same stuff as rat poison) into the ocean. the way they did it to get around eu directives was to expand the area from where it was lead out into the sea by a factor of 100km instead of the 100m from the letout that was the norm. creative thinking which would have been better used on problems which are not illegal as all hell i would say.

Thanks for those fixes! They didn't affect me and any FM's I've been working on, but I'm happy to see a solution was found and you could help those affected so quickly. I like the idea of being able to customize arrow behaviors from cvars! Most open-source FPS's (eg: Red Eclipse) offer the ability to set weapon behaviors with custom configs and create your own unique balance. While I agree it's good to not have a ton of settings, I think the weapon slots should be customizable this way... at least for now as we remain stuck with the old in-engine weapon system and can't turn the blackjack / sword / arrows into items like everything else.

Thanks! I am guessing that other fixes need to be done to "Shadows of Northdale: Act 1" ( launches to a black screen ) ?

Thanks, I found a way. So now I'm in the church and I'm perplexed by the

I'm now considering the .xcf files as being in effect the source texture for the game fonts, at least those that have been bitmap edited in GIMP. So that's an argument for putting them in the TDM assets repo. But, in any event, they do need to be backed up somewhere official.

i want to try darkradiant on linux. Not sure how heavy the software is. i don't want to abuse this poor thing Now i am in the process of researching new SSD replacement & GaN charger. i have found a primer on magnetic spinning disk & the underlying technology of solid state drive but i still found it hard to grok the magic behind this technologies cylinder, head and track number.. That's the last thing I heard when I was messing around with the solaris installer

So, I'm in the Undead Hogwarts, and I have everything I need, but there's this... ..in front of it that I can't seem to touch. If there was a written clue somewhere, I have completely missed it. Please assist.

For the FM? For beta 1 it's here: https://drive.proton.me/urls/H1QBB04GA0#oBZTb1CmVFQb I've already done around 100 fixes though, so you might want to wait for beta 2 which should be ready in a couple of days hopefully. All links are in the first post of the beta thread here: https://forums.thedarkmod.com/index.php?/topic/22439-the-lieutenant-3-foreign-affairs-beta-testing/

I just need the download link

This topic is going in different directions and it is difficult to tell if we all are in the same page. Facts: Stgatilov wants to change (improve, I guess) something and while implementing the change he realizes he will break some mission in the process. Mappers have been including (now obsolete) core files in their missions and the developer wants to know why these files were included in the first place, as in: the purpose. Changes in two mission are unavoidable, unless the authors go back and revisit the entire logic of their missions. Changes in eight missions are avoidable, in the sense that missions remain essentially the same with or without these changes. Regardless, if the improvements are to be implemented ten missions need to be reviewed and updated. Now my opinion: Considering how the topic is going the next time Stgatilov wants to improve something similar he might think it twice (we all lose because of ten missions). If these same improvements were to be implemented in the future chances are not ten but fifteen missions would have to be reviewed and updated which begs the question, does the inclusion of core files in missions put the present and future development of some areas at risk? No, as long as things remain under control: preserve what must be preserved, encourage and support innovations, identify and address trends. This requires an effort by all parties involved.

That's a very valid question. Personally, I'd say the key is to watch what the otherwise-disengaged fringes of the community are saying. If first time posters or long time lurkers start coming out of the woodwork about well made new missions, praising them for their geometry and story but saying that innovative parts of the gameplay felt frustrating or off, that's probably the first sign that the innovations are starting to get out of hand. For a more concrete example, re-read the comments on Hazard Pay. As much as I and many others love that mission, it's clearly a case where the author strayed further than many people were comfortable with. It also points to the likely endgame if authors do take their customization too far. After getting the negative feedback, kingsal made adjustments, and now the mission is much more friendly towards player preferences that don't match the author's original vision. You don't need to restrict the mapmakers' tools to stop them from straying too far from the traditional formula. When people start speaking up, the authors will rein themselves in on their own.