Playable GUI preview uploaded (Windows/Linux)
Charlie Nolan
GUI preview. It's fully playable at this point, and I'd like to get
some outside impressions of it.
http://groups.google.com/group/endgame-singularity-dev/web/singularity-0.29_pre.zip
Linux people can grab a source tarball here:
http://repo.or.cz/w/singularity-git.git?a=snapshot;h=eb889144c7d4b5bcb39b9f1f1d9f41727703f321;sf=tgz
Note that there's a new dependency on NumPy.
Known issues:
* There's no way to view the progress of a base under construction.
* The Finance and Concepts buttons are inactive.
Again, this is a GUI preview. There are some new features that came
about as part of the GUI upgrade, but more will be added before 0.29
is released.
Let me know what you think.
-FM
Charlie Nolan
* Old savegames can't be loaded. New ones save and load just fine.
All three of the issues will be fixed before 0.29, of course.
-FM
baffo32
- Trying to set a custom resolution causes the game to instantly quit.
- When I begin a new game, there is no narration and I repeatedly get
the menu popping up and the following error:
Exception in function show at Sun Aug 17 09:04:46 2008 Eastern
Daylight Time:
Traceback (most recent call last):
File "code\safety.pyc", line 58, in safe_call
File "code\graphics\dialog.pyc", line 132, in show
File "code\graphics\dialog.pyc", line 228, in handle
File "code\graphics\dialog.pyc", line 240, in call_handlers
File "code\screens\map.pyc", line 262, in on_tick
File "code\player.pyc", line 284, in give_time
File "code\player.pyc", line 446, in in_grace_period
TypeError: object of type 'generator' has no len()
On Aug 8, 10:59 pm, "Charlie Nolan" <funnyman3...@gmail.com> wrote:
> Sorry, one more issue I missed:
> * Old savegames can't be loaded. New ones save and load just fine.
>
> All three of the issues will be fixed before 0.29, of course.
>
> -FM
>
>
> > I just built and uploaded a Windows version of the current SVN as a
> > GUI preview. It's fully playable at this point, and I'd like to get
> > some outside impressions of it.
>
> > Linux people can grab a source tarball here:
Charlie Nolan
On the second, the intro wasn't in yet and the bug you hit happens
only on the harder difficulties. I think Normal works, but I know
that Very Easy does. It's been fixed since, I just haven't built a
new copy.
-FM
Baffo32
closed so rapidly if there were one I wouldn't have seen it. However,
I installed python and checked out trunk from SVN, and both issues
were gone. I ran the game at 1920x1200 perfectly, although the font
size would change from one dialog to the next.
The new way of distributing cpu load is very convenient. It took me a
bit to realise tasks were still associated with individual bases and
would be lost when the base is. Strangely, when losing a base, I also
notice a small amount of free cpu generated.
One-key control of power status was also extremely useful on higher
difficulty levels. My biggest feature request would be hotkeys for
immediately selecting the type of a newly created base, say numbers 1,
2, 3 down the list. When things get tight I tend be rapidly creating,
destroying, powering, and sleeping repeated small patterns of types of
bases across sets of continents waiting for suspicion to go down, and
end up hitting the down arrow a lot.
Additional missing features you didn't mention: There's no way to tell
what a given base still needs to finish partial construction, and no
intuitive way to cancel the production of e.g. servers in a warehouse.
Charlie Nolan
prompt in that folder. Any number of things could cause that, so
without more information, I've got no idea what needs fixing (if
anything still does).
Tasks aren't assigned to a base at all, but whenever the available CPU
drops below the amount you have assigned, the game removes CPU from
all current tasks, proportional to the amount of CPU the task had.
Rounding error will occasionally cause a small amount of available CPU
to be removed, but it should be limited to 1 CPU/task.
I like the number-hotkey suggestion. I do have one question: Should
pressing the number just select that entry, or actually choose it
(i.e. select and hit OK)?
On the two features, I'd already counted the first one under "no way
to view the progress", and the second would properly be a new feature
request, seeing as how there's never been a way to do that.
-FM
Baffo32
>
> If you want to diagnose the first issue, run the game from a command
> prompt in that folder. Any number of things could cause that, so
> without more information, I've got no idea what needs fixing (if
> anything still does).
I'm not sure this happens with the latest SVN, but here's the output
from 0.29_pre when I boot up, hit options, and click the input field
for the X coordinate of the resolution:
Traceback (most recent call last):
File "singularity.py", line 1, in <module>
import code.singularity
File "zipextimporter.pyc", line 82, in load_module
File "code\singularity.pyc", line 195, in <module>
File "code\graphics\dialog.pyc", line 132, in show
File "code\graphics\dialog.pyc", line 228, in handle
File "code\graphics\dialog.pyc", line 240, in call_handlers
File "code\graphics\button.pyc", line 109, in handle_event
File "code\graphics\button.pyc", line 122, in activate_with_sound
File "code\graphics\button.pyc", line 151, in activated
File "code\graphics\button.pyc", line 182, in show_dialog
File "code\graphics\dialog.pyc", line 46, in call_dialog
File "code\screens\options.pyc", line 183, in show
File "code\graphics\dialog.pyc", line 132, in show
File "code\graphics\dialog.pyc", line 228, in handle
File "code\graphics\dialog.pyc", line 240, in call_handlers
File "code\graphics\text.pyc", line 422, in handle_click
NameError: global name 'font' is not defined
> Tasks aren't assigned to a base at all, but whenever the available CPU
> drops below the amount you have assigned, the game removes CPU from
> all current tasks, proportional to the amount of CPU the task had.
> Rounding error will occasionally cause a small amount of available CPU
> to be removed, but it should be limited to 1 CPU/task.
Yeah -- after losing a base I tend to have to go through all my tasks
and add a cpu back onto them. In the beginning of the game I would
often have just 1 cpu assigned to all but one task, so the change was
very noticeable then.
> I like the number-hotkey suggestion. I do have one question: Should
> pressing the number just select that entry, or actually choose it
> (i.e. select and hit OK)?
I imagine having the number actually choose the entry would be much
more efficient and preferred by experienced players of the game, but
players new to keyboard control could be surprised and annoyed if they
were only trying to select the base in order to read about it. It
might be safer to have it select only; either that or make the
interface clear that pressing a number will close the dialog and
charge you resources.
> On the two features, I'd already counted the first one under "no way
> to view the progress", and the second would properly be a new feature
> request, seeing as how there's never been a way to do that.
Sorry! I must have totally missed that. I read your missing features
and then was quite surprised at one of them in game.
I played 0.28 again and you are right. I guess, in 0.28 when servers
are purchased in a single block only, I find it much more intuitive to
simply build a bunch of PC instead of Server when I don't want to pay
quite that much money. In the new interface, if I build 25 server and
realise that it's a little too expensive, then instead of switching to
gaming PC I would rather cancel them and build only 17 server rather
than 25. This requires the confusing path of switching to PC or
Gaming PC, and then switching back to Server again.
I found another crash on trunk I'm afraid. When in full screen, if I
switch to a resolution lower than my desktop resolution and then
disable full screen mode, the game quits or raises the menu with the
following output:
Traceback (most recent call last):
File "C:\endgame-singularity\singularity.py", line 1, in <module>
import code.singularity
File "C:\endgame-singularity\code\singularity.py", line 195, in <module>
menu_screen.show()
File "C:\endgame-singularity\code\graphics\dialog.py", line 132, in show
result = self.handle(event)
File "C:\endgame-singularity\code\graphics\dialog.py", line 228, in handle
return self.call_handlers(handlers, event)
File "C:\endgame-singularity\code\graphics\dialog.py", line 240, in
call_handlers
handler(event)
File "C:\endgame-singularity\code\graphics\button.py", line 109, in
handle_event
self.activate_with_sound(event)
File "C:\endgame-singularity\code\graphics\button.py", line 122, in
activate_with_sound
self.activated(event)
File "C:\endgame-singularity\code\graphics\button.py", line 151, in activated
self.function(*self.args, **self.kwargs)
File "C:\endgame-singularity\code\graphics\button.py", line 182, in
show_dialog
raise constants.Handled, dialog.call_dialog(self.dialog, self)
File "C:\endgame-singularity\code\graphics\dialog.py", line 46, in call_dialog
retval = dialog.show()
File "C:\endgame-singularity\code\screens\options.py", line 185, in show
retval = super(OptionsScreen, self).show()
File "C:\endgame-singularity\code\graphics\dialog.py", line 129, in show
Dialog.top.maybe_update()
File "C:\endgame-singularity\code\graphics\widget.py", line 288, in
maybe_update
self.update()
File "C:\endgame-singularity\code\graphics\widget.py", line 292, in update
self.prepare_for_redraw()
File "C:\endgame-singularity\code\graphics\widget.py", line 284, in
prepare_for_redraw
child.prepare_for_redraw()
File "C:\endgame-singularity\code\graphics\widget.py", line 284, in
prepare_for_redraw
child.prepare_for_redraw()
File "C:\endgame-singularity\code\graphics\widget.py", line 275, in
prepare_for_redraw
self.resize()
File "C:\endgame-singularity\code\graphics\listbox.py", line 154, in resize
self.remake_elements()
File "C:\endgame-singularity\code\graphics\listbox.py", line 125, in
remake_elements
child.remove_hooks()
File "C:\endgame-singularity\code\graphics\widget.py", line 169, in
remove_hooks
self.parent.children.remove(self)
ValueError: list.remove(x): x not in list
Jorge Vargas
>
>
> Linux people can grab a source tarball here:
> http://repo.or.cz/w/singularity-git.git?a=snapshot;h=eb889144c7d4b5bcb39b9f1f1d9f41727703f321;sf=tgz
> Note that there's a new dependency on NumPy.
>
> Known issues:
> * There's no way to view the progress of a base under construction.
> * The Finance and Concepts buttons are inactive.
>
>
> Again, this is a GUI preview. There are some new features that came
> about as part of the GUI upgrade, but more will be added before 0.29
> is released.
>
> Let me know what you think.
>
and I found an error, actually two:
1- open a new game
2- go to the change locale menu, if you go away from us, and back the
dialog will disappear
3- the buttons will reappear if you hover over them.
the second bug is with the es_AR locale, it's adding a !!!<name>!!! on
each of the continent names, I took a quick look at the code and it
seems it has a ton of !!! all over the place.
I'll take a deeper look into this soon (TM), but so far awesome work!
> -FM
>
Charlie Nolan
a look at the other.
Jorge - I'll look into the first error. The other one isn't really an
error, that's just the standard marker for missing localization data.
es_AR needs updating, badly.
-FM
Charlie Nolan
gotten to the issues Baffo and Jorge mentioned yet, but the intro is
back and there's a major new feature.
http://endgame-singularity-dev.googlegroups.com/web/singularity-0.29_pre2.zip
Linux folks should just visit this URL and hit the top-right snapshot
link, that'll get you a tarball of the current SVN:
http://repo.or.cz/w/singularity-git.git?a=shortlog;h=refs/heads/svn
-FM
Max McCracken
A side note. Can we make RMB and ESC act as Back in every window?
Seems convenient.
Charlie Nolan
>
> Font auto-resize also works on date display, so sometimes time is not
> visible.
Not quite sure what you mean. Date/time is one unit, so as long as it
resizes properly, it should always show the entire thing.
> A side note. Can we make RMB and ESC act as Back in every window?
> Seems convenient.
That's more or less planned, I just haven't decided how best to
implement it yet.
-FM
Max McCracken
>
> On 8/21/08, Max McCracken <maxs...@gmail.com> wrote:
>>
>> Font auto-resize also works on date display, so sometimes time is not
>> visible.
>
> Not quite sure what you mean. Date/time is one unit, so as long as it
> resizes properly, it should always show the entire thing.
Sometimes (when there are too many zeroes I guess) date/time display
becomes like this:
DAY 0002,
00:00:00
instead of usual :
DAY 0002, 00:00:00
And when it's 2 lines high, the time is under "Research/Tasks" button
- not visible.
Press '3' to set the speed and wait a little - you'll notice it. It
happens a few times in a game-day.
Charlie Nolan
spotted what's happening. Sort of.
For some reason, the 7 is being rendered slightly wider under Windows.
O.o That breaks the monospace font assumption, and causes the issue
you saw.
Anyway, I disabled wrapping in all of the fields that make that
assumption, so the display will just jiggle a bit when it happens.
Now, if you'll excuse me, I need to go file a bug report to the pygame folks.
-FM
Charlie Nolan
-FM
Anne Archibald
> I just uploaded a new version for anyone who's interested. Haven't
> gotten to the issues Baffo and Jorge mentioned yet, but the intro is
> back and there's a major new feature.
>
> http://endgame-singularity-dev.googlegroups.com/web/singularity-0.29_pre2.zip
>
> Linux folks should just visit this URL and hit the top-right snapshot
> link, that'll get you a tarball of the current SVN:
> http://repo.or.cz/w/singularity-git.git?a=shortlog;h=refs/heads/svn
Playing the svn version, I have a few comments:
* Why would you ever use the "<whatever> jobs" task? The "CPU Pool"
task does that plus any needed maintenance.
* What happens when you leave some processing power idle? Is it ever
worth doing? If not, perhaps "CPU Pool" could be eliminated as well.
Then it would be worth marking in red any CPU power needed to do
maintenance, so users can forgo maintenance for urgent research, but
won't do so by accident. (Although, do they have any control over
which bases die if this happens?)
* It's a pain to readjust the sliders every time your processing power
increases (say because your Quantum Entanglement Module just came on
line). I'm not sure how to avoid this, since users might want either a
constant fraction devoted to each task or a constant *amount* devoted
to one task and the spillover devoted to another. The
processing-power-decreases code assumes a constant fraction (can this
starve a base for maintenance because another was closed?).
* I ran into a bug where the map stopped updating, then went black. I
haven't tracked it down yet.
* On the console I get a zillion warnings "Warning: divide by zero
encountered in true_divide". It'd be nice if it came with a line
number... I wonder if it's related to the above?
* The text is all different sizes; sometimes too small, sometimes
reasonable. For example, in the new base name entry field, if the name
occupies two lines it becomes very small. Even when readable, the
varying sizes look peculiar.
* Do sleeping bases get automatically awakened if all your
non-sleeping bases close? It would make it a more useful way to keep a
backup.
Anne
Charlie Nolan
> * Why would you ever use the "<whatever> jobs" task? The "CPU Pool"
> task does that plus any needed maintenance.
When you want to generate cash, but maintenance/construction would use
up the CPU.
> * What happens when you leave some processing power idle? Is it ever
> worth doing? If not, perhaps "CPU Pool" could be eliminated as well.
> Then it would be worth marking in red any CPU power needed to do
> maintenance, so users can forgo maintenance for urgent research, but
> won't do so by accident. (Although, do they have any control over
> which bases die if this happens?)
Idle CPU are automatically assigned into the CPU pool. The reason for
the task is so that you can set aside CPU for the pool before
assigning the remainder to research.
I agree that it would be nice to have the necessary maintenance
visible there. Might be able to do something with the progress bar
code, I'll have to take a look at that later.
No, bases are lost to maintenance in semi-random order. What happens
is that the game goes through the base list in its own internal order
for both cash and CPU picks up bases with that type of maintenance
cost until it's collected enough to account for the shortfall. All
the bases it picked up get a 1.5% chance of decay per day for each
resource missing.
More concretely, say you have 20 identical bases, enough cash to
maintain 17, and enough CPU to maintain 10. Ignoring discovery, the
first 3 will survive a day just over 97% of the time (two 1.5%
chances), the next 7 will survive a day 98.5% of the time, and the
last 10 were properly maintained.
> * It's a pain to readjust the sliders every time your processing power
> increases (say because your Quantum Entanglement Module just came on
> line). I'm not sure how to avoid this, since users might want either a
> constant fraction devoted to each task or a constant *amount* devoted
> to one task and the spillover devoted to another. The
> processing-power-decreases code assumes a constant fraction (can this
> starve a base for maintenance because another was closed?).
It assumes a constant fraction only when there's not enough CPU left
to support a constant amount. Until then, the changing amount of CPU
just affects how many bases are unassigned.
A "lock sliders" button might work for this. Hit it, and any change
in available CPU will be applied evenly to all tasks.
> * I ran into a bug where the map stopped updating, then went black. I
> haven't tracked it down yet.
Offhand, it sounds like the map image got lost, so the next time the
entire window was redrawn, it didn't reappear. Let me know if you
track this one down, please.
> * On the console I get a zillion warnings "Warning: divide by zero
> encountered in true_divide". It'd be nice if it came with a line
> number... I wonder if it's related to the above?
Ah, thanks for reminding me. I've got a line sitting around somewhere
that fixes this. Apparently, some versions of numpy have a higher
default warning level than mine. It's not an important message, just
a case of doing three divisions in parallel and then throwing out the
ones that don't make sense afterwards.
> * The text is all different sizes; sometimes too small, sometimes
> reasonable. For example, in the new base name entry field, if the name
> occupies two lines it becomes very small. Even when readable, the
> varying sizes look peculiar.
Side-effect of the new GUI system. All font sizes are automatically
calculated, which is nice (because you don't have to worry about
overflowing a text field) but also annoying (for the reason you
mentioned). In the specific case you mentioned, I think it's a net
gain. Shrunken names are better than ones that get cut off. There
are other places where it'd be nice to have standard sizes, though.
> * Do sleeping bases get automatically awakened if all your
> non-sleeping bases close? It would make it a more useful way to keep a
> backup.
No. I suppose it might be useful to make a Sleep/Hibernate or
Nap/Sleep distinction, for making machines that come online when
needed, but I think it would cause more problems than it solves to
make all sleeping base wake up when the available CPU hits 0.
The problem is that there are two basic situations where you put a
base to sleep.
1. I don't need this right now. (e.g. an extra moon base)
2. I want this to hide. (e.g. a time capsule)
Your suggestion would be good for type 1 sleepers, but frustrating for
type 2 sleepers.
-FM
Nemoricus
one. Well done.
You should be able to destroy bases from inside their screens.