Thursday, October 3, 2013

Starship Traders CONFIGME File

From:  http://librenix.com/sst/CONFIGME :



Instructions for the configuration of SST don't yet exist!
You should be able to figure some of it out, however, by
logging in as the Sysadmin account, typing Q (for quit)
followed by C (for communications menu) and playing 
around with the numeric options presented there.

Meanwhile, until some proper documentation is written, 
here's the short form: A clue for each option in the
Sysadmin menu:

0) list a file intended to give gameops an overview of
   monitoring and policing a game.  

1) edit user (player) accounts
   o Enter an access level, ie. 40, to list all active players
     within this game who are at access level 40.
   o Enter a player name (completely) in order to edit that
     player's account
   o enter ALL to list all active players in that game

2) Configure timelimits.  Timelimits for all access levels
   are set to 4 hours per day, the maximum.  For admin 
   accounts with an access level over a certain threshold,
   the daily timelimit is not enforced, only the session
   timelimit.  Note that admin accounts should not play
   in the games as they have certain advantages!

3) Control the access levels.  This command lets you set the
   access level necessary to access any command.  For example,
   annoying players might have their access level lowered below
   the level needed to send messages.  If BOTs (automated 
   'players') become a problem on your system, you might raise
   the level needed to use telnet mode (it's much easier to 
   write a BOT for telnet mode than WWW mode) above 60 so that
   only trusted players who you explicitly raise to level 61 or
   above can use telnet.

4) This is a big one: it lets you control lots of miscellaneous
   parameters.
   0] the 0 submenu lets you change the IP address that the
      game uses, necessary if you move your system to a new IP
      address. 
      the 0 option also lets you change the maximum number of
      players given concurrent access to your system.  This
      requires a file in the main game directory that is 
      8 bytes long containing the number of players on your
      system.  I use a script to scan once per minute, count
      the number of players logged in, write out the number, 
      then move it to the name 'copies' in the game directory.
      I plan to provide an example script soon.
   1] Web user percent of maximum concurrent copies.  Again, 
      this option doesn't do anything without the file mentioned
      above.  When that file is present, this limits the percent
      of total users that can be on using web mode.  It isn't
      really very useful.  I leave it at 90% so I can always
      get in using telnet mode in an emergency.
   2] Logging options.  By default, SST creates no logfiles.
      However, you can create summary logs by setting this
      option to '1'.  Options '2' and '3' are for debugging
      and are ordinarily not used.  The logfiles created by
      options 2 and 3 can be enormous.  Use only in emergencies!
   4] New users initial home game: This controls where newly
      registered players start out.  You can set it to the
      number of any valid game, but normally, leave it at '*'.
      The '*' setting lets you control whether new players go
      into either the newest reset game or a random game, or
      to divide them between the two options, as described 
      below in option 6].
   5] assign games to ladder tournament levels: 
      SST will run as an ongoing, open-ended, tournament.
      Assign a block of games to level 1 (ie. games 0-24,
      not all of which need to be active games) and assign
      a promotion percentage.  Then, players who end a game
      in that top (promotion percentage you assigned) will
      automatically get promoted to the next level game.
      Note that this ladder only includes the 'home' games
      and doesn't include any optional games, outside the
      games defined in this option.  In the default
      configuration, games 0-174 are reserved for the 
      tournament mode.  Just configure game 25 to have an
      active game in the second level, set a promotion
      percentage on game 0, and you'll be underway.  I
      recommend that you synchronize the beginning and
      ending dates and times of all the games in the
      tournament!
   6] assign newbies to random versus recent games:
      This option lets you pick a percentage from 0 to 100
      of new players to assign randomly across all level 1
      games, as defined in 5] above.  Option 4] has to have
      newbie home game set to '*' for this to work, of course,
      as discussed in 4] above.  For example, if you had
      one level 1 (newbie level) game and it started to get
      too crowded, you might setup game 001 as well.  Then, 
      if you set this option to 50%, half of all newbies would
      be assigned to the newest game (001) and the other half
      would be randomly assigned to either 000 or 001, resulting
      in 75% of new players going to the newly opened game.
   8] as your user file starts to fill up (somewhere around
      45000 accounts) old, inactive players will be purged to 
      make way for new players.  You can prevent anyone from
      being purged this way by setting thier access level to
      this auto-purge threshold or above.  If you don't want
      anyone who ever achieves the title of +Starship Master+
      to be purged, set this limit to 60.
   9] time limit exemption level: This lets you prevent admins
      from using up their daily allotment of time and being
      unable to get back into the system.  No one with an access
      level at this threshold or above should actually play in
      the games, as they have an advantage.  However, you might
      set up a special, admin-only game, where normal users
      won't be able to play, for admins to take out their 
      frustrations.
   L] player density setting: this lets you control how fast
      game maps expand, as new players enter.  If you set it
      at 10, each game will expand by 4000 sectors for every
      (approximately) 10 active players there.  Note that, 
      for each individual game, you can override this system-
      wide setting to have special games expand faster or
      slower than others.
   M] mapsize to build new games: This setting controls how
      big new games that you create can be.  Note that every
      10,000 sectors consumes approximately one megabyte of
      disk space, so a 256,000 sector game's map file will be
      about 25 megabytes in size.  
   I] set IP logging: this option lets you limit how many
      different accounts can play from a single IP address.
      It doesn't solve the problem of some players running
      more accounts than allowed, but it helps.  The game
      is currently configured to allow no more than eight
      accounts from any one IP address if this setting is on
      so if your policy is to allow fewer accounts than that
      per player, IP logging shouldn't cause many problems 
      and will probably inconvenience cheaters significantly.
      I plan to make this more configurable in the future.
   J] initial javascript settings for new players: This
      controls the initial javascript settings each new 
      account starts with.  You can set it to alert them
      when a page or their session times out, and you can
      cause it to put the cursor in the text box automatically.
      Note that each player can configure these settings for
      their own account; this just lets you control it until
      they figure out how.
   *] Admit no new players: This option lets you turn off the
      acceptance of new accounts, and, after that, to turn 
      admission of new accounts back on again.  If you want
      to strictly limit the players in your system, for 
      example, until a game end, you can simply turn off new
      accounts for the duration of the game.
 
5) set up a game, turn off a game, change a game name:
   1] message base size in 64-byte blocks: Set this number to
      non-zero to activate a new game.  Set it back to zero to
      deactivate an existing game.  I set all my games to 2048
      blocks, to build a message base of a total of 128K in
      size.  When the message base fills up, it starts to 
      recycle old messages, so it doesn't grow or move around
      on the disk.  
   2] Message size limit in 64-byte blocks: I keep this at 64.
      If you use a very small message base for easier policing
      and less room for flamewars, you might also want to lower
      this maximum size of a single message.
   3] Gameboard access level: In addition to a player's home
      game, they can also play in any game that has an access
      level equal or lower than their own, assuming they also
      have access to the Jump command, controlled by 3) above.
      I run several 'open' games that allow players from all
      of the tournament games to play together.  I also have
      games with access levels of 50 and 60 to allow veterans
      and +Starship Masters+ exclusively to play in them.
   4] You should name any special game so that people can  
      easily identify it when they use the Jump command.  My
      Level 60 game is named "Master Game -- Come on in!".
      That invitation can only be seen by players who have 
      attained the title of +Starship Master+, of course, since
      it correlates with Level 60.

6) gameboard statistics: this simply tells you how many
   players have access to each game.  A game with fewer than
   about five players won't show up at all in this list.

7) list logfile: this lets you list the logfile remotely, if
   you have enabled logging in 4) 2] above.  If your logs are
   very large, you can search for a particular string with the
   / command, but otherwise this command will not be a substitute
   for any better way to examine your logfile.

9) configure a game that is already set up:  This option lets
   you control the tunable settings of a particular game.  To 
   configure a game, you must first Jump to that gameboard, 
   unless you are already there (as is the case with a brand new
   system with only a single game 000). This one lets you:
   G] Adjust the 'gamecycle', the period of time (in days) that
      ports and planets can accumulate inventory.  The lower this
      setting, the faster they fill up, the quicker their prices
      recover from trading (or a game restart), and the lower the
      total inventories become.  I keep mine at around 7 days.
      This option also lets you set a game's starttime back to
      3am, system time.  Since the enddate is controlled by the
      startdate, it also will move back to 3am, resulting in the
      game resetting in the wee hours of the morning when the game
      finally completes. I set all my games to start/end at 3am.
      Once set to 3am, the game will always remain with a 3am
      start and reset time.  
      Bypass the 3 am option and you'll get the option to move the
      start date back or foward by one hour or one day.  This is
      useful to synchronize a new game with some older games.  Note
      that, once synchonized, it is no longer the 'newest' game
      for purposes of assigning newbies disproportionately, so I 
      set any new game an hour newer than the older ones until its
      population catches up with the older ones.
   E] Enddate: This should more properly be called 'game duration'.
      Enter 70 for a ten-week-long game.
   A] Daily fuel (antimatter): This controls how much fuel each
      ship is issued and, therefore, how much they can move around
      within the game.  I have most of my games set between 360,000
      and 480,000 grams of antimatter per day per ship.
   B] Basecost: The price, in microbots, of a level 1 starbase. 
      This setting can dramatically change strategies and tactics
      within a game.  Very cheap starbases has far more of an effect
      than very expensive starbases.  Left alone, it will stay in
      a nice middle range.
   W] Wargame: Turn this on and all military activity will be prevented
      until the game midpoint.  No attacking, no starbases, not even
      any defensive fighters.  Come midpoint, however, and things get
      interesting fast as people generally have built up huge arsenals
      by then.  The wargame option also works quite well in conjunction
      with team-only games -- games that *require* you to be in a team
      by midpoint in order to continue playing.  Without the Wargame
      option on, non-team players can damage a team prior to the 
      midpoint, resulting in a compromised game.  I always use the
      wargame option in my team-only games.
   N] No telnet: Turn this option on to make a game usable from web
      browsers only.  This prevents telnet users from entering the
      game, including the Sysadmin.
   I] Inherit: Set this to any number from 0 to 25 to allow players
      to inherit a percentage of the reputation points of the players
      whose ships they destroy.  For example, set it to 20 to allow
      players to take twenty percent of a victim ship's reputation
      points when they destroy the ship.  Note that this setting has
      no effect on how many reputations points a player lose when
      their ship is destroyed; they always lose 25%.  Set Inherit
      to 0 to disable the capturing of reputation points.
   S] Signcost: not very useful since it only controls the price of
      a graffiti beacon.  I generally ignore it and let it randomly
      fluctuate around a very cheap price.
   H] Startholds: This controls the amount of holds each new player
      starts the game with, as well as the minimum and maximum holds
      a ship can contain.  The minimum is one half this value; the
      maximum is double the value.  
   Z] Mapsize: this lets you manually expand the map, in case you 
      might ever want to.  Caution: don't ever reduce the size of
      a map once players are in it.  They can lose resources that are
      in the newly off-limits areas.  Even a ship might be up there,
      so you can really screw up a game trying to shrink a universe!
      This option also lets you set a map to be reused in subsequent
      games.  In such a case, all the careful movement of planets
      and ports, all the mapping and secret knowlege of galaxies is
      not lost when the game resets.
   R] Edit sector record: this lets you manually edit a sector of
      a game universe.  Normally, you wouldn't do that, but if you
      are setting up a very 'special' game with a few very rich
      planet/port combinations, you can.  You can also link different
      galaxies together with one-way or two-way connections.  
      I rarely use this one.
   P] Move planets: There was a time when planets and ports were 
      immobile.  You can bring back those days with this option and...
   O] Move ports: You can turn off player's ability to move ports
      with this option.
   T] Team size: set the maximum and minimum team sizes with this
      option.  'Normal' games have a minimum of 0 and a maximum of
      5-20 ships.  You can also set up a no-team game by setting the
      maximum team size to 0.  By setting the minimum team size to
      non-zero, however, you can create a very different game.  This
      is the team-only game, discussed above in the Wargame discussion.
      In a team-only game, only the team rankings matter, so players
      are allowed to exchange fighters, and pool their resources in
      the building of starbases.  Don't be alarmed if, in a team-only
      game, a single player suddenly has a huge score.  It only means
      that player has taken control of one or more large team 
      starbases and maybe collected some team fighters as well.
   L] Live battle delay: this controls how many second elapse before
      an attacked player can regain control of their ship.  I have it
      set to 4 seconds, the minimum.  Under slow conditions, such as
      a very busy server on an ISDN line, a higher setting might be
      more appropriate.
   X] Xmit log: this lets you log radio messages to the logfile.
      I put it in so that I could monitor the type of questions asked
      in the newbie games and try to preemptively fix any parts of 
      the game that caused confusion.  It didn't help much, but it
      did clue me in to a couple of things that were stupidly designed.
      You may or may not have a use for it.
   M] Port productivity multiplyer: This lets you increase the amount
      of goods all the ports in the universe create.  Each unit you
      raise this number adds 10% more productivity over the base
      amount of each port.  By setting this very high, you can create
      a very rich universe, which if physically small, might create
      an interesting play environment.  I've only used this to 
      salvage games that I initially configured as too small.
   C] Create bunkers: This lets you disable bunkers entirely or
      limit their size to any level up to 50.  Around 25 is a nice
      level that is in balance with other default game features.  
      However, raising this toward the upper limit of 50 will change
      the game quite a bit since bunkers quickly become the optimum
      defensive mechanism in such a scenario.
   V] Override map expansion: this option lets you exempt a game from
      the system-wide setting of player density in 4) L] as discussed
      above.  Games with lots of newbies get this setting raised at
      my site; conversely, the expert-level games get a lower setting
      so that the map expands larger with fewer players.


There are a number of files that you might want to customize.
Under the main game directory, the files ending with the 
extension .html and .txt may contain site-specific information
and links.  In particular, change linklist.html so that it
points back to your system and not starshiptraders.com!

linklist.txt also should be changed to refer to your system
and you might want to remove the references to the starship
traders mailing lists there.

hello.html, newlead2.html, and newlead.html are the files that 
show up on the login page.  Those files are optional -- you might
even like the look of the login page with those files removed.
More likely, though, you'll want to customize some text, and
maybe put a banner or something in there.
       
Also, you'll want to change the text in welcome.txt to issue
a welcome to your own site.

pagetimeout.html and webtimeout.html also contain links back
to starshiptraders.com.  Change those links to point to your
system.

In general, it's best to examine all of the .txt and .html files
in the main game directory and modify them as needed.  Make
sure to back them up before you start!

Note that almost all of these .html files, with the notable 
exception of pagetimeout.html, are only partial html pages.
The game generates the headers and footers for most pages so
don't add html, /html, body, and /body tags to those pages!
Also, some pages may get their carriage returns converted into
html <br> tags.  I'll be trying to fix this so that more pages
behave properly, but, for now, change carefully and note the
effect your changes have.  And keep the originals handy to 
replace one that behaves incorrectly until you can fix it. 

No comments:

Post a Comment