Ladies and gentlemen, friends,
it has been a while since I wrote anything in here, and what better time could there be than on April fool’s? As many of you might remember, it’s not just the 1st April, it is NUTS birthday. It has been five years since I released NUTS 0.0.1 and many things have progressed since. One of them are my other NewGRFs that took place after NUTS. The latest one – BRIX – will now share birthday with NUTS as I am releasing BRIX 0.0.1 right now. I will also talk about some more things later in the article…No comments
-Add: New industry type limits of OpenTTD 1.6
-Fix: [CF] Build the version which is asked to be built instead of tip
-Fix: Mark the cython acceleration module as optional.
-Fix #7641: Sort gender and case translation tables deterministically (matthijs)
-Fix #7640: Use dashes, not hyphens in manpage (matthijs)
-Fix #7336: Action 6 offset was off by one for VA2 ranges when using a list of expressions in a switch.
-Fix #7185: Incorrect Action6 offsets for Production Action2.
-Doc: Be more verbose about MANIFEST.in and remove bootstrap from manifest as well
This version adds access to the additional rocky tiles as of OpenTTD r27220 and adds a new 'getbits' function.
But it mainly fixes the packaging issues as experienced with NML 0.4.0:
OpenGFX 0.5.2 (12 Apr 2015):
- Add: [Makefile] target 'bananas' (closes #6877, #6848) - Fix: [Makefile] Add dependency generation for pnml->nml - Fix: [Makefile] dependencies, esp. wrt. HG revision numbers getting compiled into files - Fix: Alignment of GUI icons that have different sizes in 1x and 2x zoom - Fix: 2x GUI sprite for purchase land was attached to the viewport sprite instead of to the GUI sprite (commit:ba02a90fab52) (issue FS#6267) - Fix: Do not crop the default-window-size icon (issue FS#6258)
OpenGFX 0.5.2-RC1 (16 Feb 2015):
- Add: 2x GUI zoom sprites - Add: the all black ground sprites introduced in OpenTTD r26869 - Add: Translations for Africans, Italian, Latin and Lithuanian - Update: Translation for English (US) - Change: [Makefile] Make sure that mercurial output is not changed by user presets - Codechange: [Makefile] Simplify a few pointless programme definitions - Fix: [Makefile] No need to query the whereabouts of required programmes when we make no use of that anyway (issue #5759)
Last month we put a news item out about our retention policy. We have decided to start actively enforcing this policy from the 1st of March.
This is needed to maintain proper stability of our services. Each night a 03:00 UTC our server will cleanup any files that are outside of the retention policy.
To be sure we don't lose builds that are needed we have a copy of the current data available. Should you feel like a build (for this first month) has been removed in an incorrect way we can verify our logs and fix any issues that should arise. We have run our cleanup script on a dry run for some period to prevent such errors. Should they occur contact us through IRC.
This version brings some major changes compared to the 0.3.x versions:
There's numerous other fixes, changes and additions. For a full changelog, see http://bundles.openttdcoop.org/nml/releases/0.4.0/changelog.txt
Get the latest release version from the bundles server: http://bundles.openttdcoop.org/nml/releases/LATEST/
Note to package maintainers:
As you may have noticed our services have received some outtage. This happend during a maintenance that was required for needed security updates related to CVE-2015-0235 (the glibc story / http://www.openwall.com/lists/oss-security/2015/01/27/9). When we rebooted the server the most scary thing happend for us. Our server did not return online. After some help from our hosting provider we managed to log back in.
To make the most out of this situation we immediatly also starting converting some of our local containers to a diskimage format (PLOOP / https://openvz.org/Ploop/Why). However because one of our main containers which has all the HG repositories has so many small files this conversion is taking longer then expected.
We want to apoligize for this situation and are waiting for this container conversion to finish. After this the most critical containers should all have been converted and most of the other ones are related to non-development stuff that should have no extended downtime like this.
Ladies and nutmen,
just now I am realizing I forgot to officially mention that I have been working on another project for the past months. RAWR Absolute World Replacement is currently 32bpp/ExtraZoom LANDSCAPE with ROADS and TRACKS. Eventually I am hoping to replace all the sprites the game needs, and the final output then could be a full base set.
Visually, the set is obviously 32bpp/ExtraZoom which looks relatively nice. Functionally, it lets you choose from the 4 climates and force any of them visually. That way you can apply any of them you want – especially if you load the newGRF as a static one. I hope you like it, there is still a lot of things to be done, but the core is there.
The project home is at the devzone per usual – you can also find a guide on how to apply static NewGRFs. I also have a thread at tt-forums, you are welcome to contribute/place your impressions/screenshots there
You can download RAWR from the online content – BaNaNaS – through the game, or from the website manually.
Enjoy and let me know what you think!
In recent months the retention policy for builds created by the DevZone's compile farm was rather liberal and all build for every push were kept. However, with the increasing size of NewGRFs (we needed to upgrade the allocated space for builds several times already) we need to go back to the original retention policy:
Nightlies are not built specifically anymore. But once a day, the build from the most recent push will be promoted to a nightly build.
See also our wiki page at UsingTheCF which documents the data retention policy. If you need one of the old nightly builds or push-builds, then please grab it now. The new build management script will be switched on in the coming days.
Hell000 and Merry Christmas! We are happy to announce that our inner circles have gained yet another person, Hazzard!
Being around for a long while, most of you probably know him, but if you don’t, Hazzard is a great builder and person. His logic mechanisms and other construction put your brains in greater hazard when you see them. He has been generally very helpful, teaching people, being a nice person, and everything else.
Everybody, please welcome Hazzard to the openttdcoop members club!1 Comment