Remove world editor in 2.1.0?
by Marvin Gülker
Hi everyone,
we've seen quite a bit of bugs related to the world editor. Most
recently, we have:
* https://github.com/Secretchronicles/TSC/issues/596
* https://github.com/Secretchronicles/TSC/issues/523
* https://github.com/Secretchronicles/TSC/issues/370
The last one is actually an issue that is occuring again and again. It
appears to be related to the world editor's catastrophic internal
design. The have been numerous other problems with the world editor,
just search our tracker on GitHub. Ticket #523 isn't resolvable at all
without rewriting the world editor.
I want to make a, somewhat controversial, suggestion. The world editor
has always been clumsy to use, especially drawing the path lines is a UI
nightmare. Then, it is rarely used at all -- most editing is done on
levels, and only very rarely new worlds are added. My suggestion in
order to speed up 2.1.0 release process is to remove the world editor
from release 2.1.0. This will collapse all bug reports related to the
world editor.
I agree that this isn't a longterm solution, and for 3.0.0 we want to
have a world editor again. But for the moment, I think this is the most
useful thing to do. It frees resources up for working on the more
heavily used parts of the game that require less work than the pretty
complicated world editor. For 2.1.0, I think we should deliver a stable
and usable game, and getting the world editor into a stable and usable
state is just too much work given its infrequent use. There isn't even
an official "New world" button; you can only enter the world editor by
hitting F9 on an existing world map.
Thoughts?
Marvin
--
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F
5 months, 3 weeks
Build system for TSC3
by Marvin Gülker
Hi everyone,
since I have heard complaints about cmake every now and then, I'd
carefully ask if anyone wants to propose an alternative. Luiji earlier
suggested something custom written in Ruby. Since Ruby does with its
included Rake have a quite powerful task tool that can easily be
extended, that's one possibility I'd be willing to further explore (also
given that we have Ruby as a build dependency anyway due to mruby, which
does use Rake).
Note I'm only asking for suggestions so I can evaluate them. That
doesn't necessaryly mean that I'm going to switch the build system for
TSC3 anytime soon. I'm mostly fine with cmake except for a few quirks
and for me there's only little reason to switch.
Currently, TSC3 uses cmake just like TSC2. Since TSC3 will have a
noticably smaller number of dependencies (I hope), the cmake
configuration will be noticably easier as well.
I'd like to preclude autotools from possible build system
alternatives. I've struggled with it enough when I took over old SMC.
Marvin
--
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F
5 months, 4 weeks
Server problems with systemd
by Marvin Gülker
Hi everyone,
it has long been known that our server has some problems, especially
when starting up not all daemons are properly started. Most notably, the
Cron daemon doesn't start.
It has been discovered that the reason is that our VPS is hosted on an
OpenVZ system with kernel 2.6.32, which is too old for Debian Stretch's
systemd. See https://github.com/systemd/systemd/issues/5236 (beware flamewar)
This is unfortunate and we'll have to think about how we continue. I
have been in contact with our server sponsor (First Root) already, and
they say that a kernel upgrade is outright impossible. Access to a KVM
machine has been denied to us earlier, so that's not an alternative
either. They have suggested we disable systemd and switch to SysV init
for the time being.
While this is certainly an option, it strikes me as problematic. Debian
has ported much to systemd already and is not going to go back. I regard
the alternative distribution Devuan as no professional alternative that
could be used. We have different options now.
1. We could, for now, remove systemd and replace it with SysV init,
hoping that First Root at some point upgrades their OpenVZ
installation. This sounds easiest to me for the moment.
2. We could switch from Debian to a non-systemd distribution (hard to
find a professional one, believe me).
3. We could host our infrastructure elsewhere.
Option 3 means leaving our sponsor or paying for a KVM machine. xet7 has
offered to host our infrastructure on his employer's cloud machine, but
as they're US-based this might be giving us trouble under the GDPR which
I as the project lead do have to take into consideration as I'm a EU
citizen.
Option 3 also is going to cause a lot of work as everything needs to be
ported. I don't think I have enough free time for this available at the
moment.
Any thoughts on different alternatives are highly appreciated. I even
thought I could set aside a Raspberry Pi at my home and have it run
everything, but it turns out that hosting servers at my home violates my
ISP's terms of service, so this option is out as well. Sending email
from customer IPs also doesn't do any good, they're always
hard-blacklisted as spam sources.
Marvin
--
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F
6 months, 1 week
On incorrectly displayed characters
by Marvin Gülker
Hi everyone,
a short notice. I have just fixed the bug described in ticket #528,
which was about incorrectly displayed scandinavian characters.
Problems like this are almost always due to CEGUI not being told that
the text input it receives as parameter to the setText() function is
encoded in UTF-8. Normally, this means that due to a typo the
translation function _() was used, where it should be UTF8_();
cf. lambda's comment in ticket #528. However, when the input comes from
the user (such as filenames), there is nothing to translate. In that
case, it's required to use `reinterpret_cast<>' and force the parameter
to `CEGUI::utf8*' (this is what the UTF8_() macro internally does
anyway).
If similar problems are found again, please do not reopen #528, but make
a new ticket. These are semantically different problems each time, as
the codebase evolves and new strings are added and/or existing ones
modified or deleted.
It's a little silly that CEGUI in 2018 still treats its parameters as
being encoded in ISO-8859-1 if not told otherwise, but that's how it is
and we have to deal with it.
Marvin
--
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F
6 months, 1 week