glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kai Antweiler
Subject: Re: [glob2-devel] more feedback (many topics)
Date: Sun, 15 Apr 2007 15:38:05 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (linux)

> 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.


>> 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.


>> 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.  But launchpad has a big advantage as far as I understood:
You don't have to ask for submission to add a new branch on an existing
project.  In my 1 year experience in open source development I have
seen not few people who see that something is lacking in a project.
Then they contribute this to the project and are off never to be
seen again.  Not having to ask for submission may improve that kind
of contribution.

But maybe I should worry more about the bug tracker. A lot of people
don't like it, and don't use it.  It should be used.


>>> Dragging with the middle mouse button in the main map area to move the
>>> viewport is not documented.  This is a nice feature, but I only found
>>> out about it by reading bug reports!
>
> Did you have a comment to make about my comment?

I use middle mouse button regularly.  Should be documented.
Maybe even in mentioned in the tutorial.


>> 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.
-- 
Kai Antweiler




reply via email to

[Prev in Thread] Current Thread [Next in Thread]