Interaction on doors
I'm creating new doors with new animations
How do I interact like with vanilla doors?
I activated
M Is Usable checkbox, but I don't know how to change the wording. ?
96 Replies
Why can't you use the base class of vanilla doors?
Because my animations are different
I don't remember offhand, but check this mod's source, it does it https://github.com/budak7273/GameShow/
GitHub
GitHub - budak7273/GameShow: Satisfactory mod for Satisfactory Even...
Satisfactory mod for Satisfactory Events group. Contribute to budak7273/GameShow development by creating an account on GitHub.
although idk what the syntax is to get the formatted keybind thingy
Thanks, but when I load it into the project, I only have C++, nothing in blueprint
I think all you have to do is override
GetLookAtDescription and return your text based on the mode enum of the door.
that sounds right
mod content folders are named after their friendly name and that mod's friendly name is not GameShow
otherwise make sure you followed these steps https://docs.ficsit.app/satisfactory-modding/latest/Development/BeginnersGuide/ImportingAnotherMod.html
Ah yes, that function name has a typo: "Get Look at Decription"
Thanks!
It works
All that's left is to manage the change
Cool, you can do something like this to get the bound interact key, and switch the text on the door mode.
oh sweet so that's what it is
You will need to format all that text together of course
do you know the rich text format code to get the orange box?
nope
Isn't there a function to do enum to string, and another function to get the next value of an enum in a sequence (looping back to 1st)?
you could use a Select node and then pick your strings carefully to the same effect
and the right thing would be enum to text (localizable), idk if enums have anything Text by default
There is definitely a
ToString function for every enum. I don't know about auto increment though, I don't thinkt here is anything like that for BP. I always do manually.Cool, that's a good start.
What's the point?
It works without
the point of which part?
Get ctrl + Get key
people can rebind interact to not 'E'
If you wanted it to say "Press E to switch door mode", you can hard code the E or use those functions to get the key name bound to the input action, which is better
By default, the 'E' key is the activator, right?
yes, but it might not be for everyone
and it isn't the default for controllers
Oh...
And then ?
How to ?
Actually, the function to get the next enum value is probably also needed to update the door state
How to ? what? put them together? Format TextBut that is done OnUse, not OnLookAt.
not "needed", a switch or select can be used, but convenient
I know
No how to assigne a key or ???
Point is, same logic can be used for both functions
in the base game's key binding menus
I found something like this, but it's probably overkill for 3 states (you do not need the "PreviousOption" event)
Ah yes, so you have to retrieve the assigned letter, or the button.
Also says to clear the array before initialising it, otherwise you get repeated elements
Isn't it simpler to update the 'Door State' variable?
How do you currently update it?
After that
Multigate also works
One sec
This kind of thing should work (function can probably be pure as well)
Idea being you can use this function in the
Get Look at Decription function as well as the On Use event👍🏽
That's what I found in the string tables so far
But I'm not sure how it actually works
the element displaying the rich text defines the styling
Sounds plausible
I would suggest using the string tables if possible because this way you don't need to do translations for that
IA_Use doesn't seem to be the right key
But that's the correct syntax.
Oops, you're right. It should be the action name defined in the mapping context, not input name. In this case it should be
PlayerActions_Use
Thanks, that's good, but not the format.
what format?
OOPs wait...
My mistake, sorry
looks good, ship it
Wait, I still have a lot to do before I publish it.
looks good?
looks good, ship it
Where does this information come from? (and mapping)
Enhanced Input System :: Satisfactory Modding Documentation
This page is a work in progress. Unreal Engine 5 introduces the Enhanced Input System which assits games in handling user input. Satis...
The screenshot i posted is from the
MC_PlayerActions asset in the project.It works, if you have a simpler solution, I'm interested.
Thank you all for your advice.
Get Player Character will only work with the first player
Try doing a Get Owner on the component and then try casting to FGCharacterPlayer
Oh wait, you don't need Get Owner because you have the Other Actor pin
What do the Open Door and Close Door functions do?
I'm working on some suggestions, but I need to have lunch nowAnimations and sounds
And then?
What I suppose to do, to change?
Can I see the graphs please?
Try doing a Get Owner on the component and then try casting to FGCharacterPlayer Oh wait, you don't need Get Owner because you have the Other Actor pinYou can simply cast to FGPlayerCharacter to check if the overlap was due to a player
For simple doors, I simply use Timelines.
Later, when I'm older, I'll use animations sequence, for complex doors.
Okay, thank you. Then I should probably be careful not to call "Open Door" or "Close Door" twice in a row because that could mess up the anims
(it's easy to do, especially given how I've chosen to do it)
Like this?
No
Hold on, I have finished doing the graphs
@Jean Michel This is how I would do it.
I made the "On Component Begin/End Overlap" logic (4th picture) detect players by trying to cast the actor to
FGCharacterPlayer (if the cast succeeds, we have a player). Also, since multiple people can be using the doors at the same time in MP, I decided to make the door close (in auto mode) only if there are no players in the zone. This way, if 2 players go through a door one after the other in quick succession, the door shouldn't close on the 2nd player's face.
Also, I made this UpdateDoorState function (2nd picture) which checks if the door should be open (based on the current door mode, saved into the WantedOpen local variable), and compares it to the actual door-open state. If these two values do not match, then it opens/closes the door as needed. It greatly simplifies updating the door: simply update variables as needed and then call the function.
I also introduced a GetNextMode function (1st picture) which simply returns the next mode (used by both the GetLookAtDecription function and the OnUse event). The node I used is a Select node, you can get it by dragging from the enum variable get node. To be able to set the values inside the select node, connect the output to the return node (otherwise you get a gray wildcard pin). Also, this function needs to be Pure and Const (see arrowhands, in red).
And finally, I decided to update GetLookAtDecription (3rd picture) to do something closer to what base game doors do. The advantage of this is that I am reusing the texts from the Buildables_UI string table (5th picture) in the Select node (temporarily connect the output to a Text input to set the values for each case) and the Format Text node ([{PlayerActions_Use}] is hardcoded), which means the messages for your doors will be translated (as long as base game has translations).
I think I didn't forget anything. Please let me know if you get stuck or would like some clarification.
cc @D4rk looks like base game uses this
Format String with Input Action Names node in FGPlayerController to format keys into strings
And I think I forgot to disable localisation on that one (it doesn't need to be localised)Waou, thanks, I'll try it
Cool, I didn't know that existed. I have been ignoring the localization stuff for years. 😅
What you posted looks good, but probably wont work in MP. The mode enum should replicate and the OnUse exec chain should probably be going through an RCO before calling any functions or setting vars.
Good catch! Though the original implementation also had the same problem
I think the RCO is simple, only the door mode needs to go through it
That being said, does
OnUse get called on client, server or both?Only using client I think
Okay, then it is a problem indeed
On my doors, the OnUse opens an interact UI that calls RCO events, but in this case I think the OnUse should call the RCO events directly.
Yeah
ExampleMod has RCO examples
So what do I do?
You need to make OnUse call a RCO
And you have to move the current code for OnUse into a different function, which gets called by the RCO
BTW, as to why using player controller index 0 was a problem: https://docs.ficsit.app/satisfactory-modding/latest/Development/Satisfactory/Multiplayer.html#_avoid_using_player_controller_index_0
If you read the next section too, you'll see something about RCO
And https://docs.ficsit.app/satisfactory-modding/latest/Development/Satisfactory/Multiplayer.html#RCOs explains how to use a RCO
Well well well...
so a third horse enters the race...
do you know what the difference is between these 3? from what we have written down they seem to offer similar things
-
Get Input Action Name as Text
- Get Key Name For Action Simple
- Format String with Input Action Names
https://docs-dev.ficsit.app/satisfactory-modding/latest/Development/Satisfactory/EnhancedInputSystem.html#_displaying_information_about_input_actions
this is more of a syle thing than a code thing, but I am not sure your door will open fast enough if the player is moving quickly (ex. sprinting with blade runners), how does it compare to the vanilla doors in total time to open?It takes 1.6 sec because first there is the rotation of the lock
This one opens in 1 second
But I have another one that will take at least 5 seconds because it is wider (8m)
I don't know about them, I just disassembled the blueprint of the vanilla doors and used that. My goal was to reuse the localised strings. Well, I can tell you the 3rd one does some formatting, whereas the 1st one does not.
I can't find
Get Key Name For Action Simple, but I see this is deprecated
Edit: looking at FGInpuLibrary::GetInputActionNameAsText and FGInpuLibrary::FormatStringWithInputActionNames in the decompiler, they seem to be quite similar in their workings (they both call UFGPlayerInput::GetCurrentMappingForAction and either FKey::GetDisplayName or UFGInputLibrary::GetAbbreviatedKeyName afterwards)
Workaround: make the door have no collision unless it is set to Always Closed :wonke:Why not, good idea
The door might be slow to open, sure. But that doesn't get in the way of Efficiency™ :ficsitlogo:
Well, see you tomorrow
Have a good night
TL;DR one also does FText formatting for you (which can be useful)
I don't know why both exist though
Arch might know, perhaps?