Re: [glob2-devel] flags vs. areas: getting the best of both worlds

[Kai Antweiler]

>> I think distance should have a quadratic influence, so that flag
>> has locally me power.
>
> I'm not quite sure what you mean.  Can you give an example?

Maximize: radius / (distance * distance)
But other formulars might be better.

Imagine an area of wood and wheat and you want two things:
1. get rid of the wood but keep the wheat
2. make a small path through the middle


> I agree that one wants some notion of strength.  I think under my
> proposal the radius effectively acts as the strength.  See my example
> below.
>
>> For example you might want Flag B to govern most cells to it's left
>> were it competes with Flag A, but not touch any of the cells to its
>> right.  Let's say on the right are some cell that you want to be inactive
>> now, but active at a later time.  And you can't make Flag A smaller
>> without fragmenting the areas that it should govern.
>
> Can you give an example?


I guess it is hard to come up with a good one, because radius and strength
are positively correlated.


               cc
aa
aa
    bbbb    
a A bbbbB        ccc

 aaa
 aaa          ccddD


> I add another flag C that requests zero workers and clears
> nothing (and is therefore inactive).

Ok. Works, but imagine that c part is not visible on the screen because
it is too far on the right.  What you wanted to do is have a strong
local B impact on the fields to the left that overwrite A.  When you
increase B you won't expect it to change something far away that you
don't see and that you don't have in mind right now.


>> When we are already thinking about moving, we can think about
>> approximating a stretching, shrinking and turning effect as well.
>
> What would the user interface for this be like?

In the worst case: keyboard input.
4 Keys: stretch, shrink, turn left and turn right.
In the best case: a touchpad which can detact two seperate movements.
(maybe in the next decade.)


> That is the hard part.  

There are harder parts concerning the engine, but it is good that
you care about the implementation effort.
The easier code changes are the sooner they will be implemented.
-- 
Kai Antweiler