Vanilla Netrek Server Development Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[VANILLA-L:842] List of bugs/features (INL robot stuff)

Things that I can think of at the moment that still need to be done:

Camera Robot stuff:

For some yet to be determined reason, torps have a "shadowing" effect.
That is torp info updates seem to be arriving at the client prior to
torp position updates.  This results in torps being displayed at their
old position for an update when new torps are fired.  (You might have
noticed this as an annoying blinking..)
This may be the result (but I _highly_ doubt it) of poor robot/daemon
synchronization.  In the current scheme the camera robot uses a timer
that goes off periodically.  The robot should really be woken up by
the daemon with a signal (like the ntservs are).  Similarly,
the INL robot should interact with the daemon in a more sane manner.  (But
we dont want to have to dedicate player slots to these robots.)

Currently the camera robot takes no arguments, and has "cambot.pkt"
as its predetermined output file.  Ideally it should have an option
to determine the number of updates per second, and should have the
ability to output to different files/standard output.

INL Robot stuff:

There is the problem of players advancing as guest while in INL.  Players
seem to like the idea of gaining rank quickly while playing clue games..
Unfortunately this breaks the relationship between the daemon and robot.
If the daemon calculates stats differently, how does it distinguish it
from a player's normal pickup stats.  This of course opens another can
of worms - should clue games ever set/reset a player's pickup stats.
I would be inclined to remove INL(in its current form) from the voting
list, and mandate that INL be set in .sysdef.  That way a server is
either a pickup server, or an INL server - never both.
(See my thoughts on INL pickup below.)
As another possible idea I have been toying with - a new player flag
PF_GUEST could be introduced that would instruct the daemon to treat
the player(regardless of whether or not his name was 'guest') as a guest.
That way players could advance at guest rates, and there would be no
conflict when it came time to write out a player's stats. (The daemon
would just throw away stats for guests.)  Of course, this doesn't make
it easy to return a player to normal pickup stats after the INL robot
leaves, but in practice I believe this would occur too infrequently to
cause much concern.

INL Pickup - If the INL robot is ever voted in, it should enter in
an "inl pickup" mode.  If the robot starts via .sysdef, or god's
intervention it should start in real INL mode.  This could be accomplished
with a simple command line switch..  The real effort is defining what
exactly is inl pickup.
Currently, when INL is voted in the robot closes down the pickup
queues and opens the INL queues.  However, the INL queues are commented
out in the default .ports file. (Thus, it effectively closes all queues.)
This has the result of basically crashing the server if INL is voted in when
the server god hasn't specificly prepared for INL to be voted.
As a minimum, I would declare "inl pickup" as an inl mode that uses the
standard pickup ports.  Ideally, is should also address issues of who/what
will captain, who can base, how can busted slots be free'd, etc..

INL Stats - Dave, where are you?  ;-)  I like the idea of keeping
inl stuff in the inl robot, and keeping pickup stuff in its arena.  However,
after attempting to implement stats via message parsing I have come
to the conclusion it will also need some daemon side assistance.  The
army tracking messages I sent out in my last patch is really more clutter
than usefulness.  However, instructing the daemon to keep multiple
files for multiple different modes isn't fun either..  One possible
solution would be to have the server log player stats for PF_GUEST
players(see above) each time they die.  That way the
INL robot could tag players to keep track of, and the daemon would then
log stats for them to the standard message log.  (IE, part daemon,
part message parsing..)  This has the advantage
of keeping the daemon's involvement in INL simple, while also keeping
unnecessary post-game back-tracking to a minimum.

Players seem to like to see the galaxy as it was won/lost after the
game is over.  Currently the INL robot resets the entire galaxy once
it detects a game has ended.

Hrmm..  Really the INL robot needs more play testing..

That is all I can think of at the moment.  It is difficult to describe
what I am thinking of on "paper" - if any of the above is confusing let
me know and I will attempt to elaborate on it.

-Kevin

-- 
 ------------------------------------------------------------------------
 | 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: