First Person Exploration Kit: Source Code and Class Structure Changes new in version 2.0


While most changes were designed specifically with backwards compatibility in mind, some changes required a hard cut from old code to new. This may result in your project's code working incorrectly, depending on how deep your changes deviate from the original source code.


It's a good idea to have a diff handy that shows the differences between the original v1.2 source code of this asset and your current version. The core changes apply mostly to the FPEInteractionManagerScript, and FPEInventoryManagerScript files, but there were also significant changes made to the old Standard Assets folder and the related player and input class files.

 If you modified original source code in the previous version, please read this 

Class Source Code and Related Prefab Changes


In FPEInteractionManagerScript.cs, the variables zoomedMouseSensitivity and highlightedMouseSensitivity have been made private. In their place, two new variables called zoomedMouseSensitivityMultiplier and highlightedMouseSensitivityFactor have been created. On start, the old values are automatically populated with a correct value based on the multiplier and current mouse sensitivity. Every time the mouse sensitivity is changed, the function refreshAlternateMouseSensitivities() must be called to keep the "regular" sensitivity correctly aligned to the relative zoom and highlight sensitivities. See FPEGameMenu functions called "changeMouseSensitivity()" and "refreshMouseSensitivityValue()" for example code.

Mouse smoothing, Y-Axis flip, and mouse sensitivity are now fully controlled by the new FPEInputManager class.


demoScene now has an object called FPECore which replaces all previous 'core component' requirements. TODO: docs/instructions

Player UI UI Camera

The previous FPEUICamera prefab has been removed, and the FPEInteractionManager now uses "Screen Space - Overlay" Canvas Render Mode

Controls General Put Back Type Changes

In order to support saving and loading of game data, put back locations now use a string name instead of GameObject Instance ID. This is due to the fact that saving and loading game data breaks the guarantee that a given game object will have the same instance ID across play sessions. For example, if I pick up a can of demoSoup, it may have instance ID 1. If I save the game, then reload the game, the instance ID may now be 2. The put back location needs to allow for a can of demoSoup to be put back, but can no longer rely on instance ID matching the original assigned in the inspector.

Some technical details, in case you modified this code in your project(s):

Now, internally, put back locations create a match string from the GameObject's prefab assigned in the scene editor. So for example, if you assign a demoSoup prefab called "demoSoup", "demoSoup (1)", or "demoSoup(Clone)", the matching string created will simply be "demoSoup". This means that unique put back requirements must be handled with unique prefabs. So using the "demoArtifactPickupObject" object (the gold skull cube artifact in the demo) as an example, its put back location now looks for an object called "demoArtifactPickupObject". Given that there is only ever exactly one of these in our scene, the uniqueness of the behaviour is guaranteed. It also means that saving and loading the game at any state of the "Idol Trap Sequence" in the demo will always yield a successful result, even if the player picks up and drops the idol a bunch of times before returning it to the idol "artifact missing" put back location.

Automatically generated put back locations will also continue to work as expected, and all changes to matching logic are internal to FPEPutBackScript.

Activation Type Changes

All of the above to use the new Activate and Pickup type features. Namely, the events available in the Inspector are now hooked up to the correct functions, rather than requiring each of these have their own Activate or Pickup type sub classes.

Note: Depending on the nature of any implemented Activate subclasses you made, you may want to use the new features as well. For example, the demoUnlockableDoor was changed from having one large function that talked to InventoryManager in code, it now uses two smaller specific functions: "attemptDoor()" and "cardError()". These functions are assigned in the Inspector for Activation and Activation Failure, respectively. Inventory requirements are now handled in the Inspector too, with much better granularity. In this case, the player must have 1 keycard in their inventory, and they get to keep it after they open the door. Changing this to require the keycard is in the player's hand, and that they lose it when they use it would be as simple as checking two checkboxes in the Inspector.

Audio Diaries Audio Diary Entry Note Entries