Re: [glob2-devel] teleporters

[Kai Antweiler]

>> I think you don't understand what I mean.
>> Tps are different, because they are bottlenecks.
>> Imagine your planning an attack and want to get 50 warriors near
>> your enemy quickly.
>>
>> You don't want:
>> 1. When you don't enforce good behaviour:
>>    That your warriors run to the tp.  The first warriors get hungry
>>    and want to get to an inn, but can't get back because of the others.
>>    Real big mess.
>
> This should not happen as warrior should not try to go to war flag if the 
> distance is bigger than their food reserve.

Ok, some warriors get's to the flag.  Then they get hungry.
yadda yadda yadda:  big mess.


>> 2. When you don't enforce good behaviour:
>>    In case of a two way tp.  Workers coming back through the tp.
>>    And again, no one can move, big mess.
>
> If we have no-delay tp, this should be the same as workers crossing, say, 
> between the rocks. We could improve this issue by making tp big, such as at 
> least 2x2 but prefered 3x3 or 4x4.

True,  I'd say at least 4x4,  but:
When we use big tps, we need delay otherwise globs will want short cut:
running into one edge of the tp, get out of the other.  Since we use
supremum norm in glob2 for distance.  Globs will run diagonally from
everywhere to get the small tp lift.


>> 6. In case of no queues:
>>    Most globs will be running in forth and back repeatedly.  It would
>>    be quicker to use no tp at all.
>
> Why? Excepted for the crowding issue that is a real problem, if tp work 
> transparently (without queue or user control of any sort), why should this 
> problem arise?

Oh, this was meant as normal building behaviour.  Only n free places
no precedence between those.  But I've made a mistake here never the
less.  This case is like case 5, if I remember the number correctly.

-- 
Kai Antweiler