Due to the increasing size of some projects we changed some settings in the compile farm itself, in Jenkins so that build results will not be kept any longer on that build server. As previously all build results will always be published to our file server at http://bundles.openttdcoop.org. The results of the latest build can always be found at http://bundles.openttdcoop.org/PROJECTNAME/push/LATEST (where PROJECTNAME is the name as it appears here on the DevZone, which is also part of the repository URLs)
As one of the sysadmins of #openttdcoop alot of work happens for me on the background. Most changes go unnoticed, some cause minor breakdowns (sorry ;)) but alot of changes you don’t see. The changes that mostly did go unnoticed were changes to our mail infrastructure, database updates, backup procedures. And that’s just a few.
Today one of the changes that you will see is a change to our paste service. The paste service as it currently is has changed. We have switched to a new backend which was needed. The old pastes are NOT deleted. They can still be reached at http://old-paste.openttdcoop.org. However do keep in mind that this will go offline at some point and we strongly advice against creating new pastes there.
Our new backend is currently live at https://paste.openttdcoop.org. In this case we are using sticky-notes as a backend. This gives you more privacy and options compared to the old paste. We do hope the new features help everyone out even us as admins in maintaining it all.
Another change that already is active (and you might not always notice) is a replacement we did for our bundles server. This had to happen at some point. And today it is done. This change won’t have much of an impact. But we hope to improve response times with this new server.
These are just a few of the changes you’re going to see. More will follow at some point but this is just a start
Should you have any questions join in on IRC (#openttdcoop @ OFTC or through http://irc.openttdcoop.org)No comments
Ladies and madmen, I am happy to announce that the project I have been working on for the last few months, has grown to it’s first release! First of all I would like to give a huge thanks to frosch who helped me greatly to get the production mechanism working, but also Alberth for trying to help me as much as possible. I would also like to thank all the people like planetmaker for answering my endless and often stupid questions about NML in general. I greatly appreciate everyone who have supported me with any feedback!1 Comment
Today Alberth and myself changed the required python version of NML nightly versions and a future NML 0.4.0 to python 3.2 or newer as python2 is slowly phasing out, and also the imaging module is better supported with python3. For some time there will continue be updates to the 0.3 branch as well with an occasional maintenance release, though.
If you're on windows, this is of little consequence to you, we continue to provide an exe file which can be used out-of-box, now based on python 3.3.
If you're on OSX or linux and use nmlc from a repository checkout, you'll want to use the package manager of choice and install python3 and python3-ply and python3-pillow (or called python3-imaging or similar).
If you encounter any problems, please let us know
Also package maintainers may consider to already look into updating their dependency lists accordingly
Alberth & planetmaker
This is a maintenance release for the 0.3 branch of NML.
It brings a few user-visible changes by introducing new variables:
vehicle variable vehicle_is_unloading and object variable nearby_tile_object_view, introduces new string commands CARGO_LONG, CARGO_SHORT and CARGO_TINY and the house callback result CB_RESULT_HOUSE_NO_MORE_PRODUCTION.
Notably for packagers or users of old(er) systems: NML requires python 2.6 or 2.7 henceforth, the support for python 2.5 is dropped. This version also fixes a problem with the reported version in the source tar ball as found in the previous release. Additionally a python-2.7 egg can be downloaded from the bundle site.
Compared to OpenGFX 0.5.0 it fixes a number of issues with packaging.
The source is available as xz-compressed tar archive. You can (again) opt to not install license.txt, readme.txt and changelog.txt via the variables DO_NOT_INSTALL_LICENSE, DO_NOT_INSTALL_README and DO_NOT_INSTALL_CHANGELOG.
Additionally the borked check for the build from tar archives with the checksums (by grfid -m) of the grf files was fixed again.
It's recommended to use NML 0.3.1 in order to build OpenGFX 0.5.1 or the md5sum of the grf files might differ.
Just like about 3 years ago when I announced first concepts of NUTS, this time I am glad to announce that I started to sketch schemes and industries for YETI.
This article is for one like my notepad so I remember the core idea, and to let you know and/or give feedback what you think about the concepts.
To demonstrate my ideas I have created some scheme images below.
It is happening again, 1st April is here!
Just like last year and the year before that, we can celebrate the existence of NUTS with a new version again.
In the past year NUTS made a lot of progress even though it seemed quite “complete” even last year. Most notably were added some trains (who knew) which improves the choice a player can make – and also the awesome factor of the set. Namely, PURR tracks got eaten by NUTS as they are now integrated in one newGRF – which happened because MEOW trains are completely dependent on them. Also WetRail vehicles (the wet tracks which were the main surprise in last year birthday) got completely redone and have now 10 vehicles! Plus many other details, but RAINBOW SLUGS are a thing to never forget!
At the same time, NUTS got so huge that became very confusing to new(er) players. Especially lately, I have been trying to make this barrier easier to breach – first of all by adding the wiki which is trying to explain how each vehicle works. Not just that though, another one of steps in that direction making vehicles expire – so only the useful ones remain. And with this version I made all vehicles 1 tile long so you can autoreplace any to any without losing wagons or getting into problems. My intention also was to introduce an Ultimate wagon which could attach to any train and adapt sprites/parameters accordingly, but the obstacles in coding such a thing were way too large. So, I at least added a parameter to NUTS (gets its first parameter after 2 years =D) which makes only universal wagons purchaseable for more simplicity. For full choice you can simply switch it back at any point.
It might be noteworthy that NUTS reached above 100 000 total downloads not long ago, currently counting 100992 times for versions 0-67.
Enjoy! (:3 Comments
Time for something or rather someone new: welcome aboard to our newest team member, Taede!
We know him as friendly and helpful occasional player on our servers. And recently he started to work also vigilantly on the other side of the servers which players usually don’t see (or which they only see the server’s nick name on the IRC channels of). Thus he proved himself already very helpful in maintaining our servers and started giving them a decent cleansing with a good amount of soap so that they become easier to maintain, more flexible and future proof
So tremble in fear before the new all-mighty one
Welcome, Taede!1 Comment
The http interface to the repositories is performing currently very badly and either is very slow or not available at all. In order to push to or pull from the repositories currently an ssh access is required. Please see http://dev.openttdcoop.org/projects/home/wiki/Setting_up_SSH_%28Windows%29 on how to obtain a pair of keys. Provide us (either by opening an issue here in the Help Centre, via message at tt-forums.net, e-mail or on IRC) with the public key of yours and change your path in your project's .hg/hgrc to ssh://firstname.lastname@example.org/PROJECTNAME Contact us if you have any questions or issues. See also https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Mercurial and replace step5 by giving the public key of yours to us. Never share the private key with anyone!
We are working on setting up a new http interface and access which should perform much better than the current one.
Sorry for the inconvenience. But I'm confident that the changes we're going to make will be profitable