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.
Thursday, October 3, 2013
Starship Traders CONFIGME File
From: http://librenix.com/sst/CONFIGME :
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment