Ruedii

Yeah, that would be plugins and save files. It would be nice to have a downloader, but that would also mean getting a central repository site. A lot of work for minimal effort with the current state of things, especially since many OpenRCT2 specific ride files will lose backwards compatibility in a rapidly approaching version. (See: New Save Format target) It's definitely something I would put on the idea list, even if it never gets implemented, though.

Then the issue is to simply create a way to make an "overlay" package that can switch out the options of how things operate.

If you are using the Stable release, I would recommend simply using the AppImage options. It is a lot easier not having to worry about dependencies. You don't get the latest features, but it is still recent enough.

There should be more information in the opening menu as of the restrictions and goals of each park. Currently it just displays the description text.

Does anyone know if all the appropriate tiles exist to make this patch to create the additional mode from existing assets? It sounds like a very simple coding plugin to create the additional assets from existing ones. Any roller coaster vehicle that has all the appropriate image tiles could do this, as well as the Ghost Train type vehicle systems. Additionally, the Twist could be rigged to run backwards. I'm not sure about any others, though.

Also, if you are having a staff member stuck with routing errors, you can pick them up and move them.

Try adding some transport rides so they can get from one side of the park to the other easily. They'll even pay for it if you have a pay per ride park!

Do you have an image of the ride and the surrounding landscape? You do know you need a queue line, right?

You need to run it through than wait a few minutes before it will receive it's rating.

I do agree that there needs to be a couple completely blank "Sandbox mode" templates. Basically one template for each ground type, full maximum RCT2 size, flat, with scattered appropriate trees. It should be set to "have fun" and "no money" by default. Just follow the above instructions to make a "sandbox mode" level.

I don't know. You can also put them inside a building. I don't know if that affects rain status. I think it might from scrolling through GitHub issues. Does someone have a more authoritative answer? Thanks.

There is a huge list of places that sell it. I nabbed the Steam version at Humble Store. I wish OpenRCT2 would create a release on Steam, though, for ultra-easy install. Maybe I should petition Valve about it. Similar binary replacement mods already exist on Steam. They tend to just require you own the game in question.

The current problem is that the code provided interfered with the multiplayer code, and needs to be adjusted to address that issue. The feature wasn't rejected, it was put in triage because it is not as simple as it sounds and the volunteer who wrote a patch hasn't written an acceptable patch. If you want to build a version with this feature, and forgo multiplayer, you can. The code IS available on github. As of people wanting to fix this patch. It needs the following: 1. It needs to apply multiplayer code from the brakes to the block brakes in order to fix any syncing issues. 2. Debugging is needed to insure it isn't exposing any previously unknown desync bugs in the braking code. 3. Because the code executes on a block brake (a severely desync prone part), strong desync protection may need to be added. While others may debate this position, my caution against desync bugs over performance states that strong desync protection should be added to all brakes considering it is a key point in a roller coaster that can cause minor desync bugs. They are often put in roller coasters to make sure the roller coasters behave the same between runs. They are literally desync protection for roller coasters. Having your desync protection desync is bad on every level.

Yeah, while it is likely possible on the current save format (the variable slot in question is probably free) it involves adding more code to make it import original RTC2 saves properly. It also would be subject to the same limitations as the current brakes. Moving to the new save format would fix both of these issues, and also require changes in the code for other things. It might be better to wait considering the low priority of the issue.

This helped a lot on my issues with walls and roofs. Still, a nice snap function would be good. I'm thinking of filing a feature request for that.