MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000283Zandronum[All Projects] Bugpublic2011-02-07 13:532018-09-30 19:52
ReporterStrikerMan780 
Assigned ToTorr Samaho 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformPCOSWindows 7OS VersionUltimate x64
Product Version98d 
Target VersionFixed in Version1.0 
Summary0000283: Lightning strikes cause massive traffic spikes
DescriptionIt seems whenever lightning strikes occur in a large outdoor map with hundreds or thousands of sectors, it causes an immense amount of network traffic. I'm beginning to believe this is due to the fact that the light flash is being handled server side and the server is sending info to every player for the light changes in every sector every tic that the flash begins to fade.

Perhaps could the plays be notified when a lightning strike happens, but have the client handle the flash instead?
Steps To ReproduceIn SMMP, this is pretty easy to reproduce. In the HQ map, when the stormy night approaches (Takes about 6 minutes to happen) Pings of players end up spiking beyond 300+ if there are lightning strikes in rapid succession.
Additional InformationSMMP can be downloaded here:'https://docs.google.com/leaf?id=0B5wxdPnZcqXjZjRlNzNjMmItN2U1YS00NTVlLWE1MDItODgyM2U3ODk1YmYw&hl=en [^]'

The HQ map's lump name is HQ, which is fairly obvious.
Tagsflash, lag, lightning, ping spike, smmp, traffic whore
Relationships
parent of 0001267closed Dusk All LIGHTNING scripts are treated CLIENTSIDE 
Attached Fileszip HQTest.zip (741,413) 2011-02-08 12:20
/tracker/file_download.php?file_id=146&type=bug
zip HQTest2.zip (1,675,037) 2011-03-12 02:33
/tracker/file_download.php?file_id=193&type=bug
? LightningStressTest.wad (433,454) 2012-01-15 20:50
/tracker/file_download.php?file_id=447&type=bug
Issue History
Date ModifiedUsernameFieldChange
2011-02-07 13:53StrikerMan780New Issue
2011-02-08 02:55Torr SamahoNote Added: 0001018
2011-02-08 02:56Torr SamahoStatusnew => feedback
2011-02-08 03:01Torr SamahoNote Edited: 0001018bug_revision_view_page.php?bugnote_id=1018#r495
2011-02-08 03:09StrikerMan780Note Added: 0001019
2011-02-08 03:09StrikerMan780Statusfeedback => new
2011-02-08 03:09StrikerMan780Note Edited: 0001019bug_revision_view_page.php?bugnote_id=1019#r497
2011-02-08 12:00Torr SamahoNote Added: 0001020
2011-02-08 12:00Torr SamahoStatusnew => feedback
2011-02-08 12:20StrikerMan780File Added: HQTest.zip
2011-02-08 12:21StrikerMan780Note Added: 0001021
2011-02-08 12:21StrikerMan780Statusfeedback => new
2011-02-14 03:36StrikerMan780Note Added: 0001080
2011-02-14 12:42Torr SamahoNote Added: 0001081
2011-02-14 12:42Torr SamahoStatusnew => feedback
2011-02-14 15:08StrikerMan780Note Added: 0001083
2011-02-14 15:08StrikerMan780Statusfeedback => new
2011-03-12 02:33StrikerMan780File Added: HQTest2.zip
2011-03-12 02:34StrikerMan780Note Added: 0001146
2011-03-12 16:07unknownnaNote Added: 0001149
2011-03-12 16:07unknownnaStatusnew => confirmed
2011-09-08 13:30StrikerMan780Note Added: 0002153
2011-09-10 17:17kgswsNote Added: 0002154
2011-09-10 19:09kgswsNote Edited: 0002154bug_revision_view_page.php?bugnote_id=2154#r1118
2012-01-15 02:38Torr SamahoNote Added: 0002407
2012-01-15 02:52Torr SamahoNote Edited: 0002407bug_revision_view_page.php?bugnote_id=2407#r1225
2012-01-15 03:14Torr SamahoNote Added: 0002409
2012-01-15 03:14Torr SamahoAssigned To => Torr Samaho
2012-01-15 03:14Torr SamahoStatusconfirmed => feedback
2012-01-15 20:49DuskNote Added: 0002448
2012-01-15 20:50DuskFile Added: LightningStressTest.wad
2012-01-15 20:50DuskNote Edited: 0002448bug_revision_view_page.php?bugnote_id=2448#r1237
2012-01-15 20:54Torr SamahoNote Added: 0002449
2012-01-15 21:34DuskNote Added: 0002454
2012-01-15 21:35DuskNote Edited: 0002454bug_revision_view_page.php?bugnote_id=2454#r1241
2012-01-15 22:25Torr SamahoNote Added: 0002457
2012-01-15 23:16DuskNote Added: 0002458
2012-01-15 23:29Torr SamahoNote Added: 0002459
2012-01-15 23:38Torr SamahoStatusfeedback => resolved
2012-01-15 23:38Torr SamahoFixed in Version => 1.0
2012-01-15 23:38Torr SamahoResolutionopen => fixed
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2013-01-29 01:22StrikerMan780Note Added: 0005849
2013-01-29 01:22StrikerMan780Statusresolved => feedback
2013-01-29 01:22StrikerMan780Resolutionfixed => reopened
2013-01-29 01:31DuskNote Added: 0005850
2013-01-29 02:23StrikerMan780Note Added: 0005851
2013-01-29 02:23StrikerMan780Statusfeedback => assigned
2013-01-29 02:23StrikerMan780Note Edited: 0005851bug_revision_view_page.php?bugnote_id=5851#r3198
2013-01-29 06:08Torr SamahoNote Added: 0005853
2013-01-29 06:09Torr SamahoStatusassigned => feedback
2013-01-29 11:48DuskNote Added: 0005859
2013-01-29 11:48DuskStatusfeedback => resolved
2013-01-29 11:48DuskResolutionreopened => fixed
2013-01-29 11:52DuskRelationship addedparent of 0001267
2018-09-30 19:52Blzut3Statusresolved => closed

Notes
(0001018)
Torr Samaho   
2011-02-08 02:55   
(edited on: 2011-02-08 03:01)
Please supply a minimal example wad (as minimal as possible, if it requires hundreds of actors, so be it, but it would be preferably if it would only be a single actor type) that allows to reproduce this quickly, i.e. in a few seconds.
(0001019)
StrikerMan780   
2011-02-08 03:09   
I don't know how I'm going to do that... Unless I can somehow auto-generate thousands of sectors. That, combined with all of the other factors involved such as transfer lights and whatnot.
(0001020)
Torr Samaho   
2011-02-08 12:00   
Instead of creating an example from scratch, you can also try to condense the problematic wad as much as possible while retaining the problem. Throw away all unnecessary scripts, all unnecessary actor definitions, custom graphics and sounds. It doesn't need to look good or work in any reasonable way, it just has to show the lag. And also the six minute waiting time needs to be reduced to a few seconds.

It is particularly important to that the example wad contains as little code (ACS, DECORATE, etc.) as possible. Things like SMMP are just too huge to debug ST bugs that appear in them in a reasonable way.
(0001021)
StrikerMan780   
2011-02-08 12:21   
Attached HQTest.wad, should be MAP01. It is the HQ map with all scripts removed except for the one that starts the lightning. A lot of stuff is going to be missing, like textures and actors.
(0001080)
StrikerMan780   
2011-02-14 03:36   
Hello? Does that map work well enough for testing?
(0001081)
Torr Samaho   
2011-02-14 12:42   
I had to disable the unknown texture warnings to be able to start the map in a reasonable time, but I didn't see any lightning (or lag) in the first 30 seconds after joining. So in the current state, the wad doesn't let me reproduce the problems.
(0001083)
StrikerMan780   
2011-02-14 15:08   
Well fuck... Back to the drawing board.
(0001146)
StrikerMan780   
2011-03-12 02:34   
Uploaded a file by the name of HQTest2, looks ugly as shit, but it shouldn't have near as many missing texture issues, and lightning should finally work.
(0001149)
unknownna   
2011-03-12 16:07   
There's definitely some major lag at work here.
(0002153)
StrikerMan780   
2011-09-08 13:30   
Status update?
(0002154)
kgsws   
2011-09-10 17:17   
(edited on: 2011-09-10 19:09)
Try this'http://wadhost.fathax.com/files/kgbuild-b1.zip, [^]' it should contain one map with 90x90 sectors and lightning. If not this one, try version 2. (i mean, one of maps in single wad should be correct one)
(0002407)
Torr Samaho   
2012-01-15 02:38   
(edited on: 2012-01-15 02:52)
> Status update?

With your second example wad I can reproduce the problem. I'm pretty sure I located the problematic code (it's in DLightningThinker::LightningFlash), but fixing this is not trivial. Independently of whether this is fixed in Skulltag, you should be able to work around the problem by making the script that calls Light_ForceLightning CLIENTSIDE.

One important question is whether this needs to be perfectly synchronized on all clients. If it doesn't matter that the lightning may be different from client to client, this will be much easier to fix in Skulltag.
(0002409)
Torr Samaho   
2012-01-15 03:14   
Alright, how is this? The lightning is not synchronized, the server just instructs the clients when to call Light_ForceLightning when necessary. The random numbers used by that function are generated independently on the clients.
(0002448)
Dusk   
2012-01-15 20:49   
(edited on: 2012-01-15 20:50)
Still broken. Stress tested this with Jroc with a wad with a lot of outdoor sectors (see attached) and world lightning remains to cause massive bw output.

Additionally, my server log got flooded with: "Master server message with wrong verification string received. Ignoring"
(0002449)
Torr Samaho   
2012-01-15 20:54   
Note that the fix I made only affects Light_ForceLightning, it has no effect on the "lightning" MAPINFO property. If you make an example wad for this, I can see if I can improve this too though.

Did your test map use the MAPINFO property or Light_ForceLightning?

> Additionally, my server log got flooded with: "Master server message with wrong verification string received. Ignoring"

Could be a consequence of massive lag.
(0002454)
Dusk   
2012-01-15 21:34   
(edited on: 2012-01-15 21:35)
The test map uses both. There's a switch up west that calls Light_ForceLightning. It didn't seem to cause any bw spikes, only MAPINFO lightning was doing that.

I was under the impression that the fix involved the mapinfo flag but I put the switch there nevertheless to be able to check stuff like this.

> > Additionally, my server log got flooded with: "Master server message with wrong verification string received. Ignoring"

> Could be a consequence of massive lag.
Maybe... I was lagging at the time of the test. I'll report further if this keeps happening.
(0002457)
Torr Samaho   
2012-01-15 22:25   
Alright, this should also take care of MAPINFO lightning.
(0002458)
Dusk   
2012-01-15 23:16   
Works.
(0002459)
Torr Samaho   
2012-01-15 23:29   
Thanks!

I hope nobody minds that the effects are not perfectly synchronized, but since they have no real affect on gameplay, it shouldn't matter anyway.
(0005849)
StrikerMan780   
2013-01-29 01:22   
I'd like to comment that there's some issue with LIGHTNING-type ACS Scripts as a result of the change. (Ie. Execute a certain function on a lightning strike.) Is there some way around this?
(0005850)
Dusk   
2013-01-29 01:31   
That's quite some vague information. What issue?
(0005851)
StrikerMan780   
2013-01-29 02:23   
Basically, the script doesn't execute at all. Or, at the very least, the client isn't informed of it if it does.
(0005853)
Torr Samaho   
2013-01-29 06:08   
Please post a minimal example wad that demonstrates the problem.
(0005859)
Dusk   
2013-01-29 11:48   
It appears all LIGHTNING scripts are treated CLIENTSIDE. I'll open a new ticket for this since this is getting quite lengthy.