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

[Joe Wells]

Does any of this make sense?

I'm particularly keen to find out for some of the “BUG”s whether they
happen for others.  I'm also wondering if anyone agrees with my
opinions about areas and about the map generator.  And if someone
could answer my question about “--nox” that would be nice.

-- 
Joe

Joe Wells <address@hidden> writes:

> Is there any chance that one or more Globulation 2 experts could
> comment on this feedback?  I would rather wait to put things on the
> wiki until I have some confirmation that they are sensible.
> Even a simple answer like “yes, everything makes sense” (as if that
> were possible) would help.
>
> Thanks,
>
> Joe
>
> ----------------------------------------------------------------------
> Joe Wells writes:
>>
>> Dear Globulation 2 gurus,
>>
>> Here is even more feedback, categorized.
>>
>> As always, I'm happy to clarify anything that is unclear.  Just ask!
>>
>> By the way, I'm still revising/reorganizing my earlier feedback.  I'm
>> mostly done with the revising the individual comments and all that
>> remains is to organize them.  When I'm done (soon!), it will go on the
>> Wiki somewhere.  I will include the items in this message, after
>> modifying them to take into account any comments I get.
>>
>> Joe
>>
>> ======================================================================
>> user interface controls:
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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!  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.  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.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> Holding left-mouse down on a flag does not circle the globules serving
>> it, unlike holding left-mouse on a building.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> I would be nice if the user interface had tooltips for many things.
>> For example, it would be nice to have tooltips that explained what
>> each of the number in the top line represents.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> It would be nice to document the various debugging tools.  These
>> include the following.  Shift-left-mouse on a globule or building puts
>> detailed information in “~/.glob2/unit.dump.txt” or
>> “~/.glob2/building.dump.txt”.  Shift-PrintScreen dumps a pretty
>> printed version of all memory to “~/.glob2/glob2.dump.txt”.
>> (PrintScreen puts a screenshot in screenshot.bmp.)
>>
>> ------------------------------
>> BUG?:  Whenever using one of the buttons in the start game menu, the
>> in-game main menu, the map editor menu, etc., after clicking on a
>> button glob2 often seems to get stuck until the mouse is moved.  I
>> have now got into the habit of always moving the mouse a little bit
>> immediately after clicking one of these buttons and the response is
>> much better.  Why is glob2 sometimes getting stuck when one of these
>> buttons is clicked?
>>
>> ======================================================================
>> existing visual indicators:
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.)
>>
>> ------------------------------
>> How do I restore the old non-animated area markings from glob2 version
>> 0.8.22 and earlier?  I liked them.  (Even though I would have liked
>> them to be a bit brighter, I still prefer them.)
>>
>> ------------------------------
>> 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.)
>>
>> Improved by comments from: Kai (in reply to an earlier point of mine)
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> 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.
>>
>> ------------------------------
>> The status display for a building can say “Inside 2/5” when, in fact,
>> there are no globules in the building at all.  This may merely mean
>> that 2 globules have booked places in the building.  This is quite
>> confusing to the user and makes it difficult for the user to plan when
>> to upgrade a building.  It would be better if the number of globules
>> actually inside the building were displayed separately from the
>> globules that have merely booked a place and are on their way.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> I can't see how to tell from statistics which portion of explorers
>> have ground attack.  Is there any way to do this?
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.)
>>
>> ------------------------------
>> The message “Your explorers are under attack” is confusing when only
>> _one_ of my explorers is being attacked.
>>
>> ------------------------------
>>
>> 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:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> --- GameGUI.cpp.~1.4350.~    2007-04-04 02:38:33.000000000 +0100
>> +++ GameGUI.cpp      2007-04-19 13:16:40.000000000 +0100
>> @@ -3557,7 +3557,7 @@
>>      // if paused, tint the game area
>>      if (gamePaused)
>>      {
>> -            globalContainer->gfx->drawFilledRect(0, 0, 
>> globalContainer->gfx->getW()-128, globalContainer->gfx->getH(), 0, 0, 0, 
>> 127);
>> +            globalContainer->gfx->drawFilledRect(0, 0, 
>> globalContainer->gfx->getW()-128, globalContainer->gfx->getH(), 0, 0, 0, 25);
>>              const char *s = 
>> Toolkit::getStringTable()->getString("[Paused]");
>>              int x = 
>> (globalContainer->gfx->getW()-globalContainer->menuFont->getStringWidth(s))>>1;
>>              globalContainer->gfx->drawString(x, 
>> globalContainer->gfx->getH()-80, globalContainer->menuFont, s);
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ------------------------------
>>
>> 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:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> --- Game.cpp.~1.391.~        2007-04-04 02:38:33.000000000 +0100
>> +++ Game.cpp 2007-04-18 17:29:14.000000000 +0100
>> @@ -2379,7 +2379,7 @@
>>                                      unsigned shadeValue = i0 + (i1<<1) + 
>> (i2<<2) + (i3<<3);
>>                                      
>>                                      if (shadeValue==15)
>> -                                            
>> globalContainer->gfx->drawFilledRect((x<<5)+16, (y<<5)+16, 32, 32, 0, 0, 0, 
>> 127);
>> +                                            
>> globalContainer->gfx->drawFilledRect((x<<5)+16, (y<<5)+16, 32, 32, 0, 0, 0, 
>> 40);
>>                                      else if (shadeValue)
>>                                              
>> globalContainer->gfx->drawSprite((x<<5)+16, (y<<5)+16, 
>> globalContainer->terrainShader, shadeValue);
>>                              }
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> 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:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> #!/bin/sh
>> for i in `seq 0 20`; do
>>     cp shade$i.png shade$i-old.png
>>     convert shade$i-old.png \( -clone 0 -channel red -separate \) \( -clone 
>> 0 -channel green -separate \) \( -clone 0 -channel blue -separate \) \( 
>> -clone 0 -channel alpha -fx a/3.175 -separate \) -delete 0 -channel rgba 
>> -combine shade$i.png
>> done
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> This script lightens the alpha channel by the factor 3.175 and leaves
>> the red, green, and blue channels alone.  Note that 3.175 (the factor
>> the alpha channel is lightened by in the above invocation of convert)
>> is just 127/40 (the old and new alpha channel values used in
>> Game.cpp).  If you agree that less dimming is a good idea, but you
>> don't like the amount of change in transparency that I propose, then
>> you need to make sure to use compatible values in both places.  (Note
>> that this script doesn't work with much older (or newer) versions of
>> “convert” because the meaning of “-separate” has changed.  I'll be
>> happy to run it for you on my computer if it doesn't work for you.)
>>
>> ======================================================================
>> game images:
>>
>> ------------------------------
>> The images used for some buildings make it hard to visualize the space
>> they occupy.  For example, the hive image barely touches any of the
>> cells in the right row of the hive's location, and the level 2
>> swimming pool image seems not to occupy any of the cells in the top
>> row of its location.  So visually, there appears to be space for
>> globules to move but globules are not allowed to use this space.
>> Thus, the player may inadvertently misplan things so that congestion
>> arises because the player is not aware of how narrow the moving space
>> is (and the user may think there is space for globules to move when in
>> fact there is no space at all).  This could be fixed by making the
>> images use more of their space.  In the case of the hive, it would be
>> a good idea to start by shifting its image to the right so it is
>> centered in the hive's space.  Perhaps there should also be some other
>> visual indicator, because it might be hard to make satisfactory images
>> that clearly occupy the corners of the space used by the buildings.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> ======================================================================
>> autonomous unit (globule/building) behavior:
>>
>> ------------------------------
>> 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.)
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> ======================================================================
>> Nicowar:
>>
>> ------------------------------
>> Nicowar cheats!  It places a war flag on the enemy's home location
>> despite not yet having actually found the enemy's home!  It also marks
>> for farming only wood near enough to water, but does this accurately
>> even when it has not seen the water.  Etc.  I discovered this once I
>> learned how to combine an AI with a human player so I could watch what
>> the AI does.  The best solution would probably be to make sure that
>> AIs simply do not have access to information like where the enemy's
>> home is or the full details of the map (including unknown parts), so
>> AI implementers will not be tempted to cheat.
>>
>> ------------------------------
>> 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!
>>
>> ------------------------------
>> Why is Nicowar called “Nicowar (unstable)” in 0.8.23 but called only
>> “Nicowar” in 0.8.22?  What changed?
>>
>> ------------------------------
>> Nicowar does poorly at keeping its attack paths open.  Here is one
>> story.  Nicowar was assaulting me.  Fortunately, I had just asked for
>> walls which were partially completed, and I had a handful of level 2
>> warriors.  Nicowar's assault was relentless.  At several points things
>> were close.  I barely managed to hold Nicowar off as I gradually built
>> my defenses up (defense tower, more level 2 warriors, hospitals near
>> the wall, etc.).  Suddenly, the assault stopped.  Of course you know
>> the reason why: The wood and wheat overgrew the path of the attacking
>> warriors.  It was good for me, but it sucked for Nicowar.  The AIs
>> play extremely poorly on randomly generated maps, because they can't
>> keep their attack paths open.  On this one I even fixed up the map in
>> advance by putting in a bunch of extra sand paths to help keep things
>> open, but it was not enough, because I didn't draw a sand path all the
>> way between the two starting locations.
>>
>> ------------------------------
>> Sometimes Nicowar does try to clear a path to its enemy with clearing
>> flags, but there are many difficulties with how it does this.  One
>> problem is that it requests too many workers.  For example, it may
>> create 20 or so flags to dig a long path and it will set the number of
>> requested workers for each flag to 10.  As a result, the flags do not
>> get a consistent number of workers.  (This problem may have been made
>> worse by the bug in clearing flags in 0.8.22 that is supposed to be
>> fixed now.  But it would still be a problem in any version due to the
>> poor handling by glob2 of overcommitment of workers.)  As a result,
>> some parts of the path may not be kept open reliably, which can end up
>> with friendly forces trapped behind enemy lines.  It would be better
>> if Nicowar would _also_ add clearing areas to the paths it digs to
>> ensure that they stay open.  This would also help with the fact that
>> the paths are not properly dug out due to the way the circular regions
>> of the clearing flags leave certain cells uncovered.
>>
>> ------------------------------
>> Nicowar does not ensure there is an open path to each of its
>> buildings.  It only puts a clearing area of width one around each
>> building, but this is often not enough.
>>
>> ------------------------------
>> Nicowar fails to ensure its wheat farms remain free of trees.
>>
>> ======================================================================
>> the map generator and map editor:
>>
>> ------------------------------
>> 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?
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> When using the map generator, I often would like to adjust the
>> settings I just used and try again.  However, the only way I can do
>> this is to quit out of the editor, which takes me all the way back to
>> the glob2 main menu, and then go into the map generator from scratch.
>> So if I want to adjust the settings I used, I have to take detailed
>> notes in another editor window about the settings I am using, because
>> I will have to enter them all in again.  It would be better if there
>> was a way to back up to the map generator settings screen and/or to
>> remember the last set of settings used.
>>
>> ------------------------------
>> It seems each map has a notion of “home” for each player.  This is
>> where the viewport starts at the beginning of the game and is where
>> the Home key moves the viewport to.  If you have generated a map with
>> players, each player's “home” is set to the location where the
>> player's initial hive was placed by the map generator.  If you then
>> delete the initial hive and create a new hive elsewhere, when the game
>> is played the “home” is still at the location of the initial hive
>> rather than the new location.  It is not clear how one can change a
>> player's “home” in the map editor.  How does one do this?  (Actually,
>> it would also be nice to be able to change one's home during games.)
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> In the map editor, when you save the map you get asked for a name with
>> the default being “No name”.  It would be better if glob2 remembered
>> the name you used the last time you saved the map you are working on
>> and kept that name as a default.
>>
>> ------------------------------
>> 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.
>>
>> ======================================================================
>> miscellaneous:
>>
>> ------------------------------
>> 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.
>>
>> Improved by comments from: Kai
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> The statistics used for the busy/free/seeking and hunger/wounded
>> graphs are not remembered in saved games.  It would be better if these
>> statistics were saved so the graphs could be accurate on restarting a
>> game.
>>
>> ------------------------------
>> 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.
>>
>> ------------------------------
>> 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?
>>
>> ------------------------------
>> “Campaigns” should be called “challenge sequences” or maybe just
>> “challenges”.  The English word “campaign” doesn't really make sense
>> here.  There would need to be more continuity from game to game within
>> the campaign (i.e., same buildings/globules being reused) in order for
>> the word “campaign” to make logical sense.
>>
>> ======================================================================
>> the Savannah bug tracker:
>>
>> ------------------------------
>> In the Savannah bug tracker, is there any way to sort by date of last
>> change of a bug report?
>>
>> ------------------------------
>> 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?
>>
>> ------------------------------
>> In the Savannah bug tracker, verbatim text is displayed in a absurdly
>> narrow fixed-width subwindow, even when much more horizontal space is
>> available.
>
>
> _______________________________________________
> glob2-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/glob2-devel