[Beta testing 2.10]

2 hours ago, Goldwell said:

I have two AIs that conduct a conversation in an area of my map. 
 

In a nearby area I also have a camera. When the camera detects me and the alarm goes off it breaks the two AI and they no longer have their conversation. 

 

Is there a way to get specific AI to ignore the alarm sounded by the camera?

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.

[Newbie DarkRadiant Questions]

17 minutes ago, Geep said:

DR question: suppose I have a func_static made of a large number of brushes. To select an individual brush, I know I can cycle through the components with Tab (or Shift-Tab the other way). I know I can select an individual face by touching it with Ctrl-Shift LMB. Is there some way to select a component without cycling? Either directly, or by expanding a selected face? Other than by converting the func_static to worldspawn and back.

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.

[Beta testing 2.10]

On 12/23/2021 at 11:18 PM, Dragofer said:

I've noticed that I can see the edges of light volumes as sparkly lines now - this is taken from a recent test map:

And this is m y darkmod.cfg (pretty much the one that the tdm_installer.exe gives me after updating to beta02): Darkmod.cfg

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:

[Newbie DarkRadiant Questions]

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

[Newbie DarkRadiant Questions]

@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.

6 minutes ago, STRUNK said:

Could you shine some light on that?

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.

[Newbie DarkRadiant Questions]

5 minutes ago, STRUNK said:

channel torso   ( *EyeR *EyeL *AntennaR *AntennaL)
    channel legs       ( origin Body *LegUpFR *LegUpMR *LegUpBR *LegUpFL *LegUpML *LegUpBL *LegUnFR *LegUnMR *LegUnBR *LegUnFL *LegUnML *LegUnBL *FootFR *FootMR *FootBR *FootFL *FootML *FootBL)

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".

10 minutes ago, STRUNK said:

1 hour ago, HMart said:

"origin"    -1 ( 0 0 0 ) ( -0.5 -0.5 -0.5 )

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.

[Newbie DarkRadiant Questions]

24 minutes ago, HMart said:

About IK idtech 4 does take it into consideration, for characters at lest, but I don't know if the IK info is exported from the 3D tool or created automatically by the engine, perhaps the video I posted has that info. 

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.

[Christmas "Connections" Contest 2021 - [ Winner "Iris" ]]

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.

[[2.10] Beta testing new Main Menu GUI]

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.

[So, what are you working on right now?]

@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 need your help!]

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?

[Light frustums different in DR and TDM]

1 hour ago, duzenko said:

Wasn't the two-sided thing and falloff the same issue?

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.

[Light frustums different in DR and TDM]

14 minutes ago, duzenko said:

Was that fix urgently required? I remember complains on projected lights two-sidedness, but the followup fix was also requested by mappers? If not, we can revert it for 2.10 and leave in svn to return to it after beta ends

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

[[2.10] X-Rays]

4 hours ago, Wellingtoncrab said:

I want to make certain objects solid when not wearing the xray glasses and I am admittedly not sure where to start.

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).

Spoiler

#ifndef __XRAY_GLASSES__
#define __XRAY_GLASSES__

float wearing_xray_glasses;		//this is global for the benefit of the spyglass_overridable scriptobject

object playertools_xray_glasses : player_tools
{
	void init();
	void inventoryUse(entity userEntity, entity frobbedEntity, float buttonState);
	void update_xray_entities();	//updates frobability and solidity of xray entities on the map

	float overlayHandle;
	float xrayGlassesCooldown;
};

void playertools_xray_glasses::init()
{
	sys.waitFrame();
	update_xray_entities();
}

void playertools_xray_glasses::inventoryUse(entity userEntity, entity frobbedEntity, float buttonState)
{
	if( sys.getTime() < xrayGlassesCooldown )
	{
		return;
	}

	if ( !wearing_xray_glasses )
	{
		wearing_xray_glasses = true;
		overlayHandle = $player1.createOverlay(getKey("gui"), ZOOM_GUI_LAYER);
		$player1.setSpyglassOverlayBackground();	// display the correct background based on aspect ratio
	}

	else
	{
		wearing_xray_glasses = false;
		$player1.destroyOverlay(overlayHandle);
	}

	update_xray_entities();
	sys.fadeIn('0 0 0', 1);
	xrayGlassesCooldown = sys.getTime() + 1.5;
}

void playertools_xray_glasses::update_xray_entities()
{
	// find entities whose solidity should toggle when xray glasses are toggled.
	entity e;
	do
	{
		e = sys.getNextEntity("solid_xray","",e);
		if( e )
		{
			if ( e.getFloatKey("solid_xray") == 0 )
			{
				if ( wearing_xray_glasses )	e.setSolid(0);
				else				e.setSolid(1);
			}
			
			else
			{
				if ( wearing_xray_glasses )	e.setSolid(1);
				else				e.setSolid(0);
			}
		}
	} while (e);

	// find entities whose frobability should toggle when xray glasses are toggled.
	do
	{
		e = sys.getNextEntity("frobable_xray","",e);
		if( e )
		{
			if ( e.getFloatKey("frobable_xray") == 0 )
			{
				if ( wearing_xray_glasses )	e.setFrobable(0);
				else				e.setFrobable(1);
			}
			
			else
			{
				if ( wearing_xray_glasses )	e.setFrobable(1);
				else				e.setFrobable(0);
			}
		}
	} while (e);
}

#endif //__XRAY_GLASSES__

 

4 hours ago, Wellingtoncrab said:

I see there is a global parameter to track the state of whether or not the glasses are on - does that mean it can be referenced by the map script?

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.

Spoiler

#ifndef __SPYGLASS_OVERRIDABLE__
#define __SPYGLASS_OVERRIDABLE__

//difference to normal spyglass: can't be used if already wearing xray_glasses (wearing_xray_glasses = true)

object playertools_spyglass_overridable : player_tools {
	void init();
	void inventoryUse(entity userEntity, entity frobbedEntity, float buttonState);
	void zoomOut();

	float zoomedIn;
	float zoomMutex;
	float overlayHandle;
};

void playertools_spyglass_overridable::init()
{
	zoomedIn = false;
	zoomMutex = false;
}

void playertools_spyglass_overridable::zoomOut()
{
	zoomedIn = false;
	$player1.endZoom(ZOOM_OUT_DURATION);

	zoomMutex = true; // disable commands during the zoom out transition

	sys.wait(ZOOM_OUT_DURATION/1000);
	$player1.destroyOverlay(overlayHandle);
	overlayHandle = 0;

	zoomMutex = false;

	$player1.setImmobilization(SPYGLASS, 0);
}

void playertools_spyglass_overridable::inventoryUse(entity userEntity, entity frobbedEntity, float buttonState)
{
	if (wearing_xray_glasses)
	{
		return;
	}

	// This is to avoid zoomIn events during zoomOut transitions, which look bad
	if (zoomMutex) {
		return;
	}

	if (!zoomedIn)
	{
		// Start zooming in
		zoomedIn = true;
		$player1.startZoom(ZOOM_IN_DURATION, ZOOM_STARTFOV, ZOOM_ENDFOV);

		// Create the GUI
		overlayHandle = $player1.createOverlay(getKey("gui"), ZOOM_GUI_LAYER);

		// Disable some player actions while zoomed in
		$player1.setImmobilization(SPYGLASS, SPYGLASS_IMMOBILIZATION);

		$player1.setGuiFloat(overlayHandle, STATE_ZOOM_IN_REQUEST, 0);
		$player1.setGuiFloat(overlayHandle, STATE_ZOOM_OUT_REQUEST, 0);

		// grayman #3807 - display the correct background based on aspect ratio
		$player1.setSpyglassOverlayBackground();

		eachFrame {
			// Check if the zoom has been ended >> break the loop
			if (!zoomedIn) {
				break;
			}

			float closeRequest = $player1.getGuiFloat(overlayHandle, STATE_CLOSE_REQUEST);
			if (closeRequest)
			{
				// Perform the zoomOut transition and break the loop
				zoomOut();
				break;
			}

			float zoomInRequest = $player1.getGuiFloat(overlayHandle, STATE_ZOOM_IN_REQUEST);
			float zoomOutRequest = $player1.getGuiFloat(overlayHandle, STATE_ZOOM_OUT_REQUEST);

			float curFov = $player1.getFov();
			float newFov = curFov;

			if (zoomInRequest)
			{
				newFov -= ZOOM_STEP;

				// Reset the GUI variable
				$player1.setGuiFloat(overlayHandle, STATE_ZOOM_IN_REQUEST, 0);
			}
			else if (zoomOutRequest)
			{
				// Zoom further out, if applicable
				newFov += ZOOM_STEP;

				// Reset the GUI variable
				$player1.setGuiFloat(overlayHandle, STATE_ZOOM_OUT_REQUEST, 0);
			}

			if (zoomInRequest || zoomOutRequest)
			{
				// Clamp the zoom value
				if (newFov < ZOOM_ENDFOV)
				{
					newFov = ZOOM_ENDFOV;
				}
				else if (newFov > ZOOM_STARTFOV) 
				{
					newFov = ZOOM_STARTFOV;
				}

				// Start the zoom transition from the current value to the the new one
				$player1.startZoom(ZOOM_STEP_DURATION, curFov, newFov);
			}
		}
	}
	else
	{
		// We're already zoomed in, so zoom out now.
		zoomOut();
	}
}

#endif //__SPYGLASS_OVERRIDABLE__

4 hours ago, Wellingtoncrab said:

I see the default behavior for brushwork with xray skins is to make them non solid.

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.

[View Stealth Score during gameplay?]

22 minutes ago, Araneidae said:

Certainly putting z_ in front means the numbers show and the addon isn't deleted (have just upgraded to beta -03).

However, it looks to me as if the addon isn't working properly.  I started up "The Bakery Job" (default settings after .cfg reset after beta upgrade), let the maid in the garden see me ... and she runs off crying ... and all my stealth scores remain firmly at zero.

Is there anything else I can do to debug?  Presumably there are some console commands I can run to cross-check the values shown by z_tdm_loot_stealth_stats.pk4?  It's definitely not working properly for me at the moment!

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.

[2.10 Subtitles]

10 minutes ago, freyk said:

Background of the subtitle is transparent dark.
Keep it only transparent, without a color.

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

[[2.10] X-Rays]

@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.

[Black Mage: performance problems (and fog)]

15 hours ago, nbohr1more said:

@JackFarmer

Our internal profiling shows that the lava cave is using patch geometry for path-finding. This is a known performance pitfall.

Would you be willing to look into making the cave patch geometry non-solid and then creating simplified brushes for the Fire Elementals to path-find over?

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:

[[2.10] X-Rays]

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".

[[2.10] X-Rays]

1 hour ago, Wellingtoncrab said:

but I can't find how to simply flag an object as hidden unless viewed through the xray. Is this info in the wiki somewhere?

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.

[[2.10] Feature discussion threads]

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

[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.

[Beta testing 2.10]

23 minutes ago, Spooks said:

I think there is something wrong with looping sound shaders that have a playlist of sound files to go through. They may play something from the playlist at first but then they'll get stuck looping the very first item in it and never randomly choose another. This obviously wasn't the case in the last version of the game.

Please corroborate, you can test with a regular speaker with 's_shader' set to 'animal_dog_distant' or 'frob_instrument_victrola', and 's_looping' set to '1'. If the dog bark/ditty is always the same on your end too, then it's a bug.

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

[[2.10] Volumetric Lights]

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

[View Stealth Score during gameplay?]

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.