[extension] Spell Tokens Extension

[Weissrolf]

That being said, the shape unfortunately does not match Pathfinder shapes, so it's not as useful to us as I hoped it would be. But even in DnD 5e only those square should count as target that are covered more than half by a circle.

Currently just a tiny portion covering a foe seems to count as being in target. I recognize that this is more abot FG shapes than your extension, though.

Here is an example:


PF2 burst shape as white lines for comparison:

[bratch9]

That being said, the shape unfortunately does not match Pathfinder shapes, so it's not as useful to us as I hoped it would be. But even in DnD 5e only those square should count as target that are covered more than half by a circle.

Currently just a tiny portion covering a foe seems to count as being in target. I recognize that this is more abot FG shapes than your extension, though.

Here is an example:


PF2 burst shape as white lines for comparison:

Well it process by a number of sample points against the shape. I can have it include the edge of the (n)pc size token which will do the then you shown.. or I can have it sample one half square in from the edge. But if you do that you can get 'chunks' of the (n)pc very clearly into the spell token shape.. and people will just say it should get hit by that. ( I'll never win, but I might add an 'option' to enable it. )

The DnD side to 'squares', is do you count fireball radius as a 'square' or a 'circle', because depending on if you count diagonals as 5ft or use the alternative 5ft/10ft cost it changes the shape of these things.

Its mainly a total mess, and since the most popular spell token pack uses round, that is what I've set up.

Basically the spell token shape is 'edge exclusive' ( ie.. I check for < r and not <= r for a circle. ), then that makes the (n)pc tokens should be 'edge inclusive' to match up. Basically a fireball will not 'hit' a (n)pc token that is just on its radius. But due to how the grid works you do get these cases that the corner is clearly in the radius so should be selected, when not considering the grid so should not.

I could make the spell token shape 'edge inclusive' and then using an inclusive but half grid in area on the (n)pc which might work out better.

Or If we had proper 'draw' ability, we could 'cast' the shape into the correct grid squares centres and mark it... But then you would need masses of different spell tokens to cope with the different shapes that the detection would need.

At the end of the day we have limited ability to do things.

I can make the detection more 'square', but it would require me simulating out the shape and detecting a pixel grid for the squares and then cross bit map checking that with other hit boxes.. and lua is just rubbish at that sort of stuff.. ( I'm already surprised that the amount I have to calculate to make this work is not been flagged as slowing down the games. )

The reality is it's going to be a compromise, with the limited access to do things and no access to the line of sight data. To do a proper job requires it to be done at the developer side.

All we can hope to do is the best job, make it clear that the silly GM spell template management method is not suitable, and try and get them to do the correct job with full masking support etc.

Or you could just reduce the spell token size with a slight increase on the 'per 5ft' to pull the radius in a little as a compromise.

[bratch9]

I made some performance tests generating a pixel grid lookup for spell tokens to then use to check target selection form.

On a 200x200 ft spell token ( 40x40 grid squares ), it takes about 30 ms to generate the lookup table grid array.

I suspect the time to call the 'select' token function and the network packets to reflect selection changes around the clients/host, that the network ping/delay will be larger than the 30ms code.

I was expecting the lua to me much slower, in the half second cost level, which you might have noticed. But I'm glad the lua is quick or is JIT compiled to be quick.

-pete

[bratch9]

That being said, the shape unfortunately does not match Pathfinder shapes, so it's not as useful to us as I hoped it would be. But even in DnD 5e only those square should count as target that are covered more than half by a circle.

Currently just a tiny portion covering a foe seems to count as being in target. I recognize that this is more abot FG shapes than your extension, though.

Here is an example:


PF2 burst shape as white lines for comparison:

My pixel grid tests, allow me to configure the 'per 5ft' of a fireball spell token to generate the PF2 burst square grid selection.. Using a pixel grid sample method. It might not work for all cones/lines as I did not check these.

But I'd probably need to include an extra 'collision per 5ft' in the spell token configuration, so you can mark the graphics side correct and tweak the collision sample side to get the required results.

For the 5e fireball 70 pixel per 5ft spell token at 20ft radius...

setting it to 50 pixels per 5ft got a matching square selection for 30ft burst centred on a gird cross point.
setting it to 74 pixels per 5ft got a matching square selection for 20ft burst centred on a gird cross point.
setting it to 98 pixels per 5ft got a matching square selection for 15ft burst centred on a gird cross point.
setting it to 140 pixels per 5ft got a matching square selection for 10ft burst centred on a gird cross point.
setting it to 280 pixels per 5ft got a matching square selection for 5ft burst centred on a gird cross point.

On the graphic side, these looked a little 'small', as in the 30ft burst look a more like a 26ft spell token... hence the suggestion I might add a collision per 5ft. So 70/74 per 5ft for graphics/collision to get the 20ft burst square selection.

(NOTE: these settings might work of for the current non pixel grid version, as long as you have the spell token on the cross point.. )

[Weissrolf]

Looking forward to test these.

By the way, no JIT compiler in Lua 5.1 and the third party 5.1 JIT compiler developed by a third party does not seem to be compatible with FG. Lua 5.4 promises performance improvements, but again, not compatible with FG.

[bratch9]

Looking forward to test these.

By the way, no JIT compiler in Lua 5.1 and the third party 5.1 JIT compiler developed by a third party does not seem to be compatible with FG. Lua 5.4 promises performance improvements, but again, not compatible with FG.

I'm not sure what is in the actual compiled lua 5.1 dll provided with FGU, I did not do checks to see if its a standard or custom lua language build. ( And if things are not compatible, then maybe they have some custom changes that they make use of. Which might delay them upgrading to newer lua versions. )

The performance was quicker than I was expecting, considering how 'slow' lots of things in FGU are from a user point of view. Just the pure lag of opening a character power page with list of spells gets super slow even with a hand full of spell.

I do pre-transform grid point and direction vectors into the spell token space, so I dont have to keep doing sin/cos rotation code, so pre-doing some work probably helped keep the main math work in faster linear math space. ( Probably introduces a small amount of math rounding errors that get larger with token size. )

But I was impressed with the lua performance of this code, even more if its not getting into a JIT, but I guess the math cos/sin function drop out of lua to do that work. So it probably has some pure hardware performance for things that might take a bit of time.


On a performance note in general, ( I know talking into the wind with this sort of stuff... )

I do see some performance issues in FGU to do with importing the spell tokens xml file, which on the host gets one call back caused by the database changes when it caches the spell token database into a lua table for quick access. On the client they get hundreds of refresh callbacks, as each database line arrives over the network, causing many database update/create callbacks into the spell token refresh cache table code. Which is getting bigger as it gets each part of the list. So will be re-doing more and more work each refresh. But I dont see a way around this.

But these sorts of callbacks happen in a lot of locations, I've seen many update callbacks going off with my other spell damage extension when it makes updates into the power part of the character sheet. It does way more that a quick single refresh as the system re-draws and updates the power structure and window layout.

Maybe these sorts of things will get looked at by the dev team at some point, because the lua seems quick, but the layout of a new window can lag a lot. ( I know its got text characters to render and cache into texture atlas to build up string layouts and sizes that can push window layout around while it does all that initial work. ) But web browsers do a lot of this and they never seem to lag for seconds when doing layout.

FG could feel so much better with some of these issues resolved, when you open a new window on a client and it requests it from the host and stalls all the connected clients.. Even more so when a player logs in and joins. Just a few quality of life bits would make the user experience so much better.

[Weissrolf]

From a users' point of view it is hard to tell whether the most glaring performance issues are Lua based or just bad coding. I always like to point to the nearly game-breaking performance dip when PF2's Feats by Trait list is opened (or worse: moved). It's just a sorted list of text in a window, Windows 3.11 on a DX286 could handle that nearly 28 years back (Excel was a different beast, though).

Unfortunately we cannot just throw money at the problem, because on top of being single-threaded FGU's Lua (same with WoW's) does not seem to benefit from higher CPU IPC or cache sizes. Loading a campaign takes about the same time on my 5900X as on my 9900K. Some benchmarks out there seem to suggest that this is a general limit of Lua, clock-rates are king.

[bratch9]

From a users' point of view it is hard to tell whether the most glaring performance issues are Lua based or just bad coding. I always like to point to the nearly game-breaking performance dip when PF2's Feats by Trait list is opened (or worse: moved). It's just a sorted list of text in a window, Windows 3.11 on a DX286 could handle that nearly 18 years back (Excel was a different beast, though).

Unfortunately we cannot just throw money at the problem, because on top of being single-threaded FGU's Lua (same with WoW's) does not seem to benefit from higher CPU IPC or cache sizes. Loading a campaign takes about the same time on my 5900X as on my 9900K. Some benchmarks out there seem to suggest that this is a general limit of Lua, clock-rates are king.

Yep the single thread is a pain, loading a campaign takes for ever.

If you look at the pure time to load the some thing like the players handbook.. You will find i takes about double the time on FGU as it does on FGC. The performance has gone backwards with the new version.

[bratch9]

is it me, or does the 4.1.6 build now place token in a near but still not correct location ? ( Even with my ui scale set to 100, as this should be sorted now, it seems off... maybe the grid offset it not been taken into account. )

-pete

[bratch9]

v6.2 Adjusted code for changes in release 4.1.6, added usage of 'Interface.getUIScale()' to get the UI scale factor and removed the temp option that was used to control this previously.