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