Logging

The rule on our servers is you sign your own work. This way we can see who’s done what. But it’s not a foolproof system, as players with bad intentions will most likely not sign their destruction, or respond to inquiries of other players. Because of this, admins had to guess who was responsible for such actions, which generally resulted in kicking the player who was the least known. Obviously this is not a fail-safe solution.

To combat this problem our server runs with a custom-written patch. This patch outputs certain game information to a logfile, one file for each game. Firstly it logs information from the server itself. Think of error reports, leaving and joining players, game status and password changes. Secondly it logs all the actions by the players, with their respective price tags and parameters like game tiles. And thirdly all in game chat is also logged. With this information we can accurately determine the culprit, ban him and then reload the game from an autosave to undo any bad changes. This way we are pretty much covered against any sort of in game mishap.

Privacy

Now you could consider me a privacy nut, I’m apparently one of the few who thinks it’s important and shouldn’t be given up so easily as it has been in the previous years. With that in mind I’d like to highlight the privacy side of this situation to calm the uneasy feeling you might get of the idea of being watched in game.

While we are logging everything that goes on in-game, only members, players that have shown to be trustworthy, get access to the log files. And they are not staring at it all the time either, because frankly, there are better things to do then stare at up to 20 Megabytes of text. The way the log is used is that we browse it with a tool whenever we notice bad behaviour on the server. This tool looks at the last X lines in the log, highlighting actions that could be the bad behaviour we are looking for. Think of the levelling of land, actions with huge price-tags and demolitions. This saves us the work of actually having to search for these things ourselves. Basically, we don’t look at the building in progress, we only search for abuse when it’s needed. Last but not least, logs will be deleted after a while. Generally we keep around 5-10 games worth of logs and the rest is discarded.

Statistics

The majority of our playerbase comes with a background in exact sciences, like me. With this in mind, I thought it would be a good idea to generate statistics from our logfiles. Because who doesn’t like statistics? So more then half a year ago I decided to write a program in Java that parses those log files and generates statistics out of them, like the number of lines typed and money spent.

The program is now hosted on our own Dev server. After a long time of neglecting it’s maintenance, a rewrite to compensate in a change of style and the fixing of some bad bugs, the program is finally up-to-date and all logs excluding the current one are processed. The results of this can be found here. And no, this is not useful. But it’s always interesting to have a look.

Future work

Right now I am working on a system that plots the tile information of actions into an image. Combined with some image processing, it should be possible to build a mini-mini-map, not based on how it looks, but based on how much has changed. This is an example of how such a map could look like:

I wonder if anyone can guess the game number from that image. But once again, not useful, but probably interesting to see. Besides that there is some work to be done on the usability of the program itself and adapting it for use on other servers as well. If you have any more ideas, comments or suggestions, feel free to post your them in the comments or let me know on IRC.

I hope we can make out the best games in 2009 soon.

After recent interests in self-regulating construction, there was an attempt to improve the usability of such designs. We have already seen self-regulating networks, where dummy trains transfer cargo onto ML trains, and recently self-regulating orders where vehicles could potentially go to all stations. What has not yet been done is to apply a form of regulation to point-to-point passenger games.

The main idea behind the concept is to have trains arbitrarily choose a station to drop their next load. While one could put each possible pair of stations into an order list, you would have to maintain the 240 possible pairs  for 16 stations, making it a big hassle. However, if you force trains in a certain direction by the network, you can keep everything more manageable. So if you can force a certain selection of trains in one direction, you are set.

The plan for PSG #157

In PSG #157, the idea was put to the test. The plan basically consisted of four flattened rings, where trains would be able to change on the shared parts. At three of the hubs, trains would have a choice of turning right or left. Using logic, trains were forced either left or right in turn. The two smaller hubs used flip-flops to do perfectly cut the train flow in half for each outer part. Due to the size of a flip-flop, the central hub was built using a timer. This timer forced all trains to the left for a few seconds, then right for the next few seconds, which again resulted in the stream being effectively cut in half.

Stations would need a much lower ratio – if they would get a 50/50 share, the chance was very likely that the train would drop the load at the next stop, and the chance of reaching the other end of the network would be minimal. Instead each station was given 1/8th of the traffic, which gave a good distribution without having the trains spending an eternity on the line. Due to traffic being halved, the outer hubs would take 1/4 trains each.

Station hub 2, where you can see the 1/4 selector

To pick one out of four or eight trains accurately, a mechanism was needed. The most used system consisted of a not gate (the MagLev loops at the top) which would allow the train in the counter (erail loops in the bottom) to move ahead one signal for each train. The loop had 4 signals, and thus four segments. By tapping into one of the segments, we could get a signal for every fourth train. The remaining pair of not gates (MagLev loops in the center) were used to always have one red signal and one green signal, so that trains couldn’t have second thoughts and still go the wrong way.

You can have a look at the game in the PublicServer Archive

As a special feature, there were new logic trains available. Going at supersonic speeds, they allowed the user to create extremely fast responding logic systems, and made completing the plan a lot easier. You can find them in OpenTTD’s online content section.

just yesterday I’ve been browsing through the change logs of OpenTTD and stumbled over some remarkable changes Rubidium commited just then. The network code underwent heavy changes – and now a game may have up to 255 clients!

(svn r14730) -Codechange: remove the need for networkclientsockets and networkclientinfo structs to be in a contiguous piece of memory and put them in a pool.
-Note: 255 should really be enough for now… making it any more means network protocol bumps.

and another commit just today:

(svn r14735) -Codechange: remove a bit of bit-waste in the map array (without changing the map array) and make the CompanyIDs contiguous.
-Note: 15 should be enough for now… making it any more means adding more bytes to the map array and thus wasting more bits instead of reducing the bit waste.

which allows now up to 15 companies instead of the usual eight .

With the next available nightly our servers will, of course, feature as many clients – and we’ll no longer have the problem that the server might be too full when starting a new game

A big thanks from #openttdcoop to all devs of OpenTTD for the great work.

A little History

These days we are working on Public Server Game #100. This is a real jubilee. The idea of a Public Server was realized back in December 2005. After one year of #openttdcoop having only one Server we introduced the Public Server because there were too many players and new players. We also thought that the building guidelines we used to stick to at the Main Server are very uncomfortable for new players.
In the beginning we created a Tutor Company in each game. This company had a different color and we created signs at all problematic areas in the game. The company observed the progress and guarantied a good quality of the game. Nowadays we don’t use this anymore, because the invested amount of time is immense and a lot of experienced players join our Public Server.
All this happened even before the release of OpenTTD 0.4.5 (more than 2.5 years ago). If you have a look at the archives you’ll recognize that we played our first game with r3320. Most of the time we used nightly builds of OpenTTD, because in our opinion they are more ‘stable’ than the stables as issues get fixed faster and we have a close relationship to the OpenTTD devs. The revision counter is now > 13000 and this means we followed and observed a process of more than 10k revisions of OpenTTD.
In the beginning there were quite a lot issues with networking and desyncs but OpenTTD has become a supreme game and the number of issues is decreasing.
Unluckily no one of the old nicks from the first games is here anymore (except Mucht and me).

I just calculated: ~30 months Public Server and 100 games makes an average of 3,3 games per month = ~9 days / game.
Well Done Coopers.

I hope you liked my little story and I hope I can write another one when we hit #200 =)

Dev-Server
Michi_cc released Version 4.1 of YAPP, an urgent reason to update We are using r12168M now.
Enjoy playing.

Changes:

• Trains will no longer crash on their own, barring any programming bugs. Instead, a train can now get stuck if it just can’t reserve a path. You may need to manually resolve the problem then. Note: Pressing force proceed or removing signals can still lead to crashes just as it can in plain OpenTTD.
• Lost trains do not pose a problem anymore.
• Improved depot finding for servicing.
• Stations and waypoints are now only considered safe waiting positions if they are at the end-of-line as well. A train will reserve a path through a through station according to the next orders to a safe signal, depot or line end.
• Mixing normal and PBS signals will not lead to crashes anymore, but might generate stuck trains.
• Path highlighting is now an official patch settings under ‘Interface’.
• The build signal tool will now not cycle through two-sided PBS signals anymore, as I still wasn’t able to find a use for them.
• Level crossings are now barred uppon path reservation.
• Implemented newgrf variable 0×44 for rail stations.
• Tweak various pathfinder penalties.
• V4.1 with fixed autosignal tool.

More details and the patch file can be found at the related forum posting

• CPU: Core 2 Duo 6600 (2.4 GHz)
• Memory: 2048MB DDR2 1033MHz
• HDD: 2x Seagate 250GB SATA2 in RAID1

You can reach the server via ps.openttdcoop.org and the default port (3979).

Of course the games might not be playable for people with older hardware, this includes also me, but of course the most of us can play until 700-1000 trains.I think it is still good and another server with a different concept will be launched soon.
The current game is a 1024×1024 map, which reminds me of Pile Transport. We didn’t load a trainset as we might focus on monorail.

Enjoy Playing!

The Network Plan by Floffe

Hilly 3on3 joiner of BBH01 by Planetmaker

This game was also nice because of the small planned network. I really like to adapt a network to the trains. Starting with a small network and extending it to its needs is much more fun than building a big network which is almost empty. We did pretty well in this game. In the end it is not jamming, but if you change something badly it will jam within seconds. To ensure a less jammed network while building or messing it is absolutely necessary to build bypasses and re-route trains. Sometimes this didn’t work and the ignore-signal-button turned into evilness.

Train Crash at BBH 01

Anyway I am still messing around with the ‘worst case’ problematic’, which is worth an own posting. The worst case occurs when a train enters a track, but at the point of joining the signal turns red and the train blocks a complete track. My SML Shiftback was removed because it ‘failed miserably’. Well, I’d say it didn’t fail, but worst cases make a builders life hard and SML Shiftback is important for a homogeneous network flow. Some more information about the Shiftback problematic will follow soon.

Last but not least a link to the Map Overview, you should look at it. Some artists worked there.
My major critic is that I discovered too many bad placed signals. Please have a loot at the article about signalling.

A nice game and I hope we will play more of this kind soon.

• Wiki-Report
• Download Final Savegame

• Cities didn’t accept food
• Factories didn’t accept Steel, Plastic & Paper
• You couldn’t build industries -> desync

Those problems where fixed. The only town which accepts food is Lenthwaite (there is also the Food Drop). I don’t want to go in details too much. Enjoy the game again.

Enjoy the game.

Btw. if you want to request a restart write an e-mail to openttdcoop [at] ppcis.org. This makes life much easier for the administrators.