Vanilla Netrek Server Development Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[VANILLA-L:848] INL Robot todo-list additions
Here are some more things that still need to be done in the INL robot:
INL Timers - Game time, and countdowns all use timers in the INL robot.
These 'tick counters' in their current form are rather limited. One major
drawback is that it isn't possible to issue commands during a countdown.
For example, while the robot is counting down through the 10 seconds prior
to unpausing a game it would not be possible to reconsider, send a 'pause'
request, and keep the game paused. Message commands are deactivated during
a countdown to keep the code simple. (That way there is no possibility of
issuing a command that would mess up the countdown.) I would suggest
extending the timer syntax to make it more powerful to use, and make it
easier to detect which timers are currently in use. This could also lead
to code reuse in the puck/mars robots.
Pseudo Timeout vs Real timeout - In the legacy INL server, a timeout occurs
when the minimum distance between players is less than or equal to X. Where
X is a variable that decreases as time passes. In the current INL robot a
timeout is detected by interrogating player flags to determine what the
minimum alert status is. (IE. is everyone in green alert status, at least
yellow status, or are there players in red alert.) The legacy INL server
was able to detect minimum distance between ships easily because it already
calculated this when it determined the player's alert status. However, the
Vanilla server uses a more sophisticated algorithm to determine player
alerts. It cant provide minimum ship distance in its current form. The
easy answer is - just have the INL robot check all the players and
calculate the minimum ship distance. Unfortunately, calculating this value
could be as high as 2^16 distance calculations. It is not a trivial
calculation.. (Presumably this is why the vanilla server implemented a
different algorithm.) The other alternative is to just leave the robot as
it is. Is it really necessary to use a discrete scale for detecting
timeouts? If it is, I would suggest extending the alert status checker in
the daemon to check for a pseudo alert boundary that would be specified by
the INL robot. (If anyone is interested in coding this, let me know and I
will elaborate.)
Guests can play in INL games - As was brought up in the messages with Dave
Ahn, the INL robot permits players named 'guest'. This really messes up
the stat calculations if more than one player is named 'guest'. (Actually,
it is a problem if any two players share the same name.) I think a new
.sysdef entry (something like 'GUESTS=NO') would be a fairly simple way of
solving this..
Automated stat generation/packaging/shipping - The legacy INL server has
the ability to declare games as official. This causes the logs and stats
to be packaged and mailed automaticly.
Reservations - The legacy INL server has the ability to reserve games. I'm
not sure if programming this in the robot is necessary - a simple html/cgi
script would probably be easier to implement and easier to use.
To recap, these are the items I listed in my last message:
Players like to play at 5X DI rates. (Like guests do.)
INL Pickup - If the server is "voted in" it should not attempt to use the
INL ports. It should start in a "clue-bot mode"..
INL Stats - PWstat generation.
Galaxy resets at end of game.
If anyone is interested in coding any of the above, please let me know
first. (We dont want two people coding the same things..)
--
------------------------------------------------------------------------
| Kevin O'Connor "BTW, IMHO we need a FAQ for |
| koconnor@acsu.buffalo.edu 'IMHO', 'FAQ', 'BTW', etc. !" |
------------------------------------------------------------------------
+
++ Vanilla-l Mailing List ++
To unsubscribe: send "unsubscribe vanilla-l" to majordomo@real-time.com
For more information: http://archives.real-time.com
Follow-Ups: