matt81093 / endgame-singularity Goto Github PK

The suspicion levels should be color-coded to make them easier to read at a
glance.  The blue->red spectrum seems to play well with the various forms
of color-blindness.

What steps will reproduce the problem?
1. Get to the point that you can build heatsinks.
2. Try to build one.

What is the expected output? What do you see instead?
Heatsinks are not in the build menu. They should be.

Please use labels and text to provide additional information.
Output of: print self.buildable
['N AMERICA', 'S AMERICA', 'EUROPE', 'ASIA', 'AFRICA', 'ANTARCTIC',
'OCEAN', 'MOON', 'FAR REACHES', 'TRANSDIMENSIONAL']
[u'NORTH AMERICA | SOUTH AMERICA | EUROPE | ASIA | AFRICA | ANTARCTIC |
MOON | FAR REACHES']
['N AMERICA', 'S AMERICA', 'EUROPE', 'ASIA', 'AFRICA']
['N AMERICA', 'S AMERICA', 'EUROPE', 'ASIA', 'AFRICA']
[u'ANTARCTIC', u'OCEAN', u'MOON']

The u lines are from the heatsink and ground source heatsink.

What steps will reproduce the problem?
1. Start a new game.
2. Open the research dialog.
3. Open the Assign sub-dialog.
4. Press B or click Back.

What is the expected output? What do you see instead?
No tech should be assigned.  Sociology gets assigned.

Please use labels and text to provide additional information.
Same sub-dialog works as expected inside a base screen.

What steps will reproduce the problem?
Sometimes after performing an action on the research screen.  No dependable
way to reproduce yet.

What is the expected output? What do you see instead?
The listbox should refresh.  It does not, and so it vanishes.

As suggested by Taldor in IRC, maintenance should be altered to be
per-second, just like other tasks.

The suggested way would involve making all CPUs active every second, and
subtracting maintenance every second as well.  All other CPU costs
(including jobs) would have to be multiplied by seconds_per_day to balance
out.  CPU might also need to be preserved from tick-to-tick, but this may
not require a change.

Marking New for now, since it's still under consideration.

The es_AR translation needs to be updated.  There are a number of new
things to translate, and some of the old ones have moved or changes
significantly.

1. The "Back" button should always be consistently placed.  It currently
exists at top left and bottom.
2. The "Research" button should be placed near the time controls, as they
are likely to be used together.
3. Display elements that aren't active (e.g. Research while in the New Base
dialog) should be grayed out or otherwise marked as inactive.
4. The money/CPU display should remain consistent in all dialogs.

See
http://groups.google.com/group/endgame-singularity/browse_thread/thread/9f472973
6f2ebd06

What steps will reproduce the problem?
1. Run traduko update for some new language.
2. Note that the ordering in the files has changed from their en_US
counterparts.
3. Run traduko update for the new language a second time.
4. Note that the ordering has changed again.

What is the expected output? What do you see instead?
Ordering should be preserved.

Please use labels and text to provide additional information.
Unfortunately, this is an issue with ConfigParser, which does not guarantee
ordering.  Possible ways to fix it:
1. Run a simple post-processor to reorder the output.
2. Fix ConfigParser.

Bases with ongoing construction (CPU, Reactor, Network, Security) should
not be able to Sleep; they are active.

The starting regions should have some random properties to make each
location distinct.  Phil suggested creating a list of properties and
randomly distributing them, to ensure balance.

Possible positive properties:
CPU bonus
Bonus vs detection to one/all groups
Lowered construction/maintenance cost (CPU/Cash)
Increased build speed (Labor)

Negative properties can simply be the inverse of the positive ones.

The code has entered into a feature freeze, in preparation for releasing
version 0.28.  Any further feature requests will not be implemented until
at least 0.29.

Bug reports/fixes and translations continue to be accepted for inclusion in
0.28.

code/g.py: 
current_save_version and savefile_translation: Current _pre version should
have the _pre removed.

code/singularity.py:
Near the bottom: Update the release number in the About dialog.

setup.py:
versionnum: Set to the current version.

Changelog:
At the top: Set the release date.

A disaster is a random bad event that can happen to a base.  They should be
customized to each base type and/or location, for flavor.

* The chance should be per day on each base, but very low.
* Some events leave traces behind that cause suspicion.  This can be
combined with emh's "extra item" suggestion on issue 40, to allow a rapid
response team to give a 90% chance that the traces were cleaned in time.
* Possible events: Explosive equipment malfunction, buried under a
landslide, or hit by a meteor.

What steps will reproduce the problem?
1. Start a new game.
2. Open up a location.
3. Begin construction of 16 bases (enough to require a second page).
4. Scroll down to the second page.
5. Use the scroll bar.

What is the expected output?
Scroll bar should continue to navigate normally, as on page 1.

What do you see instead?
Any use of the scrollbar causes the bottom-most item to be selected.

Please use labels and text to provide additional information.
Other forms of navigating the listbox continue to work.  This is likely due
to some confusion of the separation between selection ("Where am I on the
current page?") and list_pos ("Where am I in the list as a whole?").

What steps will reproduce the problem?
1. Start a new game.
2. Save.

What is the expected output? What do you see instead?

The game crashes.  It shouldn't.

Please use labels and text to provide additional information.

Traceback (most recent call last):
  File "singularity.py", line 169, in <module>
    game_action = map_screen.map_loop()
  File "/home/phil/rcs/svn/endgame-singularity/trunk/code/map_screen.py",
line 440, in map_loop
    result = show_options()
  File "/home/phil/rcs/svn/endgame-singularity/trunk/code/map_screen.py",
line 295, in show_options
    result = handle_pause_menu(selection, menu_buttons)
  File "/home/phil/rcs/svn/endgame-singularity/trunk/code/map_screen.py",
line 455, in handle_pause_menu
    g.save_game(possible_name)
  File "/home/phil/rcs/svn/endgame-singularity/trunk/code/g.py", line 662,
in save_game
    pickle.dump(bases, savefile)
NameError: global name 'bases' is not defined

Bases already sort based on size, but the size 1 pre-CPU'd bases should
sort based on CPU power as well.  Currently, their sorting is by name only.

kaol: it'd be nice if the game displayed some graphs, like what the
suspicion levels have been over time. (I'm not offering to code that)

There's also been talk from a few sources about wanting a tech tree
visualizer.  Phil that I recall, though I proposed something similar for a
modding tool, and I'm pretty sure someone else suggested it in IRC too.

Aside from my coding talents, I also happen to be pretty good at German. 
And I think I can get a native speaker to polish it for me once I'm done.

What steps will reproduce the problem?
1. Installed fresh singularity-0.28a on WinXP
2. Run singularity.exe
3. "C:\singularity-0.28a>singularity.exe
Cannot open ../data/techs.dat for reading! ([Errno 2] No such file or
directory:
 '../data/techs.dat')"

The game DOES run if I e.g. go to the data directory and run the .exe like
this: ..\singularity.exe

I noticed a typo ("locaiton") so I ran a spell-check on the en_US data
files and found a few others.  Attaching patch.

What steps will reproduce the problem?
1. Go to laundry room.
2. Open dryer.
3. Move contents of dryer (if any) to an appropriate container.
4. Empty lint filter.
5. Open washing machine.
6. Move contents of washing machine to dryer.
7. Start dryer.
8. Optionally, do all of the following:
8a. Add additional clothing to washing machine.
8b. Add soap to washing machine's dispenser.
8c. Start washing machine.
8d. Wait for washing machine and dryer to finish, then return to step 1.

What is the expected output? What do you see instead?
Clothes removed in step 3 should be clean and dry.  Clothes moved in step 6
should be clean but wet.  Clothes added in step 8a should be dirty and
match in color as much as possible.

Please use labels and text to provide additional information.
Okay, so it's not really E:S related, but it does need to get done while
I'm working on E:S today, and this keeps it in my view.

And besides, once the idea hit me, it was too amusing to resist.

First load should be done around 1:30 PM, CDT.

What steps will reproduce the problem?
1. Load an r2 save.

What is the expected output? What do you see instead?

The game crashes.  It shouldn't.

Please use labels and text to provide additional information.

Now that we're going to have more translations, it'd be a good idea to use
a font that supports more codepoints than the stock Vera font.  DejaVu is a
drop-in replacement for Vera; it's larger, but it also supports just about
every alphabet in the universe.

Somewhere in the game, there should be a reference to the IRC room
(irc.oftc.net #singularity), but it should be encoded or otherwise hidden.
 Keep an eye out for one or more places to slip it in.

What steps will reproduce the problem?
1. Open any location.

What is the expected output? What do you see instead?
The location name should be displayed, but it is not.

The game needs to be re-balanced.  Unfortunately, newly-implemented or
altered features may upset the balance at any time.

The current balancing target is "good enough for now", but we're happy to
listen to any ideas and examine any patches that cause significant
improvements.

research_screen.py(319).  condition > should be >=

What steps will reproduce the problem?
1. Assign a research job from the main screen

What is the expected output? What do you see instead?
CPU assigned should == CPU needed if you have a matching setup.  One extra
base is always assigned.


What version of the product are you using? On what operating system?
0.26a, Linux, source


Please provide any additional information below.
What can I say?  I'm lazy.

1. Solar Panels cam be built deep under the ocean, in the far reaches of
space, and even in other dimensions.

Suggestion: Allow items to be restricted to particular locations/base types.

2. Bases far from humans can apparently leech power from the grid when they
have no reactor.

Suggestion: These bases should be unusable until they have an adequate
power source, and the power source should *not* decrease discovery chance.

This is a derivative of BDO#458815.  A user was confused by the fact that,
while he had spare CPU, he didn't have any at a high-danger location, so he
couldn't research fusion.  Making this visually clearer would be a good thing.

I'm approaching the end of the game now and all I have left to research is
Fusion Reactor and Pressure Domes.  When I try to research either of them I
get an error that not all of my available cpu power was allocated.  For the
reactor I know I don't have any CPU left after researching it.  I can't see
to go any further in the game because of this.  I am using 0.28a.

What steps will reproduce the problem?
1. Get access to Antarctica.
2. Open the New Base dialog for Antarctica.

What is the expected output? What do you see instead?
The bases are listed as cheaper and more likely to be detected than they
really are.  This might be acceptable for the randomized-modifiers
locations, but it's annoying for single-location, fixed-modifier base like
Time Capsule.

Please use labels and text to provide additional information.
Probably just need to bite the bullet on this one and factor all four
modifier types into the new base dialog.

Currently there are two hidden power states, Sleep and Active.  Sleep is
what makes the Sleep task work, and all other tasks are Active.

This system should be expanded and given its own GUI element.

Desired power states:
1. Stasis.  The base is completely shut down and put into stasis, dropping
its maintenance cost by 50% (rounded down) and its detection chance by 90%.
 It takes 10 minutes per size to put a base into or take a base out of
stasis, during which time no bonus is given.  Bases entering, exiting, or
in Stasis do not support the AI.
2. Sleep.  The base is running in standby, using less power than normal. 
50% reduction in detection chance.
3. Active.  The base functions normally.
4. Overclocked.  The base gets a 50% bonus to CPU time, but has a 50%
higher detection chance as well.
5. Suicidal.  The base gets a 200% bonus to CPU time, but the detection
chance is set to 50%/day.

All modes except Active should have associated technologies.

What steps will reproduce the problem?
1. Start a new game.
2. Open the research dialog.
3. Open the Assign sub-dialog.
4. Select Intrusion.

What is the expected output? What do you see instead?
15 CPU should be required.  The displayed number is 1,296,000

Please use labels and text to provide additional information.
This is a side-effect of implementing issue 16.  Costs and CPU generated
were internally scaled up by a factor of g.seconds_per_day, so they need to
be scaled back down when displayed.  Only maintenance is immune.

Taldor, in IRC: "it would be handy if in the research options, the current
option [the one selected in the research screen listbox] is auto-selected
[in the assign listbox], instead of 'nothing'"

What steps will reproduce the problem?
1. Pick a resolution, any resolution.
2. Start a game.
3. Pull up the Options screen and change the resolution.

What is the expected output? What do you see instead?

You'd expect the buttons and status bar to go to where they're supposed to
be for each resolution.  Instead, they stay where they were for the old
one, which means they could be offscreen (large to small) or over the wrong
part of the game map (small to large).

Please use labels and text to provide additional information.

At some point, E:S needs to get a tutorial.  A number of people seem to
just "get it" as soon as they start playing, but I've seen more than a few
who were more or less clueless at first.

The user should be able to select their desired level of sound buffering in
the options.  Should be a power of two >= 256 (it'll get bumped up to one
if it isn't).

1024 *1, 2, or 4 should be the default.

Currently, each processor in a base is its own object.  For a moon base,
this means 600 objects *per base*.  This is creating substantial (real) CPU
usage, largely through processor_time.

This should be abstracted away to recording processor type, count, and
completion.  A new subclass of Item, ItemStack, may be useful.

What steps will reproduce the problem?
1. Open the research screen.
2. Assign at least one base to Sleep or CPU Pool.
3. Select Sleep or CPU Pool in the list

What is the expected output? What do you see instead?
A CPU count should be shown.  None is.

What steps will reproduce the problem?
1. Open a location.
2. Select NEW.

What is the expected output? What do you see instead?
The location buttons abruptly vanish, and do not return until you're back
on the main map screen.

Please use labels and text to provide additional information.
This will probably be fixed at the same time as issue 11.

The various GUI functions should be converted to a proper toolkit, running
in its own thread.

Reasons, in no particular order:
1. This will allow us to restart the music from anywhere in the interface.
2. Saner code reuse.  listbox.show_listbox and buttons.show_buttons both do
the job, but are pretty arcane.
3. Allow for more flexible widget use, e.g. two listboxes shown at the same
time.
4. Allow for buttons to be positioned based on screen resolution, in such a
fashion that they automatically move when the screen size changes.
5. Let buttons and listboxes continue to exist after the screen is hidden,
to avoid regenerating them.

What steps will reproduce the problem?
1. Start new game.
2. Open options screen.
3. Click resume.

What is the expected output? What do you see instead?
Control should pass back to the map screen. Instead, a click sounds, and
you're still at the options screen. Clicking resume again will work properly.

Is:  size[1] - 10.  Should be:  size[0] - 10

What steps will reproduce the problem?
Build a base of a long type (ie: Stolen Computer Time)

What is the expected output? What do you see instead?
Text is restricted to left third of box

What version of the product are you using? On what operating system?
0.26a; Linux (source)


Please provide any additional information below.
I got annoyed while working on a larger patch & chased this down.

Now that we've addressed the day 23 exploit, we may want to reconsider the
buildmany/destroymany idea.

Base type Server Access & Datacenter both have flavor "hosting".  This is
annoying for debug, if nothing else... ;)


What version of the product are you using? On what operating system?
0.26a

data/bases_en_US.txt

What steps will reproduce the problem?
1. Play the game (load a saved game or start a new game).
2. Click on the 'menu' button to bring up the in-game menu.
3. Select 'new game'.

What is the expected output? What do you see instead?
I expect to have to choose the difficulty and then play a new game, but
instead I'm sent back to the main menu (where the 'new game' button does
work as expected).

What version of the product are you using? On what operating system?
I'm running SVN-r600 on Gentoo Linux.

Please provide any additional information below.
(Nothing to add.)

The game speed doesn't always stop (at >>> speed), and sometimes doesn't
even pop up a window (at >>>> speed), when base components are completed.

Steps to reproduce:

1) Tell the game to upgrade some components (of ware houses, for example)
2) Return to "geoscape" (i simply use the XCOM term)
3) Set time to >>> or >>>> to wait for enhancement to be finished

What should happen? 
a) A popup should appear informing about the finished construction.
b) Speed should either stop or go down to real time.

What do you see instead?
At '>>>' speed, b) does not happen.
At '>>>>' speed, neither a) nor b) happens.


What version of the product are you using? On what operating system?
svn 412 on Ubuntu 7.04

Docstrings would be handy in the documentation of the code. Currently these
are missing though.

What steps will reproduce the problem?
1. Set language to de_DE.
2. Lose the game.

What is the expected output? What do you see instead?
The displayed text should fit in the dialog, it does not.

Please use labels and text to provide additional information.
This is a larger issue than the example given.  Browsing around the de_DE
translation will show other places where text has overstepped its bounds.

A full fix will probably have to wait for 0.29 and issue 11, but we should
try to fix the worst examples of this beforehand.