Re: [glob2-devel] patch with improvements: brushes (6), fix AI cheating (2), explorers (4), other GUI (7)

[Joe Wells]

Thanks for trying out my changes, Leo!

Leo Wandersleb <address@hidden> writes:

> Joe Wells wrote:
> patch aplied locally. i will push it to the server tomorrow so others
> can test from hg.
> comments:
>
>> 1. Changes in the effect of area brushes:
>> 
>>    A. This patch changes the shapes of the 3rd and 4th brushes to:
>> 
>>         X               X
>>          X     and     X
>>           X           X
>> 
>>       I never used the previous shapes of the 3rd and 4th brushes, but
>>       I now use the new shapes all the time for farming.
>> 
>>       (The .png images used for the button to select these shapes have
>>       not been updated and still show the old shapes.  It would be
>>       nice if these were calculated at game startup instead of being
>>       static .png files.)
>
> i see no need for that shape

It helps very much with this farming pattern (my favorite now):

  X..X..
  .X..X.
  ..X..X
  X..X..
  .X..X.
  ..X..X

This grows as much crop as

  .X..X.
  .X..X.
  .X..X.
  .X..X.
  .X..X.
  .X..X.

but doesn't have the problems of globules getting stuck.

I like this pattern much better than

  .X.X.X
  X.X.X.
  .X.X.X
  X.X.X.
  .X.X.X
  X.X.X.

because it seems to yield more crop and causes much less traffic
congestion.  The only time I use the checkerboard pattern now is when
I want to extend a farm along the coast.

> although i see the need for bigger brushes.

I don't understand.

> your changes on the speed, painting gets aplied maybe smaller brushes are 
> fine, too.

I don't understand.

>>    B. This patch changes things so that when drawing areas with a
>>       brush of size 1 by 1 (there is only one such brush), if an
>>       attempt is made to use the brush which would have no effect, we
>>       first toggle the state of whether we are adding or removing the
>>       area, so the use of the brush will have an effect.  This allows
>>       quickly repairing errors without having to explicitly change the
>>       mode by hand.  We don't do this when dragging, so only explicit
>>       mouse clicks can change the mode.
>
> i took you wrong. i understood this good feature would work on all
> brushes.

I'm not sure whether it makes sense to work on brushes bigger than 1
by 1, but maybe that could be tried.

For the smallest brush, I can't think of any reason to not always make
it toggle.  Basically, the idea is, if I am using the smallest brush
on some map cell, I want to _change_ whatever the area setting for
that cell is, regardless of whether it is on or off.

> no effect -> inverse action temporarly.

I don't understand.

>>    C. This patch fixes bugs in drawing areas while dragging.  It is
>>       now far more likely that if you quickly draw a path with the
>>       mouse that all of the map cells the mouse goes through will be
>>       correctly handled.  Two separate changes needed to be made.
>>       First, it was necessary to stop discarding as many mouse motion
>>       events (but only when dragging).  Second, it was necessary to
>>       change to using the mouse position and button state at the time
>>       of each event rather than using SDL_GetMouseState (which can
>>       return the mouse position and button state after many events
>>       that have not yet been processed).
>> 
>>       (If SDL doesn't supply enough mouse motion events, then it is
>>       still possible to skip over some cells, even after this patch.
>>       This potential problem seems not to happen in practice.)
>
> works perfect here.

Do you mean the potential problem I mention does not happen?

>> 2. Changes to the visual appearance of area brushes:
>> 
>>    A. This patch makes the area brushes show the exact cells that will
>>       be turned on or off, instead of just a square or circle.  (This
>>       change is needed by the new brush shapes.)
>
> i don't like the borders touching each other and would prefere to see
> it like it will look when painted.

I don't understand.  Can you clarify?

>>    B. This patch draws the area brush in a color (red, blue, or
>>       yellow) corresponding to the kind of area (forbidden, guard, or
>>       clearing) that is being added or removed.  The actual colors
>>       that are used were obtained by inspecting the .png files for the
>>       area animations.
>
> good.
>
>>    C. The area brushes were dimmer to indicate area removal.  However,
>>       the brushes for removal were still bright enough that it was
>>       hard to notice the difference.  (I never realized there was a
>>       difference until I saw the code.)  This patch makes them even
>>       more dim, so that the difference is more likely to be noticed.
>
> ok.

By the way, what I would really like would be for the lines to be
dashed in this case instead of being dimmer.  I think that would be
much clearer.

>> 3. Changes to AI behavior:
>> 
>>    A. There was code in AIEcho.cpp that allows AIs to cheat by telling
>>       them where each player's starting buildings are located.  This
>>       allows AIs to launch attacks with war flags against enemies they
>>       have never even seen.  This patch disables this “feature”.
>
> known "feature".

Actually, it is undocumented, and highly surprising (at least to me).

> I'm curious how nico performs now and if Bradley likes it.
> Nicowar is still strong as before i'd say. his explorers find me
> faster now so i guess the "feature" is not needed anymore.

It makes a difference on bigger maps.  Watch Nicowar play on a 256 by
256 map with and without the change and you'll see a big difference.
The key point is that without cheating Nicowar doesn't find you before
you find him unless he makes more explorers.

>>    B. This patch adds code to ensure that Nicowar does not commit to
>>       defeating a particular enemy until it has seen at least one
>>       building of that enemy.  (This is a necessary adjustment to the
>>       removal of the feature that the AIs know the location of all
>>       other players' starting buildings.)
>
> again :)
>
>> 4. Changes to explorer behavior:
>> 
>>    A. This patch greatly increases the likelihood that explorers will
>>       explore unknown areas on large maps.  Explorers now effectively
>>       explore 128 by 128 and 256 by 256 maps.  (This has not been
>>       tested on 512 by 512 maps, due to the memory use bug since glob2
>>       version 0.8.22 (bug #19601).)
>
> testing on 4squares i am impressed.

I'm happy to hear you think it helps.

>>    B. This patch makes explorers prefer to try to heal immediately
>>       after feeding and to feed immediately after healing.  This is
>>       necessary for explorers to have enough range to explore large
>>       maps.
>
> hmm... not convinced.

It makes a big difference on 256 by 256 maps.  Otherwise what happens
is this:  An explorer returns from exploration, starving and losing
hit points.  The explorer feeds.  The explorer goes out.  Before he
reaches the frontier, he notices he is wounded, and goes back to heal.
After healing, the explorer goes out again (without feeding first).
Just after he reaches the frontier, he starts to starve, and must
return again.  The cycle repeats over and over, and for each explorer
trip hardly any actual exploration happens.  Plus more of the
explorers end up dying of starvation.

>>       completely haywire when saving and reloading a game.)
>
> i believe what you say ;)
>
>>    D. This patch improves decisions about whether a direction is
>>       diagonal or not which affect explorer behavior.
>
> ???

Basically, I use 2.41 instead of 2 in one place, because 2.41 is the
mathematically correct value.

>> 4. Other changes to visual displays:
>> 
>>    A. The units working for a building are always shown with white
>>       circles while the building is selected, instead of just when the
>>       mouse button is held down.
>
> great

By the way, as a side effect, this also fixes things so you see them
for flags as well as for buildings.

>>    B. This patch reduces the amount of dimness from the fog of war,
>>       because the old amount of dimness made it painful to view the
>>       screen.  The .png files used for the borders of the fog of war
>>       have been correspondingly adjusted.
>
> now you barely see the diff between fog and no fog -> change is too
> much in my opinion.

Can you try different values and tell me what would be okay?  The
current dimness is black at 50% opacity, which is way too dim.  I'm
using instead black at 16% opacity, which I like very much.  It is dim
enough that I can easily tell where the fog is, but bright enough I
can still see details without problem.  Can you try 20% and 25% and
see if those would be okay?

>>    C. This patch reduces the amount of screen dimming due to pausing
>>       the game.
>
> same.

Again, can you please try some other values?  I'm using black at 8%
opacity.  Can you try 15%?

Keep in mind that the dimness from fog of war and from pausing get
_combined_.  So without my patch, when paused, the area under
fog-of-war is dimmed the equivalent of black at 75% opacity.

>> 5. Other changes to user interface controls:
>> 
>>    A. This patch adds new keyboard commands for selecting all of the
>>       building construction tools, the flag tools, and the area tools,
>>       and for setting the area adding/removing mode, and for setting
>>       the area brush.  These commands can be bound to any of the keys
>>       from “a” to “z”.  Also, there are 3 prefix commands which group
>>       together all of the building tools, the flag tools, and the area
>>       tools.  For example, if you bind the prefix command for
>>       buildings to “b”, then “b” followed by “i” selects the “inn”
>>       tool.  You can also bind “i” directly to the command for
>>       selecting the “inn” tool if you want.  The default binding of
>>       the prefix command for area tools is “a”, for building tools is
>>       “b”, and for flag tools is “f”.  (The default for the team
>>       marking command (which shows the team numbers for each globule)
>>       has been moved from “a” to “h”.)
>
> great. i added some default:break; to the switches to get rid of the
> warnings on every possible key.

Sounds good.  (Why wasn't I getting these warnings?)

>>       (The language translations of the new commands have not yet been
>>       added (not even English).)
>
> ok. not so bad. someone will do it. you see the keys now i guess.
>
>>    B. This patch enables holding the Control key while pressing the
>>       arrow keys to move the viewport by half-screens instead of by
>>       single cells.  At the same time, some bugs are solved where
>>       window manager controls involving arrow keys and other modifiers
>>       could sometimes accidentally be interpreted by glob2.
>
> nice. but half screen is too fast for my taste.

What about 1/3 screen?

>>    C. This patch enables using the Tab key to cycle through all of
>>       your globules of a given kind (worker, explorer, or warrior).
>>       (This was vital for debugging explorer behavior.)
>
> good
>
>>    D. This patch allows the user to require the Control key to be held
>>       down before the scrollwheel changes the number of requested
>>       workers.  This solves a problem (bug #19600) where the number of
>>       workers keeps getting accidentally messed up.  (With this patch,
>>       the user requests this by setting the GLOB2_NO_RAW_MOUSEWHEEL
>>       environment variable; this should be done with a user option
>>       instead.)
>
> ???? please clearify

With my patch, when I set this environment variable, I have to hold
down the control key while using the “scroll wheel” to change
requested worker numbers.  The problem is that I don't actually have a
scroll wheel, but instead I have a touchpad which simulates a scroll
wheel using a small strip on the right edge of the touchpad.  This
means without my patch I get *lots* of accidental adjustments to the
requested worker numbers.

-- 
Joe