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

[Joe Wells]

Leo Wandersleb <address@hidden> writes:

>> It helps very much with this farming pattern (my favorite now):
>> 
>>   X..X..
>>   .X..X.
>>   ..X..X
>>   X..X..
>>   .X..X.
>>   ..X..X
>
> ok now i see. still this looks hard to do.

Being able to do this quickly was a big part of my motivation for the
brush changes.

> (i want farming areas)

What do you mean by that?

>> 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.
>
> right! Many use
>
> .x.x.x.x
> ........
> .x.x.x.x
> ........
> .x.x.x.x
>
> i suspect to have non optimal groth conditions.

That works only when the resource is already there.  The pattern I am
using allows expanding the resource in one direction (typically away
from the water).  The checkerboard pattern allows expanding the
resource in all directions.

>>> although i see the need for bigger brushes.
>> 
>> I don't understand.
>
> if i don't want my globs to go to some area i paint it as cutting it
> off

Right.  I've always used the 5 by 5 square for that purpose (which
seems perfectly adequate).  I've never tried the big circles for it.

> makes the globs already in the area stay there.

Huh?  I would expect the globules in a newly added forbidden area to
exit it as soon as possible.

>>> your changes on the speed, painting gets aplied maybe smaller brushes are 
>>> fine, too.
>> 
>> I don't understand.
>
> as it is easyer to paint large areas with smaller brushes i don't need
> the big brushes.

This is true.

>> 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.
>
> if you are painting your pattern
>
> .x..x..x
> ..x..x..
> x..x..x.
> .x..x..x
> ..x..x..
> x..x..x.
>
> and accidently get one wrong
>
> .x..x..x
> ..x..x..
> x..x..x.
> .x.xx..x
> ..x.xx..
> x..x.xx.
>
> you don't want to change for the 1x1 or the inverse brush to fix
> it. you simply want to click a second time.

Good idea.

> no effect means you click 3red on 3red. that would mean remove 3 red.
> if you click with all effect or with little effect (3red on 2 red) it
> takes the chosen effect.

Good idea.  You want to implement it?  :-)

>>> works perfect here.
>> 
>> Do you mean the potential problem I mention does not happen?
>
> I mean to all my little testing i was happy it works better than before.
>
>> I don't understand.  Can you clarify?
>
> if i have the 5x5 i prefere to see only one square of the right size
> and not 25 small ones.
> with the checkerboard patterns that's nice now.

I see your point.  What I am doing now is easier to program, as it
simply calculates what to show on the screen from the brush's bitmap.
One could special-case the 5-by-5 and 3-by-3 squares in the code
somehow.  Or maybe use the same idea as is used for drawing walls,
where the shape depends on which neighbors are also walls.

>> 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.
>
> right. i just thought about drawing only half squares or diamonds but
> dashed is fine.

Actually, that's a nice idea.  A shape distinction would be easy,
because there is already code for rectangles and circles.  Rectangles
could mean adding and circles could mean deleting.  That would need
only minimal programming.

>> 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.
>
> hmm... i understood that. but i guess if they go explore they are not
> wounded enough to go to hospital so they do a normal exploration
> circle ligtly wounded risking more when getting hit by turrets or when
> turning hungry.

The issue is that an explorer's hit points are an important part of
its range.  The range of an explorer is food+hitpoints.  You often see
an explorer returning from a long trip arriving at the inn with less
than 10 hit points because it was starving on the way, even though it
was fully healed when it left on its trip.

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

Search for “241” in Unit.cpp.  I have added a comment with the
mathematical explanation.

> you know that they are faster diagonally? time
> from one tile to the next is always the same no matter if diagonally
> or straight.

My change actually increases the likelihood of diagonal travel.

>> Can you try different values and tell me what would be okay?
>
> will see if i come to this.
>
>> The
>> current dimness is black at 50% opacity, which is way too dim.
>
> agreed
>
>> 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?
>
> without trying i would vote for 25% if you can then see enough through the fog

Don't have time to try now.  I had to delete all my glob2 stuff to
make sure I don't spend any of my extra time on it for the next few
weeks.

>> Again, can you please try some other values?  I'm using black at 8%
>> opacity.  Can you try 15%?
>
> why not 25% in pause?

Don't know.  Can you try it and see?

>> 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.
>
> still: why not 25%?

Well, combining 25% with 25% will yield 44% opacity, which I think is
a bit too dim.  Combining 20% with 20% would yield 36% opacity, which
might be okay.

>>> 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?)
>
> no idea. i got tons of them.
>
>>>>    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?
>
> now i found another problem: direction keys don't work anymore. i need
> cell-wise arrow keys to paint forbidden areas on straigh lines.

Can you describe this a bit more?  What used to work?  And what
happens now?

>>>>    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.
>
> can this go into basic settings? environment variable sound complicated for 
> noobs.

You are correct: this kind of thing should go into the settings.  I
don't know how to do that and I don't have time right now to figure it
out.  But I desperately needed the fix, so I did something.

-- 
Joe