Retaining old IRC logs...
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
Regarding the discussion about purging old IRC logs, I do not think we should just delete all logs older than 6 months.
If we want to move them off the server, that is fine, but I think they should be kept somewhere. Major meeting and some important discussions are in the logs.
Having a search function, however, would make the old logs much more useful.
--
Sent by Chessboard.
3 years, 8 months
Project management software / server OS
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi everyone,
xet7 yesterday decided that we are going to install Sandstorm as the OS
on alexandria. I read the corresponding email today, and I want to put
this before the entire team to decide on.
Here is the IRC log from yesterday, 2016-01-16:
- ----------------------------------------
16:23 -->lambda-11235 entered #secretchronicles.
16:23 xet7 | Quintus_q head8debian: I now have access to new donated VPS. For comparison: Alexandria 2 GB RAM, 240 GB disk space where 64 GB used - mostly backups that are 44.6 GB, kernel 2.6.32. New VPS, running at DigitalOcean Frankfurt datacenter: 1 GB RAM, 30 GB disk space where 2.2 GB used. Running Ubuntu 14.04 64bit, with kernel 3.13.0-71. TSC website would need to thank DigitalOcean for providing hosting. I will use https://sandstorm.i
16:23 xet7 | o platform on the server. Server is donated by Sandstorm, that had DigitalOcean free credits. They will check progress after one year. I have been translating Sandstorm projects to Finnish, and will continue that.
16:25 xet7 | Anyway, alexandria server will remain as is now, until I have tested and configured all on new server.
16:25 xet7 | New kernel also makes possible to use OpenVPN on server, if needed.
16:27 xet7 | Sandstorm has lot of security features that require newer kernel.
17:21 <--DarkAceZ left the IRC network (Read error: Connection reset by peer)
17:21 -->DarkAceZ entered #secretchronicles.
17:49 --datahead8888 is now known as datahead7777
18:57 ZenWalker | datahead7777: thanks
19:01 head8debian | xet7: Why didn't you jsut ask Firstroot for another server? They would have been glad to give us one.
19:03 <--Tobbi left the IRC network (Remote host closed the connection)
19:03 -->Tobbi entered #secretchronicles.
19:04 xet7 | head8debian: Really? I can ask sure.
19:06 xet7 | head8debian: I could really use more RAM and disk space, it that is possible. I'll send Firstroot a ticket.
19:12 datahead7777 | lambda-11235, I merged your PR earlier today
19:22 lambda-11235 | datahead7777: I saw that.
19:51 head8debian | xet7: I'd talke to QUintus first. ;)
19:51 head8debian | talk*
19:52 datahead7777 | head8debian, are there advantages if we can get a second server with First Root rather than having two different providers?
19:53 xet7 | I already sent Firstroot a ticket .. did I act too fast?
19:53 head8debian | datahead7777: Not really, except that First root knows us quite well, and has been very generous and willing in the past.
19:53 head8debian | I guess we just sit back and see...
19:53 head8debian | I was hoping to hear Quintus's opinion, since he has worked with them quite a bit.
19:57 xet7 | head8debian: I tried to be polite etc in my ticket to Firstroot. And previously at this channel Quintus said "<Quintus_q> head8debian: It would be nice if you took the time and work together with xet7 for upgrading alexandria and setting up our own project infrastructure"
19:59 xet7 | Plan was first to upgrade alexandria current server, but using Sandstorm for infra would be much easier and secure for upgrades etc, and Sandstorm requires newer kernel.
20:00 xet7 | I will send Quintus email about current status.
20:03 datahead7777 | I was thinking in the back of my mind if there was any chance they think we're asking too much of them to try to get another server, though it really depends on our relationship with them
20:04 datahead7777 | I guess it depends on how we approach it, too
20:04 head8debian | datahead7777: Yes it does.
20:05 datahead7777 | head8debian, well, having one provider simplifies are administration
20:05 datahead7777 | We'd have one company to contact for any needs
20:05 head8debian | datahead7777: From what i can tell from QUintus's convos is that they are quite impressed with what we have done so far, and are quite happy to keep helping us, but i could be wrong.
20:05 head8debian | Anyways, im afk...
20:05 datahead7777 | Having a release makes a differences
20:05 datahead7777 | We'll need to get another release semi-soon to show more progress
20:10 xet7 | I sent email to Quintus.
20:32 datahead7777 | Okay, let us know if there's anything we should be aware of. The mailing list is probably a good place to announce anything.
20:32 datahead7777 | Or discuss anything
20:33 datahead7777 | Thanks, xet7
20:36 xet7 | datahead7777: Yes I will let you know. Currently I'm testing various infra software etc, so no actual changes to any current system yet.
- ----------------------------------------
I have neither heard of nor have I tried Sandstorm previously. This
doesn’t have to say anything, though. However, a quick view on the
website of this software makes me sceptic about how it fits our current
workflow. It is more like a complete collaboration platform that
replaces everything we currently have. This is a fairly major switch
that I want to see appreciated by more people on the team. As for my
part, I think it is a known fact that I am a commandline hacker who has
not a lot of use for fancy UIs. I mostly communicate by means of email,
and I recently complained to GitHub their email notifications on PRs do
not contain a link to the full URL needed for $ git pull so that I am
forced to visit the website. My ideal project issue tracker is fully
email-transparent and mostly acts like a mailinglist; it doesn’t have to
be entirely like this, but to some degree I need my email interface. I
recognise I am of a somewhat singular opinion in this regard, but I hope
not completely alone.
To be clear, I don’t want an email-only thing only either. I do know it
is difficult for some people to use, although I can only point out how
much more productive one is this way. If there’s a web interface, that
is okay, just don’t force me to use it in a project I work on
voluntaryly. TSC does not have a large amount of contributors anyway,
and thus it is important that first and foremost any software we use
fits our workflow and only on a secondary level is easy to use for
non-core TSC contributors. As it stands, I fear we’re about to change
our current workflow from a rather classic, commandlineish, emailish OSS
one to a modern hyped one. If it wasn’t clear from the above, I am a
fairly conservative nature.
I realise I am not in the position to dictate the team what it has to
use as software, but neither is xet7. I will call for a vote on this if
you really want to impose this newly-fangled stuff on me.
It would be unfair of me if I forced xet7 to make a server only fitting
my very own views after I told him to think about stuff himself. I would
thus of course take over server maintenance myself again, so he is not
covered with work arising only from my queer views of how to administer
a project and a server. For the work he already put in the server OS and
software reserach, I do say thank you. It was me whose wording in IRC
was unclear; I expected to get a little more feedback before someone of
us runs out and asks other companies for support. For this I apologise.
Any input from anybody is appreciated.
Valete,
Quintus
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWm5prAAoJEPHYeZ+8yLxP1hoH/ijChoyJc6V0cKP3WdH7vaBf
8LvaeeG3RPxQUhIVMjzT6wD8QlzBORs8BJsMTvRdsQFTevLZhYOHm2JC5SWtqZrA
j10a/alUI8NNJxmku8sR7YEBPglTFC4h1Sjfei0U5WkeMjLioC6u62njrsTKsaGo
VrbbRUq6DgOAzhEfD2hV8B22xELWkdL8aAY/aBfsqEt4Vappzi89Rrjr9tlOIEhh
1fpCTnC6D6lbesCSaw9MUxKgRBXNXeb1xIsUZIVtXuKTfIVIusf+HOH2XWkwvGfP
FpfIFhy4gnbDACu5tSRw/XZQCcp43lEkFbG2zrOfUj92MCAeVXAbp8Fq4+7Bgdo=
=6/ZS
-----END PGP SIGNATURE-----
3 years, 10 months
State of the SFML port
by Quintus
Hi everyone,
today I completed my work on the sfml-port-input branch. For the first
time in our SFML porting efforts I was able to actually compile, run,
and play the game. I successfully finished lvl_1.
The sfml-port-input branch has now been merged into feature-sfml-port2,
which thereby now contains a roughly playable version of TSC mostly
ported to SFML. The port still has its issues, but I think the largest
part now has been moved over. The biggest thing remaining is the porting
of the audio system from SDL_mixer to SFML’s audio module, but thanks to
kirbyfan there is a PR available for that already[1] which will
drastically simplyfy things. If I have a correct view on the topic, it
is possible for us to wipe the SDL1 dependency from the codebase after
merging kirbyfan’s audio PR.
The SFML port in feature-sfml-port2 is, as outlined, roughly
playable. It has some issues we now need to tackle:
1. Mouse button input doesn’t work. You have to navigate the game with
the keyboard, including menus.
2. Graphical glitch with blue arrows in the HUD and everywhere points
should occur. This is probably due to an unported call to
glPixelStorei() in video.cpp[2] that I don’t know how to
handle. datahead, Luiji, would be nice if one of you OpenGL people can
take a look at that and estimate what that line intended to do (and even
better, fix the problem).
There are probably numerous further issues that I haven’t spot by simply
running through lvl_1. Please compile and test feature-sfml-port2 now,
and even more important, please contribute to it. The lengthy part of
the SFML porting should be over now, so let’s finish this.
Before starting the game, move away or delete your
~/.config/tsc/config.xml file. SFML doesn’t understand the SDL
key codes (obviously) and you would be unable to input anything with
your keyboard. Deleting that file causes the game to recreate it with
the default values (jump = s, fire/iceballs = space, etc.).
If you run ArchLinux or another rolling release distribution, beware
issue #500[3]. There is an incompatibility between our old CEGUI version
and the newest version of freetype2. This doesn’t specifically affect
the feature-sfml-port2 branch, but also devel and all versions of TSC
and probably even SMC alike. The issue tracker contains a workaround for
the problem.
Let’s work on completing the move to SFML. Happy coding!
Valete,
Quintus
[1]: https://github.com/Secretchronicles/TSC/pull/488
[2]: https://github.com/Secretchronicles/TSC/blob/f1a7838e6265ac2fb154ec24cfea...
[3]: https://github.com/Secretchronicles/TSC/issues/500
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
3 years, 10 months
Do we use sprite sheets at all?
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
Do we use sprite sheets at all? This basically means we would place an entire set of sprites into one image and have that loaded from the file system all at once. It would then use the coordinates on the image texture in order to properly render the sprites at runtime. This tends to help with performance.
The discussion recently came up for Super Tux - https://github.com/SuperTux/supertux/issues/183
I was just curious if we were using sprite sheets ourselves. I've not seen any reference to them, though I may not have dug deep enough to verify this yet.
--
Sent by Chessboard.
3 years, 11 months
TSC now has a bank account.
by Quintus
Hi everyone,
today I visited as promised my local bank and opened a new bank account
that can now be used for any monetary aspects of the TSC project. The
bank account is part of the SEPA system and has the following
identification:
BIC: GENODEM1DOR
IBAN: DE13 4416 0014 6437 8328 02
The running costs for the account are 2€ per month.
The bank account is registered on me currently. I was told that it is
generally possible to have the bank account require confirmation of more
people for any transfers, and that this also is possible from people
around the world. However, it is required by law that these people once
show up in the bank and sign the treaty right there.
Therefore, the account for now is on my name alone. I think that once we
get to the point where we go for a nonprofit organisation, we could also
combine this with adjusting the bank account properly. For the moment I
think this is sufficient.
I will (most likely annually) report any movements on the account. Of
course, you may query me at any time for a quick status report.
There is no money on the account yet. I will transfer some 50€ or so to
it during the next days, but feel free to transfer some money there for
supporting the project as well.
Valete,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
3 years, 11 months
[ANN] Luiji steps down as project assistant lead
by Quintus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi everyone,
on 2016-01-05 Luiji notified me that the timeframe he has available is
too limited for him to further support the TSC project as assistant
lead. He is happy to remain with the project to some extend, but judges
it unreasonable to have a higher position than others who invest more
time than him. That is, Luiji will continue to be a part of the TSC team
with repository access and voting rights, and we will occasionally see
contributions from him, even if they’re just of a communicative nature.
I think I can speak in the name of the entire TSC team to express our
greatest gratitude to Luiji, who played a central part during the early
days of the project and made a fork look reasonable and
possible. Without him, his administrative and programming efforts TSC
would not be where it is today: A stable version 2.0.0 released and on
the road to further improvements. We hope that you enjoy your further
pathes and wish you all the best.
With Luiji’s retirement the position of the project assistant lead
becomes vacant. I invite everyone from the team to think about taking
over this position; it’s duties aren’t of a too grave nature. The
project assistant lead:
* Guides votings if the project lead (me currently) is unavailable
(§5(3) VotR), which means posting the vote announcements and counting
the votes and
* Can be asked to check and thus invalidate votings which violate the
formal voting process (§§14 ff. VotR).
Apart from these formal duties, he:
* Acts in place of the project lead if that one is unavailable for
whatever reason,
* Should watch the tracker more closely than others and ensure important
tickets don’t fall asleep,
* Should have an open ear for complaints by team members and non-team members
about social issues in the team and the TSC community, and if
required, try to resolve them, and
* Will occasionally be emailed by the project lead about issues
affecting the project as a whole.
To summarise, he should simply have a closer look at what is going on in
the project. It does not mean you have to hang around in IRC all day
long or post to the tracker permanently. But if you find that a PR has
not been answered for two weeks by anybody, you should do that.
It is worth to point out that it’s okay for the project assistant lead
to not contribute much code or assets to the game. It’s more of an
administrative position that is meant to ensure that the project stays
in a healthy overall state. Since all his work is usually done together
with the project lead that is usually not too much. If you once every
one or two weeks take a look and answer the important stuff, you’re
usually doing fine.
Before I make any suggestions about who I think would fit into the
position I’d like to encourage you to think about taking it yourself. As
always, I would like to reach a consent between all team members about
that.
Quintus
TSC project lead.
- --
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWkOV5AAoJEPHYeZ+8yLxPASMH/itbsiAF/ktOHsPpzlMlkL2F
VaUziDoPc2ANDAAxS6uADc5oucjm3ycDwm4Rhxu2KHYwAnJs9IweMmZZB0d/9oam
EmjkGDfjIVfd53qqgoN0r4qguj1swz412qnN9Pc29IRZTBS7PNMp2ELfqEEc4zwH
QW4AY5rFZwML6hBk4wtuSFqNGVhqIs8jtPW5YW8pgKXeHuYFCRHl9Lfls2CaVMIX
fDwbFwar8MCFJy1RInEO9mF6f96rB5UnagLxZFd+7yE8JV5mHHUlyYck5TRY0HSR
3oY3pc2t7J1GWN+u1y326cRIhmom/qwppXTVB3yvVqf/BRb/QfEYpFk135I12zA=
=7Yhd
-----END PGP SIGNATURE-----
3 years, 12 months
SFML Port... What is it?
by Bugsbane
Post via forum by Bugsbane <piers@xxxxxxxxxx>:
Hey all,
I feel like I'm far behind everyone else in understanding this as I'm only going off issue titles in Github here, but what actually *is* SFML and the SFML port? Why are we doing it and what benefit does it bring?
I don't ask any of these questions to challenge it. I honestly have no idea what it is, I've seen many mentions of it, and I'm just curious.
Cheers
--
Sent by Chessboard.
4 years
SFML Tasks?
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
@Quintus, you had said there was a long menu implementation task remaining for the SFML port. Which task is it, and which SFML tutorials are critical for it?
--
Sent by Chessboard.
4 years
