Huge delay for some players when editing an active lighting effect

[Sterno]

We've noticed in my game that the "flicker" effect on torch really killed performance for some players as they moved around the map. I'd edited the torches in my game to remove it, but one player still had an older copy of a torch with the flicker effect on it and equipped it.

Editing the effect string on his equipped torch, I started deleting the "flicker 25" part of his torch effect string. With each character as I backspaced, the effect was removing and reapplying (one character shorter each time). On my end it was a little slow but no big deal as I backspaced those 10 characters. Same deal for 2 of my 5 players. The other three players, though, got delayed hard and their FGU didn't catch up with what was going on for about 2 minutes. We all just sort of sat there and waiting to do anything else until their systems had caught up.

Lesson learned, I won't edit an active lighting effect like that, but I wanted to post this since it seemed insanely slow for a few people.

I was recording the session and the problem starts around here (and for the next 2-3 minutes): https://www.youtube.com/watch?v=pL00J_Ydf9E&t=6870s

[Zarestia]

The most sane "solution" would probably be to only update the effects of an equipped item either with a re-equip or when closing the details window (or loosing focus). Though I don't use the 2E ruleset, I use the advanced effect extension and when editing any item effects I always unequip them first (just to not clutter the chat like a madman, haven't done this with torches yet).

[JohnD]

The most sane solution would be additional engine optimization IMO.

[Zarestia]

The most sane solution would be additional engine optimization IMO.

You just can't slap "engine optimization" on everything. Some "not considered" code in a ruelset or extension can still break or slow down things, even if it's the best engine in the world. Either way, this can only be handled by the 2e ruleset dev and/or SW.

[JohnD]

I see lots of reports of performance problems that have nothing to do with a particular ruleset but OK.

At this point it probably isn't worth even mentioning the issue since I guess.

[dogfisc]

If the effect is in the combat tracker, you can turn it off, edit the string, and turn it back on.

[Sterno]

To be clear guys, I understand how to work around and avoid the problem in the future. I just though it odd that whatever it was doing (presumably removing a lighting effect, then re-adding one 1 character shorter 10 times) was so slow as to cause 2-3 minutes of delay for some of my players before they caught up.

A few seconds, sure. 2+ minutes seems weirdly slow. Just wanted to report it in case investigating this scenario can generate info on how to improve the overall performance with lighting... if indeed it's related (and it does seem to be... I've done this with other non-lighting effects in the past and not experienced the same huge delay).

[LordEntrails]

Yep, FGU is trying t update real-time after each character stroke. Don't think that is desired. But need to make sure it updates intuitive/as expected. (i.e one could say when enter is hit, but some users might not hit enter etc)

[Moon Wizard]

This is a bit by design. We had multiple issues where people would edit effects; but not tab out of the field to allow the updates to save. Thus, the effects fields are dynamically adjusting the database as you edit them. Unfortunately, for VISION/LIGHT effects; this means that the actual linked token vision/light values are being adjusted every time a character is adjusted.

You should avoid editing LIGHT/VISION effects directly in CT; and apply from Effects list or Presets.

I could change it back to a wait for lose focus to update database scenario; but that's how we got here in the first place...

Regards,
JPG

[LordEntrails]

Would it be reasonable to add delay such as 2 or 3 seconds before re-evaluating? Don't know, not an easy challenge.