Changes since v3.01.11
Map Generation and Layout
- Ranged System Resources - The v2.8.6 approach to this issue, which enabled a single average value for system resources to be selected from a range, did not integrate well with the existing v3 feature of separate average values for each of Minerals, Fuel and Agriculture. Also, it was discovered that in v3.01.11, the range feature had accidentally only been applied to games with mirrored maps. The feature has been rewritten completely in v3.2, with each of Minerals, Fuel and Agriculture having both a base value and an optional range value. Hence, whether it features a traditional or a mirrored map, it is now possible to specify, for example, that a series has Min/Fuel/Ag resources of 27-33/28-32/35-45.
- Mirrored Maps - The feature which was introduced in v3.01.5 and disabled in v3.01.11, and which aimed to minimise the likelihood of maps with single chains of planets between the opposing halves of the map, has been reintroduced in v3.2.
- Map Origin - Many players find the negative co-ordinates frequently resulting from the normal distribution around zero approach to determining the map origin so counter-intuitive that they lead to mistakes in play. Therefore a method of determining map origin which renders their appearance extremely unlikely, but which also prevents players from gaining an idea of the location of their opponents without exploring, and does not result in astronomically large positive co-ordinates, has been adopted. Where N is the product of number of players and number of systems per player, and System X,Y is the map origin, X and Y are separately allocated random values between 2N and 3N.
- Jumpgates and Builders - The use of a Jumpgate to send a Builder to another planet on the same turn that the Builder performed a creation operation has, under earlier releases of v3, been able to create a link from the created planet to the destination of the jump, even though the two planets were not adjacent. Referred to as the Wormhole effect, there has been considerable discussion of whether it is a bug or a feature, and whether its use is cheating or fair play. However, taking the view that it was not among the intentions of the designer of those ships' capabilities, and that were wormholes a desirable game feature some more intuitive way of creating them should be designed and a way of representing their existence on the map be found, the code has been altered to disable this method of creating them.
- Cloaker - Under previous releases, if a cloaked Cloaker visited a planet belonging to an empire with which the owner of the Cloaker had not yet had First Contact - admittedly a rather unusual occurance - the visit causes Contact, thus robbing the Cloaker of its surprise effect. Under v3.2 a cloaked ship cannot cause First Contact, but, this being the case, the action of uncloaking now can.
- Colony - As there is support in v3 for series which permit the building of ships at planets with populations considerably less than fifty, and building Colony ships has the effect of reducing population, it has been made impossible to build a Colony ship at a planet with less than two population points.
- Surrender and Draw - In the interests of backward compatibility, the Surrender and Draw Diplomacy options, which were introduced in v2.9 and did not feature in any of the v2.8.x versions, have been placed under the control of a series configuration option, so that it is possible to define a series that doesn't permit them.
- Surrender Awards - Under previous releases of v3 and under v2.9, the rules governing awards when a player surrendered were as follows:
It was possible, therefore, to avoid any stain on an empire's record by surrendering. These rules have been altered to disconnect the award of the Nuked from that of the Nuke, and to ensure that the Nuke is awarded if possible:
- In a 2-player game, the player surrendering was awarded a Nuked, and the other player was awarded a Win and a Nuke.
- In a game allowing more than 2-players, a player surrendering was not awarded a Nuked unless one of the other players was awarded a Nuke, which would only happen if the surrenderer's homeworld was colonised. This was the case even if the surrenderer was one of the last two remaining players - under which circumstances, the game would end on surrender and the homeworld could not be colonised.
- When an empire surrenders, a Nuked is added to its record immediately, regardless of whether a concomitant Nuke is awarded at all.
- If the surrendered homeworld is subsequently colonised by another empire, that empire receives the Nuke.
- Only one Nuke can be awarded for each surrender in this way, so if the homeworld is subsequently colonised again, this does not result in a second award.
- If the surrendered homeworld is not recolonised before the end of the game:
- If the game ends with a single winner, the Nuke is awarded to the winner.
- If the game is drawn or is won by an alliance, the Nuke is not awarded.
- Alliance -
- The Over-Allying Loophole - Although v3 has always had a series configuration option specifying the maximum number of allies any empire is to be allowed, it was possible with perseverence to overcome the restriction and form an alliance of more empires than should have been permitted. This bug has been fixed in v3.2. The fix was also retrofitted in v3.01.5b.
- Premature End-of-Game - The game is intended to end when all the remaining players are allied with each other. However, under earlier releases of v3, it was possible for the game to end when just one of the empires was allied with all the others, regardless of the diplomatic status between the other empires. This fault has been cured. The fix was retrofitted in v3.01.5d.
- The Bridier System - The traditional system of player ranking in SC, ordering empire records according to raw numbers of Wins, Nukes, Nuked and Ruined, has many drawbacks for an unmoderated networked game. In particular, as any one win is worth the same to the record as another, the incentive to artificially enhance your record by creating a second empire and playing against yourself is irresistable to some players. The introduction of the Bridier System as a server option in v3.2 is intended to reduce the rewards for cheating and increase the incentive to good, fair play. If the server adminstrator enables the Bridier System, then the series designer is offered the choice of whether each 2-player series is a Bridier Ranking series. For details on the mechanism, implementation and implications, see The Bridier Ranking System for Stellar Crisis.
- SC v2.9 and earlier releases of v3 incorporated a piece of defensive programming which prevented players from entering HTML tags or entities into the various modifiable fields within the game, as these could be used maliciously. v3.2 has implemented sterner restrictions on some of the user-defined text items to prevent further exploitation.
Invisible Population Changes
- A new feature which is the logical extension of the Invisible Build feature introduced in v2.9. In series which have Invisible Builds specified, the drop in population caused by building Colony ships is also invisible to other players until after the update under v3.2. Also, changes made to the Max Pop setting for a planet are not visible before the update, to prevent unwanted telegraphing of pop-tricks. Like Invisible Builds, the purpose of these changes is to reduce as far as possible the amount of information that a player can gain by leaving his update until after all other players have updated, thus making the game fairer and faster.
- Game List - Both the short Game List and the Detailed Game List have been revised considerably:
- Presentation Order - Below games in which the empire is already taking part, both Game Lists now separate the remaining games on offer into two sections - those games which have already begun and which the empire may join, and those which no other has yet joined and which, therefore, this empire may start.
- Series Details - For each series listed, there is a new button, which displays a screen showing the full details of the configuration of the series, ie., the Detailed Game List entry for that series. The full Detailed Game List can be a very large download, so this feature should conserve bandwidth and save time.
- Detailed Game List - The presentation of game details has been rationalised. Values affecting only ship types which are not permitted by the series configuration are not shown, and numeric data precision has been improved so that the number of decimal places displayed is no more than needed.
- Update Time - The Game Lists no longer attempt to predict, erroneously, the time of next update for games which have so far zero or only one player entered.
- User Profile -
- Several checkbox options, such as Use Frames, Separate Map, and Update Countdown, were redundant and have been removed.
- A note has been added explaining the purpose of the Theme URL field, to reduce the number of support calls complaining of broken images.
- The Empire Name field has been removed from the User Profile screen. It was redundant in that any modification made was not applied, and anyway there was a bug which resulted in only the first word of a multi-word name being displayed.
- History -
- The History Viewer now presents a menu of recently-ended games, rather than one potentially vast concatenated pile of History text. Selection of one of the games from the menu takes you to the static History page which was saved by the server when the game ended, rather than to a server-generated screen. Use of the browser Back button is recommended here.
- The recorded History text has been enhanced to include more Diplomacy events, and minimal details of battles. Also, that accursed final spurious comma has been removed.
- A snapshot of the Game Map, taken immediately before the final update, is included.
- In the case of a Bridier Ranking game, the changes applied to the Bridier Rank and Index of the players is recorded.
- Update Text -
- Several other more esoteric ship actions, as well as Carriers taking damage, were found to be truncating Update Text. Those found have been fixed, and it's hoped that no more have eluded our gaze.
- Under v3.2, in reporting ships sighted or destroyed, the update text will treat named and unnamed ships differently. In particular, a fleet of unnamed ships will not be represented as a string of N-1 commas. The names of named ships will be given but a count of unnamed ships will replace the empty separators, eg:
- John, Paul, George and Ringo of Beatlemania were sighted in Hamburg
- 14 ships of Castrati were sighted in La Scala
- Frodo, Samwise and 1 other ship of Hobbits were sighted in Mordor
- Ratios Line -
- The Ratios Line which displays the current values of Maintenance Ratio, Fuel Ratio, Tech Level and Tech Development, and which was previously visible only on the Ships and Build Screens, is now also present on the Tech, Fleets, Systems and Diplomacy Screens.
- Previously, it did not appear on a Ships screen which showed no ships, or on a Build screen which stated that you had no planets with sufficient population to build - in both those cases, it now does appear.
- The numeric precision of the Tech Level field in this display has been increased from one decimal place to three.
- Under the control of a new User Profile option Enhanced Ratios Line, it can additionally show Total Minerals, Total Fuel, Total Agriculture and Ag Ratio.
- Text Color-Coding - The choice of whether data items are represented on screen using the cream color introduced in v3.01.11 or in the standard server or series color is now governed by a User Profile option - Separate Data Color.
- Info Screen -
- Game Notes - A small notepad has been added to the Info screen, allowing players to record their notes on the game for later recall.
- Series Constants - Having to Exit the game and download the whole Detailed Game List simply to find out the value of a single series configuration variable such as Engineer Loss or Jumpgate Range was infuriating. The Detailed Game List entry for the series in play has been added to the bottom of the Info screen.
- Tech Screen - The text on the Tech Screen which indicates how many of each of Tech Selections, Restricted Techs and Trade-Ins are available has been altered to improve comprehensibilty.
- Ships and Fleets Screens - The feature which was introduced in v3.01.5 and disabled in v3.01.11, and which ensured that ships at the same planet appeared together on the Ships Screen, has been reintroduced in v3.2. The concern which caused it to be suspended from v3.01.11, that it might influence combat resolution, was unfounded. Less significantly, the method has also been applied to the Fleets Screen.
- Ships Screen -
- The change to the ordering of columns on the Ships Screen introduced in v3.01.11, moving the Type column from the far right to the second left, has been made a server configuration option, so that the server admin may choose whether or not to keep to the traditional layout. Therefore on some servers it may appear that this change has been reversed.
- Numeric precision of the Max BR field has been increased from one decimal place to three, to take account of loss values associated with ship actions that are not multiples of 0.1.
- Under the control of a User Profile option Show Next BR, the Ships table may include a column which gives the projected BR of the ship next turn. This value does not take ship action losses into account, however.
- Map Screen - Maps in which for all the planets shown, one or both of the co-ordinates were all negative, displayed incorrectly under v3.01.11, in that padding space was included from the position of lowest negative magnitude up to zero. This has been mended.
- Button Text Color - The text color on the non-graphical buttons in the row at the top of each screen has been altered from the server or series text color to black, to promote readability. It appears that this change is significant only to users of X-windows browsers, as other systems seem to ignore button text color and present black anyway.
- WebTV Mode - Users of this interface have found that several of its features cause problems with some of the game screens. This new User Profile option has been provided to control access to modifications to the affected screens designed to assist with these problems. At present, selection of the option alters only one value - the width of the Max Pop field on the Systems screen, which is otherwise rendered too narrow by WebTV. Other improvements for WebTV users may be forthcoming, and should also be placed under the control of this option.
- Upload Custom Icon - As this feature has never been implemented, the presence of the button was only causing confusion. For the time being, and until an implementation is forthcoming, the button has been removed from the Edit Profile - Player Icon screen.
- Game Screen Title - By popular request, the order of elements in screen Title strings has been altered to Screen Name, Series Name, Game Number, Server Name. This makes it much easier to find the desired screen when searching among truncated titles such as on Taskbar buttons or browser history menus.
- Stat Viewer IP Addresses - Marked reduction in the significance of IP Addresses in determining the source of a connection, due to the recent proliferation in use of proxy servers among other things, and misunderstanding thereof giving rise to many false accusations and bad feeling, coupled with the widespread availability of Denial-of-Service 'tools', has led to doubt about the wisdom of showing IP Addresses on the publicly-visible Stat Viewer. The information has been retained on the Admin Empire view screen, and the presence of multiple empires in the same game using the same IP address is recorded in the server log instead. Until a better method of detecting multiple empires under the control of a single player is found, it is recommended that players rely on the vigilance of the server administrator to protect them from this form of cheating.
- Admin Button - Under v3.01.11, some empires had an inactive Admin button on their Game List screen. This has been removed until such time as a function is found for it.
Miscellaneous Bug Fixes
- End Turn on Loss - If on pressing End Turn, the update was triggered on which the empire was nuked, annihilated or invaded out of the game, a Roxen Error Screen appeared, caused by the attempt to load the Info Screen for a player no longer in the game. This bug has been fixed.
- End Turn Idling - Each game keeps a record of which update was the last on which a player performed a play action, so that, after two turns of inactivity, the empire can be marked as Idle - whereupon it is considered to have pressed End Turn immediately after the update and the countdown begins to its ruin. However, the action of pressing End Turn itself was not counted as a play action for these purposes, so a player who chose not to perform any action but pressed End Turn so as not to hold up the game was effectively penalised as if he was truly idle. Under v3.2, pressing End Turn counts as a play action for this purpose, so that choosing not to build or move ships for play reasons is not penalised.
- First Update Timing - v3 has always purported to offer the series designer an option to delay the first update of a game beyond the normal update period, to give the game a better chance to fill after the entry of the second player but before play began. However, until now, this option had no discernable effect. Under v3.2 its use is recommended, especially for games which allow many players and which require a high number of wins to enter them.
- Tech Selection - It was found that with repeated use of the same Tech screen by means of the browser Back button, it was possible to select more Technologies than should have been permitted according to the empire's Tech Level. This omission has been rectified. The fix was also retrofitted to v3.01.5c.
- Naming Cheat - The fix applied in v3.01.11 (and v3.01.5a) to prevent the '%' planet-naming cheat was a kludge, in that it didn't address the vulnerability of the code to the existence of '%' characters in user-specified strings, it only translated that character into something innocuous. In v3.2, an attempt has been made to render the code itself invulnerable to this effect.
- Database Purge - The criteria for removal of an empire from the database under the purge feature have been altered. An empire will not be removed if its last access time falls within the last one hundred days. However, if the last access is longer ago than that, a positive record is required to keep it - it must have either Wins or Nukes. Non-zero values for Nuked or Ruined will not save it.
- ASCII Database - Selection of ASCII as the default database type applied successfully to the loading operation but not to saving. This has been corrected.
- Ranged Systems per Player - A bug which prevented a Systems per Player Range from being added to a series which had been defined under a version of the code which didn't support the feature has been fixed.