Dragofer

The mission has been given a small maintenance update to ensure it'll remain compatible with a tweak to custom assets handling - there should be no changes visible ingame. Some clutter like old snapshots of the map file has also been removed so that it's become a smaller download than before. Update provided by Obsttorte.

The animal_patrol spawnarg governs that.

The Black Mage and Seeking Lady Leicester FMs are not part of the William Steele series and were expressly offered for adoption by grayman, as opposed to the remaining chapters of the William Steele Series.

That's anyone's guess, I think. Maybe grayman knew the cause, but didn't know the fix or get around to it. That said, I don't think anyone's reported knockout fatalities in my FMs - maybe worth comparing your method? I haven't heard of that warning. Snapshot sounds like it would have to do with cubemaps... By the way, I learned recently that if you use "testmap" it's actually a combination of "dmap" and "devmap". Devmap is the same as map except that you will get console warnings that are usually hidden. Maybe that's what you're using? The arcturus_fire material was one of those fixed as part of a wider effort to systematically find and eliminate console warnings generated from core assets. In any case, asset bugs are best reported on bugs.thedarkmod.com to avoid them getting buried in forum threads.

Alright, the problem in your case seems to be that the addon files have to be on the level of the base installation (in order to apply to all FMs), so they can't overwrite files that already exist in FM .pk4's. Yes, that's a limitation. What you can probably do, however, if you're modifying scriptobjects (tdm_movers.script contains only scriptobjects), is to derive a new scriptobject from the existing scriptobject and define its functions again. See here for more. You'll also have to update the base classes of affected entities to make use of your modified scriptobject.

It works the same as any other file: if a file has the same name and folder location, then: FM files overwrite base installation files Files outside .pk4's overwrite files that are inside .pk4's If you want to override the base version of tdm_mover.script, include your own copy of tdm_mover.script in your FM or addon package.

TDM/fms/anymission/script/tdm_mover.script replaces the 2 copies of tdm_mover.script in the .pk4 and the base installation. tdm_custom_scripts.script and tdm_user_addon.script can be deleted because tdm_mover.script is already #included by tdm_main.script.

It's not a question of overwriting. When the map loads, the #include lines are replaced with the contents of the specified .script files so that you get one giant merged script file in tdm_main.script. tdm_main.script includes tdm_custom_scripts.script, then tdm_user_addons.script, so the contained scripts will be added in that order. If you #include the same .script file multiple times from different files, like in your example, you risk getting multiple copies of the same script which causes map loading to fail - see one-definition rule. Inclusion guards (#ifndef, #endif etc.) stop more than one copy of the same script from being added. If you want your version of the script to take priority, you should give it the same file name and folder location as the base script, without using tdm_user_addons.script. It works the same as, for example, letting a custom model take priority over a base model.

@Araneidae I've posted on your bugtracker #5888

Yeah I noticed it too. This would be a case for @duzenko

Problem in this case is that def_attach only returns the classname (entity type) of the attached entity, while name_attach is not the actual name of the attached entity, but an internal name to allow other spawnargs to modify this attachment.

An alternative option to make attachments non-solid is to set spawnargs in the format "set x on y" "z". In this case it would be something like "set solid on armor" "0". y is the name_attach (not the $name). You can see what the attachment name is by checking the AI's spawnarg list for "name_attach" spawnargs, matching the "def_attach" spawnargs. For example, "def_attach2" "atdm:breastplate01", "name_attach2" "armor" -> y is "armor".

Now we just need to remove the console clutter from core asset bugs and pointless mass-warnings and the console will be perfect.

The name definitely doesn't change after a KO/kill. Maybe setContents just doesn't work as expected for AIs.

This pinned thread's purpose is to collect links to all the discussion threads for new features to be added in 2.11. [2.11] GUI warnings and changes [2.11] Large static meshes no longer considered dangerous for performance [2.11] Frobstages: automatic generation and customization [2.11] OBJ model format [2.11] New Blackjack System (available via dev build) [2.11] Stencil shadows optimizations As well as older feature collection threads: [2.10] Feature discussion threads

You can try setContents(0), but this will also make them invisible to AIs, unfrobable and maybe cause them to fall through stuff. The most practical would be to ensure there's enough space.

It's the positions of the top left and bottom right corner of the box that the trace moves from the player's eyes to the flame. If the box hits anything else on the way the trace returns less than 1. If you don't want to use a box you may as well use tracePoint instead and delete those two vectors.

You'll find them in "def_attach" spawnargs of candle holder entities. I doubt any holders use the moving versions, though. Can unpack all your TDM .pk4's and use Notepad++ to search in .def files for such spawnargs.

Most walls in TDM are 8-16 units, so reducing distance won't be adequate. You can let the script do a trace to detect whether there is something solid inbetween you and the candle. My camgoyle turret's scriptobject, as found in my scripting thread (see signature), makes use of traces.

I don't think particles can be frobable since frobbing seems to rely on clip contents. Also, I donxt think the flame materials have frob highlight stages yet. Well, maybe you can at least use SetContents after map start to make the particle solid to frobbing throughout its entire bounds (warning: rabbit hole). Probably more realistic to frob the candle vs. the holder.

Obsttorte wrote a trigger_look script which should be available as an entity in the base assets. Otherwise you could try looking it up on the forums.

I think @AluminumHaste could share some tips with us all.

Had best bring a knife to carve a path through that fog.

Yeah, try looking at how popup tooltips were done for main menu settings. Shop item descriptions are found after #str_02256 in strings/english.lang canBeBlownOut seems to exist to stop flames from being extinguished by fire arrow blasts.

Yeah, I mentioned door handling position entities for this a little earlier on.