Announcement

Collapse
No announcement yet.

What's the different between a normal local macro var between the persistent one ?

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

    What's the different between a normal local macro var between the persistent one ?

    If this one doe's it's job well.
    Click image for larger version

Name:	FlipFlopReady.png
Views:	1
Size:	125.9 KB
ID:	1140512
    What is the meaning of this one? :
    Click image for larger version

Name:	PersistentBool.PNG
Views:	1
Size:	11.8 KB
ID:	1140513
    Check out my game OldSchool Nightmare : http://www.indiedb.com/games/oldschool-nightmare

    #2
    Anyone ?...
    Check out my game OldSchool Nightmare : http://www.indiedb.com/games/oldschool-nightmare

    Comment


      #3
      A persistent local bool retains its value between executions of the macro. A normal local bool does not; it re-defaults every time the macro is triggered again.

      As an example, suppose you have a node which performs an output once every 3 inputs; you would need a PERSISTENT local Int to keep count, otherwise it would always reset to 1 every time the input was triggered. On the other hand, a regular local Int would be good for a "do 3 times" node, since each input execution would need to refresh the count used to determine how many outputs had been fired.

      EDIT: Wait, I must be wrong, because I would think a flip flop node would need a persistent local bool...

      Comment


        #4
        Originally posted by RhythmScript View Post
        EDIT: Wait, I must be wrong, because I would think a flip flop node would need a persistent local bool...
        Exactly, the flip flop node made me wonder, i hope someone can shed some light on it.
        Check out my game OldSchool Nightmare : http://www.indiedb.com/games/oldschool-nightmare

        Comment


          #5
          There got to be a reason this is there right?... For the love of Epic can someone explain it to me ? :|
          Check out my game OldSchool Nightmare : http://www.indiedb.com/games/oldschool-nightmare

          Comment


            #6
            What I would think is that peristance in this sense has to do with saving and loading state of the level rather then persistance between script turns.
            A local variable is local for that script, but will it be reset on each start, or is the function and the variable itself somehow keept in scope?

            That is what I am thinking about.

            Comment


              #7
              Originally posted by TheSpaceMan View Post
              What I would think is that peristance in this sense has to do with saving and loading state of the level rather then persistance between script turns.
              A local variable is local for that script, but will it be reset on each start, or is the function and the variable itself somehow keept in scope?

              That is what I am thinking about.
              Sounds logical. but i would really like some from epic to approve it. maybe it can help us and this is a shame that epic worked to add this feature and we don't use it because we don't know what it is :\
              Check out my game OldSchool Nightmare : http://www.indiedb.com/games/oldschool-nightmare

              Comment


                #8
                So I dug into this more deeply, not so hard since we got source access.

                Simply put, when the engine is generating names for variables, for the editor, if the object got the flag bIsPersistent set and is a variable, the editor will append the name Persistent to the beginning of the name.
                Further if we look at the comment for bIsPersistent, it states as follows

                /** Whether or not this variable should be flagged with CPF_SaveGame, and inherit its name from the GUID of the macro that that gave rise to it */

                Or simply put, should we give the variable a unique name and persist it with the save data when we save the game?

                In most cases for a FlipFlop I guess this is ok, we don't care if it's in a flip state or a flop state, we only care that it change state between calls.

                Someone from Epic could confirm this in more detail, but I see no reason for the source comments to lie about this.

                Comment


                  #9
                  Originally posted by TheSpaceMan View Post
                  So I dug into this more deeply, not so hard since we got source access.

                  Simply put, when the engine is generating names for variables, for the editor, if the object got the flag bIsPersistent set and is a variable, the editor will append the name Persistent to the beginning of the name.
                  Further if we look at the comment for bIsPersistent, it states as follows

                  /** Whether or not this variable should be flagged with CPF_SaveGame, and inherit its name from the GUID of the macro that that gave rise to it */

                  Or simply put, should we give the variable a unique name and persist it with the save data when we save the game?

                  In most cases for a FlipFlop I guess this is ok, we don't care if it's in a flip state or a flop state, we only care that it change state between calls.

                  Someone from Epic could confirm this in more detail, but I see no reason for the source comments to lie about this.
                  Thanks ! I'm sure a lot of users will found that information useful!
                  Check out my game OldSchool Nightmare : http://www.indiedb.com/games/oldschool-nightmare

                  Comment


                    #10
                    Just want to say thanks TheSpaceMan for investigating!

                    Comment

                    Working...
                    X