|
Changes between v3.01.5 and v3.01.11
Map Generation and Layout
- Ranged Systems per Player - In v2.8, each series had a fixed number of systems per player. One of the features of v2.8.6 which had been added since the codebase forked, and so was missing from v2.9 and earlier releases of v3, was the ability to define a range of values for this parameter for a series. If this option is taken up by the series designer, when a game within the series is begun a random value for the Systems per Player variable is chosen from the specified range, and applied to that game throughout its life. It does not mean that some players may cause more planets to be added to the map when they join than others, only that the players do not not know exactly how many planets that is. The purpose of this feature, then, like that of the next two features, is to reduce the amount of information that can be deduced by an experienced player about the map location of his opponents by looking at a small portion of the map. This feature has been introduced into v3.01.11.
- Ranged System Resources - Similarly, v2.8.6 featured the ability to specify a range of values rather than a single value for Average (non-Homeworld) Planet Resources (Mineral, Fuel and Agriculture). Once again, the value chosen from the range is allocated at game start, but the players do not know precisely what that value is. On the other hand, earlier v3 releases had allowed the series designer to give separate values for each of the three resource averages. These two features have been amalgamated in v3.0.11.
- Map Origin - Under v2.8, when a game starts the first planet assigned to the map is at a position predetermined for the series, being System X,X, where X is the product of the number of players and the number of systems per player. This has the unfortunate effect of giving to subsequent entries a very good idea of the location of the Homeworld of the first player to enter. The information was fudged slightly in earlier v3 releases by multiplication of X by 5, but still a second player with knowledge of the code could predict the direction in which to find the first player with ease. v3.01.11 has adopted the same approach as v2.8.6 to this problem, randomising the position of the first planet onto the map in a normal distribution around zero.
- Mirrored Maps - Between v3.01.4 and v3.01.5, a change was introduced into the algorithm that generated mirrored maps. The intention was to minimise the likelihood that the resulting map would have only a single chain of planets between the two halves of the symmetric map - an outcome which greatly reduced the interest value of the ensuing game. It worked by ensuring that once the first set of planets was allocated, the side of the bounding box to be the pivot of the reflection was not randomly chosen from among all four, but only from among those which had the highest number of worlds along their edges. For instance, if the bounding box had two planets along its northern edge, three along the west, and four along the south and east, then the random selection would be made from between only the south and east. This feature was accidentally disabled in v3.01.11.
Ship Properties
- Cloakers - Under all v2.8.x, and v2.9, it was the nature of Cloakers to be uncloaked when built, requiring a turn to cloak them before sending them into play. Under v3, until now, they were always built already cloaked, saving the turn and increasing the element of surprise they confer. Though this has been largely (but not universally) accepted as an improvement, it does interfere with the ethos of backward-compatibility to which v3 aspires. It is the intention of v3 to enable the series designer to configure a series which plays exactly as expected by someone who is accustomed only to v2.8, or v2.8.6, or v2.9 (with the obvious necessary exception of those versions' known bugs being fixed) so in v3.01.11, Cloakers built cloaked is a series configuration option.
- Morphers - Unfortunately, the original implementation of the Morpher was quite seriously flawed, resulting in a ship whose behaviour was less intuitive, but considerably more powerful, than the author intended. The main problem was that like Cloakers, Morphers were invisible to other players when built, and only became visible when they first changed into some other technology. There were also some strange anomolies which resulted when a Morpher changed into a Cloaker. These problems have now been cured. Under v3.01.11, Morphers begin their lives visible, and can only become invisible by changing into a Cloaker. When they do so, whether they are immediately invisible or require a turn to cloak is governed by the Cloakers built cloaked setting for the series. While cloaked, a Morpher/Cloaker does not have the option to change into another technology available to it; it must uncloak first, just as it must uncloak in order to be able to fight or nuke.
- Builders - To prevent the overuse of Builders resulting in a seriously unwieldy database, a high arbitrary limit has been placed on the total number of planets that can be created by Builders in any one game.
- Morpher/Minefields - Since the advent of Morphers has enabled the previously unknown phenomenon of Minefield explosion at uncolonised planets, a bug has come to light which resulted in the population of an uncolonised planet being raised from zero to one by the explosion. This meant that the planet could not subsequently be colonised, but could be invaded. This error has been fixed.
Malicious Play
- Naming Cheat - Most versions of the SC code contained a bug which resulted a Roxen Error Screen instead of the Ships or Fleets Screen, if a player had chosen to place a '%' character in the name of a planet either at or adjacent to the location of one of the ships listed on the affected screen. In v3.01.11, this problem has been circumvented by translating '%' into an innocuous string. This change was also retrofitted to v3.01.5, as v3.01.5a.
User Interface
- Game List - The Game List, as opposed to the Detailed Game List, previously contained very little information on the configuration of each series, only the Brief Description text, number of players and time of next update. This has been enhanced with inclusion of some basic configuration information such as would be present on a v2.8 server's Game List.
- History -
- The system now writes the history of each game to a separate HTML file, as well as showing recently concluded games in the History Viewer. The file name format is <series_name>.<game_number>.html, where <series_name> is the name of the series as it appears on the Game List except with any spaces replaced by underscores. The location of these files is a server-configuration option, but is recommended to be the history subdirectory of the Support Directory. Therefore, for example, if you wanted to see the history file for Galactic Powers Game 37, a good guess would be support/history/Galactic_Powers.37.html.
- Previously, the result of drawn games was not written to the History text, giving the impression of a game left hanging in mid-air. This has been fixed.
- Game-End Notification - A player who has been nuked, annihilated or invaded, or has surrendered, out of a multiplayer game before the end, is now notified when the game ends, in case he is curious to inspect the history file for the game.
- Auto-Update - The JavaScript code which forced a Game Screen refresh at update time, and that which enabled the use of Graphical Buttons, were conflicting with each other, causing unpleasant side-effects if players selected both options in their user profile. This problem has been rectified.
- JavaScript Timer - If enabled by the User Profile option Use Javascript, each Game Screen shows a countdown field giving the amount of time remaining until the next update.
- Update Text - The message within the Update Text showing that a Carrier had taken damage was causing all preceding Update Text to be discarded. This has been fixed.
- Text Color-Coding - To distinguish data items from header and label text, all data items within Game Screens and the Game List have been color-coded to be a cream color, regardless of the text color specified for server or series.
- Planet Color-Coding - Planet icons displayed on the Map Screen representing uncolonised planets are now distinct images, depending on the greatest resource allocated to the planet. This enables predominantly agricultural planets, for instance, to be easily disinguished from mining planets by their different color. However, it is the server administrator's choice whether the three icons displayed are actually different.
- Tech Screen - The Tech Screen layout has been revamped to improve readability and item alignment.
- Ships Screen - Between v3.01.4 and v3.01.5, the order in which ships were presented on the Ships Screen was altered to ensure that they appeared in the same order as on the Systems Screen. This meant that all the ships at a particular planet appeared together on the Ships Screen, which was particularly useful in large games. However, due to some concern about the implications of the change for combat resolution, this change was disabled in v3.01.11.
- Ships Screen - The order of columns on the Ships Screen table has been altered. The Type column, which previously appeared on the far right of the table next to the Orders column, now appears on the left, immediately after the Name column.
- Game Screen Headers - Now include Game Name and Number.
Administrator Interface
- Broadcast Message - A feature has been added which allows the Administrator to broadcast a message to all players.
- Game Spawning Error - The bug which prevented further games in a series from being spawned after the specified maximum number of games for the series had been reached, even though some of the games had finished, has been fixed.
- Database Purge - All the empires in the database whose record shows zeroes in the Wins, Nukes, Nuked and Ruined fields, and who are not currently engaged in any game, can be automatically removed by the click of a button on the Admin Menu. Another button causes all empires' database entries to be purged of spurious fields (which can arise in databases imported from earlier versions of the code).
- Weekend Update - The value of the Weekend Update checkbox on the Edit Series screen had its sense reversed. This has been fixed.
- ASCII Database -
- Default Database Type - Administrators can now choose in the server configuration area which database type, ASCII or encoded, is to be saved and loaded by default.
- Save/Load Buttons - Four buttons are now provided on the Admin Menu - Save the database and Load the database, which refer the encoded type, and Save ASCII database and Load ASCII database, enabling the administrator to choose the non-default type for manual saves and loads.
|
