Announcement

Collapse
No announcement yet.

GC FSM - Event-driven, hierarchical finite state machines in blueprint

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

    Thanks a lot gamecentric , appreciate your efforts for fixing this

    Comment


      gamecentric Is it possible to control the tick interval of GC States?

      Comment


        Originally posted by Street Mage View Post
        gamecentric Is it possible to control the tick interval of GC States?
        What kind of control would like to have?
        Gamecentric

        Comment


          Originally posted by gamecentric View Post

          What kind of control would like to have?
          Like how actors and components can set the tick interval

          Comment


            Currently that's not possible. It's not technically impossible to implement, but I am using the tick also to ensure that the FSM are properly disposed as soon as the context object is destroyed. Introducing a tick interval might create a delay in the destruction of the FSM. I will add this feaure to my TODO list.
            Gamecentric

            Comment


              Version 1.1 of GC FSM is now available
              Playing ascendant challenge location and Stream Netflix On Switch

              Comment


                Originally posted by hoir View Post
                Version 1.1 of GC FSM is now available
                Actually, version 1.7.7 of GC FSM went online just yesterday.
                Gamecentric

                Comment


                  Hello,
                  I'm coming here for a design problem and I was wondering if you already encountered that problem before and know how to solve it.

                  Here is what my FSM looks like right now:
                  [0_fsm_is_opened.PNG]

                  What I want, as shown on the screen, is to avoid having to trigger BOTH "IsOpened" and "Battle|Call|Map|Alert" events to actually go into one of the OpenedFSM states.

                  I have found something that works, but I'm not sure it's the best way to handle this.
                  I'll demonstrate it for the Opened_Battle state only, as it works the same for the other ones.

                  I added a FName ExitEvent variable to my FSM, and changed the "IsOpened" transition to "Battle" for the demo:
                  [1_fsm_battle.PNG]

                  In BP_ADFSMS_Closed, OnExit, I'm now setting that ExitEvent variable:
                  [2_state_closed.PNG]

                  In BP_ADFSMS_Opened_Idle, OnEnter, I trigger the event a second time using that variable. Then I reset the variable.
                  [3_state_opened_idle.PNG]

                  It works: I now just have to trigger the event "Battle" to do Closed->Opened->Battle in one shot.

                  Do you have a better idea?
                  Thanks for the great plugin anyway!
                  Attached Files
                  Last edited by raboulave; 10-30-2020, 01:48 PM.

                  Comment


                    Can you do something like this?



                    Attached Files

                    Comment


                      Hi DsyD ,
                      Thanks for your suggestion
                      However, that would not be very convenient as we will adding Event pins to the OpenedFSM.
                      As you can see in the first screenshot I've attached, we already have an additional "End Match" pin that leads to a FSM Stop node.
                      That would force us to add an "End Match" pin to every Opened State (Battle, Call, Map, Alert), and do the same every time we will add a pin to the global OpenedFSM.
                      This is not very maintainable, I'm afraid!

                      Comment


                        Hi raboulave, yours is a very interesting example. Your approach definitely works. I agree that it's a bit cumbersome to have to save the event in a variable to re-trigger it in the submachine. It would be nicer to have a way to "inject" a past event into a new submachine state, but unfortunately that's not currently supported. Good food for thought, though. BTW, why do you need to cast the context variabile? You should be able to just declare the variable of the correct type. Unless you are going to re-use the state class for different classes, in which case you are probably using a base class...
                        Gamecentric

                        Comment


                          FSM is great, however those returning pins and wires (from right side of graph to the left) are real pita. Something should be done about this.

                          Comment


                            Thanks gamecentric for your answer We'll keep that way of dealing with re-triggering events then, until eventually you come up with something fancier.
                            As for the cast, this is simply because the ExitEvent variable was on the BP but the Context variable is of a custom FSM base class and is declared in C++, but thanks for having looked at it so carefully!

                            Comment


                              Originally posted by raboulave View Post
                              Hi DsyD ,
                              Thanks for your suggestion
                              However, that would not be very convenient as we will adding Event pins to the OpenedFSM.
                              As you can see in the first screenshot I've attached, we already have an additional "End Match" pin that leads to a FSM Stop node.
                              That would force us to add an "End Match" pin to every Opened State (Battle, Call, Map, Alert), and do the same every time we will add a pin to the global OpenedFSM.
                              This is not very maintainable, I'm afraid!
                              I see, I didn't know you wanted to have more than those four "Opened" sub-states. In that case I think it makes sense to have Opened and Closed states.

                              Is it the case that when "Opened," every sub-state (Battle/Call/Map/Alert etc.) is reachable from every other sub-state? In that case, it might be easier to just store the sub-state as a variable, like an enum. In a typical (deterministic) FSM, the next state depends on the input and the current state, but if every state can be reached from every other state, then the next state only depends on the input. So you only need to observe the input to determine what actions (side-effects like OnEnter) to execute.

                              Comment


                                Thanks, that's another good suggestion.
                                We won't use that now though, since the project is in a very WIP state and we still don't know how that object will be used.

                                Comment

                                Working...
                                X