Multiplayer issue: Beams are showing to players with a delay

[Shad000w]

To Reproduce

module: beamtesting.zip

Run the module via nwserver (doesn't matter if windows or linux) and log onto it with client, then use the floor lever to run the beam animation.

Specifics

• OS Windows, Linux (didn't test mac)
• Game build: observer in build .34 and .28
• Distro platform: irrelevant
• Content overrides?: of course not
• Regression?: yes, don't know which build introduced it the first time

If needed, describe the bug

Beams are showing with a delay in multiplayer, at least if there are multiple of them going to be rendered. The issue can be easily seen on this video: https://youtu.be/xl_3S4hw5Hc

As you can see in 1.69 all beams appeared almost simultaneously, in EE they are appearing one by one and some aren't even rendered at all because they were delayed by engine for longer than was their uptime.

This is not happening in singleplayer, although there are small differences between 1.69 and EE as well. Namely in 1.69 all beams will appear instantly without any kind of delay at all (in the video from 1.69 multiplayer you can see the beams are rendered in four "batches" and that is basically how it looks in EE singleplayer, but in 1.69 singleplayer all beams are rendered in one go.

[Baaleos]

I can confirm a similar behaviour which is particularly visible when using this script package. https://neverwintervault.org/project/nwn1/script/psc-pentagrams-summoning-circles-v145-real-time-3d-geometry

This community package is used to create geometric shapes using placeables and visual effects. It worked perfectly on 1.69 Since moving to EE - it looks like there is some sort of throttling going on which is preventing some of the visuals from rendering in time.

Note - this works fine on single player.

I've tested this across various different versions of client and server.

8193.19 - singleplayer - entire animation plays - acceptable

• multiplayer - animation is glitchy / unreliable

8193.34 - same results as above

8193.35 (preview) - singleplayer is actually super fast - almost to the point of appearing bugged - it was never that fast on 1.69 multiplayer

• multiplayer - possibly worse than 8193.34

draw_test_19.zip draw_test_34.zip draw_test_35.zip

To use the provided test modules Start module - either singleplayer or multiplayer (my tests were done with the client acting as server in New Lan game - it reproduces the issue accurately enough)

once logged in - use console to enter DebugMode 1 then in console type runscript draw_circle

When the script runs on multiplayer, it typically will draw like this: https://media.giphy.com/media/KzZIjIMn1pInLv7fLk/giphy.gif

On singleplayer in version 8193.35 - it appears super fast, like so

[Baaleos]

8193.35 introduces the following : server.tweaks.message-limit

Which has a default value of 200 When I increased this from 200 to 4000 - my multiplayer tests revealed better results

Message limit 200 Message limit 4000

@Shad000w - maybe you could test your module on 8193.35 and see if the message limit solves it for you?

[Shad000w]

@Shad000w - maybe you could test your module on 8193.35 and see if the message limit solves it for you?

Hi I just noticed this. Well I don't know how. I heard about 35 already, but don't know where to get it. But I provided the repro module I used in my initial bug report so maybe you can test it for me?

If the message limits fixes this that would be great, but won't it be for a price in efficiency elsewhere?

[Baaleos]

On steam- you can enter the beta code ‘previewpreview’ to get access to .35 version. EE introduces more information to objects and placeables- such as transform information - which was not required in 1.69. So it stands to reason that things that were ok on 1.69 might need a little extra added to the message limit on EE - to maintain the same level of performance. There is talk that this might adversely affect things like Ai and pathfinding- but it will be a case for each server owner to benchmark and find the sweet spot I imagine.