Lugdunum Stellar Crisis Services

SC Logo

Stellar Crisis v3.2 - Software Release Notes
Andy Graves - 18/3/2000

Stellar Crisis spacerule

Addendum - Changes since v3.2.0

v3.2.1

7th March 2000
  • Lost Virgin Morphers - When v3.2 was installed at Lugdunum, over the database inherited from v3.01.5d, it was discovered that the existing new (unmorphed, invisible, sometimes called virgin) Morphers were trapped by the code change in a state of limbo. They appeared to be cloaked, though they had not morphed to Cloakers, and so they could neither uncloak nor morph. This version of the code included a small, hurried patch to allow these ships a one-time opportunity to uncloak.

v3.2.2

18th March 2000
  • Cloakers - Although since v3.01.11 there has been a series option determining whether Cloakers were built cloaked or uncloaked, in series where they are built uncloaked, they nevertheless did not take part in combat on the turn that they were built. This anomaly has been corrected in this version.
  • Morphers - It was stated in Changes between v3.01.5 and v3.01.11 that a Morpher changing into a Cloaker would either be invisible immediately or not depending on the Cloakers built cloaked series option. This was not in fact true - they were immediately invisible regardless of the value of that option. This version now works as previously stated.
  • Ratios Line - The Ratios Line now appears on the Map Screen.
  • Mini-Maps - The single-planet Systems screen obtainable by clicking on a planet in the map, now includes a small extract from the map as well, showing just the immediately and diagonally adjacent planets. This extract is also clickable.
  • WebTV Mode - When this mode is selected, it is possible to limit the size of the map displayed on the Map screen. A field labelled Map Size appears to the right of the Exit button, into which a number may be typed. A value of zero indicates normal operation, but when a non-zero value is given, the concept of a Map Center is introduced. To begin with, the center is the homeworld. The map displayed shows only planets which are no further from the Map Center than the given Map Size, either orthogonally or diagonally. Therefore, for example, a Map Size of 3 gives a map of at most 7 by 7 planets. A menu of explored planets is provided at the bottom of the map which permits selection of a new Map Center, which takes effect when the Map button is clicked again.

v3.2.3

4th April 2000
  • Fleets Screen Next BR - The feature which caused a Next BR column to appear on the Ships screen, under the control of the User Profile Option Show Next BR, has been added to the Fleets screen as well. To complement this, the projected total fleet strength for next turn - Next Str - is also shown.
  • Planet Icons -
    • Annihilated Planets - The image of an annihilated planet, planet2.gif, which has traditionally been shown to distinguish planets that have been destroyed from those which may be colonised (or jumped to), was not being displayed on maps due a to a bug introduced between v3.01.5 and v3.01.11. This has been fixed.
    • Equal Minerals and Agriculture - When Minerals and Agriculture for a planet were equal, but Fuel was less than either, the map nevertheless showed planet.gif (the Fuel-planet icon). Of course this only affects servers where the three images are actually distinct, but anyway, it is now fixed.
  • Admin Empire Viewer - A small bug in the Administrator's Empire View screen, whereby the indication of the Empire's use of WebTV Mode had fallen out of the table and was appearing at the top of the page, has been fixed.

v3.2.4

26th April 2000
  • Series Definition - Some of the less reasonable defaults in the Admin Start New Series screen have been altered. Also, it has been made possible to disable the Maximum Ships per Player restriction altogether by specifying a zero value.
  • History Map Bug - When a game ended with the remaining players all ruining simultaneously, the attempt to draw the game map for the History file failed, causing a Roxen Error screen and keeping a null game on the database. This has been rectified.
  • Improved Admin Cheat Logging - Multi-empire warnings are now written to a separate file, in a more parsable format, to facilitate reporting.

v3.2.5

7th August 2000
  • Game Lists -
    • Standard - a new server option has been added: Split Game List. If it is set, the Game List is separated into three screens, showing Current Games, Open Games and New Games respectively, each with its own button. The default screen on first logging in is the Current Game List showing only those games in which the empire is already engaged. The Open Game List shows those games which already have other players and which this empire may join; the New Game List shows games this empire may start. If Split Game List is not set, the Game List behaves as before.
    • Detailed - since v3.2.0 the information provided by this potentially huge page has been duplicated by the Series Details buttons and the Series Constants section of the Info screen within games themselves, and so is effectively redundant. The button has been removed. Programs needing to access the page, such as the GAP, still can, however.
  • History Viewer - the items in the History menu are now in chronological order, without the strange discontinuities.
  • Gate Range - under previous releases of v3, where the series definition specified a finite range for Stargates or Jumpgates, the effective range, and therefore whether the gate operation took place, was determined as a function of the Current BR of the gate before combat took place. This was anomalous with all other BR-dependent special operations, and has been modified to use the Current BR after combat as the basis for determining effective range. Therefore a gate which is set to send to the limit of its range will now fail if it suffers damage that turn.
  • First Empire Map Visibility - a series option, Blind until Start, has been added which, if set, prevents the first empire in a game from viewing the Map and Systems screen until the second empire has joined. This is intended to counter the phenomenon of empires joining and quickly quitting games in search of what they consider to be a favorable starting position.
  • Bridier Ranking -
    • Bridier Awards - are now based on empires' Bridier status recorded at the start of the game, rather than the current status at the time the game ends.
    • Bridier Potential - the Bridier rank which the empire stands to gain is shown on the Open Game List entry for each ranking game. This enables potential second players to avoid games in which the rewards will be smaller than they would choose to play for. On the Current Game List, both gain and loss potential are shown, for information.
    • Challenge Level - the empire who starts a Bridier ranking game, however, does not have the luxury of a Bridier potential display, so it has been made possible to select a Challenge level on starting such games, by selecting a value from 0 to 10 from a menu. Depending on the level selected by the first empire, a would-be second empire may be refused entry into the game. If the Bridier status of the second empire is such that the gain in rank available to the first empire would be less than the Challenge level, the second empire is turned away. The default Challenge setting of zero allows any opponent to join the game. To refuse an opponent whom beating would gain you ten or more Bridier points is not possible, though, as ten points is the default stake between equal, established empires.
    • History Display - The Bridier Awards table shown at the bottom of the History file of each ranking game now shows four rows, rather than the former two. Basis is the Bridier status of the empires when they joined this game, from which the Awards are calculated. Before and After show the effect of applying the awards to the status at the end of the game.
  • Mirror Map Generation - two alterations to try to make mirror maps more interesting to play:
    • Homeworld Placement - choice of homeworld location has been loaded to make it slightly less likely that they appear next to border worlds and thus only two hops from the enemy home.
    • Links Between Border Worlds - it is now possible for links to exist between border worlds.

v3.2.6

18th August 2000
  • Map - Cosmetic tidy up. Spacer images have been included to prevent table collapse after engineering. Also, since the newline tag was removed from the names of annihilated planets to prevent it from fouling up the Ships screen, the lack of it has been fouling the map instead, so for map display purposes only, it has been put back.
  • Carriers - An obscure bug arising from carriers selected for DEST when their current BR was less than the Carrier Loss setting has been fixed. Thanks, Eric.
  • Built Planets - the Max Pop setting for created planets was often wrong in series with a ranged average agriculture value. Corrected - again, thanks to Eric.
  • Series Details -
    • Restricted Techs - Allowed number of Restricted: and Number of trade-ins: are only shown on the series details if any Restricted Techs are actually specified for the series.
    • Ship Limit - Series without any limit on the number of ships now shows as No Limit rather than zero.
  • End of Game Report -
    • Bridier Games - The award table is now shown following the fact of win or loss of game.
    • Report to Ex-Players - Small cosmetic tidy-up.

v3.2.7

28th August 2000
  • Bridier Awards - A bug which allowed the Bridier index value to drop below the permitted minimum of 100 has been fixed.

v3.2.8

7th September 2000
  • Bridier Game End in Ruin - A recently-introduced bug which caused Bridier ranking games that ended in the ruin of one of the players to crash, resulting in an unfinishable game on the database and no corresponding awards, has been fixed.
  • Code Change for Roxen v1.3 Compatibility - It was discovered that v3.2.7 would not load as a module into Roxen Challenger v1.3, because an obscure and no-longer-needed piece of Pike syntax had been used in the definitions of the Database Dump functions. The offending syntax has been corrected and v3.2.8 now loads successfully into Roxen v1.3.

v3.2.9

22nd September 2000
  • Sensitive Map - Under the control of a new Profile Option, Sensitive Map, a small magnifying glass symbol appears at the south-west corner of each planet on the Map. Wave your mouse cursor over this symbol, and a window appears with details of the system, including the ships present.
  • Option Layout - The layout of the Options checkboxes has been altered on the Create New Empire, Edit Profile and Admin Empire Editor screens. The four Javascript-related options (including the new Sensitive Map option) have been separated from the five other options. Some other redundant material has also been removed from these screens.
  • Code Change for Roxen v1.3 Compatibility - Another small change was required to account for a difference in Pike behaviour between Roxen v1.2 and v1.3. This one was in the Top List code.
  • Redundant Header Info - Empires who have not selected the Update Countdown option no longer have a redundant indication of time until next update in its place.
  • Themed Images - themability of certain images has been rationalised.
  • Victory Sneer - a message to be sent to your enemy at the moment of victory may be specified in your profile.

v3.2.10

12th December 2000
  • Game Passwords - The first player to enter a game has the option of setting a password on the Info screen, until another player joins. Subsequent entrants must provide the password in order to be allowed entry to the game. If it has been set, the password is shown on all players' Info screens until the game closes, and an indication that the game is password-protected is shown on the Open Game List.
  • Auto-Update - The Auto-Update feature was found to be disconnected from its Profile option - that is, it was operational whether the user had selected it or not. Now, it's possible to disable it by deselecting the option.
  • Empire Creation Screen - The first password field on the Creating A New Empire screen was redundant, and has been removed. Thanks to Jerome for pointing out this and the previous problem.

v3.2.11

9th January 2002
  • Combat Resolution - In the past, a fleet having a fuel ratio of less than one when going into combat would suffer degradation to its ability to inflict damage on its opponents, but its resistance to damage would not be affected. This sometimes meant that two closely-matched under-fuelled fleets might meet, and neither have enough offensive power to destroy the other outright. In this version, inadequate fuel supply affects resistance to damage as much as it affects destructive power. Thanks to Max and Jerome for suggesting this fix.
  • Game Passwords - This feature has been modified to work correctly with multi-player games. The previous implementation worked properly only with grudges. It has been restricted to use with 'Spawn First' series - that is, those which spawn a new, empty Game 2 as soon as one player enters Game 1, as opposed to the kind of series which doesn't spawn Game 2 until Game 1 has closed - because otherwise, it becomes simple for a miscreant to lock the series up indefinitely. Also, the screen which asks for the game password behaves correctly if the Return key is pressed rather than the Submit button clicked - formerly, this caused a crash.
  • Unend Turn - After pressing End Turn, but before the update takes place, players have the option of rescinding their commitment using an Unend Turn button.
  • Update Since Last Access - If there has been an update since a player last received a game page from the server, then it is possible that pressing End Turn on that page would result in the player committing on a later update than the one intended. Previous versions had an unreliable defence against this situation. The defence has been improved in this version, and has also been extended to notify players when pressing Unend Turn has had no effect because the update has already occurred.
  • Sensitive Map Population Details - In build-invisible games, the Systems and Map screens can show different population and maximum population figures, depending on whether the owner of the system is looking, or another player (See Changes since v3.01.11, the section on Invisible Population Changes). Previously, the pop-up windows associated with the Sensitive Map option were not sensitive in the same way - they always behaved as if the viewer was not the owner of the system. In this version, the pop-up windows display the same Pop and Max Pop figures as the Systems and Map screens.
  • Login Screen Cosmetics - The position of the Login button has been altered. Table rendition under MSIE seems strange to me.
  • Bright Red Text - A bug has been fixed which associated the de-selection of the Auto-Update option with bright red game text.
  • Admin Reset Next Update - This function has been rewritten to save, rather than load, the database prior to operation, and to return a meaningful page to the Administrator.

v3.2.12

25th January 2002
  • Game List Sort Order - It is now possible for players to determine in their Empire Profile the order in which series appear on Game Lists. Primary (1st), secondary (2nd) and tertiary (3rd) sort order can be specified from a selection of six criteria, ascending or descending. For instance, if you play only longterm games, and prefer games with a low Tech Advance multiplier, you might choose 1st: Update Time / Descending and 2nd: Tech Advance / Ascending, to ensure that the games most likely to be of interest to you are near the top of your Game Lists.
  • Bridier Inadequacy - Open Bridier games for which the empire is ineligible, due to a high challenge level having been set by the first player to enter, no longer show up on the Open Game List. Thus the message "Sorry, your Bridier status is inadequate for that game" should not appear under normal circumstances. However, password-protected games show on the Open Game List of every empire that is eligible to play that series, because knowing the correct password is considered adequate whatever the challenge level.
  • Hidden E-mail Addresses - For security reasons, it is not a good idea for an administrator to send an empire's lost password to any e-mail address other than the one registered in the Empire Profile. However, players often choose not to register an e-mail address because they don't want other players to know who owns their empire. Therefore, it is now possible to register an e-mail address, but hide it from other players, using the Hidden: profile option.
  • "Always Available" - If a restriction is placed upon the times of day a series is available to play, it is shown in the description of the series in the Game Lists. If there is no such restriction, however, it isn't really necessary for the description to state explicitly that the series is always available, so that statement has been removed.
  • Stat Viewer - The Stat Viewer screens in both the Player and Admin interfaces have been rationalised (some code duplication eliminated) and tidied up. In particular, the team-related fields which have been redundant for some time have been removed.
  • Series Parameters - The Series create and edit screens in the Admin interface have been tidied up, by the removal of the "Restricted Games" and "Joining Password" fields. The functionality associated with those fields was never fully implemented, and has hopefully been superceded by the Game Password feature anyway.

v3.2.13

30th January 2002
  • End Turn Malfunction - The bug fix described in Update Since Last Access uncovered two other bugs, resulting in mayhem as the End Turn button suddenly became unreliable in No Weekend Update games when pressed during the weekend. Therefore the fix has had to be abandoned, and the defence is once again useless. Beware. This problem will be addressed again when the update-timing code has been revamped.
  • Admin Stat Viewer - A minor layout bug introduced in the previous release was fixed.

v3.2.14

27th February 2002
  • Game List Shows Idling - An empire who is idle in a game now sees a report of the fact in the Game List, if he cares to look.
  • Max Pop For Used Planets - When a planet is recolonised, its initial Max Pop setting is now determined as for new planets, dependent on its resources. Prior to this change, it was determined by what the previous owner had set it to.
  • Message Truncation - Certain update messages were overwriting, rather than being appended to, previously stored update messages. This has been corrected.
  • Admin - Mountpoint Issues - Some problems associated with having the Stellar Crisis virtual server mounted on a virtual directory other than / have been dealt with.

v3.2.15

28th June 2002
  • Update Code Crash - A morpher which was consumed by the effort to morph, while in a combat zone, could cause the combat code to fail, resulting in unresolved combat and ship orders not being completed for the update. This should no longer be a danger.
  • Upload a Custom Icon - This feature has been reinstated, and now even appears to work correctly. It is governed by a server-level Enable/Disable option. Note to Administrators - custom icons are uploaded into /support/aliens/custom, so if the option is enabled, this directory must exist and be writable by the server. Also, for verification purposes, you should install the standard utility giftrans, preferably in /usr/bin.
  • Predictable Ship Destruction Order - For a long time the combat code has relied on a feature of the Pike language in which it is written to provide the necessary random element for determining ship destruction order. Recent tests have demonstrated that, at least on some platforms, this feature is not providing sufficient randomisation to prevent some players from predicting outcomes. Therefore, an additional explicit layer of randomisation has been introduced, to decrease the predictability of the order in which ships will be selected for destruction during combat.

v3.2.16

24th February 2003
  • Bridier Ranking System Enhancements - Significant changes have been made to the way in which Bridier awards are calculated.
    • Award Basis - Start or End of Game - When Bridier ranking was first implemented, the rank and index figures used to calculate awards were those available at the moment the game result was determined, ie. those from End of Game. In v3.2.5, this scheme was changed, because it was observed that a malicious player could spoil an opponent's award by surrending other games early, so rank and index figures from each empire were recorded at Start of Game for each empire to be used as the basis for the awards when the game ends. This scheme has also turned out to have a serious flaw - a new empire who starts a large number of long term games at once can still be earning 50 rank points for winning one of those original games, long after he has become established - and so a hybrid system is now used. Each empire's award is calculated based on its own Game End values, but its opponent's Game Start values.
    • Series Index - As well as the overall index, a table of series-specific Bridier indices is also kept for each empire. When calculating Bridier awards, if the overall index is less than the index relating to the series in play, then the average of the overall and series indices is used. Series indices are subject to decay in the same way as the overall index, except that each step of the decay process happens after a timeout period four times longer than the equivalent step for the overall index. This change is intended to reward empires who are successful in a wide variety of game types, in that they will become established faster and yet be able to gain more significant awards.
    • Index Reduction - The traditional method of decreasing the index value when a Bridier ranking game is completed is to subtract from the index the absolute value of the rank award. Some feel this results in establishment being achieved much too slowly. Therefore, a multiplier has been introduced as a server-level option. It may be set by the administrator to 1.0, 1.5, 2.0 or 2.5. If 1.0 is used, Bridier will behave in the traditional manner. If 2.5 is used, empires playing Bridier games will become established in a very small number of games, but the value of established ranks as a predictor may be impaired. It's a trade-off, so choose wisely.
    • Game List - For each Bridier Ranking series, the Game List reports your current series-specific index before the other details.
    • Diplomacy Screen - In Bridier Ranking games, the Diplomacy Screen listing now shows three Bridier values for each player - <Rank>:<Overall Index>:<Series Index>.
    • History Display - As a result of these changes the Bridier Awards section of the History file for each game has to be more complex, reflecting the extra value of series index feeding into each calculation, and the fact that the bases used for the winner's and loser's award calculations are different.
  • Cluster-Balanced Map Generation Algorithm - For 2-player games, there is now a third alternative map generation algorithm, combining some of the benefits of both Traditional (Random) and Mirror methods. For each game, the system generates fifty separate maps, and analyses each in an attempt to evaluate both its fairness and interest value. Fairness is gauged in terms of proximity to resources, and interest in terms of planet clustering in the area equidistant from the two homeworlds. One map is chosen which scores best for fairness among the twenty or so most clustered, and the other forty-nine maps are discarded. This method does not claim to produce perfectly fair maps every time, and it is expected that the evalution algorithms will be improved with experience, but even as it is, it should greatly reduce the incidence both of grossly unfair maps where all of one player's resources are gifted to his opponent by proximity, and spindly horrors where the area over which the game is fought and won is a single chain of planets.
  • Mirror-Map Resource Allocation - In games with Mirrored maps, the resource allocation algorithm was handing out too few resources to planets (by approximately one planet's worth). The bug which caused this error has been found and fixed.
  • Predictable Ship Action Order - It was discovered empirically that under the circumstances where two empires had invincible fleets, each over the other's homeworld, and both set to nuke, that the game would be won by the first empire to press End Turn. Though the exact mechanism by which this worked is still a mystery - probably buried somewhere deep in the Pike interpreter - another explicit randomisation has been added, this time to the order of ships' special actions. Tests now show that the order in which End Turn is pressed no longer determines the order in which nukes are executed.
  • Accidental Surrender Prevention - Following several complaints that empires have been surrendered from games without the owner's volition, a blinking warning message has been added to alert players to Diplomacy settings of Surrender, in case the setting is not deliberate.
  • Compass Points in Orders - Ship and Fleet Order menu options now include compass points to help the directionally challenged :)

v3.2.17

16th February 2004
  • ASCII Database Load - The Bridier Series Index feature requires a deeper level of data nesting in the players section of the database than was needed before it existed, necessitating enhancements to the ASCII Database dump and load functions. The required change was made to the dump_asciidata() function in v3.2.16, but load_asciidata() was omitted, meaning that v3.2.16 was unable to load a database it had dumped, if it included any series index information. This issue is now corrected.
  • Bridier Inadequacy - Modifications made in v3.2.16 for the new method of calculating Bridier awards, introduced a bug which resulted in players being told that their Bridier status was inadequate to join a game when this was patently untrue. This has been cured, with apologies to the insulted players.
  • Rejoin After Surrender - There have been several reports of merry mayhem ensuing, when a player who surrenders very early in the game is able to rejoin the same game before it closes. Therefore this has been made impossible. Once a player has lost a game, any attempt to rejoin it is met with refusal - "Sorry, you may not rejoin a game you already lost."
  • Administrative Improvements - The following changes, made by Rowan Deppeler and already implemented at the Stargate server, do not affect players but will be of interest to server administrators. All but the first change listed are optional at the code level, being activated by including the line #define STARGATE_ENVIRONMENT high in the code. If you have an existing server and do not want to alter its operating environment, do not define STARGATE_ENVIRONMENT. If you are setting up a new server, defining STARGATE_ENVIRONMENT is recommended, as the new layout is more intuitive and versatile. Here is Rowan's list of his changes:
    • Several syntactic fixes have been made to enable this version of the code to run under Pike v7.2.
    • Added 'doc_path' to separate online documents.
    • Added separate 'login_header()' function to allow modification of login form.
    • Added 'login_bg' to allow selection of the login form background image.
    • Changed 'searchpath' to 'datapath'. Used for all absolute file writes/reads.
    • Modified operation of 'dump_file'. Made relative to 'datapath' to make more intuitive.
    • Modified history save to relative path from '/support'.
    • Modified ASCII data dumps to include '.asc' extension.
    • Changed 'ad_name' to 'ad_login' to avoid confusion.
    • Added 'ad_mailname' for use in email links.
    • Added separate 'login_footer()' for login screen.
    • Cleaned up code to remove references to '/support' directory; images & html files.
    • Actually made the 'history' path do something.

v3.2.18

11th August 2004
  • Admin Reset Next Update - The change made to the administrative function Reset Next Update in v3.2.11 has been reversed. Here follows the sad story of why:

    • "The original implementation of the Reset Next Update administrator function first loaded the database, then for each game in progress altered the recorded time of the last update to the current system time. At the time of v3.2.11, I allowed myself to be persuaded that the load operation was a mistake, by someone who believed that the original author of the function had intended to incorporate a database backup step into the function, but had absent-mindedly mistyped load instead of dump. This was a complete misunderstanding of the purpose of the function and a disservice to its originator.

      "The first thing the server code does upon receiving a HTTP request, whether from a player or an administrator, is to check all games in progress to see if any of them are due for updates, and if so, update them. Now, when a database is loaded that is old - for instance, a backup is being restored from the time before some corruption has taken place - this normally very sensible first action can be extremely destructive. The administrator needs, under these circumstances, to be able to prevent updates that were due from being executed, and to be able to reset the time of next update to some way into the future, to allow players a chance to get back into their games. If the Load Database function and the Reset Next Update require separate HTTP requests, then the updates will necessarily be executed upon any newly-loaded database before they can be prevented. Therefore the database must be reloaded as the first step of the Reset Next Update function, or else the damage it is intended to prevent has already been done."

v3.2.19

28th May 2008
  • Saving History - A third database file has been added alongside the players and games databases. It's purpose is to save any information that isn't directly associated with players or games. At present it holds the Game History List and the Login Message. More items may be added later.
  • Empire Profile - Alien Icon - An exhortation has been added asking players not to use the icon chooser/uploader feature to create confusion.

v3.2.20

31 May 2008
  • Diplomacy - Validation of diplomacy settings has been tightened up. It may have been possible, before this fix, to hack a draw in a series where draw was not meant to be allowed.

v3.2.21

1 June 2008
  • Diplomacy - Begun the job of separating the Surrender and Draw series options. This change includes the beginnings of the necessary database modifications.
  • Game End Notice - The Game End Notice sent to the losers of each game has been enhanced to include a clickable link to the History page for the game.
Previous

Stellar Crisis spacerule

SourceForge Logo