X7123M3-256

The checksums can be corrected by some care is required. If you recalculate the checksum to match the modified file, the ride will become exporting but it will not be treated as the same ride - you end up with two copies, and existing parks will continue to load the broken one. The solution I use is to instead tack on some extra bytes in order to make the original checksum correct again. Then the original file can be replaced by the corrected version and the game will not notice. OpenRCT2 is supposed to do this correction automatically, but it does not always work properly. As a rule of thumb, tracked rides that aren't my own are usually created in Buggy's ridemaker, and hence unexporting. Flat rides do not trigger the bug and so should always work. If you do not get this error message when loading the park, then either all rides exported properly, or the park was not exported at all.

This error message means the save file contains a packed object whose checksum does not match the contents of the file. In theory, this indicates that the object has been corrupted, and the game stops loading of that object. In practice, there is usually nothing wrong with the object, it just has the wrong checksum. This is because some custom objects include nonzero bytes in locations that are zeroed by the loader - these bytes are zeroed when the object is loaded, but the checksum is not updated. When the object is packed into the save file, it has the wrong checksum. When you reopen the park, you see this message. If you already have the object installed then the object is loaded from your ObjData folder anyway, and this is just a warning. If you do not have the object installed the object load will fail and you will be unable to open the park (unless you have "Allow loading with incorrect checksums" enabled, which disables this check entirely). OpenRCT2, unlike vanilla, does recalculate the checksum of objects upon saving - this was supposed to fix the issue but it doesn't work in all cases. As long as you are able to load the park then this message can be ignored for the most part, but if you are sharing the park online you should also upload copies of all the objects that aren't exporting so that those who don't have them can install them. This is especially important if you expect the park to be opened in vanilla, which doesn't allow bypassing the checksum test.

Yes, all the special peep names still work in OpenRCT2.

In RCT3 it was John Wardley. In RCT2 "John Wardley" is a cheat but it doesn't do the same thing - it just changes the guest's thoughts. IIRC there was no way to disable support limits in vanilla RCT2, at least not without hacks.

It's command line option, you type --verbose after the executable name when you invoke the program. It enables more detailed logging and sometimes produces more detailed error messages. Or it may not help at all, but it's usually the first thing I try if something isn't working.

It shouldn't. Have you tried running a server locally and then trying to connect to it?

The game is being developed rapidly, and even the servers running develop aren't all using compatible versions of it. If you can't connect to the master server list, have you tried to connect directly by IP? Can you connect to a server running on your local network? Have you tried running the game with --verbose to see if it tells you why it can't connect?

Even if he doesn't, it probably shouldn't just crash. Would be better to pop up an error message saying "cannot locate RCT2 installation" or something. (I thought it already did this).

Yep, you can rotate the entrance and it still functions correctly (it does look kind of weird - when the peeps come out of the entrance they are not on the station platform, but as you would normally make the entrance invisible and build your own platform this is hardly an issue).

It's not dumb, the stable builds get behind really quickly. The last stable was released a couple of weeks ago, but since then they've added the ability to rotate objects in the tile inspector, the ability to change track types of existing rides, and numerous bugfixes. Things are being added all the time, and if you wait for them to reach stable that means several more months of ad-hoc solutions and workarounds for features not yet implemented. IMO it's worth putting up with a few more bugs, especially as they tend to get fixed quickly anyway.

That's because features are being added so quickly that the stable builds are rapidly outdated.

This is actually already possible, it's just that in the vanilla game it's only used to change water colors. You can create a DAT file with the palette you want, and set that as the water type for the park. This doesn't seem to be that frequently used, possibly because there are limits to how much you can change the palette without making existing objects look awful, but I've seen a couple of parks use this to create a grayscale effect.

Yes, the current banking is absurd - not heartlined, way too abrupt, and there ought to be continuity of the roll rate across track pieces (which in practice means the roll rate should be zero at the boundary). This is something I really wish could be changed as well.

I would just use whatever 3D editor you're most familiar with.

If using a renderer without support for orthographic projection, a workaround is to move the camera very far away and zoom in very far. This will give you a projection that's close to, but not quite, orthographic. I've done all the modelling for my rides in Blender, and I find it does the job well. I don't render my rides in Blender (I use my own renderer), but I've used Blender for rendering other sprites, and as long as you get the projection right and turn off anti-aliasing the results are good. Realistically, pretty much any 3D renderer can be used - you don't need any sophisticated features for this. If you are doing a scenery object and only have a couple views to render, you can always draw them by hand. I don't recommend this approach, but it's an option.

I've never seen another swimming pool ride but that doesn't mean there's definitely not one ... is there something specifically wrong with AE's? The only thing I can think of is that the peep model isn't that great, but then, that's true of pretty much every custom ride. Also be aware that METRTUBE.DAT does not export correctly even in OpenRCT2... I still haven't figured out why.

And then you can do this

If you're placing portals on track, you could make the object a door instead of relying on zero clearance. These can be placed on narrower tracks (such as wild mouse) without the need for cheats, and they are animated, so you could have some sort of effect when the train goes through.

There is a lazy river type ride that has guests sit in rubber rings instead of swimming (METRTUBE.DAT) - maybe that's what he's asking about?

A couple of points about AE's tutorial: Don't render to a GIF and then convert to RCT2's palette. You're palletizing the image twice - the resulting quality loss is evident in several of AEs rides. Render first to true color, and then convert. I wrote my own renderer to handle the process, but that's probably overkill. When you are converting to indexed color, if your object is supposed to be remappable don't include the other color indices in the target palette. Otherwise, you might end up with non-remappable colors in remappable areas. AE suggests touching it up manually. I don't - it will get very tedious if you are doing a ride as they have lots of sprites. Also, the colors that AE marks as remappable aren't actually the remappable ones. I wrote my own renderer to handle all this for me but that's probably overkill depending on how many sprites you need to render (some of my rides have tens of thousands). Don't just guess the camera angle by trial and error. It's a well known projection that was/is common in "isometric" games (it is not however a true isometric projection). There's no need to guess, it, I have the projection matrix and the angles you need to set the camera to if you want them. AE says several things are hardcoded that are not actually hardcoded at all. You can change the spacing of cars, you can increase the number of riders per car, you can add extra sprites, you can change the makeup of the train and really anything else except the track style and sound effects (there's other hardcoded stuff, like splashes, but it's not as frequently encountered). Flat rides are far more limited, because the animation sequence and base size are hardcoded, but still, I would recommend actually checking whether something can be changed if you need to.

I don't have any experience doing custom scenery (yet), but I've done a number of custom rides. I can give all the information I have if you need it. I have information on the format of the .DAT files (though the OpenRCT2 source code is by this point probably the best resource for this), the palette you need to use, the angle that the camera should be set at, the correct scale for the game, and all the angles that you need to render sprites at (for rides mainly ... with scenery there's only 4 angles)

The problem with including female peeps (or any other variations on the peep model), is that presently every ride has it's own peep sprites. If you add female peeps, you double the number of sprites you need for the ride... except you don't, because peeps are currently paired up. You would either have to have a sprite for every possible pairing, or have individual sprites for peeps instead. Either way, you now need four times the peep sprites per ride. Also, the peeps are so small you could barely tell the difference between male and female anyway. I would also like to see swimming pools properly implemented, but I don't think it will happen any time soon. I don't think it's a bad idea, but it would still need the base graphics to be extended with sprites for peeps wearing swim clothes, and some slight alterations to the object format, at the minimum.

I have no experience with trainers as I've only ever used OpenRCT2 for hacks, and so I don't know exactly how the train length cheat that trainers provide is implemented. Trainers can only change memory values, not the code, so it's definitely not done by patching out the check like I did. In vanilla, the maximum train length is recalculated repeatedly whenever the ride window is open, so I doubt that just changing that value alone would work. When I did it in vanilla I would modify the minimum train length in the object file, which was the only way I found to force the maximum to be increased - otherwise, the station length and minimum friction are pretty much hard limits. If you do this with a trainer though, remember to reset the minimum after you've built your ride or the object won't export properly. In vanilla and all current versions of OpenRCT2 (except my patch), there is a hard limit of 16 cars (including zero cars and invisible cars, which don't show in the in-game car count). Attempting to bypass this limit will corrupt memory and most likely crash your game.

The stats are terrible, and the ride is terrible... If you're trying to show stats are not a good judge of quality you need a different example. Generally, I would say bad stats => bad ride, but the converse does not necessarily hold. The stats calculation is pretty crude and mostly tells you whether your ride is safe, not whether it's actually any good.

OpenRCT2 still depends on RCT2 code which is x86. You can compile OpenRCT2 for ARM, and that has been done, but the result is unplayable because all the RCT2 code is missing. Therefore there's no point in anyone providing ARM binaries at this point.