UFO: Alien Invasion Issue Tracker
Please log in to bookmark issues
CLOSED  Bug report #361  -  Multiplayer is not destroyed correctly
Posted Sep 22, 2006 - updated Jan 28, 2013
icon_info.png This issue has been closed with status "Closed" and resolution "Not determined".
Issue details
  • Type of issue
    Bug report
  • Status
  • Assigned to
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
  • Resolution
    Not determined
  • Priority
    3. Normal
  • Reproducability
    Not determined
  • Severity
    Not determined
  • Targetted for
    icon_milestones.png Not determined
  • Complexity
    icon_customdatatype.png Not determined
  • Platform
    icon_customdatatype.png Not determined
  • Architecture
    icon_customdatatype.png Not determined
Issue description
Item 361 imported from sourceforge.net tracker on 2013-01-28 18:18:28

I've found the game will exit with an error when you perform these actions:

- Start up the game - Select multiplayer - Go back to the main menu - Select single player - Start a new campaign - Build a new base

The game will display an error message that says "Error: CL_UpdateHireVar: SoldiersInBase: 8, teamNum[1] : 1, p: 0" and exit.
Comments Ported from Sourceforge  ⇑ top
cassiterite (2006-09-27 15:31:25)  ⇑ top
Logged In: YES user_id=1171370

This applies to RC5 and SVN and in my testing it can happen without first going into multiplayer as well.
cassiterite (2006-09-27 22:09:00)  ⇑ top
Logged In: YES user_id=1171370

Revision 3870 in SVN trunk should fix this.

The bug was two-fold: new aircraft were being added when switching between multiplayer or singleplayer yet gd.numAircraft was not nessecarily being reset. Additionally a newly added aircraft could be assigned the wrong IDX due to an out-of-order assignment.

PS: I managed to press the wrong buttons during commit and somehow let a blank commit message through. However a comment that covers r3780 is included in the log for r3871 (sorry for any confusion caused!).

Steps to reproduce this issue
Nothing entered.