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

[Joe Wells]

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.