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

[Joe Wells]

Kai Antweiler <address@hidden> writes:

>> Kai Antweiler <address@hidden> writes:
>>
>>> Bug:  when the only offered jobs come from an Inn with full food and no
>>>       guests,
>>
>> Does that ever happen?  It seems to me that in any real game there
>> will always be other kinds of jobs also.
>
> But such things can lead us to code that does not what it should do.
> This is clearly no blocker bug.  Maybe it is even intended, but
> I wanted to mention it.
>
>>>       sometimes a glob harvests wheat.  There is no white box.
>>>       Only a black box.
>>
>> What do you mean by “white box” and “black box”?  Do you mean instead
>> “small white circle above the inn” and “small black circle above the
>> inn”?
>
> I see boxes.  But I think we're meaning the same.

Okay, I think you meant to write this:

  BUG:  Workers sometimes harvest wheat even when the only offered jobs
  are from inns that are full of food and have no guests, and there are
  no clearing areas or clearing flags.  There are no building sites or
  hives needing wheat.  The workers that harvest wheat are shown as
  carrying wheat after it happens, as though they were harvesting the
  wheat to carry it to a building.  When this happens, the indicators of
  small circles above the inns show only black circles meaning that the
  inns have not accepted any workers.

Am I understanding your report correctly?  Also, is this for 0.8.22?

>>> It would be nice if buildings get identification tag.
>>> When you click on a glob you could see the tag of the building
>>> it is working for.
>>
>> Agreed!  The path doesn't show this if it is fetching a resource first.
>
> Actually I think we should get rid of the paths, because this is not the
> way glob2 works.  Tags like "i3" for an special Inn are much more glob2
> style.  Or only draw straight lines from globs to buildings.  We don't
> know which resource the globs are heading to anyway.

I find the paths extremely helpful, despite their problems.  I only
wish they were a bit better.  I think for workers going to harvest
resources, it would be enough to update the paths every 5 seconds to
account for changes.  Plus, I would like to see a path to the building
the worker is gathering the resource for.

>>> We can change the tracker.
>>> I think glob2 could profit from switching to lauchpad.net, but
>>> I don't know if their tracker handles duplicates better.
>>
>> That is part of why I made my comments.  _If_ the tracker is changed
>> (and I have seen some proposals for this on the mailing list), I think
>> it would help to keep in mind the issues I mentioned.  But changing
>> the tracker is a lot of work, and will break lots of links in archived
>> e-mail messages and Wiki pages, so it had better be a big improvement
>> to justify it.
>
> I didn't worry much about the tracker.  I just thought in case we
> would switch to launchpad that problem would vanish for new bugs.
> My reasoning is that either we will switch to mercurial on
> Stephs host, or to bazaar on launchpad.  I prefer mercurial over
> bazaar.

By the way, if there is a switch to a new bug tracker, it would be
helpful if the old bug tracker remained in place, but with all edits
banned.  This would allow old URLs pointing at specific bug reports to
continue to work.  (Even better would be to import all of the old bug
reports in the new tracker and somehow automatically forward all of
the old URLs.  But that would be hard!)

>>> We should include a "no logfiles" commandline option for you.
>>> Can't be that difficult to implement.
>>
>> That would be good.  It is probably more complication than it is worth
>> to try to detect if the disk is getting full (before it happens
>> anyway), so just turning the logs off is probably the best option.
>
> You can patch your local glob2 sources.
> src/LogFileManager.cpp line 48-51:
>                 FILE *file=fileManager->openFP(logName.c_str(), "w"); 
>                  
>                 if (file==NULL) 
>                         file = stdout; 
>
> commenting out:  // FILE *file...
> and   // if(file...
> should de the trick.  Then your logs would be writen to the terminal.
>
> When your on unix system editing just the first line might be better:
>                 FILE *file=fileManager->openFP("/dev/null", "w"); 
>
> I think LogFileManager.cpp isn't changed often so this might work well.
> (Btw:  Mercurial has a nice feature that manages personal patchsets on
>        repositories.)
>
> I've got an idea what you can try:
> # cd .glob2/logs
> # for in * ; do rm $i; touch $i; chmod -w $i ;done
>
> This should work without changes to the glob2 source code.

I'll try this last option (denying write permission on the .log files)
and see if it works.  (I'm not planning on compiling from CVS any time
in the near future.  I'm happy to try releases.)

-- 
Joe