Dragofer

Only way I know of to make AIs ignore an alert-causing event is to give them 0 acuity. Could start them at 0 auditory acuity, then set this to 1 via a script that's called by the same trigger that starts the conversation.

There's a button called "Select Group Parts" on one of the top panes of DR. Rather misleadingly, it won't let you select parts of actual groups.

By the way, I noticed that these starry lines along the light volume boundary become more noticeable at low anisotropy filter values and invisible at 16x. 16x anisotropy: 1x anisotropy:

@STRUNKBy the way it would be good to see your bone hierarchy.

@STRUNKI'd open some .md5meshes in Notepad and look what kind of values you see for the "origin" bone and compare it with your own .md5mesh to get a clue on the floating. IK is what allows feet to step on uneven surfaces while keeping the body at a relatively constant height. You can see IK spawnargs specifying how high the waist should be above the floor and the ankles at minimum, as well as a spawnarg to designate which bone is the waist. Definitely should look at a Blender Youtube tutorial to get an understanding of how IK bones work.

This looks problematic. The asterisk in front of the bone name means that you also include all bones that are beneath this bone in the hierarchy. For example, *origin is the same as listing all bones individually by name without asterisks, since all bones are lower in rank than the origin. So "*LegUpBR" is the same as writing "LegUpBR LegUnBR FootBR". I guess this goes in the .def file or the Entity Inspector? Bookmarked the video. It's with a different 3D editor but might clarify some things. This is a line from an .md5mesh file specifying properties of the "origin" bone - I believe the 3 sets of numbers are its bone ID number, start and end of the bone. The .def file is nothing else but a list of spawnargs, saved as a preset that represents an entity. Note that entities also get spawnargs from entities they inherit from. Try looking at a human or a spider to see examples of IK spawnargs referencing IK bones.

You need to add IK bones in the modelling app (see Youtube tutorials), then simply refer to them in the entity's .def in TDM.

I believe the idea was that if your FM contains 2.10 features you'd release it only to players who installed 2.10 dev builds, while other players would wait until 2.10 is out. Voting would still be open around the 2.10 release. Well, maybe the contest deadline and estimated 2.10 release date are quite close together now.

I always imagined the FPS limit as an environmentally friendly option that also spares your hardware from running at maximum load all the time. Especially for laptops on battery.

@DeTeEffI suppose the problem is that the core assets don't include the scripts that are required for that numberwheel entity. Missions that have numberwheels have their own copy of the script in the FM's script folder. The Black Mage is one such mission. It's probably too late to add those scripts to the core assets, unless maybe all FMs use a version of the script file that has inclusion guards at the start and end.

I'm not sure what you mean with your question. Which script has a spirit? Is this in a specific FM, or are you trying to make your own FM or script?

Not as far as I can tell, you committed something that fixed the two-sidedness, then a while later I noticed the falloff has become properly smooth instead of cutting off to black abruptly. It's the first time I've seen a projected light with correct length-wise falloff in TDM.

The security camera required that fix to two-sidedness and also to proper falloff. The spotlight now works perfectly in both those regards.

My approach was to add another function to the scriptobject, "update_xray_entities", which is called by the scriptobject's init function at map start and whenever the player puts on or takes off the xray glasses. See the customised scriptobject below (it also contains a proper cooldown to limit how rapidly the player can toggle the glasses to minimise visual glitches). Yes, making that variable accessible to other scripts was the reason behind making it global. Personally I've used this for a custom version of the spyglass scriptobject that can't be used while the player has xray glasses on (see the beginning of the inventoryUse function in the below scriptobject). Note that the custom spyglass scriptobject has to be #included later than the xray glasses in tdm_custom_scripts.script so that the variable already exists by the time the spyglass scriptobject tries to read it. The xray system itself should not have any effect on the solidity of entities, only the regular "skin". That said, I can't exclude 100% from my memory that setting a nonsolid "skin_xray" on i.e. a brush entity may affect its solidity in unforeseen ways.

I think that's a unique bug in that civilians spotting the player at close range don't count towards the stealth score. It's even got a ticket in the bugtracker.

A dark background is needed to make sure the text is always readable regardless of the image behind it.

@WellingtoncrabMixing models is probably my favourite mode, too. For adjusting their relative contributions I found it useful to add a line with "alpha" followed by a number to the xray material stage. Note that if you go for alpha values over 1 the rendering may become... weird and overly bright, depending on your colour precision setting.

If the cave patches are made non-solid they'll become nonsolid to the player too and brushes will not be able to believably mimic their contours. Also, there is in fact already extremely simple monsterclipping in the map above the patches, but parts of the monsterclip floor come within 32 units of the patches so at those points the patch surface would be used for collisions instead of the brushes: That said, @JackFarmer can massively reduce the patches' tri counts by enabling "Fixed subdivisions" in the Patch Inspector (Shift + S) and setting this to i.e. 4x4, instead of letting DR automatically set the number of subdivisions. They should also not all be in the same func_static entity: The ingame appearance is almost identical:

Beta2 features a new spawnarg: "suppressInSubview". Specific to lights, setting this to "1" makes the light visible only in normal vision while "2" makes it visible only in xray vision. Note that this affects other subviews like mirrors and camera screens, too. The below screenshot was achieved by setting the spawnarg on the regular ceiling lamp to "1" and on the blue flame light to "2".

The current method mentioned in the wiki in the spawnargs section is just to set "skin" "invisible" and "skin_xray" "visible". We thought about using the "xray" spawnarg for this so that "0" = invisible in xray, "1" = invisible in normal vision and i.e. no value = visible in both, but the skin method just seemed more intuitive.

This pinned thread's purpose is to collect links to all the discussion threads for new features in 2.10 so that they no longer all need to be pinned. [2.10] Beta testing new main menu GUI [2.10] Volumetric lights [2.10] X-Rays [2.10] Dmap locations diagnostics [2.10] Dmap optimizations [2.10] Entity limit removed [2.10] Subtitles TDM security cameras

Next topic: it looks quite feasible to extend the security camera code to detect not only the player, but also AIs. Question is, how should the AI react to being detected? Currently it would just go into agitated search mode as a result of the alarm, which means it more or less stays in the security camera's sight cone and the alarm just goes on and on. Maybe the expectation is that the mapper would place other AIs (i.e. guards) near the security camera who would come running and fight the intruding AI. Maybe some intruders should flee (i.e. a thief) while others (i.e. undead) should stand their ground. Another option would be to attempt to fight the security camera, but most probably won't be reachable to melee AIs and almost all archers use broadheads so they can't harm inorganic cameras. If the security camera were linked up to a turret (which doesn't exist yet as an official entity) you'd probably expect the AI to run for their lives.

I can confirm this happens with looping multi-sound shaders, but IIRC it happened on 2.09 too.

Shouldn't it rather be fixed properly? Volumetric lights include shadowcasting, so why would wall shadows be excluded?

Ah right so @Araneidaethe .pk4 addon's name should not start with tdm_, otherwise the tdm_installer treats it like a stock .pk4 that'll be deleted when updating. Try putting z_ in front of its name, or _a if that doesnt work. Let me know which one works.