This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: keyboard production setting (long standing bug)


>> The map should scroll if the current unit is moving and gets too close to
>> the edge. Are you sure it is not just this recentering that you are seeing?
>
>If it is recentering, it is doing it wrong.
>The producer in most cases is a non-moving city, so the unit is not moving.
>Also, it moves the map the distance the *previous* unit moved.

That's exactly what I meant. It refocuses on the unit that moved. I have
tested things exactly as you describe and this is what I see. The scrolling
always puts the unit that just moved in the center of the map. So the
amount of scrolling does depend on its position, but not on the distance it
moved.

The reason for this is probably that Tcl does nothing in real time (a major
problem with this interface). All you can do is "schedule" things to happen
later, whenever Tcl feels like it. So it seems the scheduled recentering on
the unit that just moved overlaps with the build command to the next unit.

What is strange is not the recentering itself, but the fact that it always
happens, irrespective of the position of the unit that moved. When you move
several units after each other, recentering on each unit is filtered out
unless one of them end up too close to the edge. Seems like this does not
happen if you switch to a build task, which causes the map to recenter
every time in that case.

Hans

Hans Ronne

hronne@pp.sbbs.se



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]