Transport Tycoon Forums

Many years ago I proposed a new disasters framework (http://www.tt-forums.net/viewtopic.php?f=33&t=32514). I finally got around to writing it, and attached to this post is a patch that changes a number of things with disasters:

1. Instead of a single disaster timer (_disaster_delay), each non-vehicle disaster has its own timer. When the timer reaches zero, there is a chance that disaster can be triggered. On the rare setting, this is 1 in 8; for normal it is 1 in 4; for frequent it is 1 in 2. Furthermore, specific disasters can be disabled.

1a. A side effect of having concurrent timers is that multiple disasters can occur in a short amount of time.
1b. I changed the start and stop years for the disasters. There is no reason why coal mines stop collapsing in 1985.

2. There is a console command, "disaster", which can be used to introspect the new disaster system. Disasters can be invoked manually from the console; see the usage text for "disaster".

3. This applies bumps the saved game version to 154. For save files prior to 154, the old _disaster_delay value is used to initialize all disaster timers.

The first screenshot shows the console in use. In this situation, both a coal mine and small UFO occurred. [attachment=2]Multiple Disasters.png[/attachment]

The second screenshot shows how one can adjust disaster settings. UFOs, for example, are disabled in this screenshot. [attachment=0]Disaster Timer Settings.png[/attachment]

This patch applies cleanly to SVN r21329, and has been tested on OS X 10.4 and 10.6. I do not play multiplayer, so I do not know if it works for that environment. Prior to applying the patch, please adjust my FIX ME in saveload.cpp to point to the correct SVN revision. If this patch is accepted, I would like to create new disasters: wildfire, oil spill, etc.

It looks very, very interesting. I hope that it is desync-free.

IMO activating disasters manually (even if done via the console) should be marked as a cheat (as already done for things like getting more money or changing companies). You might also consider adding the manual activation of these disasters to the cheat GUI.

You should also consider implementing the patch as a patch queue, which makes the code easier to review and test.

Terkhen wrote:IMO activating disasters manually (even if done via the console) should be marked as a cheat (as already done for things like getting more money or changing companies). You might also consider adding the manual activation of these disasters to the cheat GUI.

I think it is test-command like stop_ai (not marked as cheat).

Terkhen wrote:IMO activating disasters manually (even if done via the console) should be marked as a cheat (as already done for things like getting more money or changing companies). You might also consider adding the manual activation of these disasters to the cheat GUI.

You should also consider implementing the patch as a patch queue, which makes the code easier to review and test.

I personaly disagree. I like to play with the more realistic disasters that don't nesecarily affect the company as often on in TTDPatch and leave the UFO's off.

robotboy wrote:I personaly disagree. I like to play with the more realistic disasters that don't nesecarily affect the company as often on in TTDPatch and leave the UFO's off.

I'm only talking about the activation of disasters manually, not about the timer settings.

Terkhen wrote:I'm only talking about the activation of disasters manually, not about the timer settings.

And cheats have positive effects (well, it is possible to drain cash), not negative (like disasters).

Kogut wrote:And cheats have positive effects (well, it is possible to drain cash), not negative (like disasters).

That only means that they can easily be used to mess with the competition.

I did a quick check of the patch, and attached you will find my comments.

I quoted some part of the patch, and added my comment below it, prefixed with ">>".
For ease of reading I also added lines of "----------------" to seperate parts.

I like the idea, but the patch needs some more work.
Please also add a revision number somewhere, eg in the file name, making it easier to keep different versions apart from each other.

You may also want to create a FlySpray issue for it (bugs.openttd.org) if you think it is ready for trunk, patches less likely get lost there.

>> Why not make 4 strings 'none', ... , 'frequent', and one string for each disaster?
>> Having zillion of the same strings just creates more maintenance work.

How can I reuse the strings in settings_gui.cpp? When using SGF_MULTISTRING, the displayed string is referenced offset to the base string. I suppose I could play tricks by manipulating the minimum value, but that would obfuscate the code worse. Ideally I would declare a new SettingGuiFlagLong (maybe SGF_FREQUENCY?), but the comment on line 41 of settings_internal.h suggests that there is no space available.

Once this issue is resolved, I will have a new version available, broken into several smaller patches.

Sorry for the confusion, I was wrong here, the strings seem quite hard-coded together.
Please ignore my remark, and just keep the strings as you have them.

We'd like to change this connection, it should be a different patch than disasters.
(your patch makes the problem a bit more urgent )

Albert

Thanks, Albert. I posted my patches to FlySpray.

to http://bugs.openttd.org/task/4286

coal mine - 1970 - 2020
factory - 1970 - 2020
refinery - 1960 - 2010
zeppeliner - 1890 - 1955
small ufo - 1940 - 1970
big ufo - 2000 - 2100
small sub - 1920 - 1960
big sub - 1970 - 2100

I can imagine that zeppeliner is disabled after 1955, but:
- ufos , coal mine etc can stay forever
- I would like to play with zeppeliner after 1955.

And one more thing - how coal mine/factory/refinery disaster works with, say ECS? Or FIRS?

Industries define which disasters can happen to them (basically grfs provide IndustrySpec::behaviour): Then they work as usual.