Switch directory name change impacts level scripts...
by datahead
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
The full path for switches is TSC/tsc/data/pixmaps/ground/underground/switch
Apparently, at some point the directory name was changed from pow to switch.
Levels that used the old directory name in their scripts need to change.
I know it broke my Desert Break In level; it probably broke quintus_3.tsclvl as well.
For now I'm posting this so we have a record of it. If desired, I can open a ticket so that we are less likely to forget.
[code]
datahead@datahead-G750JW:~/TSC-Release/TSC/tsc/data/levels$ grep -i pow * | grep -i image | grep -vi property
desert_break_in.tsclvl: UIDS[4291].image = "ground/underground/pow/blue_active.png"
desert_break_in.tsclvl: UIDS[4291].image = "ground/underground/pow/blue_active.png"
quintus_3.tsclvl: switch.image = "ground/underground/pow/blue_active.png"
[/code]
--
Sent by Chessboard.
4 years
Transfer of secretchronicles.de domain to xet7
by Marvin Gülker
Hi everyone,
xet7 expressed in IRC that he would like to have full control over the
secretchronicles.de domain so that moving and maintaining the
infrastructure is easier for him. Likewise, he would later take control
of secretchronicles.org if we ever register it.
I am the current owner of secretchronicles.de, which as of now is
registered with <http://www.df.eu> and has a yearly cost of 9.48 € (with
taxes). Technically, I would terminate the contract with Domainfactory,
request the transfer auth code from them and send this one to xet7
so he can register the domain with his favourite provider. There is no
possibility that some third party registers the domain in this time due
to this process.
The secretchronicles.de domain is part of the project's core
infrastructure, so I did not want to make the decision alone. Especially
I would like to have datahead's agreement to this, but every team
member's concerns are considered if you voice them.
Vale
Marvin a.k.a Quintus
--
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
4 years, 1 month
Changing the Git branching model
by Marvin Gülker
Hi everyone,
from the outside TSC looks pretty slowly developed, and from the inside
I also have this impression more often than not. Taking a look at the
git log of “devel”, there for two months have not been many commits, and
no commits by anybody else than me. Actually there have been more
commits and by someone else than me (datahead), but they sit around in
their separate feature branch forever and with the low amount of time we
can dedicate to the development it is uncertain when this will
happen. Taking a project’s main development branch as its development
activity measure is common and serves TSC ill.
This is not a singular case; the SFML and CEGUI changes were in their
feature branches for months, before a big blob merge happened at some
point in time (or not, see the proposed but never finished filesystem
compression changes).
As of now, we are using the GitFlow model[1] to manage our branches, and
I think that it has failed its purpose for our slow environment. I know
there are people who dispute the usefulness of the GitFlow model
altogether, but I wouldn't want to go as far as that. It surely has its
uses, but I think those uses are more appearent in an environment were
many coders simultaneously work on a quickly evolving codebase. As of
now, this is not the case for the Secretchronicles project. As a result,
its formal nature with all its separate feature, hotfix, development,
and master branches, which is intended to organise large development
structures, hinders a small project like ours more than it serves it.
I would thus like to suggest to change away from it and instead do
things differently. The entire GitFlow model is rather formal and
difficult to learn, which is not really useful in our context. Instead,
I suggest a simple set of rules:
a) All normal development should happen in the main branch.
b) If you develop something large that frequently breaks compilation,
develop in a separate feature branch that is available from the
repository.
c) Locally, you can use any amount of branches you find useful.
d) If you are not a TSC team member and thus have no commit access,
your changes should be in a separate branch for your Pull Request.
The “master” branch we have now only contains tagged releases. Nonsense,
we have tags for that, thus this purpose is completely eliminated. In
return to classical Git terminology “master” should be the main
development branch, and “devel” shall vanish. Current unmerged feature
branches are merged into “devel” before merging “devel” into “master”.
This suggestion is part of my desire to get others more involved. An
overly formal development model is not good for that.
Please give opinions if you either have coded on TSC or want to code on
TSC in the future as it will affect you then.
Valete,
Quintus
[1]: http://nvie.com/posts/a-successful-git-branching-model/
--
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
4 years, 1 month
Forum down?
by Ryan Gonzalez
I'm getting a "503 Service Temporarily Unavailable". I had a new version of
the tutorial theme that I was going to upload. :(
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
4 years, 1 month
