I was mourning to sydney today that TSC has no artists to bring the
story forward. Well, there's only so much we can do about
that. Currently, the list of remaining bugs is down to 7 entries and the
total of tickets listed for 2.1.0 is 18.
TSC's `devel' branch looks reasonably stable to me, and apart from the
story problem, I think it's good to release mostly. I'm going to take a
look at the remaining open bugs and tickets marked for 2.1.0 and remove
from the 2.1.0 milestone any tickets that have to do with graphics,
because without any artist in sight, there's no hope these tickets can
advance anytime soon. Instead I intend to release 2.1.0 later this year
and couple the release announcement with an explicit request for
artistic contributions. Once the release is out, I'm going to submit a
packaging request to Debian to get TSC back into the Linux distribution
pipelines. Together, this should hopefully leave us with at least one
artist to work on the subsequent TSC2 release.
I am going to have some time available around the beginning of November,
so I think it'd be great to issue the 2.1.0 release in that period.
Currently, I'm improving some rough edges of TSC's build system. Once
I've finished that, I'd be grateful if someone could try building a
Win32 executable using our new MSYS2 support.
Finally, I'm going to use this e-mail to publically apologise to
datahead. I've not placed any effort into the TSC3 rewrite as I
originally wished to do, and as datahead rightly foresaw. That doesn't
mean it's off the table, but for the moment I focus on TSC2. By now I
believe that we're going to see a couple of TSC2 releases before any
TSC3 comes along. I know I'm probably lacking consequence in my
development efforts, but for me this is a free-time project after all,
and as such it highly depends on my current mood.
as part of my efforts to prepare for the 2.1.0 release, I today set up a
Wiki again for us! Visit
to start Wiki editing right now!
...wait, you can't edit anything? Indeed, you need to log in. I have
coupled the Wiki to our web forum, so you have to use the same
credentials you use to log into our web forum at:
If currently you are only subscribed to this mailing list by e-mail, you
need to create an account on the forum to edit the Wiki (because the
mailing list subscription isn't really an account). The web forum will
automatically match your mailing list subscription to your web forum
account if you use the same e-mail address.
The wiki software in use is Moinmoin. It's easy to maintain, and it's
Python software just like Mailman 3. This way the two applications can
be deployed the same way.
Getting the single-sign-on done was a bit hairy, but I got it to work
finally. Sydney, if you find some time sometime, I can give you an
explanation of what I did.
we had a problem with our mail server. Incoming e-mail connections timed
out due to a bad firewall policy blocking port 25 during the last 4 or 5
days. xet7 resolved the problem today. Outgoing e-mail was not affected,
i.e. you did not miss any messages that were posted to the list.
If your e-mail to tsc-devel(a)lists.secretchronicles.org failed to deliver
with a timeout error, please send it again now. It should now work.
We apologise for the inconvenience.
I was taking a look at ticket #560 and the related ticket #489. While
thinking about it, I came to ask myself why TSC even has this image
cache functionality. After all the years I work with the TSC codebase, I
still honestly don't know why it exists. So, does anybody have an idea?
If not, is anybody inherently against removing the image cache?
My only guess for the image cache is that we have some high-resolution
images in our pixmaps directory. These images maybe once caused problems
when loaded as a texture directly. Given the code's age I doubt that
this causes any problems anymore, and the image cache generation is an
annoyance every user of TSC has experienced. Removing it would not only
make TSC's startup faster, but also fix all problems with the cache
going out of sync (and making #560 obsolete -- the ticket describes a
problem in messing with raw pixels in Downscale_Image(), which looks
like a rather complex problem).
To give you some data: our largest pixmaps are some level background
images with a width of 4096 pixels,
e.g. game/background/beach_island.png and
game/background/puffy_clouds.png. 4096 pixels sounds like a reasonable
size to expect from graphics hardware today;
sf::Texture::getMaximumSize() returns a value over 8000 for my aged