Anyway around "recursive node event" error when actually looking for some recursion?

[MadNomadGM]

OK I realize this is probably an obscure case, but I have been struggling for hours trying to find a way around the Script Warning that detects recurisve functions. You built it TOO GOOD! LOL

I'm using an onUpdate handler to watch for an update to a string field, and when updated, check for a pattern, if pattern is present, edit that field. Kind of like an autocorrect. I have checks in place to ensure it doesn't actually cause mass recursion. Like disabling handler and a variable check to make sure an edit actually took place. But it doesn't seem to factor those into it.

I also tried creating secondary handlers to trigger subsequent actions off of that to edit the original trigger item, but it catches that too.

It seems there is no way to edit the source of item that triggered the original onUpdate handler event, which is what I need in this case.

Is there some clever trick I'm not thinking of?

[Moon Wizard]

The problem is that any time that an onUpdate function ends up calling itself; that is basically an indication of an endless loop condition and there is no way to detect whether it will be an endless loop or not. So, you have to write your code to avoid update loops.

Try looking at the common/scripts/button_record_isidentified.lua file in CoreRPG for an example where I used a blocking variable (bUpdating) to prevent update functions from being called in loops.

Regards,
JPG

[SilentRuin]

OK I realize this is probably an obscure case, but I have been struggling for hours trying to find a way around the Script Warning that detects recurisve functions. You built it TOO GOOD! LOL

I'm using an onUpdate handler to watch for an update to a string field, and when updated, check for a pattern, if pattern is present, edit that field. Kind of like an autocorrect. I have checks in place to ensure it doesn't actually cause mass recursion. Like disabling handler and a variable check to make sure an edit actually took place. But it doesn't seem to factor those into it.

I also tried creating secondary handlers to trigger subsequent actions off of that to edit the original trigger item, but it catches that too.

It seems there is no way to edit the source of item that triggered the original onUpdate handler event, which is what I need in this case.

Is there some clever trick I'm not thinking of?

I used global flags in my lua manager code for the extension. Ugly, but if your careful it works. For example in my polymorphism extension I declare the global flags:

-- We need to make sure we do not spam effects processing through different unnecessary calls
local bDO_NOT_PROCESS_EFFECTS = false;

-- We need to make sure we do not process targets when already processing targets. 
local bDO_NOT_PROCESS_TARGETS = false;

-- We need to make sure we do not process targets when already processing targets. 
local bDO_NOT_PROCESS_LIST = false;

Then during certain "reset" areas of the code I will insure they are not left set by something going wrong (as that can really mess you up so just a safety measure) by calling the below function...

-- if some piece of code crashes (even stuff not ours) we can get stuck with these flags set - so occasionally we make sure they are all off. 
function ClearInternalFlags()
	--Debug.console(User.getUsername() .. "(" .. tostring(User.isHost()) .. ") -> manager_polymorphism:ClearInternalFlags called");
	bDO_NOT_PROCESS_EFFECTS = false;
	bDO_NOT_PROCESS_TARGETS = false;
	bDO_NOT_PROCESS_LIST = false;
end

Then when I actually enter one of the things that might trigger a recursive call I do something like this....

	bDO_NOT_PROCESS_LIST = true; -- every exit from this function must set this to false.

And make ABSOLUTELY SURE there is no way out of the code without setting it back to false.

Then where the recursion has to be guarded I do something like this...

	-- prevent recursive calls
	if bDO_NOT_PROCESS_LIST then 
		--Debug.console(User.getUsername() .. "(" .. tostring(User.isHost()) .. ") -> manager_polymorphism:ValidateAndUpdateListFromDB skipping");
		return false;
	end

Now if someone can answer my radial menu map issue I'll feel complete

[MadNomadGM]

The problem is that any time that an onUpdate function ends up calling itself; that is basically an indication of an endless loop condition and there is no way to detect whether it will be an endless loop or not. So, you have to write your code to avoid update loops.

Try looking at the common/scripts/button_record_isidentified.lua file in CoreRPG for an example where I used a blocking variable (bUpdating) to prevent update functions from being called in loops.

Regards,
JPG

Thanks, MoonWizard, that was super helpful.
SilentRuin, thanks also for the input. I didn't fully break down your example, since I found the answer in MoonwIzard's example, but I'm sure it would have helped.

UPDATE: Actually, I guess that didn't work. Used the bUpdating approach, but still terminates recursive event. Think I will have to throw in towel on this one. It doesn't seem like anything the code can do can get around this because if an onUpdate handler action calls a function, and that function later does something that triggers the handler, which is the action i want because i want to make an update upon noticing an update, even if i have a hard stop in there with bUpdating, it still sees it as a recursive event.

Although it seems to be working when I am editing an already existing node, its just on the creation of a new one I have the termination. Which is odd. I'm sure that is the clue to solving this. Maybe with some more coffee...

[SilentRuin]

Thanks, MoonWizard, that was super helpful.
SilentRuin, thanks also for the input. I didn't fully break down your example, since I found the answer in MoonwIzard's example, but I'm sure it would have helped.

UPDATE: Actually, I guess that didn't work. Used the bUpdating approach, but still terminates recursive event. Think I will have to throw in towel on this one. It doesn't seem like anything the code can do can get around this because if an onUpdate handler action calls a function, and that function later does something that triggers the handler, which is the action i want because i want to make an update upon noticing an update, even if i have a hard stop in there with bUpdating, it still sees it as a recursive event.

Although it seems to be working when I am editing an already existing node, its just on the creation of a new one I have the termination. Which is odd. I'm sure that is the clue to solving this. Maybe with some more coffee...

My way will work - but it requires one to do it

I had the same issues and that is how I resolved them - ugly - but the only way in this environment that I could find.

[MadNomadGM]

Maybe, but I guess I'm not understanding what you are doing at all. Are you using event handlers? I don't see any reference to them.
I think I've tracked down the source of my issue and why MoonWizards bUpdatign method doesnt work for me. It's because the initial onUpdate() call that is supposed to handle the initial function call, before applying the onUpdate handlers, doesn't work in my case because when the effect node is created, it does not actually have a label value, which is what I am manipulating. So when I call onUpdate initially I am sending it nothing. Then it applies the onUpdate handler and the onUpdate triggers on the initial creation of the label value. I would need some way to only apply the handler after the label value is not nil.

[SilentRuin]

Maybe, but I guess I'm not understanding what you are doing at all. Are you using event handlers? I don't see any reference to them.
I think I've tracked down the source of my issue and why MoonWizards bUpdatign method doesnt work for me. It's because the initial onUpdate() call that is supposed to handle the initial function call, before applying the onUpdate handlers, doesn't work in my case because when the effect node is created, it does not actually have a label value, which is what I am manipulating. So when I call onUpdate initially I am sending it nothing. Then it applies the onUpdate handler and the onUpdate triggers on the initial creation of the label value. I would need some way to only apply the handler after the label value is not nil.

I was describing how to solve any recursive call issue as you originally described. What you are describing is something slightly different. In my case, it was a complex set of handlers triggering in different scenarios and in some of those scenarios setValue() would trigger some other handler and get a recursive call into it - which I would not want to process (as it was already processing). The definition of a recursive call.

If I understand you correctly, I'd be overriding the function doing the handler logic and make it guard against processing the nil value. Depending on where it was I'd be replacing the function itself in my manager with a save<functionname> to call the original logic if I can while processing my particular process before or after that call - if function was in a global manager. If the code is tacked on to some .xml logic then I do a merge="join" on that and replace the script - with a bunch of super. calls to original where I'm not doing anything particular to my needs. Last call and one I least like is actually outright replacing the code entirely with my own version. I always avoid that if at all possible as it stomps other people potentially using the same code.