[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [glob2-devel] more feedback (many topics)
Re: [glob2-devel] more feedback (many topics)
Sun, 15 Apr 2007 12:36:34 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
Kai Antweiler <address@hidden> writes:
> Bug: when the only offered jobs come from an Inn with full food and no
Does that ever happen? It seems to me that in any real game there
will always be other kinds of jobs also.
> 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
>> It would be nice if the lines drawn by the "draw unit paths" feature
>> (which draws lines that indicate where globules are going and is
>> invoked by default by "t") appeared even when neither source nor
>> destination are on the screen. This is needed to allow tracking a
>> long line across several screens to try to understand where a globule
>> is going (and why it is going there!).
> 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.
> Or an option that the tags are printed on the
> screen. And more convenient: colors. Select a building and all
> globs that work for it and the building get some color.
You can already get this by holding left mouse on the building (I
think this also works on flags?): it circles the assigned globules in
color. I've made some remarks before on how this could be improved.
But it should also be possible to get the information from the
> Also the lines from "draw unit paths" get that color.
That's a good idea. But I think the unit paths might need to become
more reliable first. :-)
>> the bug tracker on Savannah:
>> Duplicates do not seem to be linked (at least not automatically). It
>> should only be possible to mark a bug report as a duplicate if one
>> specifies _which_ other bug report it is a duplicate of. And in that
>> case, there should be a link between the two bug reports. This
>> doesn't seem to happen (at least not automatically). This means that
>> the effort put into a bug report marked as a duplicate is effectively
>> lost, because one can not find it from the main bug report. Is there
>> some way to fix this?
> You can manually add a comment: "marked this as duplicate of ..."
One actually wants this link on both reports. Bugzilla does this
> You can suggest this wish to savannah.
Yeah, I've got a lot of bugs I should file. :-)
> 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.
>> Whether a bg report is open or closed is orthogonal to its status.
>> This is confusing. Is there some way to tie bug status to whether a
>> bug is open or closed?
> I like it that way. You can close a bug that is old and has never
> been confirmed or fixed without loosing its state. Also you can
> mark something as fixed and leave it open for a week or so and
> ask others (like the creater of the bug) to check if this really
> is really working for him.
Okay, good point. I withdraw my remark.
>> 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?
>> The log files in ~/.glob2/logs continue to grow even when glob2 is
>> paused. I left glob2 running overnight paused and it filled my hard
>> disk. Ugh.
> Do you know which logfiles?
> There are many of them.
Here is the size of the log files at the end of a quick short game:
> cd ~/.glob2/logs
> ls -s | sort -rn
This should give you an idea of which log files grow most rapidly.
> 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.