Interactive Doors

My initial idea for how the player should be transported from the door to the destination was that the player would set off a custom event inside the door blueprint and set the characters location based on the positioning of a collision sphere called "destination" inside the door blueprint, this destination could be moved anywhere.

Eventually I changed this, I figured that rather than doing the event, I could just make it so that there was a location variable in the player itself that when the door overlapped with the player would be changed through a cast to the player controller to edit the "destination for door" variable. 

When the player stops overlapping the door, nothing really happens. This is just some old code from when I was attempting to use the older method where transport was done through the door blueprint. This method included checking if the player was close enough to the door to interact with.

In the newer version this is still a thing but under a different name in the main character blueprint.

When the player overlaps the door, a branch checks if they have the ability to use doors any more. This is more important when describing the end of the game. if it's true that the player can use doors, then an e to interact widget is created and added to the viewport to tell the player this is the case.

Following being added to the viewport, the boolean "IsAtADoor" is set to true, meaning that the player is able to use the door. This is what I meant when I said that the door being within interacting range was still used despite abandoning the older system of doors.

When the player stops overlapping the door, the variable on whether they are in range or not will change to false, meanwhile all widgets will be removed to get rid of the "E to interact" button. This is dependent on whether the actor has the tag "TypeOfDoor" or not as only stopping overlapping a door will mean the variable needs changing, not a speaking box.

If the door is locked (another branch), then all widgets will be removed and replaced by a door is locked widget, this is then added to the viewport.

This will then set a variable called "Door is locked popup active" which is a remnant of older code and could be removed for future optimisation. The player walk speed is set to 0 to prevent any form of movement and there will be a 3 second gap whilst the player looks at the "Door is locked" widget. This is then removed with a remove all widgets node and the player is given their walk speed back to continue exploring the map.

Otherwise, the player blueprint actor will be set to the location that was cast to the player when they began to overlap with the door. This is followed by a remove all widgets node to clear the screen. 

If the name of the current level is equal to the final level, then the interactive doors are all destroyed, the widgets are removed and as a final failsafe "the can't use doors" variable is activated, preventing the player from escaping once they enter the corridor at the end to shoot the monster.

Just for added context, the red sphere in the middle is the destination and the block collision is just the radius that sets off casting top the player and the player being within range to use the door.

The main thing to take note of is that despite the box collision being at the living room door and stretched, the sphere isn't. This is due to being able to change all of the locations for the components within a blueprint by clicking on each component on the menu shown below on the right.

(Shown throughout)

Conclusion

In conclusion, the interactive doors work exactly as they should do, with my only criticism being the inability to use them straight after using another. Instead, if you pay attention, you have to walk a small distance and go back to the door to be able to use it. If I had the time, I would definitely implement a system to use the door again without having to go away and back to it, as the current system seems rather clunky and makes no logical sense at all.