Download

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

If this one doe’s it’s job well.
FlipFlopReady.png
What is the meaning of this one? :
PersistentBool.PNG

Anyone ?..

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…

Exactly, the flip flop node made me wonder, i hope someone can shed some light on it.

There got to be a reason this is there right?.. For the love of Epic can someone explain it to me ? :expressionless:

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 :\

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!

Just want to say thanks TheSpaceMan for investigating!