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.

Yeah, I just thought that might be an issue because of missing image files. I suspect the appropriate image file segments could be warped to handle sloped pieces for breaks and block breaks, but that won't work for curves. We could also use original image overlays if we wanted to. Added physics functions would be needed. This isn't a big deal. As of save format, I'd have to check if there are still unused designation codes for track pieces types. Still it clearly is more work than it sounds. As of the issue of block breaks always slowing the train to a near stop, we could in theory treat them as regular breaks for this function (having a speed) and set a default identical to what the original RCT series uses if the value it puts there is found. I'd have to inspect the save file format to see if the appropriate field is free for that tile, but I suspect it is. This would cause minor problems porting the file back to the original RCT series and RCT Classic, but nothing a little informative note won't address, as if standard programming technique is used, the field is simply ignored and treated as default.

On roller coasters, the maximum speed traveling in a station (excluding station starts) is a puny 18MPH. With the original this wasn't much of a problem, but 31 car long trains in OpenRTC2 make this incredibly sluggish. Concererns for safety aside, it would be nice to be able to increase this to something a little faster. It should not accelerate faster unless you have boosters (for obvious reasons) but instead should slowly speed up until you hit the adjusted limit, or where the friction exceeds the current velocity. Likewise, it shouldn't slow down the car coming in below the set speed, until the car stops. Treating the individual station pieces like adjustable speed breaks could allow users to let cars barrel into the station and smoothly stop on the last 4-8 pieces, greatly reducing time rolling into the station.

On the note of block breaks, and breaks in general, being able to have them on sloped pieces would be really nice, permitting them on any piece with a cheat would also be great.

Already in the game "Make all guests happy" in the cheat menu. You can enable the cheat menu in the options menu. I don't think there is a persistent version of making guests happy, though. There is also a one to give all the guests a big load of cash to spend. It can't buy happiness for them, but maybe for you. 😁

I was wanting to be able to add better custom music to my OpenRTC2 game, but I noticed the crap old RAW format they want it in. Is there a way we could add support for newer formats. Particularly Ogg and WebM-Audio using Vorbis, Opus and FLAC codecs should be supported out of box. Additionally, support should be available for WebM container AAC as well as MPEG container AAC and MP3 if system support libraries are available. In the spirit of Open Source, these patent encumbered formats should rely on external libraries and soft-fail by not supporting such formats if those libraries simply aren't found. We should encourage people to use WebM/Opus as this is the ideal "fully open" format available right now. As a note, if we could make a data repackager for Android that repackages the sound data in Opus (conveniently supported by EVERY Android device currently in the market) we could reduce the game data size to a fraction of what it was, making it ideal for that old tablet you have.

I was about to suggest the same thing. I use this method a lot, especially on spacing rides like antique cars. Getting the cars spaced perfectly can keep the lines running smoothly as there is always at least one car in the station. (Antique cars are a particularly fun gentle ride, and they give a place for a large number of gentle ride fans to stay while their friends ride the big intimidating coasters that "make them sick just looking at it.")

It would be nice to ship with a couple premade sandboxes for it. Do you think we could tap the community for such sandboxes? There are four possible ways to set the goal: No Goal: i.e. Have Fun Minimal Goal: Last at least one year Insane Goal: Reach 999 Approval Long term "Don't Fudge it" goal: Don't let your rating drop below 200 before year 25.

Anyone know how to build tall walls made out of stacked walls? Do you build the top wall and use the control trick to slide it up?

This is an issue with having ALL the land be part of the park. You have to make a small segment outside the park bounderies for the entrance to set in. This can be as small as 3x3 to permit the entrance and a small path going to it from the side.

A modern library included app packaging format is generally better than static linking, because it permits insertion of library patches post-release for compatibility with annoyingly stubborn systems. Your best option is to use the AppPack build for this. This one includes all it's libraries and has nice executable compression. You can also prune the libraries when making this, for further compression. There is a premade AppPack, but there is also a build script for it in the source code. Another option is to use FlatPak, which is similar to AppPack but uses a system container, providing more insulation and security. FlatPak also makes several premade run-times available with fixed library sets including the latest bugfix patches. It's a very good option. However, FlatPak requires a runtime and a special user-level package manager (supported by most major modern distros.) This makes it less portable. There currently isn't a flatpak build script last I checked, but it's easy to add. The FlatPak website has a guide, and I think I might have seen a prebuilt one on Flathub. Simply put advantages quick and dirty: FlatPak: System in place for runtime updates. AppPack: Runs as a standard monolithic Elf binary, fully portable and able to run on any system without substantial library issues. As a note, OpenRTC needs the following for FlatPak permissions: Access to Window Manager functions, Access to OpenGL and X11 functions, Sound system Access. Full network access, Access to user directory in filesystem.