GET STARTEDUPGRADING FROM 1.X
Upgrading from 1.x
Update the plugin and open your project. Your 1.x doors, levers, pickups and other objects are migrated when they load and keep working the way they did in 1.x. You do not need to re-save anything, and a re-save keeps the same behaviour.
Most single-player projects only need a full cook. Multiplayer projects get a server that checks every use, so they are worth one test session.
Before you update
Section titled “Before you update”Commit your project to version control or back it up. 1.x cannot read the settings that 2.0 saves, so going back means going back to the 1.x files.
What happens on its own
Section titled “What happens on its own”- Assets saved with 1.x are migrated each time they load. Their Actions, MoveHandlers and Conditions keep the 1.x settings: one shared object per interaction object, no check on the server.
- Actions, MoveHandlers and Conditions that you create in Blueprint with 2.0 get the 2.0 defaults: a fresh copy of the Action or MoveHandler for every use, and Conditions checked again on the server.
- C++ classes keep the 1.x behaviour until you set the new values in their constructor.
What to check
Section titled “What to check”| Your project | What to do |
|---|---|
| Any project | Make one full (non-iterative) cook after the update. Why |
| Any project | Look in the Blueprint compiler log for variables renamed to InstancingPolicy_0, NetExecutionPolicy_0 or ServerValidation_0, and check the nodes that use them. Details |
| Multiplayer | The server checks every use and can reject it. Play with two clients and look for rejections in the CISLog log category. What each rejection means |
| Multiplayer | Change an object’s state and its usable flag on the server. A change made only on a client now logs a warning, and the server can reject the next use of that object. Details |
| Multiplayer | Uses from far away or right after a teleport can need wider tolerances: Project Settings › Plugins › Character Interaction System. Settings |
| Multiplayer | Every machine that shows a use now runs its Action and MoveHandler itself. An Action that must finish only on the server needs ServerOnly or LocalPredicted. Details |
A copy of the 1.x demo in /Game/CharacterInteraction | It keeps working. The 2.0 demo now ships inside the plugin; to switch to it, follow four steps. Steps |
| Content made from the 1.x demo character | The demo character is now the UE5 mannequin Manny, and it uses Enhanced Input. Details |
| A use that ends when the character walks out of the trigger | Walking out no longer interrupts a use. End it yourself with TryInterruptObjectUsing or FinishAction. Details |
| C++ code | SetOwnerOfActor and ServerSetOwnerOfActor give a deprecation warning: call AActor::SetOwner on the server instead. Overrides of Serialize, PostLoad, PostInitProperties and EndPlay must call Super. C++ API |
If a use stops working in a multiplayer test and you are not sure the server’s check is the cause, turn off Server Validation (Project Settings › Character Interaction System) for one test. The server then accepts every use, as 1.x did. Turn it back on before you ship: without it a client can use any object from anywhere.
Every change in detail
Section titled “Every change in detail”Upgrading from 1.x: every change lists
each behaviour change, who it affects and what to do. The plugin ships the same text as MIGRATION.md. The
Changelog gives the reason for each change.