Help has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...

Bug #918800

Current ingame year displayed incorrectly when outside signed short range

Added by Alina L. over 1 year ago. Updated over 1 year ago.

Start date:
Due date:
% Done:


Estimated time:


In the GTK+3.22 client, the ingame year (as displayed in the sidebar) seems to be interpreted as a signed short – if the value is too large, it overflows and loops back to a negative year.
After launching a spaceship, the estimated year of arrival in the spaceship report exhibits the same behavior. However, the message received when first launching the spaceship displays the year correctly. The server also uses the correct year (e.g. for autosave names).

To reproduce, change a ruleset's starting year to some value too large for a signed short. Initially noticed for 41000, which is displayed as 24536 BCE, and tested again for 65539 (= 2^16 + 3), which is displayed as 3 CE.

Tested in a recent 3.1/master experimental build (commit 3466068fa5). Likely affects other versions (S2_6 and S3_0), and possibly other clients (if this stems from common client code, rather than GTK3.22-specific code).


#1 Updated by Alina L. over 1 year ago

Possibly relevant: In common/packets_gen.c, the game year regularly appears in DIO_GET() and DIO_PUT() calls as an sint16 (current master, commit fe382f38), so I figure the problem here might be that the year is treated as a signed short in the network protocol and thus loses its more significant bits on the way to the client.
(I believe we had a similar issue some time ago involving team pooled research and negative contributions from the team due to tech upkeep; though I can't find the ticket right now. Might have been in the days of Gna.)

#2 Updated by Marko Lindqvist over 1 year ago

  • Category changed from gui-gtk-3.22 to General
  • Status changed from New to In Progress
  • Sprint/Milestone set to 2.6.4

YEAR is defined as SINT16 in packets.def, so this seems like network protocol issue. Fixing in master should be trivial, but stable branches with network protocol frozen require more work.

#4 Updated by Marko Lindqvist over 1 year ago

  • Status changed from Resolved to Closed
  • Assignee set to Marko Lindqvist

Also available in: Atom PDF