Announcement

Collapse
No announcement yet.

UFSM: Finite State Machine

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Vaei


    So, I've added these new nodes and will send updated plugin to Epic soon...





    The situation you describe above could be dealt with doing something like this:






    To avoid wasting time creating Event signatures, instead of creating an Event manually, drag from the new Latent "Finish State" Node and the signature it accepts will automatically apply when you create an Event attached to it:





    Note however that Async nodes won't work inside Function graphs, must be onto main graphs and you can't call them directly from outside the FSM Component's Blueprint...

    The "On Begin Equipping" function should make a call to a custom Event on main Graph to execute the latent Finish node.
    Last edited by BrUnO XaVIeR; 07-04-2018, 07:57 PM.
    | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

    Comment


      For the record I'm doing the state machine stuff entirely in BP. All C++ does is find a reference to the state machine and check the state/set the state in a few cases. The items themselves that make use of the state machine still use a lot of C++.

      As for MakeStates() after FindComponent succeeds it actually calls SetupStateMachine() which calls MakeStates().

      Code:
      void AVESItem::PostInitializeComponents()
      {
          Super::PostInitializeComponents();
      
          StateMachine = FindComponentByClass<UStateMachineComponent>();
          if (StateMachine)
          {
              StateMachine->SetupStateMachine();
          }
      }
      STATES are all valid before and after MakeStates(), it's being invalidated somewhere else.

      And - Awesome, the new nodes look really good
      Last edited by Vaei; 07-04-2018, 07:58 PM.

      Comment


        Try change the source code of "Make States" function to something like this and see if the problem still persist:

        Code:
        void UStateMachineComponent::MakeStates(const TArray<FName> &NewStates, FSM_Transition &Transition) {
            if (NewStates.Num()==0) {
                Transition = FSM_Transition::Aborted;
                LOG_FSM(Debug,GetOwner(),this,ESeverity::Error,FString("'New States' Array is zero sized."));
                LOG_PIE(Debug,ESeverity::Error,this,FFIND(TEXT("MakeStates")),FString("'New States' Array is zero sized."));
            return;}
            //
            for (auto &State : STATE) {
                State.Value.OnBeginState.Clear();
                State.Value.OnUpdateState.Clear();
                State.Value.OnExitState.Clear();
            } STATE.Empty();
            //
            for (int32 I=0; I<NewStates.Num(); I++) {
                if (!NewStates[I].IsValid()) {LOG_PIE(Debug,ESeverity::Error,this,FFIND(TEXT("MakeStates")),FString::Printf(TEXT("Name for generated State of index {&i} is invalid."),I)); continue;}
                if (NewStates[I].IsNone()) {LOG_PIE(Debug,ESeverity::Error,this,FFIND(TEXT("MakeStates")),FString::Printf(TEXT("Name for generated State of index {&i} is invalid."),I)); continue;}
                STATE.Add(I,NewStates[I]);
                STATE[I].Owner = this;
            } Transition = FSM_Transition::Succeeded;
            //
            LinkStates();
        }

        If still the same, might be something hidden inside State struct constructor.
        | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

        Comment


          No such luck. At this point I've resorted to rebuilding the state machine, but I'll keep the old one for testing as long as I can because finding the solution would stop it reoccurring.

          [unrelated] The code that changes the initialization process that you gave me before - do you think you could integrate it into the plugin with an option to use it or not? (so that if you update the plugin I don't have to keep putting the change back) - perhaps a selfish request but maybe other people would use it also.

          Comment


            Yes, I've added it to the code.
            I've also added debug code to check if an internal State object is invalid or is its internal Name that is actually corrupted...
            Last edited by BrUnO XaVIeR; 07-04-2018, 09:06 PM.
            | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

            Comment


              Can I send you this project to see if you can find the issue with the invalid state? If so PM me your gmail so I can give you access to a zip on Google Drive.

              You'd need to build it in VS2017 (4.19) for "DebugGame Editor", press F5, hit play in editor. Then press "F" which will pick up an item, and then crash.

              Comment


                Originally posted by Vaei View Post
                Can I send you this project to see if you can find the issue with the invalid state? If so PM me your gmail so I can give you access to a zip on Google Drive.

                You'd need to build it in VS2017 (4.19) for "DebugGame Editor", press F5, hit play in editor. Then press "F" which will pick up an item, and then crash.
                I can send you modified version of Plugin with extra debug code I've added, but at this moment I will not be able to examine projects (I'm working for someone else right now).
                In few minutes I will pack new plugin version and PM you a link, hopefully the changes solves the problem or help you identify what happened to your index "1" there.
                | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

                Comment


                  Hmm, no difference. What is the extra debug code expected to do?

                  Comment


                    So the do-over has the same issue this time. Both occur with the 'Equipping' state and it happens following the success of the 'FSM: Set State' node going to "Equipping". I can connect "Succeeded" to a loop printing everything from the STATE TMap (I exposed it to BP for debugging) and they all print fine then proceeds to crash (immediately) from the Update function.

                    Last edited by Vaei; 07-05-2018, 12:35 AM.

                    Comment


                      Does the State name "Equipping" appears on the panel when you click the "Visualize FSM States" green button??
                      Also, this happens every time no matter where you call it from?!

                      Btw, if you comment out the event causing the crash, would maybe fix this... but the problem is we both don't know yet why this is happening in your project.
                      If you execute Broadcast of events within PostInitProperties when the Game World is invalid this kind of crash might happen, but in this case it's unclear why that broadcast crashes there for you.
                      Last edited by BrUnO XaVIeR; 07-05-2018, 06:06 AM.
                      | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

                      Comment


                        Originally posted by BrUnO XaVIeR View Post
                        Does the State name "Equipping" appears on the panel when you click the "Visualize FSM States" green button??
                        Also, this happens every time no matter where you call it from?!
                        Sure does!

                        However, I've found more info. It only occurs when calling "Finish State". The transition is specified (as you can also see in the visualizer).

                        It is not only "Equipping" that Finish State (and the exact logic shown) is used for - it's used for several and works for all other states. However, if I tell it to ignore the "Equipping" state in the logic that calls Finish State and instead use the same logic with a Set State node in "On Update Equipping" it works fine (but only with a Set State node, if I use Finish State here it will also crash in the same place). Which means the Finish State node is somehow related to it.

                        Debugging "Finish State" shows that it calls SetState successfully. Passes the correct StateID to Enter(). Calls all the On Begin State delegates, meanwhile the STATE TMap is all still valid (no invalid Equipping state). Then the update tick crashes it.





                        Comment


                          Oooohhh ok...
                          Then the problem is possible to be your "(Mixed Flags)" values in there.

                          Clean up all "Rules" flags from all defaults links and please tell me if this problem still happens...
                          One of those Rules might have invalidated the State object by the time that event in Update is reach.

                          For some reason Unreal Engine is automatically applying first Rule value (create state)... It shouldn't do that at all.
                          Flags should be clean by default.

                          ___

                          The team who requested those flags aren't even using them anymore, so I will probably just remove them to reduce complexity.
                          Last edited by BrUnO XaVIeR; 07-05-2018, 06:32 AM.
                          | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

                          Comment


                            Originally posted by BrUnO XaVIeR View Post
                            Oooohhh ok...
                            Then the problem is possible to be your "(Mixed Flags)" values in there.

                            Clean up all "Rules" flags from all defaults links and please tell me if this problem still happens...
                            One of those Rules might have invalidated the State object by the time that event in Update is reach.

                            For some reason Unreal Engine is automatically applying first Rule value (create state)... It shouldn't do that at all.
                            Flags should be clean by default.

                            ___

                            The team who requested those flags aren't even using them anymore, so I will probably just remove them to reduce complexity.
                            Thank you!! Removing the flags fixed it. I didn't even take note of them Definitely very destructive that they're on by default and as you say, blueprints sometimes have weird defaults that you can't seem to get rid of especially where structs are concerned.

                            Comment


                              Yeah, this is new...
                              Unreal Engine didn't do this on earlier versions. by default the flags were simply (none).
                              Anyway I will just remove those flags, they were implemented before them async nodes existed. (they do the same thing anyway)
                              | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

                              Comment


                                Thanks again for your wonderful support

                                Comment

                                Working...
                                X