complete works of sluggo I

Article 1                  [ top | bottom ]

Subject:      Re: Discussion on new pb and base labelling
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/04/28

In article ,
jgoodma1@cc.swarthmore.edu (Joseph Goodman) wrote:

> In article <3nr9jh$nnv@news.bu.edu>, y-tony@bu.edu (Yan Lee) wrote:
> 
> > I am not sure whether I am the only one who has this problem because I 
> > play on and black and white computer.  I think it is a great idea to 
> > label the pbs because it gives better communications.  However, I cannot 
> > tell how badly the pbs have been damaged now that they are labelled.  I 
> > suppose I could label and unlabel them constantly, but it is not 
> > convenient.  Rignt now I can't think of a good solution.  Does anybody 
> > have this problem too?
> 
> Yeah, this is a problem (happens in color too). I think a solution would
> be to have the labels placed to the side of the pill rather than on top of
> it?
> 

Doh, why not just hit cmd-p when you want to identify which pillbox you
are looking at and then toggle the labels off again when you are going to
attack?  It really doesn't matter much which pill you are firing at once
you are already firing, but the labels help identify which pills are
placed where, so that when you see an x appear on the display, you can say
"oops, there goes that pill back on base 2".  Personally, I think it is
fine just the way it is.

sluggo


Article 2                  [ top | bottom ]

Subject:      Re: BIG bug on 0.995.... pill taking by pushing other tanks
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/04/29

In article <3nv2cc$e48@news.bu.edu>, y-tony@bu.edu (Yan Lee) wrote:

>Stuart Cheshire (cheshire@cs.stanford.edu) wrote:
>: What do you do to something that's caught between an irresistable
>: force and an immovable object?
>
>: Someone just gave me a good suggestion: You destroy it.
>
>: Sounds good to me. What do happens to a tank when it is pushed into an
>: immovable object? It explodes, potentially damaging the tank doing the
>: pushing too.
>
>: Any objections?
>
>: Sounds like an interesting new way to take out newbies, without
>: fundamentally changing the game play.
>
>Heehee, it wil sure add some flavor to tank vs tank battles!
>
>Tony
>aka Hedgehog

Woo hoo!!!!!!!
Demolition derby!!!!!!!!!!!!!!!!!

sluggo


Article 3                  [ top | bottom ]

Subject:      Re: Things to be discussed/fixed about .99.5
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/04/30

In article , cls6@midway.uchicago.edu wrote:

>1. Command-V does not map to Paste.
>

yeah, this needs to be fixed

>2. Pushing a tank onto a pill is a cheap way of taking pills. WM and I
>took 16 pills in 2 minutes by just pushing each other onto them.
>

I think this was a result of fixing the bug in 0.99.2 which let you build
a pillbox underneath your tank.  Perhaps a better solution would be to
disallow building of a pillbox underneath the tank in the same manner as
buildings were not allowed to be built underneath the tank in 0.99.2. 
Also, in 0.99.5, this behavior (buildings underneath tank) is changed such
that rather than just a message saying "you cannot build under your tank"
a building is built then crushed into rubble.  My personal preference
would be to have the building of a wall or a pillbox result in a "the man
cannot build underneath a tank" message.

Something that I haven't seen mentioned yet that I really like is the new
feature that a tank landing on top of an enemy base does not convert that
base as it did in 0.99.2.  This eliminates the problem of base-lagging
while, at the same time, preventing people from stealing a base by leaving
alliance while on top of the base.

>3. Map Overview should either (my opinions here):
>
>        1. be removed.
>        2. be an option, like allowing hidden mines or bots.
>

I disagree completely with (1.) but I could see (2.).  Map Overview is
really the biggest new feature of this release and, although it still has
a few flaws to be ironed out, is on the whole a really cool addition.

>The reason being:
>        1. It favors those with larger monitors who can display it with
>        greater ease and size.
>        2. It favors those who have fast computers, since it takes
>        computing cycles to map.
>        3. It takes away from spirit of the game, where you used to
>        only see what was happening in your area, or limited to your
>        pill view.
>        4. It, in my experience, creates lag.
>

Well, (1.) and (2.) are certainly true to some extent, which is probably
the best argument for making it an option, as allowing brains which
provide mapping or other enhancements which may not be equally available
to all players in the game is an option currently. 

I do not agree with (3.), however, as the map overview is done in such a
way that the areas of the map which are actively visible (or are intended
to be, sans pill view bugs) are the same tank view and pill views which
were visible, albeit not as readily, in 0.99.2.  

As for creating lag, I haven't really experimented with it enough to tell
the difference in whether it is your perception of lag (jumpy graphics) or
an actual increase in ring delay or network errors which is influenced by
the increased amount of processing necessary to continually uipdate the
overview map window.  Although, I will say that in the past I have seen
people blame everything from frame rate to waving a bloody chicken foot as
a cause of lag.


>4. Pillbox and base numbers should be changed, to either:
>        1. Smaller numbers
>        2. Numbers *beside* the pills or bases
>        3. Flashing (like someone else suggested)
>
>The reason being:
>        It is currently impossible to see the damage of a pill
>        the way it is currently numbered.
>

Umm, it is *really* easy to turn pill/base labelling on or off by just
hitting cmd-p (pillbox) or cmd-b (base).  I think the way that it is
implemented right now is perfect, actually.  If you want to see which base
or pillbox you are looking at, just toggle the labels on for a second then
turn them off again when you want to start shooting at them (although I
would not recommend shooting at the red pillboxes because they shoot
back).

>5. Lockout should:
>        1. Be announced when you select it.
>        2. Only affect that computer that has it selected. (I've heard
>        conflicting reports on how it affects other people in the ring.)
>

I don't really see that (1.) is necessary, and it was my understanding
that the current implementation is (2.), that is, no one can join *your*
ip once *you* disallow new players.

>
>6. Autoscroll is confusing... even more than ever. I now have bullets
>flying at me from the edge of the screen.
>

Autoscroll is implemented a little differently, but it is consistent with
what people have been asking for on r.g.b. for a while as far as I can
tell.  It may take a little while to get accustomed to, but I would
suggest using it for a while before making a judgement of whether it is
better or worse.  In my first few games I didn't even realize it was
different, being so used to constantly hitting cmd-a and cycling the arrow
keys (which, btw, don't *have* to be the arrow keys anymore).


>Overall - great job, Stuart! Love the modal dialogs!

Yes, many thanks to Stuart and congratulations on a job well done.  The
movable modal dialogs are really nice, especially when grabbing that ip
from BoloFinder without having to completely quit (although having cmd-v
fixed would be even nicer :)).  A couple more of my favorite new features:

1.  Multiple keys for functions.
      Woo hoo!! now I can have those extra gunsight keys on my mouse-hand side!

2.  Status window shows tank/pill/base indicators during countdown.
      A lot of people don't use this much anymore (I guess they enjoy watching
      trees growing on their tarmac maps) but I like the idea of seeing how
      many players are in the game and who you are allied to, etc. before
      the countdown runs out.


Bolobolobolobolobolo,

sluggo


Article 4                  [ top | bottom ]

Subject:      Re: -knowing-
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/05/03

In article <3o6uck$t25@nntp.Stanford.EDU>, Stuart Cheshire
 wrote:

>In article  ,
>nobody@yale.edu writes:
>>I do not like ... the new lag effects ...
>
>My hope was that the new networking code should reduce lag.
>
>Given a particular ring delay, building should complete quicker, mines
>should explode more promptly when you hit them, and effects like
>"enchanted canoe" should be eliminated.
>
>One nasty bug that bit me once (I'm not used to playing with high lag)
>is where you can drive full speed off a road onto a boat and go so
>fast that you're over the other side and into the deep sea before the
>game notices that you should have boarded the boat. That should be
>fixed too.
>

Yes, this is one of the nicest features of the new version, IMHO.  I now
don't need to run over a base or pillbox several times to capture it, and
don't have to slow down to a crawl in order to get onto a boat and leave
the shore.


>The important question I'd like answered is whether high-lag games are
>now more like low-lag games, or less like them.
>
>>I take way more damage [when attacking a pillbox]
>
>If you mean "more than in a high-lag game" that makes sense. If you
>mean "more than in a no-lag game (like practice mode)" then that is
>surprising.
>
>Which is it?
>

In the games that I have played so far over the net, it seems that walls
are more consistent in that they absorb shots more like they would in an
appletalk or low lag game.  Of course, the connection between UCLA and the
rest of the world seems to suffer from heavy packet loss and frequent
network errors, particularly during daytime hours, and these effects
usually bring any game to a grinding halt before I can really determine
how much better the new version really is.  The new Dead Reckoning feature
does also seem to help smooth things a bit when playing in net lag,
although it does have a few strange side effects as well which may take a
bit of getting used to (i.e., ghost images from previous pill/tank views
and tanks "skating").

slugmo


Article 5                  [ top | bottom ]

Subject:      Re: 0.99.5 and autoscroll
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/05/03

In article <3o8fu5$l32@savoy.cc.williams.edu>, Llan (Thomas Reid)
<97ttr@williams.edu> wrote:

[bunch of stuff in support of the new map overview]

Yeah, what he said.

sluggo


Article 6                  [ top | bottom ]

Subject:      Re: Benefits of BoloSounds
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/05/03

In article <3o8s1n$s56@mark.ucdavis.edu>, ez006626@chumley.ucdavis.edu
(David Clancy) wrote:

> In article <3o8hme$13tn@bigblue.oit.unc.edu> you wrote:
> 
> : If it helps you any, Santa and i never use sounds. I guess you get used to
> : playing without them. Even when we get the opportunity we don't use them.
> 
> 
> : grinch
> : --
> 
> If it helps any, I never use graphics.  In fact, even if I happen to have
> a monitor at the time, I rarely hook it up.  I find all the movement and
> explosions and stuff distracting.
> 
> I do you use a keyboard, though, and I highly recommend it.
> 
> --xav

Keyboards are for wussies.  I never use  keyboard or a mouse or a monitor
or sound or a computer to play Bolo.  I find that using a computer to play
bolo just detracts from the simplicity of the game.  I think it should be
an option in the next version of Bolo to disallow computers from the
game.  That way, no one will have an unfair advantage by actually using a
computer to play Bolo.

slugmo


Article 7                  [ top | bottom ]

Subject:      Re: evil new Bolo web page
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/05/04

In article <9-0405951111590001@mark-brown.umeres.maine.edu>, 9 (Mark
Brown) wrote:

>
>Hey Puppy Love.  Am I not worthy to be on your list of players to beat? 
>Personally I think I'm worthy enough to be put on the list. One other
>thing, I beat Beastmaster* yesterday but for some reason I can't post it
>on your page. 
>
>Grandwizard¨
>
>-- 
>-Beastmaster*

Yeah, I had the same problem posting my victory over Standard Autopilot on
Biggest Swampiest Map Ever.  What gives?

sluggo


Article 8                  [ top | bottom ]

Subject:      Re: Odd bug: no pb or base info at start.
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/05/05

In article <3oe48s$ek0@chem.Stanford.EDU>, koehler@chem.Stanford.EDU
(Michael Frederick Koehler) wrote:

>Has anyone else experienced this?  I joined a game on Everard last night,
>and when I was in, and started driving around, I noticed that there was 
>nothing in the pb and base status windows.  I mean nothing.  Just the 
>base symbol and pb symbol in the middle.  After about 10 seconds, the 
>pills came up, and after 30 more seconds, I got the base information.  Was
>this just a lag hiccup?
>
>Grimm

This happened to me once the other day.  I just hid and unhid the windows
using cmd-h and everything was fine, so I never really thought about it
again.  It does seem that this is a bug of one sort another, although it's
occurrence does seem to be very infrequent and, unfortunately, I didn't
really make a note of the circumstances associated with its occurrence.

slugmo


Article 9                  [ top | bottom ]

Subject:      0.99.5 "New Game" bug
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/05/06

I was messing around with 0.99.5 and noticed a rather unusual bug.  If
your builder is killed and you select "New Game" from the File menu then
join or start another game, your builder will still be dead.  On one hand,
this could be a good thing in that it would deter somewhat people who like
to quit and rejoin a game in which they have just lost their builder.  On
the other hand, I would hate to end one game with a dead builder then
start a new game on a map that has giant walls or deep sea where my
builder will ultimately land.  Of course, my usual strategy is to shoot my
own builder within the first 30 seconds of any game to make my tank
lighter for the base rush, so I guess the point in my case anyway is moot.

sluggo


Article 10                  [ top | bottom ]

Subject:      Re: base lagging solution
From:         chdillon@seas.ucla.edu (Charles H. Dillon)
Date:         1995/05/07

In article <3oi5a8$pra@news.ycc.yale.edu>, tempest@minerva.cis.yale.edu
(William Bayliss (SM 1996)) wrote:

> This seems silly but it is probably an easier way to fix all those nasty
> base lagging bugs from .99.2
> 
> Have the tank take damage when it reduces the armor in an ememy base
> by running over top of it.
> 
> As it is, once armor is reduced to a certain level--"x"ing the base
> even if there is some little armor in it the tank can run over that armor
> and destroy it.
> 
> If you make the tank take hits equal to the square of the armor in the base
> it will be very very impractical to lag bases by putting a tank on top of 
> a base--and this can preserve the ability to run over bases that have 
> very very little armor in them.  (the formula can be adjusted so that that
> little armor destruction causes no damage)
> 
> This will also make tanks get destroyed when they wall "lag" a 
> base--possibly killing their builder.
> 
> The pill tank destruction while on top of a pill will be horrifying 
> in builder race situations.  You rebuilt it in time, but because of lag,
> the enemy blew up on your pill and killed your builder. aaarg.
> 
>  T
> E   T
> M    S
>  P  E

In case you hadn't noticed, the base lagging problem has already been
solved in 0.99.5.  A tank no longer kills a base by landing on it.  So
even if you accidentally lag on top of a base, it will not be killed. 
Also, you can no longer steal a base by leaving alliance while sitting on
top of the base.

sluggo