Infinite loop in windowlist?

[Moon Wizard]

I have a situation where a windowlist is getting into some sort of infinite creation/deletion loop.

This is using the 4E_JPG ruleset. I am sharing the combattracker node with the client.

When the effects lists are open on the host side and you're running a combat, sometimes an extra effect entry will appear which is in an infinite loop (deleting/creating). The steps to recreate the issue appear to be variable, as I haven't been able to nail down a set of steps every time. Though, I can usually get it to happen consistently with all the effects open.

All access to effects are removed on the client. However, closing the client will stop the loop.

This looks like a variation on the infinite loop problem I saw when initially sharing the CT in the d20_JPG ruleset. However, I was never able to pinpoint the issue. I just ended up building a bunch of special templates to try to avoid.

Thanks,
JPG

[Foen]

I'm not sure about this issue (it is hard to pin down) but I suspect it might be to do with the variable delay between a node changing and the various observers (host/clients) being notified of the change. A bit like a race condition, perhaps?

I am starting to give up on shared access to database nodes - it doesn't seem very stable unless it is quite basic (like only the host and one client).

Stuart

[Moon Wizard]

It's such a key component of my ruleset that I can't avoid sharing data. I agree that simple sharing works the best. It's the lists that seem to have the problem, not the individual fields/nodes.

Cheers,
JPG

[Foen]

Specifically with effects nodes, I think I had some success wrapping the event handlers with a flag which suspended one event processing while another was still being handled. I'll take a look at my code and get back to you.

Stuart

[Foen]

Hi JPG

I've had a quick look at the Foundation ruleset (which was suffering with the same problem) and it arose because the checkForEmpty function was being called more than once, I think.

I changed the function explicitly to prevent new windows being created by wrapping the createWindow call in disablecheck statements:


function checkForEmpty()
if not disablecheck then
local found = false;
for k, v in ipairs(getWindows()) do
if v.label.getValue() == "" then
found = true;
break;
end
end
if not found then
disablecheck = true;
local w = createWindow();
disablecheck = false;
end
end
end

I'm not sure if that is also your problem, but it seemed to do the trick for me.

Stuart