-
September 15th, 2020, 17:12 #1
- Join Date
- May 2020
- Posts
- 53
Anyway around "recursive node event" error when actually looking for some recursion?
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?
-
September 15th, 2020, 17:19 #2
Supreme Deity
- Join Date
- Mar 2007
- Posts
- 20,554
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
-
September 16th, 2020, 16:57 #3
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:
Code:-- 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;
Code:-- 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
Code:bDO_NOT_PROCESS_LIST = true; -- every exit from this function must set this to false.
Then where the recursion has to be guarded I do something like this...
Code:-- prevent recursive calls if bDO_NOT_PROCESS_LIST then --Debug.console(User.getUsername() .. "(" .. tostring(User.isHost()) .. ") -> manager_polymorphism:ValidateAndUpdateListFromDB skipping"); return false; end
Free(Forums/Forge) Extension(FGU 5E):
Paid (Forge) Extension(FGU 5E):
-
September 20th, 2020, 16:51 #4
- Join Date
- May 2020
- Posts
- 53
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...Last edited by MadNomadGM; September 20th, 2020 at 17:55.
-
September 20th, 2020, 18:08 #5Free(Forums/Forge) Extension(FGU 5E):
Paid (Forge) Extension(FGU 5E):
-
September 20th, 2020, 19:03 #6
- Join Date
- May 2020
- Posts
- 53
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.
-
September 20th, 2020, 19:30 #7
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.Free(Forums/Forge) Extension(FGU 5E):
Paid (Forge) Extension(FGU 5E):
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks