#openttdcoop

Wouldn’t that be a cool thing to try?

dihedral and me talked about that and we came to the idea to make a “World Wide OpenTTD Game Day”. So, we are searching for a day where most people are online and we all should try to play together.

Read the rest of this entry »

Our lovely member Progman did it! A config tool for a easy way to set our start options, no thinking about diff_options anymore.

Because the NewGRFs will also be managed over this tool, we need a new system for saving our GRFs, they need to have the right orders. Trainsets have to be after narrow gauge track i.e. etc.

Read the rest of this entry »

We just had an interesting game on the Public Server (Game 59 when it closes down and is archived), where we tried to play a whole map without any terraforming, and IMO it was a blast. It was hard, tricky and challenging, but it was a blast. The most common problems was ‘relearning’ how to build stations and hubs without using any kind of terraforming to make room for it. Luckily we were realistic about our first try and got it on a very flat map so it wasn’t that big issue as it could have been. But nevertheless it forced us to think an extra time about where to place it and how to use the enviroment around the area to be used for making it even easier because you wanted to make the network just slightly more efficient.

The only turnoff for people was that they had some problems with that it wasn’t as easy as it used to be, failing to like a good challance from time to time. This aren’t a kind of game to be played several times in a row, but one here and then forces you to think outsite the box about how to build diffent things, but it have to be on a relatively flat map if possible to make it that tiny bit easier with fewer lakes than the game we had. they are a pain to bypass unless you ‘cheat’ with canals at waterline paired with liberal use of dynamite, though it could debated weather it is some kind of terraforming or not.

With revision r10437 peter1138 added a new feature to the trunk of OpenTTD: Automatic signal completion. What does that mean in detail? I did a few tests and created a wiki page to show you how the newest feature of OpenTTD works and how you can use it. One thing is for sure, it makes the life of OpenTTD-Players (and Co-Ops) a lot of easier. I needed one second to signal this weird construction in the screenshot. Imagine massive Mainlines you can signal them in seconds now. Just wonderful.

Signalling & Automatic Signalling
Enjoy this great new feature of OpenTTD

stillunknown created an awesome patch which reduces the CPU usage quite a bit. The idea is to reduce the train collision checks with a sort of cache instead of a an on-going loop (details @ tt-forums).
Tonight we did some tests how this patch affects the game and it is quite impressing. I don’t want to say this is was a real performance test, but we checked the CPU load with a patched and an unpatched version of OpenTTD (r10048). My local machine was used as the server (PPC G5 2GHz) and as references we used Public Server Game #09 and Game #34.

The Results (vary with network layout, amount of trains and so on):
cpu usage in percent
Game#34: w/o patch: ~45%; patched: ~40% (~700 trains)
Game#09: w/o patch: ~67%; patched: ~50% (~1300 trains)

Especially games with a big mainline loop profit from this great patch.