Re: [glob2-devel] yet more feedback (many topics)

[Joe Wells]

Thanks very much for your extremely helpful replies, Leo!  I will edit
my list of issues to take them all into account before adding the new
points to the wiki.

Leo Wandersleb <address@hidden> writes:

> Joe Wells <address@hidden> writes:
>>
>> It would be better if dragging with left mouse would start scrolling
>> the viewport when the mouse reaches the edge of the viewport, rather
>> than waiting until it reaches the edge of the application window.
>
> minor change. rather make left-drag behave like middle-drag. did i get
> you right?

No.  Right now, on the top and right edges, the behavior is strange.
On the right side, the main map viewport ends 128 pixels from the
right edge of the window, because the rightmost 128 pixels of space is
used for the minimap and controls area.  When you position the mouse
near the right edge of the entire window, the main map viewport starts
scrolling.  This is strange because you have to move the mouse *way*
out of the main map viewport for this to happen.  It would make more
sense if this auto-scrolling behavior started when you moved the mouse
cursor to the right edge of the main map viewport, rather than having
to move it an extra 128 pixels to the right edge of the window.

> sorry i'm drunk a bit.

:-)

>> ------------------------------
>> It would be better if dragging off the edge with left mouse would move
>> diagonally to the extent that the point the mouse went off the edge is
>> not in the center of the edge of the viewport.  Right now you have to
>> drag to the exact corner of the window (which is harder) before you
>> get diagonal viewport motion.
>
> i guess this is due to a view point mevement that ist integer rather
> than rational. i'd prefere to have rational scrolling to get smoother
> movement. but implementing that failed when i saw how many cases of
> a<<2, b>>3, ... would have had to be replaced by some real
> equivalent. (wantedViewport=(x,y)
> ontimer(){visualViewport=0.95*visualViewport+.5*wantedViewport;})

Your idea is very interesting.  It would be interesting to get
scrolling that works in very small increments.  And doing so would
make my request easier to satisfy.

Even keeping the current method of scrolling by multiples of a map
cell, it would still be nice to have a larger border region where
putting the mouse in the region would trigger diagonal scrolling.

>> ------------------------------
>> BUG:  The viewport can be moved by dragging with middle mouse, and it
>> can also be moved by positioning the mouse in the region near the
>> window edges, which automatically triggers scrolling.  Both of these
>> are nice features.  Unfortunately, they combine!
>
> this is already in the bug tracker.

Which bug is this?  I can't find it.

>> If you are moving
>> the viewport by middle-mouse dragging, and the mouse pointer strays
>> into the region next to the window, you get both motions
>> simultaneously.  This is extremely disconcerting and confusing, and it
>> would be better if window-edge auto-scrolling did not happen while
>> middle-mouse dragging.  If middle-mouse dragging ends with the mouse
>> near the window edge, then it would be better if the window-edge
>> auto-scrolling did not happen until the mouse moved away from the
>> window edge and then back again.

>> ------------------------------
>> Immediately after you use “d” to remove a flag, you can not currently
>> use Tab to go to the next flag.  This doesn't work now because after
>> using “d” a flag is no longer selected.  Thus, currently it is harder
>> than it ought to be to delete a bunch of flags in a row.
>
> *agreed*

Maybe a solution is whenever something is deleted, the game could
switch to the control for creating a new thing of the same type.  So
If you delete a war flag, you immediately get the war flag creation
control.  If you delete an inn, you immediately get the inn creation
control.  Etc.  In this mode, the Tab key will do the right thing.
(Well, mostly the right thing.  Currently, it starts over from the
beginning of the list of buildings/flags of that type.  But much
better than nothing.)

This would have other benefits than just solving the problem I
mentioned, because it would help in replacing the thing you deleted.
For example, when you accidentally place a new inn construction site
in the wrong place, you could just delete it and then immediately
click again to place it in the correct place.

>> It would be
>> better if Tab remembered the last kind of thing to have been selected.
>> It would be even better if it remembered where it was in the list of
>> things of that kind.
>
> little harder to do. but still: *agreed*.
>
>> ------------------------------
>> The use of Shift-scrollwheel to adjust the radius of a flag is
>> undocumented (I think).  I only learned about it by digging through
>> GameGUI.cpp.
>
> thanx for that info.

Do you mean you didn't know about this control?

> it should show up in some tutorial mode if it doesn't get used.

Are you proposing to add it to the tutorial?

>> ------------------------------
>> Holding left-mouse down on a flag does not circle the globules serving
>> it, unlike holding left-mouse on a building.
>
> you fixed that one already.

Sort of.  I simply force the white circles around the serving globules
to always be on while any building (or pseudo-building like a flag) is
selected.  If others don't like always seeing these white circles and
want to revert that change, then the old code that temporarily turns
them on when left mouse is held on a building should be extended to
also handle pseudo-buildings.

So, this raises a question:  Is there anyone who doesn't want to see
the globules serving a building to be circled with little white
circles while the building is selected?  Before deciding, try the code
with this patch applied (I think Leo added this in latest main branch)
and see if you like it.

>> ------------------------------
>> In the first game I played in 0.8.23, the first war flag I created
>> started with a requested number of warriors of 20.  Huh?  How is this
>> possible?  Is this remembering things from my last game in 0.8.22?
>> This seems like not a good idea, because the last war flag from a
>> previous game is likely to have a high number, which is not a good
>> idea for a new game.
>
> it should be the number you set in settings. unfortunately it is the
> radius of your last flag. (bug reported and confirmed)

Bug 19731.  Thanks much for filing this!

>> ------------------------------
>> The number of requested workers for my hive at the start of the game
>> is always 1, regardless of my settings for what hives should start
>> with.  The very first thing I always have to do in any game is quickly
>> adjust the hive setting in order to minimize the amount of time my
>> workers waste wandering randomly.  It would be better if the default
>> was the same as the starting number of the workers or my settings for
>> hives were honored for the initial hive.
>
> problem here most likely is that the new game is like a saved game and
> has stored the numbers of workers for each building. a distinction
> would make sense in that place.

I personally suspect the problem is that whatever number of requested
workers given in the map editor is used for pre-existing buildings.
This needs to be checked.

>> ------------------------------
>> To help plan attacks, it would be useful to have a distance measuring
>> tool.  Currently, I do this by trying to estimate how many screenfulls
>> of space there are, but this is an imprecise and slow method.
>
> hmmm.... sounds far taken. a "show warriors gradient" tool would help
> here.

Okay, I had not thought things through like that.  I was thinking more
of straight line distance, assuming that I would clear a path as
needed.  (Hmm.  That wouldn't work if there were stone in the way.)
But using a gradient would be nice too.  And it would also help in
figuring out the most likely direction from which the enemy would
attack me.  (Except that wouldn't work if the gradient honored _my_
forbidden areas, because they obviously don't apply to the enemy.)

> i would not vote to implement such rational features. decide
> depending on taste. not facts.

“rational”?  “depending on ... not facts”?  Can you clarify?

>> ------------------------------
>> I agree with Kevin (donkyhotay) that it is very hard for new users to
>> tell the difference between workers and warriors.  After a while one
>> can see this at a glance, but it takes a while.  I agree that it could
>> be quite off-putting to new users and might drive some away.
>
> i guess it would be nice to clearer distinguish them but see no need
> to force that point as it is quite normal in new games that one
> doesn't know who are the terrorists/counterterrorists, what are the
> armory/what is it good for and what's the difference to the forge...

I suppose my point is that if someone ever decides to redo the artwork
for the globules, this would be a nice thing to handle at that time.

I agree that after a not too long playing the game, one can tell the
difference between workers and warriors.  But I definitely remember
having a lot of trouble at the beginning.

>> ------------------------------
>> Forbidden/guard/clearing areas on stone only serve to visually
>> distract the player as they have no impact on game play.  So it would
>> be better if attempts to make a forbidden/guard/clearing area on stone
>> were ignored.  This could be done by having any attempt to draw areas
>> on the map ignore any portion of the stencil which is over stone.  The
>> map editor could also remove any areas when stone is placed.
>> Similarly, it would be better if clearing areas were ignored on sand,
>> because nothing clearable can ever grow on sand.  (Actually, it might
>> be enough to just not _draw_ such areas.  The user wouldn't be able to
>> tell the difference.)
>
> my vote: don't draw areas on buildings, fruits and stone as it doesn't
> effect anything there.

I agree about fruits and stone, because those are not clearable and
can never change.  But not drawing areas on buildings could lead to
the user being very surprised when a building is destroyed that there
are suddenly areas there (which were really always there but just not
drawn) that could cause problems.

>> ------------------------------
>> When the “draw unit paths” feature draws a path from a worker to a
>> resource, this is currently merely a prediction of which resource the
>> worker is heading for.  This prediction is often inaccurate (or even
>> horribly wrong) and is not updated as the available resources change
>> (e.g., if a resource is used up or becomes forbidden).  A particular
>> problem is that often many workers are shown as going to the same
>> resource.  It would be nice if these paths were periodically (perhaps
>> every 5 seconds?) updated to account for changes.  (Note that I am
>> _not_ complaining that the lines are straight.  I understand that the
>> globule will in general need to follow a winding path to actually
>> reach its destination.)
>
> this is debug only.

That is an interesting statement.  I find the unit paths invaluable in
normal game play.  I don't think of them at all as being just for
debugging.

> if you need it more precisely, do it.

:-)

> the lines to buildings are accurate.

Yes.

> the lines to res are more an indicator "unit is going to wheat".

Right.  It just would be nice if these lines were less inaccurate.

>> ------------------------------
>> It would be nice if “ghosts” of enemy globules were left where they
>> were last seen.  Right now, if your explorers (or other globules) see
>> enemy globules and you aren't watching that portion of the map at that
>> exact moment, you have no way of knowing.  It is important to have
>> some kind of “memory” of these events in order to plan your strategy
>> properly, so I suggest that something that looks like a “ghost” should
>> be remembered.  These ghosts would only remain at spots that are not
>> actively being looked at.
>
> nice idea. these ghosts fade away?

I suppose the intensity might depend on how long it had been since
they were seen.

Actually, it might be nice to also see ghosts in areas that you have
current vision of, just to help you remember where the enemy has been.
So maybe there could be some options and some ability to control this
“memory” during the game.

>> ------------------------------
>> It seems that one can only select an enemy unit (construction site,
>> building, or globule) to get information on it if enough of it is in
>> area you can see.
>>
>> This is problematic for several reasons.  First, it takes a long time
>> to figure this out.  For a long time it was extremely mysterious that
>> I could select some enemy units but not others.  For some units it
>> would work, but for others I tried clicking on them zillions of times
>> and nothing ever worked.  I tried clicking on each different cell of
>> the location of enemy construction sites to see if that made a
>> difference.  For a long time nothing made sense.  It would be better
>> if I could select the unit and the status display would then explain
>> that no further information was available because not enough of the
>> enemy unit was visible.
>
> maybe your fog of war is not dimm enough?

I don't understand what the dimness of the fog of war could have to do
with it.  It is easy to see which portion of the building is covered
by the fog of war, even after my patch.

>> Second, it is problematic because even if you are attacking an enemy
>> building with your warriors, which are therefore right next to it (in
>> _contact_ with it), it is not considered “visible” if your warriors
>> are only attacking a corner (and it seems to be impossible to get
>> warriors to move around an enemy unit once they have contacted it).
>> Being close enough to a unit to be attacking it should entitle you to
>> ask for information about it.
>
> never experienced that problem.

Have you tried to select a large enemy building (barracks or bigger)
while your warriors are attacking it but it is not visible by one of
your explorers, hives, or defense towers?  (The main point of
selecting an enemy building is it allows seeing the exact hit points,
so you can see how much damage your warriors are doing.)

>> ------------------------------
>> In building status displays, instead of showing the total construction
>> resources needed, it would be more helpful to show the remaining
>> resources needed, because that is what the user needs to know to make
>> plans.  Currently, the user must do the subtraction in their mind to
>> figure this out, which slows the user down.
>
> sorry. that's perfectly ok with me. the overall status is drawn in
> the line under the site.

The line under the building only tells you what portion of its full
hit points the building has.  It doesn't tell you see what particular
resources are still needed, or how much of each.  You may need to do
things (e.g., clearing paths to stone or algae) to make it easier for
your globules to get the right resources, but you need to find out
first what resources your globules are having trouble getting.

>> ------------------------------
>> It would help if there were a bigger color distinction in the mini-map
>> between unknown territory and wood.  Right now it is hard to tell the
>> difference between these two things in the mini-map, because the color
>> for wood in the mini-map is quite dark.
>
> also a zoomed mini map would help on bigger maps.

Agreed!  Also, already mentioned in the list on the wiki:

  “...  It would be nice to be able to expand the mini-map
  (obviously only temporarily) to the whole screen to see more
  detail. ...”

>> ------------------------------
>> It would be nice to be able to see during the game the graphs that are
>> currently shown only when you quit.  Of course, only the data for
>> yourself should be available until someone has won.
>
> _disagree_ aou are controlling your city and are in the middle of
> it. all those stats about history are only interesting
> afterwards.

I think they would be quite interesting in the middle!  It helps to
see how effectively one is doing overall, or how badly one has been
damaged by a fight.

> maybe show game time to decide on switching strategies
> based on the experience when the first attack might occure.

That is a nice idea.  That would also help you see how well your
computer was performing.  If you played 20 minutes and only 5 minutes
of game time went by, you know your computer is overwhelmed.

>> ------------------------------
>> It would be nice to have a FPS (frames per second) indicator to help
>> in knowing how badly my computer is performing.  (I would have liked
>> even more if 0.8.21 had had an FPS indicator, because I suspect there
>> was a big slowdown in 0.8.22 and it would help to know for sure.)
>
> frame counter would be nice, too. i'm comparing unit allocation
> systems based on the end game match time that is very inaccurate.

Good idea.  I'll mention it.

>> ------------------------------
>> The message “Your explorers are under attack” is confusing when only
>> _one_ of my explorers is being attacked.
>
> well... it is only because that happens early in the game. live with it.

Actually, it happens throughout the game.  :-)

I suppose in general, I would prefer messages like “7 of your warriors
are under attack” and “2 of your explorers are under attack”.  That
would be a lot more useful.

>> ------------------------------
>>
>> It would be better if the display was not dimmed so much when glob2 is
>> paused.  Right now, it is dimmed by displaying pitch black at half
>> transparency on the screen.  (By the way, this dimming is _combined_
>> with the dimming that marks areas not recently seen (the “fog of
>> war”).)  I have tried and found black at 10% transparency to be much
>> easier on the eyes.  Here is a patch:
>
> it is in tip now.

Thanks!

It would be good if people would comment on this.

By the way, personally, I don't think it is necessary to dim the
display at all when paused.

>> ------------------------------
>>
>> Areas not currently seen are dimmed.  This helps visually delineate
>> the area covered by the “fog of war”, where the user can not expect to
>> know about the motions of enemy globules.  The dimming makes it hard
>> to see details in those areas.  In particular, it is very hard to see
>> where forbidden/guard/clearing areas are set.  It would be better if
>> things were not dimmed as much.  I have tried out a fix and found
>> using black at roughly 16% transparency is much easier than black at
>> 50% transparency.
>>
>> Fixing this requires two changes.  First, a patch:

   ...

>> Second, images are used for the border of the dimmed areas so that the
>> dimming is gradual.  These images need to be made more transparent.
>> This can be done by running the following script (using a program from
>> the ImageMagick version 6.2.4 package) in the data/gfx directory:
>
> where should i put them? and how?

The modified image files go where they are now.  In the .tar.gz file,
they are in data/gfx.  I don't know if they are in the same place in
the repository.

>> ------------------------------
>> When a hive is set to request 1 worker, the top of the hive's image
>> looks like a black circle just to the right of the single circle
>> indicating whether a worker is serving the hive.  This has led me on
>> multiple occasions to mistakenly think the hive was set to request 2
>> workers, and I made gameplay errors as a result.  This could be
>> improved by making the hive image slightly less tall on the center
>> spike.
>
> no problem here. i'd rather vote to make the hive taller to fit its
> area.

I would be happy with any solution which moves the part of the hive
image that looks vaguely like a black dot and coincides with where one
of the black status dots appears.

>> ------------------------------
>> The images for the level 2 and 3 defense towers are great, but the
>> image for the level 1 defense tower doesn't look to me like a “tower”.
>> It would be better if the image looked more like a “tower” to help
>> justify why it gives better vision around it.
>
> school, market, racetrack, ... what gfx is ultimately good? if we
> get better we might take it. no need to hurry on the turrets.

I suppose my point is that this particular image doesn't help the
users understand the idea that the defense tower gives better vision.

>> ------------------------------
>> It would be better if a clearing flag attracted workers only when the
>> clearable resources inside the flag's area are reachable.  (Probably a
>> gradient should be involved somehow.)  Otherwise you get the situation
>> where some number of workers end up assigned to the flag doing
>> nothing.  (Alternatively, it would be good to be warned of such
>> situations, so the player can do something to fix them.)
>
> clearly the first solution is the better one. problem now is that
> even if the globs can reach the res but have to leave the flag
> circle they will not do the job.

Ah!  I did not notice that aspect of the problem.  I will add that to
my problem description.

>> ------------------------------
>> In glob2 0.8.22, I've seen workers swim long distances to fetch wheat
>> when closer wheat can be found by following the shoreline.  The
>> workers also do not seem to take into account their swimming speed in
>> deciding which resource to fetch.  Sometimes the workers will swim
>> when it would be faster to walk along the shore.
>
> right. that's a problem due to the wave front algo. we now have 2
> gradients. one for swimmers and one for non swimmers. this does not
> fit for all combinations of Level123 swimmers and walkers. so
> basically the algo gonsiders the glob to move as fast on land as on
> water.

Even worse, I guess that the gradient for swimmers also thinks land
and water are equal cost.  In fact, I guess all gradients think moving
1 map cell is always the same cost if it is possible at all.  Ugh.
Solving this would probably require moving to gradients with much more
than 8 bits per cell.  In the limit using floating point gradients
could solve things, but that would most likely take 64 bits per cell,
increasing memory usage by a factor of 8.  I wonder if there is some
clever approach which would solve this problem without too much
expense.  Three additional bits per map cell would allow
distinguishing 8 different levels of cost.  Would that be enough?

>> ------------------------------
>> Putting a forbidden area on a cell after a worker has decided to
>> harvest it does not stop the worker.  It would be better if this
>> stopped the worker.  Often (usually near the beginning of games) I
>> discover a worker is about to harvest the last bit of a resource in an
>> area I would like to farm.  In a panic, I try to stop the worker but
>> the worker ignores me.
>
> minor change at a considerable effort (i guess).  i agree it would
> be nice.

Well, the additional effort could be to also check whether the
resource is protected when harvesting ends, and if so abort the
harvesting.

>> ------------------------------
>> In general, it is frustrating that there seems to be no way to get
>> warriors to break off contact with an enemy.  It seems impossible to
>> get warriors to do many sensible things in battle.  For example, the
>> unit paths might show that a warrior is serving a particular war flag.
>> However, the warrior refuses to leave battle with a particular enemy
>> warrior to serve the war flag.  As another example, you could have 3
>> warriors beating up on one enemy, which is more than enough, and 1
>> warrior defending against 3, and it is impossible to get 2 of the 3
>> to go help the 1.  It is impossible to get warriors to retreat (both
>> flags and forbidden areas don't work), even though that would be much
>> better because then they could fight within range of your defense
>> towers.  Etc.
>
> that is desired bahaviour. warriors are to be far more defensive
> than offensive in order to enable the player to block onrushing
> warriors without having to build a double wall around the whole
> base.

Sure, but my complaint is that warriors are in this case, in effect,
too _offensive_.

> cheating by allieing with the opponent, walking through right to the
> inns and then switching back to hostile is a cheap win.

Huh?  I don't understand how this is related to my comment.  Can you
clarify?

>> ------------------------------
>> It could be better if defense towers did not use their ammunition on
>> building sites.  It is a big problem in my games against Nicowar that
>> defense towers prefer targeting building sites over enemy globules,
>> because Nicowar seems to like placing completely infeasible building
>> sites near enemy bases.
>
> here i guess we agreed that the slight chance to kill a building
> maybe with units inside has higher priority than shooting at units
> that go repair then. the problem with building sites having 1hp for
> nothing remains.

I suppose what would be enough would be to make 1hp buildings lowest
priority and to only shoot at them if there is plenty of ammunition.

>> ------------------------------
>> In 0.8.23, Nicowar (two different Nicowar enemies) put a barracks
>> construction site right next to my hive.  This was at the very
>> beginning of the game when I only had 9 globules and the enemy hives
>> were on the other side of two lakes (although closer than usual).
>> This seems almost like cheating to me.  Later in the same game, both
>> enemies (sometimes both at once!) kept putting hive construction sites
>> next to my base, very unfairly using up most of the ammunition from my
>> defense tower!
>
> not respecting the 4s delay a human has is what i consider serious
> cheating.

Any abuse of building sites is cheating in my opinion.  I would refuse
to ever play again with a human who deliberately put building sites
just to inconvenience me and waste defense tower ammunition.

>> ------------------------------
>> More map dimensions than 64, 128, 256, and 512 would be nice.  I'd
>> like 96 and 192 as options also.  Is there some reason why arbitrary
>> sizes are not currently allowed?
>
> i guess this is due to high optimisation towards the use of binary.

Can you clarify?

>> ------------------------------
>> BUG:  The random map generator puts too much stone on the shores.
>> This is a big problem on big 512 by 512 maps.  The River generator is
>> particularly bad.  Even if set to 0 stone, it still puts a layer of
>> stone 5 or 6 cells wide on each shore, making it impossible to get to
>> any algae (or do any swimming).  The river becomes completely
>> irrelevant except as a barrier.
>
> that's my part. please put it in the bt and assign it to me. problem
> with river is that the count of levels in the intermediate height
> map is too little to draw the line between stone and wheat/wood.
>
> plan was to introduce some extra height maps:
>
> * a finer one that blends with the water gradient for algae and
>   wheat/wood
>
> * an even finer one to place trees and stone

Huh?  “Height”?  And how does “height” affect stone vs. wheat/wood?

>> ------------------------------
>> In the map editor, it would be better if clicking on a resource gave
>> you its status the same way as it does in the game.
>
> many things should be "the same as in game".

Good point.  I've already pointed out a number of things where the map
editor differs from the game.  I'll group them together as a single
issue.

>> ------------------------------
>> In the map editor, when you place a resource like wheat/wood/algae
>> each cell gets a random resource value from 1 to 5.  If you don't like
>> the value a particular cell gets, you have to redo the cell repeatedly
>> until eventually you get what you want.  It would be better if you
>> could simply click on the cell, have its status displayed in the right
>> panel, and have a slider in the right panel to adjust the value.
>
> is that realistic? growth takes place far too fast to predict the
> amount you will have after 2s.

My impression is that the overall amount of wheat available early
(distance to hive, number of map cells, and quantity on each cell)
makes a big difference in how well a team does.  (The precise number
of cells of wheat is more important when there is very little of it,
e.g., just 10 cells near the hive.)  If a cell has a quantity of only
1, it will often be harvested before it can spread, and this is
similar to having started with one less cell.  Getting these things
balanced is important for fairness.

>> ------------------------------
>> In the map editor, when you save the map, if you accidentally choose
>> the name of an already existing map, it does not warn you that you are
>> about to destroy all of your work on that other map.  I think the only
>> time glob2 should not warn you is if you have previously saved the map
>> you are working on by that name or loaded it from that file.
>
> agreed. it also doesn't warn when quitting without saving.

Agreed!  Also, already mentioned in the list on the wiki:

  “Quitting the map editor with unsaved changes should prompt for
  saving them.”

>> ------------------------------
>> It seems there is now in glob2 version 0.8.22 a feature where secret
>> forbidden areas are placed in the extra area a building needs when it
>> is being upgraded to a larger size.  The idea is to speed up the
>> process of getting globules out of the way so the upgrade can proceed.
>>
>> There are two problems with this.
>>
>> First, I have seen cases in 0.8.22 where globules would not get out of
>> the way of the larger space a building needs to be upgraded.  I have
>> been able to solve the problem by adding real forbidden zones by hand
>> to get globules to move out of the way.  So, it seems to me that this
>> new feature is not working fully correctly.
>>
>> Second, I think it would be much better if the forbidden zone added
>> for this purpose was _not_ hidden.  Otherwise the player may end up
>> extremely confused about why their globules are not able to get
>> through a passage.  It can trap a globule and the user might not
>> realize their globule is trapped.  I just now saw a globule that
>> seemed to be trapped by such a hidden forbidden zone, spinning around
>> and not moving at all.
>
> i totally agree!!! there are bugs and you can very hardly tell when
> exactly they occure. i only know it has not only to do with
> buildings but also with traffic jams when sometimes 10 globs starve
> to death spinning in the void.

Good point.  I'll add that to my problem description.

> also i've seen patches of wheat/wood
> that didn't get harvested an seeded on like in a forbidden
> zone. but adding and removing a red zone had no effect on that!

I'll add this.

>> ------------------------------
>> BUG:  When reloading a game, the values on the top line are all zero
>> for a number of seconds before they get fixed.  Probably other
>> statistics not shown on the top line are also zero for a while.  This
>> shows up in the end-game statistics if it happens to sample the values
>> during the interval before they are fixed.  You get strange graphs
>> where all of the lines show a sharp spike down to zero in the middle
>> of an otherwise normal graph.
>
> never seen that

When you reload a game, are the statistics always instantly correct?
There is always a delay for me while the statistics are all zero.

Sometimes (rarely), this delay happens to include the point in time
when the statistics are recorded for making the end-game graphs, and
it messes them up when this happens.

>> ------------------------------
>> BUG:  If you rename a game file, glob2 can not load it, because the
>> old name is stored in the file and glob2 fetches that name from the
>> file and then uses the name stored in the file to open it (even though
>> it must have already opened the file to even get the bad name!),
>> rather than the file's actual name.
>
> ok. so that's the reason for this strange behaviour? wondered about
> such thing, too.

Well, I'm guessing!  The old file name shows up in an error message.
I can't see how else glob2 could get the old file name, if it were not
stored inside the file.

>> ------------------------------
>> There is no easy way to tell from the documentation just what the
>> “--nox” option does or what it is for.  There is no match for “nox” on
>> the wiki.  It is not mentioned in the man page.  The only mention of
>> it in any documentation is in the output from the “--help” option,
>> which says “runs the game without using the X server”.  At first, I
>> guessed that meant it would run on the console directly, bypassing X.
>> Reading the code however tells that it completely disables the GUI.
>> So what is this for, and how do you use it?
>
> heard it on the ml, too but have no idea neither ;))

:-)

>> ------------------------------
>> In the Savannah bug tracker, it seems that it is not possible to
>> preview what your comments will look like in the bug display, and
>> there is no way to fix a comment after it has been made.  Is there a
>> way around this?  Is there a page where you can write a test comment
>> and see how it will be formatted after submission?
>
> never missed that. we will not blame you if your ascii art is not printed 
> well ;)

Well, my concern is I might not notice some use of punctuation in my
text that triggers some special syntax treatment.

>> ------------------------------
>> In the Savannah bug tracker, verbatim text is displayed in a absurdly
>> narrow fixed-width subwindow, even when much more horizontal space is
>> available.
>
> no idea what you are talking about but tell them.

I've put a screenshot of one instance of the problem at

  http://www.macs.hw.ac.uk/~jbw/savannah-bug-tracker-fixed-width-too-narrow.png

You can see where the text

  glob2: HeightMapGenerator.cpp:197: void HeightMap::makeIslands(unsigned int, 
float): Assertion `false' failed.

is displayed as just

  glob2: HeightMapGenerator.cpp:197: void HeightMap::makeIslan

without even any indication that it is truncated in any way.  You can
get the full text if you select it with the mouse and paste it in
another window.

Does this not happen to you?

-- 
Joe