Conditions

A condition decides whether a character may see or use an object. It is a class derived from UCISInteractionObjectCondition, with one function, Check Condition, that returns true or false. An object lists its conditions in two places: Visible Conditions, which decide whether the object is visible to the character, and Usable Conditions, which decide whether the character can use it. The demo HUD’s E | INTERACT prompt shows only for the object the character can use, so a failing condition in either list hides it. The lists belong to the interaction object component.

What it does

• It answers one question about a character and an object, such as “is the character close enough” or “is the way clear”. Your code writes the answer in Check Condition.
• It runs on the player’s machine, to show or hide the object and to decide whether the use is sent.
• It can run again on the server before the server accepts a use. Its Server Validation setting says whether it does.
• A condition is an object of its own, not an actor. It has no components and no network settings of its own.

How it works

Visible and usable. The character’s data object checks each object again on every tick, on the player’s machine. The data object exists only on that machine, so the conditions run only there. First the object must be in reach, face the character, be usable, and not be used by anyone else. Then every entry of Visible Conditions must pass. Only when the object is visible does the data object check Usable Conditions, and each of those must pass too. A null entry is skipped. A visible object can show an icon, which the data object draws from OnVisibleChanged. A usable object is one that the use button works on, and only a usable object can become the best object, which the demo prompt follows. See Troubleshooting for the checks in order.

Where a failing condition leaves the player. A failing visible condition hides the object, so there is no prompt. A failing usable condition keeps the object visible, so an icon drawn from OnVisibleChanged stays. The object is no longer usable: the use button does nothing, and the demo HUD’s E | INTERACT prompt disappears. A use that the player’s machine blocks this way sends no request and writes no log line.

The server check. A server checks a use request in this order: the object and its character, the usable flag, occupation, the state’s Action, the side, the distance, the facing, then the conditions, and last the hold time. The server evaluates the entries of both Visible Conditions and Usable Conditions. It checks an entry only when the entry’s Server Validation says so, and the Default value applies to both lists. The server has no data object, so it calls Check Condition with the server’s copy of the character, its component, the object and the requested side. A failing condition ends the request as ECISUseRejectReason::ConditionFailed.

Server Validation. Each condition has this setting, with three values:

• Default checks on the server for a Blueprint class, and does not check for a C++ class.
• Validate checks on the server for every class.
• Do Not Validate checks only on the player’s machine.

The project setting. Server Validation in Project Settings › Plugins › Character Interaction System turns the server check of all use requests on or off, and it is on by default. With it off, the server skips these checks, the conditions included. It still rejects a side or an Action that it does not have, and a character that already runs a use. The server checks only the requests of remote clients. A standalone game, a listen host’s own character and the characters the server runs are not checked.

The demo conditions. The plugin ships three conditions in its demo folder:

• BP_InteractionObjectConditionDIstanceCheck has a Distance variable. It passes while the distance from the object’s actor to the character is at most Distance. Its Server Validation is Validate.
• BP_InteractionObjectConditionTrace traces a line from the character to the object, each end raised by a vertical offset variable. It passes when the line is not blocked. Its Server Validation is Validate.
• BP_InteractionObjectCondition_IsObjectRendered casts the character to BP_CISCharacter. For a first-person BP_CISCharacter it passes when the object was recently rendered on screen. For a third-person one it passes. For any other character it returns false. Its Server Validation is Do Not Validate, because only the player’s machine knows what is on its screen.

Most demo objects have BP_InteractionObjectCondition_IsObjectRendered in Usable Conditions, so only BP_CISCharacter can use them. The demo levers and switches have BP_InteractionObjectConditionTrace and the distance check in Visible Conditions, and the pick-up items have the trace there. The distance check is in Usable Conditions of the doors, levers, switches and pick-up items. See The demo.

Set it up

The steps are in the guides, so this page gives only the outline. Follow these guides in order:

1. Make a Blueprint from UCISInteractionObjectCondition and write Check Condition, as Your own Condition does in its steps 1 to 3.
2. Choose the Server Validation of the condition, and put the condition in Usable Conditions of the object, as Your own Condition does in its steps 4 and 5.
3. For a game with more than one player, check the server’s behaviour in Object for multiplayer, step 4.

Use it

• Override Check Condition, which takes the character, the character’s component, the object’s component and the side. Return true when the character may use the object. The condition returns true by default.
• Put a condition in Usable Conditions to limit the use. Put it in Visible Conditions to hide the object from the character, which hides its prompt too.
• Keep Server Validation at Default for a condition that uses positions of the two actors, because the server knows them. Use Do Not Validate only where a modified client could skip the check without harm.
• Remember that a server check uses the server’s copy of the character. A distance measured there can lag behind the client, so give the condition a small margin.
• Use one condition for many objects by making its values instance-editable, as Your own Condition does with Distance.

Key settings

Settings
Server Validation	Default

The settings of a condition class: its server validation setting.

Setting	What it does	Default
Server Validation	Whether the server also checks the condition before it accepts a use. Default checks a Blueprint class and not a C++ class.	Default
Visible Conditions (of the object)	The conditions that must all pass for the character to see the object, with its icon.	Empty
Usable Conditions (of the object)	The conditions that must all pass for the use button to work on the object. Checked only while the object is visible.	Empty

Check that it works

• Stand about 2 m from your switch, facing it, and press E. Nothing happens, because the condition limits the use.
• Walk up to about 1 m from the switch, facing it, and press E. The switch changes state. The check is the one in Your own Condition.
• In a game with more than one player, a use that the server refuses writes the line ServerRequestUse from <character>: the use of <object> is rejected (ECISUseRejectReason::ConditionFailed), key <key>. when CISLog is at the Log level. See Object for multiplayer.

Troubleshooting

• The object is never usable, even when you are close. The condition is in Visible Conditions instead of Usable Conditions, or it is not compiled. Check the list it is in.
• The prompt does not show. A visible or a usable condition fails, or another check fails, such as the reach or the facing. A usable condition is not checked while the object is hidden.
• The icon shows, but the prompt does not and the use button does nothing. A usable condition fails. Check Check Condition and the condition’s values.
• The server refuses a use that the player’s machine allows. A condition with Server Validation Validate or Default fails on the server. The server’s copy of the character can lag behind the client, so a distance needs a margin. The reason is ECISUseRejectReason::ConditionFailed.
• A C++ condition is never checked on the server. Under Default, a C++ class is not checked. Set Server Validation to Validate to check it.
• A condition that reads the screen or local input fails on the server. Set Server Validation to Do Not Validate. The server then skips the condition, and a modified client can skip it too.
• The demo objects do not respond to your own character. The demo condition BP_InteractionObjectCondition_IsObjectRendered lets only BP_CISCharacter use them. Test your own character with an object of your own.
• No condition is checked on the server at all. The project setting Server Validation is off, so the server skips the condition checks, and a use that the player’s machine allows goes through unchecked. Turn it on for an online game.