X7123M3-256

I noticed some things crash OpenRCT2 that don't crash vanilla. For example, if you create a custom ride with no default color schemes set, OpenRCT2 will crash with a floating point exception when you try to use it, but it used to work fine (I don't know if this is just coincidence, but it was a source of much confusion for me when it first started happening).

The reason for the change was that dropdown menus can't currently support more than 64 entries, but people wanted the limit set as high as possible. I considered having a spinner with the cheat enabled and a dropdown if not, but I'd rather keep it consistent (and simpler). I agree with @Gymnasiast here - a tooltip is the easiest solution.

The weight placed on each factor is different for each ride type - wild mouse coasters get less of a penalty for lateral Gs, and some coasters get no benefit from inversions, for example - but the actual calculation doesn't differ, and most rides have the excitement and intensity severely reduced if a certain minimum drop size is not met (though the exact minimum depends on the ride).

As @jensj12 pointed out, the intensity rating is halved because of the lack of a drop, and that brings the intensity into the safe range. The rating calculation would have to be changed to correct this.

Purchasing unpurchasable land is possible - enable sandbox mode, then go to the minimap. There you will find a tool that allows you to set land as purchasable, or to directly set it as owned. This also allows you to own the tiles on the map edge, which is not normally possible.

My objective was to find out if the SV6 format would support such a hack, but @Spacek links to a park which has it, thus making my test pretty much irrelevant - if there's a park out there that does it, then it's definitely possible. It's just a matter of implementing the feature. If/when this is implemented I would change the name of the cheat from "Disable support limits" to "Disable height limits", as that would make clear it's not just supports anymore. As for why my script didn't work, I'm not sure, but I did only touch the surface tiles, so if there's anything else that needed to be updated at the same time that's probably the source of the problem.

There is no way to remove the height limit for the ground in game at the moment. None of the existing console commands are for disabling limits - all that stuff is in the cheat window/menu. Console commands are mostly used for changing values like park rating or money. I decided to do some tests using an external script to move the land tiles up - but not only can I not break the limit, I can't even reach the existing limit - if I set the tile heights in the map data to 62 (the normal limit), it gets loaded as 54. Not sure what's going on there, so I'll have to have a closer look. This test is inconclusive. It may or may not be possible to remove the limit in a backward-compatible way, but I am not sure that it's baked into the save format - map elements in general can have clearance heights up to 255, so I'm not sure why surface tile behave differently. I might consult the source and see if I can find anywhere else where tile heights are stored.

The crooked house is a flat ride, but it still has an associated track type (type 71) . All the draw functions do nothing, so setting a ride's track type to crooked house makes it invisible. This is one command, so it's much quicker than doing it through the tile inspector. However, there aren't draw functions for every track element. If your ride includes an unsupported element, the game will crash. Therefore, I would recommend always saving immediately before applying this hack. The boat ride should be fine though, as I don't think the boat ride allows any pieces that crooked house doesn't.

The other use of patrol areas is keeping handymen out of queue lines. Queue lines never get littered, but handymen will spend most of their time winding their way up and down them if you let them. Also, you could probably hide a boat ride with the crooked house method instead. It's much faster since you don't have to click each tile individually, but if the ride contains unsupported elements your game will segfault (that should not be the case for a boat ride though). It's also much easier to switch back if you need to make the ride visible again to work on it.

You can already do that - just make the station invisible with corrupt elements and then zero-clearance new track over the top (in the other direction, so it doesn't merge). In order to get the station platform to line up with the paths, it may be necessary to lower the ride 1 unit, which can't currently be done in OpenRCT2. I just put up with the clipping issues for now. It's not great, but it still looks better than the default platforms. You can make wide platforms this way as well as long as you have quarter-tile base blocks available (you'll also need quarter tile railing pieces for the gates).

Depends on the ride. You won't usually have kicker wheels on a mid-course brake run but you do often see them in the final brake run and in the station. Rides with magnetic brakes often have the brake run on a slight slope, with a clamp at the end to stop the train. When the train needs to move off again the clamp is simply released - the train will proceed forward under gravity. Some coasters that use linear motors for launching also use them for braking (such as most Maurer Sohne and Premier launched coasters). In this case the brake run is capable of launching the train, because it is also the launch run. I was thinking the problem is not that the train shouldn't be sped up at all, but that it shouldn't take place instantaneously like it does right now - it's not that noticeable when the train is only accelerating to 4mph, but for higher speeds it would look bad.

To connect the gates properly, you'd need quarter tile paths, as 1 tile is far too far apart for the gates. Also, the gates ought to line up with the cars, but the cars can have arbitrary spacing, which is problematic since map objects can't be aligned more precisely than the nearest quarter tile in RCT2. As much as I'd like to see something like this, I don't think it's easily implemented right now.

Clidking on the path again will connect the exit but it disconnects the entrance Zero clearanced paths are a pain to work with - just moving the cursor over a path can disconnect it.

You were correct - the exit was disconnected but peeps will always leave the exit whether connected or not, so it appeared to function fine until the mechanic tried to enter through the exit. The worst thing is, I can't seem to fix it without disconnecting the entrance - zero clearance and paths do not mix well.

I'm not sure the AI actually needs a new file format to be improved - it's even worse than vanilla at the moment.

The real difficulty with something like this is that it means runs are no longer reproducable, so you can no longer extrapolate behaviour from a single test. At the moment there are only subtle variations in train speed from peep loading, so each run is more or less the same. I'm also not sure how easily implemented this is - every track piece has a brake speed anyway, so it shouldn't need modification of the save format, but at the moment the train stops and starts instantaneously in block brakes - if you allowed increasing the block brake speed, that would be a problem, because you don't want block brakes to be able to accelerate the train significantly like they did in RCT3, you want to let the train through at the specified speed only if the block is clear and otherwise stop it completely. I don't think we need an E-stop button because the game does that automatically whenever any kind of breakdown occurs. Maybe it could also be available as a cheat, but I think there's already a cheat to force a safety cut out, which does the same thing really.

The point of testing is to ensure the ride works; people complain about the difference the weight of the peeps makes, so I think that testing should stop the train in each block. Actually, I think the game should run two tests, both with and without the blocks engaged, because it is necessary also to ensure that the ride is safe at the higher speed. The game's ratings are only affected by the stats, most of which record the maximum value of each quantity, and the train should be moving slowly at the point where the blocks are located anyway, so the difference should be subtle.

I like the idea but it should not apply in testing mode - it is important to ensure the ride can complete the circuit if it is stopped in the block.

Yes, I should probably check that the exit is connected properly

I watched a mechanic walk up to the exit of the ride, turn around, walk up to the entrance, turn around, then leave and walk halfway across the park, still trying to find the ride. I'd have thought it something to do with zero clearanced paths (they have caused me endless trouble as they refuse to connect properly) - but peeps have no problem finding that ride. I still don't know what the problem is. Also, the logic for setting staff patrol areas seems broken in the latest develop build - the squares appear partially gray and partially blue (and tiles assigned to other staff members do not show up at all, instead of showing up in gray like they normally do). I might make an issue about that.

Not necessarily - it switches to the first track piece on the tile. If you build the track with the blocks first (as I usually do), then you have to switch the tracks around in the tile inspector so it switches onto the alternate track instead. If you build the merged track first then that should not be necessary - I like to build the blocks first so I can ensure the block system is working before switching the trains onto the alternate track. I know this definitely works, because I've used it for all three coasters in my current park.

Block brakes on merged rides are actually already possible - the trick is to make sure that all the blocks are on the same circuit - which needs to be a complete circuit - but the train doesn't actually have to stay on that track between the blocks. You can merge it onto another track, and then merge it back before the block section. The parts of the other track that the train does not run on can either be built underground or made invisible with corrupt elements.

I'm not really looking for video of the ride running, more the SV6 file you used. It's hard to be sure exactly what the problem is if I can't reproduce it. But I have already observed that strange things happen when you mix long trains with block brakes - this sort of thing should almost be expected at the moment. I'd recommend saving your game before using cheats marked "unstable" for this reason.

When a ride is running in block sectioned mode, the trains will spawn at each block section. If the block brakes are more closely spaced than the trains are long, then they overlap like this. Sometimes they will move apart if you let the ride run, and sometimes you have a train spanning two blocks, which prevents the ride from ever moving. I'm not sure if that's what's happening here, but without seeing the ride run it's hard to tell.

I've had this glitch happen on multiple occasions. It appears that you have built the track leading away from the switch in the wrong direction - you need the little yellow arrow to point in the direction you want the trains to face, not the direction the trains should move. If you do not want the tracks to merge; as is the case if you're adding a second track for aesthetics, switching the order of the track elements in the tile inspector usually prevents this bug from occuring. Also, your switch track needs to be long enough to accomodate the full length of the train, otherwise you will split it in two. This is probably not what you want.