Welcome to #openttdcoop
[More]
Public Server is upUsing: r20690
Players: 0 / Spectators: 0
Pro Zone is upUsing: r20594
Players: 0 / Spectators: 0
Dev Server is upUsing: 1.0.4-RC1
Players: 1 / Spectators: 1
#coopetition (h2h) is offline Stable competition Server is upUsing: 1.0.4-RC1
Players: 1 / Spectators: 1
Next check: 07:46 mins.
Mon, 16 Aug 2010 at 17:16:46 CET
I think I dont understand what is the issue anymore 
Feel free to contact me on the IRC 
… blog isnt the best place for discussions
Mon, 16 Aug 2010 at 12:46:35 CET
Screen-shot showing train orders and track:
http://wiki.openttdcoop.org/images/3/31/Screenshot_waypoint_vs_1tile_station.png
- The rail in Trendham woods is broken up to force all trains through that station (because it produces the least amount of wood and you need trains <85% load to visit the same station again in order for this experiment to work).
- Added a way-point next to the "check if full" 1 tile station.
- The 3 trains visiting the way-point don't load a 2nd time at Trendham woods if they are <85% the first time.
- The 1 train visiting the 1 tile station loads every time.
- Orders are identical except for order #1's destination.
Check it for yourself it are only small adjustments.
Mon, 16 Aug 2010 at 09:43:40 CET
Although the savegame is broken (or at least I cant load it), I would assume that you forgot to put there an order with “go via” – instead, you left there “go non-stop via” … differences between waypoints and stations are none in this matter as far as I know.
The backwards PBS is a penalty indeed. It forces trains into the station if it is empty.
The 2way signal is to make trains never join the station that is already occupied. – That works based on “twoway EOL” (in .cfg as yapf.rail_firstred_twoway_eol) – if the first signal on a choice is 2way, and is red, the train will try to choose any other path. That is one of the most important things in SRNW because that way you can spread the trains just as you want, otherwise they would most likely go only to one station 
(Removed double link to same page :))
(Category)
(Redirect!)
(Redirected page to [[Communication]])
(new newgrf)
(/* Major gametypes at #openttdcoop */ )
NFORenum - NFORenum 4.0.0
Today we release a new stable of NFORenum with many improvements over the previous version. At the same time the maintainership of NFORenum has been taken over by some developers here.
As the NewGRF specification gets extended we will update NFORenum, so if you're using the latest bits of the specification you'll probably be better of with a nightly. However, the stable releases should be perfectly fine if you want to develop something that is supported by the stable versions of OpenTTD or TTDPatch.
If you used the release candidate not much has changed, besides some packaging improvements that should make it easier for our downstream packagers.
GRFCodec - GRFCodec 1.0.0
Today we release a new stable of GRFCodec with many improvements over the previous version. At the same time the maintainership of GRFCodec has been taken over by some developers here.
If you used the release candidate not much has changed, besides some packaging improvements that should make it easier for our downstream packagers.
OpenMSX - OpenMSX 0.3.1 released
This release addresses a few issues which were found with certain songs in the 0.3.0 release and could lead under certain conditions even to a crash of the sound driver and OpenTTD. Seven songs have been addressed in that respect, and 'Keep on Rolling' replaced for similar reason by Jim Redfarn's 'Big Man Boogie'. Especially windows users who have problems with their sound playback or experienced sound-related crashes previously are encouraged to update as these changes work around the touchy sound drivers. Find the new version at the usual places, bananas and http://bundles.openttdcoop.org/openmsx/releases/0.3.1/ For a full changelog see http://bundles.openttdcoop.org/openmsx/releases/0.3.1/changelog.txt
NFORenum - NFORenum 4.0.0-RC1
Due to time constraints and loss of interest DaleStan could not work on GRFCodec and NFORenum anymore. This resulted in the slow decay of both GRFCodec and NFORenum.
This caused problems for people compiling it with recent compilers (it failed to compile), for the developement of the NewGRF specifications (new features wouldn't be supported) or for the people, such as the nice folks at OpenTTDcoop's developer zone, for using it to develop NewGRFs; many warnings about valid NFO, but just because NFORenum hasn't been updated.
With the release of NFORenum 4.0.0-RC1 we revive NFORenum in the hope to keep it useful and usable for as long as it's neeeded. In any case some things regarding the development have changed. The source repository and issue tracker can be found on http://dev.openttdcoop.org/projects/nforenum and as such bug reports and feature requests for NFORenum should go to there. Furthermore we will try to release at least two stable version of NFORenum per year, or more often if required.
Finally we would like to ask all NewGRF developers and downstream packagers to test this release candidate so we can release a proper 4.0.0 in a couple of weeks. Especially knowing about parts of the specification that NFORenum does not understand or understands incorrectly are important to us.
In any case, we would like to thank DaleStan for initially developing and maintaining NFORenum.
GRFCodec - GRFCodec 1.0.0-RC1
Due to time constraints and loss of interest patchman and DaleStan could not work on GRFCodec and NFORenum anymore. This resulted in the slow decay of both GRFCodec and NFORenum.
This caused problems for people compiling it with recent compilers (it failed to compile), for the developement of the NewGRF specifications (new features wouldn't be supported) or for the people, such as the nice folks at OpenTTDcoop's developer zone, for using it to develop NewGRFs.
With the release of GRFCodec 1.0.0-RC1 we revive GRFCodec in the hope to keep it useful and usable for as long as it's neeeded. In any case some things regarding the development have changed. The source repository and issue tracker can be found on http://dev.openttdcoop.org/projects/grfcodec and as such bug reports and feature requests for GRFCodec should go to there. Furthermore we will try to release at least one stable version of GRFCodec per year, or more often if required.
Finally we would like to ask all NewGRF developers and downstream packagers to test this release candidate so we can release a proper 1.0.0 in a couple of weeks.
In any case, we would like to thank patchman and DaleStan for initially developing and maintaining GRFCodec.
NewGRFs - TTDPatch and Action 14
TTDPatch now supports skipping of Action 14 (since r2334; http://svn.ttdpatch.net/trac/changeset/2334).
It is not necessary to skip an Action 14 with an Action 9 for TTDPatch, as it either (<r2334) will refuse to load a grf with Action 14 in it or (>=r2334) simply will ignore the Action 14.
ProZone Game 13: Timed (aka insane) SML
As some of you might have already noticed, another PZ game has been finished. This time we focused on trying out the timed SML(below as t-SML) concept, and with it we experienced numerous interesting things. In this article I will attempt to show how was the t-SML developed from it’s very beginnings, how it works and what were the problems, solutions to them, and last but not least – examining a game with
200 169 goods production per month! Read further at your own risk!
Building 101: double bridges and you
Introduction
From the very start that you start building networks in OpenTTD you’ll need to have different tracks crossing each other. When you just start out this will be done by just simple level crossings which aren’t very efficient (except when using YAPP/PBS), later on you will start using bridges and tunnels to do this so different tracks don’t influence each other. Because bridges and tunnels don’t allow signals on/in them you will soon notice that you get slowdowns at them, the common solution is to use two bridges or tunnels for the same line and have their combined capacity compensate for the lack of signals. Unfortunately there are proper ways to do this and wrong ways to do it. Underneath I will discuss these and explain what you should and shouldn’t do.
OSQC the follow up ? at last
It has been way to long, but here it is the second OpenTTDCoop Scenario Quest Competition. In the scenario file you’ll find the goals for this map. Deadline to submit the game is August 31st 23:59 CEST. Submitting can be done by raising an issue at the OTTD Dev Zone under category OSQC. Judgement will be done by members of OTTD.
#openttdcoop NewGRF package - Release: #openttdcoop NewGRF package 8.0-beta1
We converted the VCS system to Mercurial and moved to the DevZone and now, the NewGRF compiler does also care about this package.
With the release of 8.0-beta1, we removed EVERY BaNaNaS NewGRF from the pack and moved a lot to the obsolete folder, as this is still a beta, we won't remove version 7.3, anyway, this package should be FULLY compatible with EVERY archive game and EVERY server we run.
Some testing would be very welcome:
- move your current newgrfs to a temporary unreachable location (don't forget about bananas (content_download/data)
- load our beta (http://bundles.openttdcoop.org/grfpack/releases)
- try to load a random game from our archives
- try to join our servers
- report issues here or at our forums thread
Server status powered by OpenTTDLib
RSS fetching by Magpie RSS
Thu, 26 Aug 2010 at 21:10:13 CET
Added GRF info to post…