Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001267Zandronum[All Projects] Bugpublic2013-01-29 11:522018-09-30 20:29
ReporterStrikerMan780 
Assigned ToDusk 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.0 
Target Version1.1Fixed in Version1.1 
Summary0001267: All LIGHTNING scripts are treated CLIENTSIDE
DescriptionContinuing from 0000283: it appears all LIGHTNING scripts are sent to the client to execute no matter if they're CLIENTSIDE or not.
Steps To Reproduce- Host a server with example wad and connect a client to it.
- Hit the switch - this calls Light_ForceLightning to trigger lightning.
- Two log messages are printed out, "CLIENTSIDE LIGHTNING" - this is produced by a LIGHTNING CLIENTSIDE script, and "SERVERSIDE LIGHTNING", this is produced by a normal LIGHTNING script.

The serverside message should be printed into the server log, not onto the client. This shows that the client is executing all LIGHTNING scripts.
Attached Fileszip file icon LightningScriptTest.wad.zip [^] (1,359 bytes) 2013-01-29 11:52

- Relationships
child of 0000283closedTorr Samaho Lightning strikes cause massive traffic spikes 

-  Notes
User avatar (0005860)
Dusk (developer)
2013-01-29 13:08
edited on: 2013-01-29 13:08

I decided to do some restructuring to the lightning networking: server manages lightning and tells clients to flash when needed. Removed some obsolete networking code and fixed LIGHTNING script management in the process.

'https://bitbucket.org/CrimsonDusk/neurosphere/commits/0c3f6101733beed16b5d8db93edc47b2 [^]'

Note that this is currently in the neurosphere head as I'm pretty sure I'm going to have to do some adjustments.

User avatar (0005911)
Torr Samaho (administrator)
2013-02-02 08:45

Can you elaborate your changes in DLightningThinker::Tick? If the server is supposed to handle the synchronization, how can it avoid calling parts of the code like

    LightningFlashCount = (pr_lightning()&7)+8;
    flashLight = 200+(pr_lightning()&31);

Or are the flashes still supposed to be not fully synchronized (they weren't synchronized before either)?
User avatar (0005914)
Dusk (developer)
2013-02-02 10:48

That stuff is determines lightning duration and strength, it has nothing to do with the logic to decide when a lightning strikes.

The first call to ::Tick sets those variables you quoted and performs initial flash, sky mask, sounds, etc. After, it is called repeadetly as long as LightningFlashCount is > 0 and said counter is decreased each time - this is for the fade-out effect. The clients can decide how long and strong each lightning flash is so the server jumps past it.
User avatar (0005979)
Torr Samaho (administrator)
2013-02-10 11:04

I see, intentionally not syncing the length and strength between client and server is fine with me.

I think you can simplify the code slightly by removing the StaticStartTypedScripts from the server block and moving the nextflash above the StaticStartTypedScripts calls.
User avatar (0005981)
Dusk (developer)
2013-02-10 14:31

'https://bitbucket.org/CrimsonDusk/neurosphere/commits/3853 [^]'
Better now? If this is good I'll push to a new head.
User avatar (0005983)
Torr Samaho (administrator)
2013-02-10 19:33

Yes, looks good to me now. Thanks!

I didn't test this at all though, so I'll assume you tested it sufficiently.
User avatar (0006031)
Dusk (developer)
2013-02-16 23:03

Ah, dang, forgot all about this..

Here is this:'https://bitbucket.org/CrimsonDusk/neurosphere/commits/80ea1f130719fe23033a1be653de84090485c479 [^]'
User avatar (0006039)
Torr Samaho (administrator)
2013-02-17 08:56

Thanks! Pulled.
User avatar (0006057)
StrikerMan780 (reporter)
2013-02-21 02:57

I can test this if another build is made.
User avatar (0006061)
Torr Samaho (administrator)
2013-02-23 08:09

This should contain Dusk's fix.
User avatar (0006069)
StrikerMan780 (reporter)
2013-02-24 08:59

Confirmed to work. Thanks.

Issue Community Support
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.

- Issue History
Date Modified Username Field Change
2013-01-29 11:52 Dusk New Issue
2013-01-29 11:52 Dusk File Added: LightningScriptTest.wad.zip
2013-01-29 11:52 Dusk Relationship added child of 0000283
2013-01-29 11:52 Dusk Reporter Dusk => StrikerMan780
2013-01-29 12:07 Dusk Assigned To => Dusk
2013-01-29 12:07 Dusk Status new => assigned
2013-01-29 13:08 Dusk Note Added: 0005860
2013-01-29 13:08 Dusk Status assigned => needs review
2013-01-29 13:08 Dusk Note Edited: 0005860 View Revisions
2013-02-02 08:45 Torr Samaho Note Added: 0005911
2013-02-02 08:45 Torr Samaho Status needs review => feedback
2013-02-02 10:48 Dusk Note Added: 0005914
2013-02-10 11:04 Torr Samaho Note Added: 0005979
2013-02-10 14:31 Dusk Note Added: 0005981
2013-02-10 14:31 Dusk Status feedback => needs review
2013-02-10 19:33 Torr Samaho Note Added: 0005983
2013-02-16 23:03 Dusk Note Added: 0006031
2013-02-17 08:56 Torr Samaho Note Added: 0006039
2013-02-17 08:58 Torr Samaho Status needs review => needs testing
2013-02-17 08:58 Torr Samaho Product Version 1.1 => 1.0
2013-02-17 08:58 Torr Samaho Target Version => 1.1
2013-02-21 02:57 StrikerMan780 Note Added: 0006057
2013-02-23 08:09 Torr Samaho Note Added: 0006061
2013-02-24 08:59 StrikerMan780 Note Added: 0006069
2013-02-24 12:52 Dusk Status needs testing => resolved
2013-02-24 12:52 Dusk Resolution open => fixed
2013-02-24 12:52 Dusk Status resolved => feedback
2013-02-24 12:52 Dusk Resolution fixed => reopened
2013-02-24 12:52 Dusk Status feedback => resolved
2013-02-24 12:52 Dusk Fixed in Version => 1.1
2013-02-24 12:52 Dusk Resolution reopened => fixed
2018-09-30 20:29 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker