0000283: Lightning strikes cause massive traffic spikes

(0001018)
Torr Samaho (administrator)
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 (reporter)
2011-02-08 03:09
edited on: 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 (administrator)
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 (reporter)
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 (reporter)
2011-02-14 03:36

Hello? Does that map work well enough for testing?

(0001081)
Torr Samaho (administrator)
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 (reporter)
2011-02-14 15:08

Well fuck... Back to the drawing board.

(0001146)
StrikerMan780 (reporter)
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 (updater)
2011-03-12 16:07

There's definitely some major lag at work here.

(0002153)
StrikerMan780 (reporter)
2011-09-08 13:30

Status update?

(0002154)
kgsws (reporter)
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 (administrator)
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 (administrator)
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 (developer)
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 (administrator)
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 (developer)
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 (administrator)
2012-01-15 22:25

Alright, this should also take care of MAPINFO lightning.

(0002458)
Dusk (developer)
2012-01-15 23:16

Works.

(0002459)
Torr Samaho (administrator)
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 (reporter)
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 (developer)
2013-01-29 01:31

That's quite some vague information. What issue?

(0005851)
StrikerMan780 (reporter)
2013-01-29 02:23
edited on: 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 (administrator)
2013-01-29 06:08

Please post a minimal example wad that demonstrates the problem.

(0005859)
Dusk (developer)
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.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Notes
(0001018) Torr Samaho (administrator) 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 (reporter) 2011-02-08 03:09 edited on: 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 (administrator) 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 (reporter) 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 (reporter) 2011-02-14 03:36	Hello? Does that map work well enough for testing?

(0001081) Torr Samaho (administrator) 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 (reporter) 2011-02-14 15:08	Well fuck... Back to the drawing board.

(0001146) StrikerMan780 (reporter) 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 (updater) 2011-03-12 16:07	There's definitely some major lag at work here.

(0002153) StrikerMan780 (reporter) 2011-09-08 13:30	Status update?

(0002154) kgsws (reporter) 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 (administrator) 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 (administrator) 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 (developer) 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 (administrator) 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 (developer) 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 (administrator) 2012-01-15 22:25	Alright, this should also take care of MAPINFO lightning.

(0002458) Dusk (developer) 2012-01-15 23:16	Works.

(0002459) Torr Samaho (administrator) 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 (reporter) 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 (developer) 2013-01-29 01:31	That's quite some vague information. What issue?

(0005851) StrikerMan780 (reporter) 2013-01-29 02:23 edited on: 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 (administrator) 2013-01-29 06:08	Please post a minimal example wad that demonstrates the problem.

(0005859) Dusk (developer) 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.

Issue History
Date Modified	Username	Field	Change
2011-02-07 13:53	StrikerMan780	New Issue
2011-02-08 02:55	Torr Samaho	Note Added: 0001018
2011-02-08 02:56	Torr Samaho	Status	new => feedback
2011-02-08 03:01	Torr Samaho	Note Edited: 0001018	View Revisions
2011-02-08 03:09	StrikerMan780	Note Added: 0001019
2011-02-08 03:09	StrikerMan780	Status	feedback => new
2011-02-08 03:09	StrikerMan780	Note Edited: 0001019	View Revisions
2011-02-08 12:00	Torr Samaho	Note Added: 0001020
2011-02-08 12:00	Torr Samaho	Status	new => feedback
2011-02-08 12:20	StrikerMan780	File Added: HQTest.zip
2011-02-08 12:21	StrikerMan780	Note Added: 0001021
2011-02-08 12:21	StrikerMan780	Status	feedback => new
2011-02-14 03:36	StrikerMan780	Note Added: 0001080
2011-02-14 12:42	Torr Samaho	Note Added: 0001081
2011-02-14 12:42	Torr Samaho	Status	new => feedback
2011-02-14 15:08	StrikerMan780	Note Added: 0001083
2011-02-14 15:08	StrikerMan780	Status	feedback => new
2011-03-12 02:33	StrikerMan780	File Added: HQTest2.zip
2011-03-12 02:34	StrikerMan780	Note Added: 0001146
2011-03-12 16:07	unknownna	Note Added: 0001149
2011-03-12 16:07	unknownna	Status	new => confirmed
2011-09-08 13:30	StrikerMan780	Note Added: 0002153
2011-09-10 17:17	kgsws	Note Added: 0002154
2011-09-10 19:09	kgsws	Note Edited: 0002154	View Revisions
2012-01-15 02:38	Torr Samaho	Note Added: 0002407
2012-01-15 02:52	Torr Samaho	Note Edited: 0002407	View Revisions
2012-01-15 03:14	Torr Samaho	Note Added: 0002409
2012-01-15 03:14	Torr Samaho	Assigned To	=> Torr Samaho
2012-01-15 03:14	Torr Samaho	Status	confirmed => feedback
2012-01-15 20:49	Dusk	Note Added: 0002448
2012-01-15 20:50	Dusk	File Added: LightningStressTest.wad
2012-01-15 20:50	Dusk	Note Edited: 0002448	View Revisions
2012-01-15 20:54	Torr Samaho	Note Added: 0002449
2012-01-15 21:34	Dusk	Note Added: 0002454
2012-01-15 21:35	Dusk	Note Edited: 0002454	View Revisions
2012-01-15 22:25	Torr Samaho	Note Added: 0002457
2012-01-15 23:16	Dusk	Note Added: 0002458
2012-01-15 23:29	Torr Samaho	Note Added: 0002459
2012-01-15 23:38	Torr Samaho	Status	feedback => resolved
2012-01-15 23:38	Torr Samaho	Fixed in Version	=> 1.0
2012-01-15 23:38	Torr Samaho	Resolution	open => fixed
2012-06-09 13:22	Torr Samaho	Category	General => Bug
2013-01-29 01:22	StrikerMan780	Note Added: 0005849
2013-01-29 01:22	StrikerMan780	Status	resolved => feedback
2013-01-29 01:22	StrikerMan780	Resolution	fixed => reopened
2013-01-29 01:31	Dusk	Note Added: 0005850
2013-01-29 02:23	StrikerMan780	Note Added: 0005851
2013-01-29 02:23	StrikerMan780	Status	feedback => assigned
2013-01-29 02:23	StrikerMan780	Note Edited: 0005851	View Revisions
2013-01-29 06:08	Torr Samaho	Note Added: 0005853
2013-01-29 06:09	Torr Samaho	Status	assigned => feedback
2013-01-29 11:48	Dusk	Note Added: 0005859
2013-01-29 11:48	Dusk	Status	feedback => resolved
2013-01-29 11:48	Dusk	Resolution	reopened => fixed
2013-01-29 11:52	Dusk	Relationship added	parent of 0001267
2018-09-30 19:52	Blzut3	Status	resolved => closed