Beta date?

[Xenega]

nthykier have resolved the blocking issues and we have made a lot of change, so we should choose a date for the release of a 1.0 beta version now.

What date should we choose?

[nthykier]

Today? :)

[nthykier]

I think the only thing we "need to have" is an updated changelog (#181). If we can get #173 or/and #177 done that would great too, but they can come later in another beta, the final 1.0 release or even later.

So I am in favour of releasing a beta as soon as possible for wider testing and exposure!

[sunfall]

Feel free to ignore this, because I haven't been doing much of anything on the code side, but:

If we get an opaque savefile entry redirect change in sooner rather than later, I would really like to go back through all the game's text and techs and do a rewrite/reordering/rejuggle pass. It will forever bug me that Arbitrage (for example) doesn't work in a sensible way given its name, and I'd like to reposition it. In addition, a lot of the tech and item descriptions are pretty bland. Given how few we have to deliver flavor to the player, I'd like to take advantage of the ones we have.

If we do it, this sort of change should 100% be done before releasing a beta, as it's likely to break the heck out of savefiles if it's done wrong.

[nthykier]

I tried to cut a release and it is available from: https://github.com/singularity/singularity/releases/tag/singularity-1.0a1

Please take it for a spin and see if there is anything not working as intended.

[evilmrhenry]

Initial run-through notes:

• Options and About screens should have border for consistency
• GUI sounds are rather harsh. Recommend replacing with free sounds.
• Font resizing creates inconsistent appearance. Recommend having default font size, and only using resizing if the given text does not actually fit in the space given.
• Changelog and similar files should have .txt extension for convenience of Windows users.
• Remove " * Send update notice to happypenguin.org, freshmeat.net and pygame.org." line from release/README.txt. First 2 don't really exist anymore, pygame.org doesn't seem worth bothering with.

None of these are show-stoppers, just notes for the next release.

I am currently working on getting a Windows exe up and running; py2exe is dead, which means the instructions for building an exe are also wrong. I think I have a usable replacement, I just need to figure out why it's not working right.

[nthykier]

Thanks for the update. :)

• The screens now have borders (42be521)
• I filed GUI sounds are rather harsh #201 for following up on the GUI sounds
• I filed Font resizing creates inconsistent appearance #200 for following up on the font sizes
• The README/Changelog now uses .txt extensions (de03284 + e844775)
• The "send notice" remark has been removed from the release documentation (0ce3617)

Side-note: I am probably going to cut a new release relatively soon. Among other due to aa04fcc and #198 but it will also enable us to re-test the changes to the release documentation. :)

[evilmrhenry]

The reason auto-py-to-exe was failing is because the main py file is named singularity.py, while the import directory is also named singularity. For some reason, giving these the same name causes it to break in a way that doesn't create useful error messages.
brentvollebregt/auto-py-to-exe#82
I am currently unsure if changing a filename will be required; for now, just assume this is a possibility.

[rofl0r]

I am currently unsure if changing a filename will be required; for now, just assume this is a possibility.

if considering this possibilty keep in mind that changing file names or moving them to another place breaks git history (stuff like git blame, git log -p, etc).
an option might be to just rename/copy the file during packaging.

[nthykier]

@evilmrhenry Thanks for working on the Windows compilation.

Could you see if the alternative-main branch fixes this problem?

[nthykier]

The alternative-main idea is busted. If you have singularity installed (e.g. via a distribution) the method from that branch will silently load the distribution provided one instead of the git checkout.

I guess a simpler fix is to rename the singularity.py script to run_singularity.py or so.

[MestreLion]

I guess a simpler fix is to rename the singularity.py script to run_singularity.py or so.

Being the one that created singularity.py a few years ago (omg, so much activity since then!), I believe this is the best approach.

Being 2019 we have much better ways to run the game locally without this launcher, namely pip install -e ., as it uses setuptools entry_point in setup.py to create an executable in /usr/bin or ~/.local/bin, which you guys have already done 👍 ; and/or python -m singularity, provided we create a ./singularity/__main__.py that merely invokes from . import main; main()

Given those 2 ways, I believe this executable is not needed anymore. But, if we keep it, there's no point in it being having a .py extension, as it already has a #! shebang. So it could simply be named run_singularity, to clarify this is merely a shell launcher. Also, it should contain a few in-code comments about how optional and redundant it is, something along the lines of:

# You can also run the game with 'python -m singularity'

or

# You don't need this launcher if you run 'pip install -e .',
# as it creates a 'singularity' executable in your $PATH

[nthykier]

@MestreLion Hi - welcome back. :) Thanks for your input

@evilmrhenry I have written the launcher to avoid the PyInstaller issue. Let me know if it works (or if you need a new alpha release to for testing)

[evilmrhenry]

As an update, there appears to be some working directory issues with the exe; it actually runs code now, but it still doesn't work. I'm still tracking it down. In the meantime, line 148 in dirs.py should probably be changed to
if (item["parent"] not in read_dirs or not read_dirs[item["parent"]]):
as read_dirs[X] can never be None. (This doesn't actually break anything, it just got revealed thanks to this other issue.)

[evilmrhenry]

OK, wasn't as hard as I thought. In dirs.py, you should change the line

    root_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))

to

    if getattr(sys, 'frozen', False):
        root_dir = os.path.join(os.path.abspath(os.path.dirname(sys.executable)), "singularity")
    else:
        root_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))

This doesn't need to be in the actual release; if it's not, I'll just add it. I want this in place for the next release, though.

At this point, I have the ability to create a working exe. I started a new game and clicked around a bit, and everything seems to work. Do you want to build a new alpha release before I really start testing?

[nthykier]

Excellent :)

I have committed your changes to master and cut a new release. Turns out we have accumulated quite a few changes since 1.0a1. :)

[nthykier]

Hi @evilmrhenry

Did you get around to build a windows release for 1.0a2? :)

[evilmrhenry]

I kind of forgot about this. Thanks for the reminder.

[evilmrhenry]

OK, I've gotten a Windows compile. I'm alright with making this a real release.

[nthykier]

Thanks for confirming it works. :)

I think I will cut another release now, which I think we should make the first "real" release. I discovered and fixed a bug that only manifested under python3, where Australia never got a location modifier assigned (there are 5 modifiers but 6 locations and Australia would always be picked as the location without a modifier).

I will ping you when I am done with the release.

[nthykier]

@evilmrhenry - I got the beta1 done now (https://github.com/singularity/singularity/releases/tag/v1.0b1)

Besides the bug I mentioned already, I also found a crash bug with savegames that also got fixed.

[evilmrhenry]

Do you plan for this to be the actual release, or should I hold off a couple days to catch anything else that shows up?

[nthykier]

evilmrhenry:

Do you plan for this to be the actual release, or should I hold off a couple days to catch anything else that shows up?

I think we should align our expectation here and I hope you will expand on your side of the situation. My view is that we have just cut the first beta1 release of singularity 1.0 and it is ready for wide-spread testing. They will ideally find some bugs that we would like to iron out before doing the final release. My preference for the short term is to do a "release-early-release-often" approach for such bug fixes. It lets the beta tester move on from that bug to the next and give us more accurate feedback. At the same time, it keeps the steam running on our side as well. On the flip side, I am aware that I am not the only person in this project and we need this to work for everyone. Which brings me back to: What are your expectations here? Where would you like this project to head towards?

[evilmrhenry]

Oh, wait, you wanted my opinion here.

My perspective is that beta releases are for testers, not for the general public, and I would expect testers to have a Python setup available to them. The Windows binaries are useful for general releases, as people who play games on Windows cannot be expected to have a Python install. As such, my expectation is that we do however many beta releases are needed until we're reasonably sure the game is stable and playable, then we do an actual release with a Windows binary and what not.

Now, if beta testers want Windows binaries, I can manage that, it's just a bit annoying, and I don't want to commit to putting out a dozen beta binaries if they're not going to be widely used.

[nthykier]

Ok. Sounds reasonable to me. We will keep the Windows binaries for the "final" releases only.

What about announcing the betas for wider play testing? Are there any good places to do that or should we assume they are all subscribed to the github repo?

[evilmrhenry]

You could ask on the endgame mailing list; I'm not sure how well that would work, though. Having a bug in the final released version isn't the end of the world, anyway.

[nthykier]

Thanks for the input. Given we have a beta and an agreement on when/how to build Windows releases, I think this is overdue for being closed. :)