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
0001265Zandronum[All Projects] Bugpublic2013-01-28 14:402018-09-30 20:20
ReporterDusk 
Assigned ToDusk 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.0 
Target Version1.1Fixed in Version1.1 
Summary0001265: Strife phosphorus fire fix
Description'https://bitbucket.org/CrimsonDusk/neurosphere/commits/3829 [^]'

I really hate mercurial's commit bureocracy, makes correcting fixes really convulted...
Attached Files

- Relationships
has duplicate 0001311closed Strife's Phosphorous Grenade flames never go out online 
has duplicate 0001326closedDusk Strife phosphorus grenades fire does not die 

-  Notes
User avatar (0005845)
Torr Samaho (administrator)
2013-01-28 20:36

The patch still uses SERVERCOMMANDS_MoveThing instead of SERVERCOMMANDS_MoveThingExact (or SERVER_UpdateThingMomentum if resyncing is necessary) on self.
User avatar (0005858)
Dusk (developer)
2013-01-29 11:30

'https://bitbucket.org/CrimsonDusk/neurosphere/commits/3833 [^]'
User avatar (0005867)
Torr Samaho (administrator)
2013-01-30 06:26

Thanks! Pulled and rebased.

BTW: One thing I just noticed: Did you test that it's not necessary to inform the client of drop's reactiontime with SERVERCOMMANDS_SetThingReactionTime?
User avatar (0006148)
Watermelon (developer)
2013-03-20 04:17

What should I do to confirm this working in 1.1? Test it online with myself with ping emulation?
User avatar (0006154)
Dusk (developer)
2013-03-20 10:29

In 1.0 the flames never seemed to cease existance IIRC.
User avatar (0006261)
Qent (updater)
2013-04-06 21:17
edited on: 2013-04-06 21:34

The bug occurred online in 1.0 without any ping emulation. The flames disappear in 1.1 with and without latency and packetloss.

User avatar (0006268)
Dusk (developer)
2013-04-07 11:58

Quote
BTW: One thing I just noticed: Did you test that it's not necessary to inform the client of drop's reactiontime with SERVERCOMMANDS_SetThingReactionTime?

reactiontime is used for A_Countdown, which is server-managed. Thus I don't think the client needs it.

Since testing revealed no problems I'll mark this fixed.

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-28 14:40 Dusk New Issue
2013-01-28 14:40 Dusk Assigned To => Dusk
2013-01-28 14:40 Dusk Status new => needs review
2013-01-28 20:36 Torr Samaho Note Added: 0005845
2013-01-28 20:37 Torr Samaho Status needs review => feedback
2013-01-29 11:30 Dusk Note Added: 0005858
2013-01-29 11:30 Dusk Status feedback => assigned
2013-01-29 11:30 Dusk Status assigned => needs review
2013-01-30 06:26 Torr Samaho Note Added: 0005867
2013-01-30 06:29 Torr Samaho Status needs review => needs testing
2013-01-30 06:29 Torr Samaho Product Version => 1.0
2013-01-30 06:29 Torr Samaho Target Version => 1.1
2013-03-20 04:17 Watermelon Note Added: 0006148
2013-03-20 10:29 Dusk Note Added: 0006154
2013-03-29 13:34 Dusk Relationship added has duplicate 0001311
2013-04-06 21:17 Qent Note Added: 0006261
2013-04-06 21:17 Qent Note Edited: 0006261 View Revisions
2013-04-06 21:34 Qent Note Edited: 0006261 View Revisions
2013-04-07 11:58 Dusk Note Added: 0006268
2013-04-07 11:58 Dusk Status needs testing => resolved
2013-04-07 11:58 Dusk Fixed in Version => 1.1
2013-04-07 11:58 Dusk Resolution open => fixed
2013-04-19 12:18 Dusk Relationship added has duplicate 0001326
2018-09-30 20:20 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker