I could add PIE Warning there.
I will take a look today, that will require “Debug” checkbox enabled tho.
No problemo, cheers! Whereabouts is the debug checkbox?
You could also output an error string from the state change node instead, which might be a better solution since I’d like to log them at runtime as well.
Sure, I’m almost done with a job task and once I finish this stuff I’m adding that to the plugin’s source.
This is why you’re the best developer on the marketplace.
lol I don’t know about that, but thanks a lot! [HR][/HR]
Your problem may be something silly like for example overlooking the name you input into a “Set State” node.
For example you may have a State named “Normal Walk” while on the node you have something like “*Normal Walk *”.
To make sure that never happens, I’ve added a sanitizing function to automatically check spaces.
Internally “Normal Walk” will now just be “NormalWalk” and the plugin runtime will now always ignore spaces from State names you input into ‘Set State’ nodes. [HR][/HR]
All nodes will now output deeper logs to let you know what is going on internally when a Set State and related functions have failed.
You have to mark “Debug” check on the FSM Component’s Details panel (advanced tab) to have those logs active.
I just modified the already existing UFSM_Log.h file and now you will get logs on the Output Log panel, PIE Messages panel, or the Visual Logger window.
If the State set have failed for whatever reason, those debug tools will tell you why:
https://i.imgur.com/PHJnSoA.png
https://i.imgur.com/nPakKOr.png
https://i.imgur.com/k5Fc0H2.png
The Visual Logger is interesting because it can tell you where and when in the game world the warning has happened.
You can read more about Visual Logger here:
https://docs.unrealengine.com/en-us/…s/VisualLogger
Those changes to UFSM_Log.h will be uploaded for plugin version 1.8.5.
In this case I’m plugging a stored enum (the same one that defines the states) into the set state by name so there shouldn’t be anything wrong with it, hence needing the debug output.
That is awesome, thank you. Is there any chance I can help you test it before you upload it?
I’ve already uploaded to EpicGames when posted images above.
Could send you a zip file, but I’m away from Pc for next hours of the day.
Btw, when you change your BP Enum, changes will not automatically propagate to the array of States on the Component.
You have to explicitly clear the Enum slot then add it again to the Details Panel when the Enum has changed.
That is because the enum is never checked at runtime, it is only read once in Editor IF you placed a new Enum on Details Panel.
(that is the only time it triggers overriding States array on the FSM Component).
Yeah I’m aware of the enum change propagation issue.
No problem, I can wait.
Marketplace team already processed update above for Launcher
They’re getting quick!
Edit: I guess it takes a few hours for the scheduled releases to go through.
Hey Bruno, thanks for putting the enum request in, that was really quick!
I have an issue that likely stems from my own lack of understanding. I’m making an inventory. Non-owners simply follow the server’s state and don’t think much for themselves:
Then I override “FSM: On Replicate State ID” and print the resulting state name which is always “NULL”. Doesn’t seem right, figured maybe it was only replicating the ID and I had to manually set it, so I tried that but it always executes the “Aborted” callback so maybe not.
The print string prints ‘2’ which is the state that it is being set to at the point I’m testing, however the debug continues to display the initial state and if I print on tick (for example) it shows the state was never actually set.
As you can see, I have debug checked and their states are not updating to the replicated state ID.
What am I misunderstanding?
@Vaei not sure if this is your issue, but there’s no parity between Enum IDs and State IDs. Sometimes they match up by accident but they can change. The only time you can trust a State ID is if you fetched it from a State originally. I’ve been using State Name almost exclusively since finding this out.
I guess it’s possible that the State ID for that state is different on the server.
I’ve been using the state name too, however the replication is only offered for StateID, and I thought it would propogate throughout (so if you set the state ID the corresponding name should be set), so long as the state ID is replicated the name should be too (in my mind). If that isn’t the case I can just have a replicated name that sets it, I suppose.
Tha’s Unreal Engine’s multiplayer weirdness.
If you want Owning Clients to replicate State set, you have to execute on Server the "SERVER] Set State" node.
If you want the same of above, but Owning Client has the Authority to change the State instead of Server, then you want to use the “CLIENT] Set State” node.
That RPC will execute OnBegin(), OnUpdate(), and OnExit() on Server + Owning Client.
However that is only between Server and Owning Client…
If you want everyone to match a State change even for a FSM they don’t own, you have to use a “[MULTI] Set State” node on Server.
Also make sure on FSM Components’ Details Panel you have set Replication Mode to a type relevant to everyone or they won’t receive “OnREP_” notification either.
Multiplayer networking is annoying
Ah that’s not what I’m after and the MP is actually really good! I don’t want to use multicast because he’s more costly and unnecessary and not absolutely time critical in my usage (which is where multicast is warranted)
The server and owning client run the same logic and I use server and client RPC to do that. If the client calls an RPC then it follows the local execution and instructs the server to do the same. However if the server calls the RPC to the client it doesn’t follow the local execution, it just instructs the client to call theirs and the initial pattern comes into play . Because the client leads the execution every time in theory there is no desynchronization other than fringe cases that are handled with an extra rpc ensuring the result is identical.
The result is that the server and owning client run the same code safely and reliably. All that remains is the remote clients which don’t need to run any of that code, they just need to obtain the result from the server (and never the owning client).
To send the result to the simulated clients I don’t want to rpc as it’s unnecessary and for this case, wasteful . All I need is the resulting state to replicate from the server and when the state is set via replication the corresponding function is expected (i.e begin state, update state, etc)
Does it make sense? It’s hard to type on this phone
If they, simul clients, are receiving replicated ID correctly then I would try to call the normal “offline” Set State node in the overriden OnREP ID function.
This way every time Server changes State they simply take resulting ID and apply that same State locally.
That is necessary because OnREP will never invoke anywhere Enter() or Update() or Exit(), internal Fsm functions.
The ‘Aborted’ callback is the result when I do that
I am testing this as well.
Seems like the *OnREP_StateID_Implementation *has a bug when it is overriden by the GeneratedClass.
I will see if I can fix that by manually adding Exit(PreviousID) then call Enter(StateID) from within the native C++ OnREP_ function instead;
That may resolve the issue.
@Vaei I have fixed that problem here in my Component doing these changes to the native OnREP_ functions:
void UStateMachineComponent::OnREP_StateID_Implementation(uint8 &ID) {
ID = StateID;
FSM_Transition Transition = FSM_Transition::Succeeded;
Exit(PreviousStateID,ID,Transition,InExit);
Enter(ID,InBegin);
if ( Transition != FSM_Transition::Succeeded ) {
LOG_PIE(Debug,ESeverity::Warning,this,FFIND(TEXT("OnREP_StateID")),FString("[OnREP_StateID]: Exiting 'PreviousStateID' was aborted."));
}
}
void UStateMachineComponent::OnREP_StateTime_Implementation(float &Time) {
Time = StateTime;
}
void UStateMachineComponent::OnREP_PreviousStateID_Implementation(uint8 &PreviousID) {
PreviousID = PreviousStateID;
}
Doing that instantly fixed here all my Components containing overriden *OnREP_StateID *function.
Are you sure Epic have released the update? I’ve been restarting the launcher but I’m yet to see an update to the plugin come through.
To be double sure I enabled debug and I’m trying to get some info out. The state I’m trying to set isn’t showing up as failed (or at all). So far all I see is normal looking stuff:
PIE: Warning: {FSM}:: ''Blueprint Auto Flow FSM'' is enabled; Trying to invoke ''On Begin'' for (OpeningCharge) State, but (OnBeginOpeningCharge) function have not been found! --> Begin: [Function /Script/UFSM.StateMachineComponent:Begin at (StateMachineComponent /Game/AvGaHo/Maps/UEDPIE_0_Map_Bull.Map_Bull:PersistentLevel.PC_Bull_2.StateMachine)]
PIE: Warning: {FSM}:: ''Blueprint Auto Flow FSM'' is enabled; Trying to invoke ''On Exit'' for (OpeningCharge) State, but (OnExitOpeningCharge) function have not been found! --> Exit: [Function /Script/UFSM.StateMachineComponent:Exit at (StateMachineComponent /Game/AvGaHo/Maps/UEDPIE_0_Map_Bull.Map_Bull:PersistentLevel.PC_Bull_2.StateMachine)]
PIE: Warning: {FSM}:: ''Blueprint Auto Flow FSM'' is enabled; Trying to invoke ''On Begin'' for (EmergencyStop) State, but (OnBeginEmergencyStop) function have not been found! --> Begin: [Function /Script/UFSM.StateMachineComponent:Begin at (StateMachineComponent /Game/AvGaHo/Maps/UEDPIE_0_Map_Bull.Map_Bull:PersistentLevel.PC_Bull_2.StateMachine)]
Maybe I’m doing something else wrong? I’ve set up a call to queue a future state, then when the current activity is finished it switches to that state:
The execution chain is: it starts with OpeningCharge, has Stare set as the future state and then EmergencyStop executes when it reaches the edge of the play area. When it calls emergency stop it waits for a moment then calls the event to set the next state, which is when it aborts.