Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000871Zandronum[All Projects] Bugpublic2012-06-10 18:482024-03-14 05:08
ReporterDusk 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionunable to reproduce 
PlatformOSOS Version
Product Version1.0-beta 
Target VersionFixed in Version 
Summary0000871: RCON users get SERVER_Printf'd messages twice
DescriptionIf a client with rcon access issues an rcon command that ends up calling SERVER_Printf to broadcast a message to clients, he'll get the message twice - once from the verbose output and another from the real broadcast.

Fix here:
'https://bitbucket.org/CrimsonDusk/neurosphere/changeset/9bbf7257d865 [^]'
'https://bitbucket.org/CrimsonDusk/neurosphere/changeset/6e34d2e66647 [^]'
Attached Files

- Relationships

-  Notes
User avatar (0003835)
Torr Samaho (administrator)
2012-06-24 10:31
edited on: 2012-06-24 10:44

 For the sake of consistency (CONSOLE_SetRCONPlayer already exists), instead of exporting g_ulRCONPlayer, the access function CONSOLE_GetRCONPlayer should be introduced.

Anyway, the whole constructing gets weird: We already have
SERVER_RCON_Printf( outlinecopy );
if ( g_ulRCONPlayer != MAXPLAYERS )
  SERVER_PrintfPlayer( printlevel, g_ulRCONPlayer, outlinecopy );
and now you add an additional construction in SERVER_Printf to counter this. The existing construction deliberately prints messages twice for the RCON player, once with SERVER_RCON_Printf and once with SERVER_PrintfPlayer. So to me this behavior seems to be intentional and not a bug. Possibly I'm overlooking something here.
User avatar (0003837)
Dusk (developer)
2012-06-24 11:00

 .. WTF?

How can something like this be intentional? I'm confused now.
User avatar (0003838)
Torr Samaho (administrator)
2012-06-24 11:47

 I didn't write any of this code, so I can just speculate about its intentions. The fragment from c_console.cpp I posted above apparently prints the messages twice, once with SERVER_RCON_Printf and once with SERVER_PrintfPlayer. I'd guess it makes a difference which of these functions is used to print a message.

If we come to the conclusion that this is wrong, we should fix it in that fragment. Since SERVER_RCON_Printf is only called once, we could move the ( g_ulRCONPlayer != MAXPLAYERS ) part into SERVER_RCON_Printf along with the logic you added at two other places.
User avatar (0005872)
Dusk (developer)
2013-01-30 14:14

 I think I might've been a bit vague with this: with RCON user I mean a client logged into RCON access with send_password and is issuing commands with the rcon command.

I also took a closer look into this now and I think SERVER_RCON_Printf has nothing to do with this. The code fragment in the first reply is in PrintString which is executed by all Printfs on the server, including SERVER_Printf. So if an RCON user sends a command to for instance change dmflags, SERVER_Printf broadcasts it to clients (including the RCON user) and logs it to the server console - which is then tee'd to the RCON user, thus he's getting it twice.
User avatar (0023391)
Ru5tK1ng (updater)
2024-03-14 05:08

 I can't seem to reproduce this with puking or changing dmflags with 3.1. Closing ticket as a result of my findings. Feel free to reopen this if it's still an issue.

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
2012-06-10 18:48 Dusk New Issue
2012-06-10 18:48 Dusk Status new => assigned
2012-06-10 18:48 Dusk Assigned To => Dusk
2012-06-10 18:48 Dusk Status assigned => needs review
2012-06-10 19:01 Dusk Description Updated View Revisions
2012-06-24 10:31 Torr Samaho Note Added: 0003835
2012-06-24 10:31 Torr Samaho Status needs review => feedback
2012-06-24 10:42 Torr Samaho Note Edited: 0003835
2012-06-24 10:42 Torr Samaho Note Edited: 0003835
2012-06-24 10:43 Torr Samaho Note Edited: 0003835
2012-06-24 10:44 Torr Samaho Note Edited: 0003835 View Revisions
2012-06-24 10:44 Torr Samaho Note Revision Dropped: 3835: 0002089
2012-06-24 10:44 Torr Samaho Note Revision Dropped: 3835: 0002090
2012-06-24 10:45 Torr Samaho Note Revision Dropped: 3835: 0002091
2012-06-24 10:45 Torr Samaho Note Revision Dropped: 3835: 0002092
2012-06-24 11:00 Dusk Note Added: 0003837
2012-06-24 11:00 Dusk Status feedback => assigned
2012-06-24 11:00 Dusk Status assigned => feedback
2012-06-24 11:47 Torr Samaho Note Added: 0003838
2013-01-30 14:14 Dusk Note Added: 0005872
2013-01-30 14:14 Dusk Status feedback => assigned
2013-01-30 14:14 Dusk Assigned To Dusk =>
2013-01-30 14:14 Dusk Status assigned => feedback
2024-03-14 05:08 Ru5tK1ng Note Added: 0023391
2024-03-14 05:08 Ru5tK1ng Status feedback => closed
2024-03-14 05:08 Ru5tK1ng Resolution open => unable to reproduce




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker