X7123M3-256

There is at least one command not listed in the in-game help - but Github has the source code from which the game is built, so if a command isn't present there then it either doesn't exist or hasn't been merged into develop yet.

I'm not sure it is the same. Sprites are things like peeps, litter, and coaster cars. The limit is around 10000, but I don't think you usually get an error for it - it just stops spawning new ones. It looks like you recieved that error message when you selected that object, which means it isn't the object limit and probably isn't the sprite limit either. Given that the error originates from gfx_object_allocate_images, it looks there's a limit on how many images you can have loaded at once. I don't think this will stop you from building on the map (until you hit the object limit), but it would stop you from loading new objects unless you unload an existing one.

Are you sure you can't place anything, or is it just that you can't load new objects? It shouldn't crash either way - if you hit the object limit you get a message box when you try to place things.

I think I prefer the AE swimming pool ride to a hacked waterslide, because the peeps are animated and their movement is randomized. AE's peep sprites don't look as good as the game's, but since there isn't a body slide in the vanilla game, you need to use a custom one anyway. Also, SLDTUBE1 and SLDBODY are missing from that list.

I don't think there is one. "date" certainly isn't a variable accepted by the "set" command.

The pathfinding AI does not take into account transport rides - guests will not ride transport rides in order to get to a destination. The peeps do not know that the ride will take them off the island, so they just keep trying to find a path out. To fix this would need an overhaul of the peep AI, which is really needed IMO - RCT2's AI was too simplistic but in OpenRCT2 it's even worse.

This is incorrect - steep slopes were made available on the Junior coaster two months ago. The junior coaster track shares sprites with the water coaster so these pieces could be added relatively easily. However, for whatever reason, they forgot to include the diagonals. The required sprites for diagonal tracks are in the game, so I think this should be considered a bug. I will submit a pull request to fix it. EDIT: The PR has now been merged. Updating to the latest version should fix this problem.

No changes are required to OpenRCT2 to do this. Vehicles have always been stored in .DAT files; all that's required to make RCT1 rides work is for someone to transfer the RCT1 sprites to the RCT2 file format. I already did that for the RCT1 mini suspended coaster, and I know it's also been done for the RCT1 spinning coaster and possibly some other rides as well. However, RCT1 uses 16 frame rotations and RCT2 uses 32 frame rotations. The solution I used was to simply double up the sprites, but be aware that the animation won't be as smooth as normal RCT2 rides. Also, the sprites are not in the same order within the file - I had to reorder them manually, though I'm sure if you were looking to port every ride you might be able to find some sort of pattern to it. For the Junior coaster specifically, I would prefer to use a custom ride with the required sprites because RCT1 sprites look awful and out of place when used in RCT2, but I don't know if a custom junior coaster exists. Maybe I should make one (though my rides look pretty awful as well so that's probably not an improvement).

It overrides the limitation on how much money you have, and is therefore a cheat. That limitation is essential to gameplay - the ability to override it completely obviates the point of tracking money. I am saying that the ability to change car types is never something that should have been restricted - and indeed it isn't for some rides already. Many rides do allow alternate car types that could be switched in game, such as the Arrow suspended or the B&M hyper coaster (which, for some reason, allows cars to be interchanged with the Giovanola hypercoaster - pretty sure those cars shouldn't be able to be switched), but for some reason not every ride that could have been handled this way is. The need for the cheat would be eliminated if the default groups actually reflected which rides can run on which track. For example, the vertical drop coaster should be (and is) seperate from the rest of the B&M rides because DM track is wider, yet B&M sitdown, standup, and floorless trains ought to be interchangeable, but they aren't. The groups are also hardcoded and you can only have one per track type, which often forces you to seperate rides that really belong together. Fixing this would require a new object format however. You cannot research track pieces, only objects. Like I said before, I think that if a track piece genuinely shouldn't be available on a given ride then using this feature shouldn't unlock it, and if it does then I'd agree that should be fixed, but many track pieces are missing for no good reason, like the missing steep to flat piece on the Arrow looper that is allowed on the Arrow hyper (which shares a track style). They've already added steep slopes to the junior coaster, and I've been experimenting with allowing corkscrews on the dive machine. If the game is allowing you to select vehicle types you haven't researched yet, that's a bug in the implementation of the feature that needs to be fixed, and not a reason to make the feature itself a cheat. I think that this feature, properly implemented, need not confer an advantage to players who use it, and if it does, then that should be fixed rather than relegating a potentially useful feature to a cheat. I do not know if the issues you've brought up were an oversight or an inherent limitation of the current codebase, since I didn't implement this feature. But with the eventual switch to a new file format, any such remaining limitations could be removed anyway. It's long past that point now. It's now an improved version of RCT2, so if something will improve the game, I don't see why it needs to be made a cheat just because it's different. It could be made an option, so people can choose whether or not to enable it. And this feature, in particular, is already an option - if you'd rather not use it you can turn it off. I don't have it enabled because it makes it hard to tell what objects are available from the ride selection menu.

Disable locked scenarios is an option, not a cheat, and I think it should remain so. The original game does not have a means to lock scenarios and I prefer it that way - I don't see why you should be required to tackle the scenarios in order, though a lot of people did want this feature. Sorting by difficulty shouldn't disable the setting if you have it enabled though, that could be a bug. Allow testing of unfinished tracks should probably have gone in the cheat menu rather than the options IMO, since at present the vehicles crash if you do this. No test crashes fixes that problem but should probably remain a console command for now because of the awkward way it is implemented (double closing and retesting the ride as soon as it crashes), but if that were replaced with something a bit cleaner I think the feature could be enabled by default. RCT3 had this feature and it is useful - it saves time having to build a temporary connection to the station so you can check what you've built so far. Cheats and debugging tools are already in their own tab and you can hide both in the options if you want to The debugging tools are cheats, and I don't know how useful they really are for debugging. I think the menu would be better named "hacks", but I don't think it should be merged with the cheat menu as the debug tools let you edit the map data in ways that can crash the game or cause problems if not used carefully, whereas cheats generally have fewer side effects and do something more specific. I think this distinction is significant.

I don't think this should be a cheat. I think the best solution is to prevent changing car types to one that doesn't have allow the track pieces currently used, and to prevent building track pieces that the currently selected train type does not allow or doesn't have sprites for (since many trains just allow everything). Then have a cheat to bypass that and let you build everything. Which is stupid, changing cars IRL does not involve demolishing and rebuilding the track. I don't think everything that changes gameplay should be considered a cheat - only things that can cause glitches or override limitations that are supposed to be there.

Update to the latest version before reporting bugs, especially when your current version is now a month old. OpenRCT2 recieves updates constantly - if you haven't updated in more than a few days then you probably don't have the latest version, and the bug may since have been fixed. This is a known bug but it was fixed 18 days ago and should not be present in the latest develop.

I usually use a tracked ride with a shoestring and invisible track for that sort of thing. It looks better than just peeps falling implausibly slowly, but it's very difficult to make work if compatibility with vanilla is required (because both OpenRCT2's invisibility cheats don't work reliably in vanilla). But I see the use case, I just don't think it's a good idea to implement a feature solely to make something like that work when you could instead implement a feature that makes it unecessary (i.e better custom flat ride support). I know the latter is a long way off, however.

This has already been done, the limit was raised from 120 to 320 ft. However, a further raise might be possible - I'm not sure if this is the absolute limit. Removing the limit entirely would require a new file format. This has been suggested over and over again but it can't be done until the save format is changed. I think mechanics already can enter through an entrance if they are unable to locate the exit. But I don't think we need to explicitly support leaving the exit disconnected, that would probably kill the peeps IRL. Well, you don't need a scripting engine to make custom scenarios, that's what the scenario editor is for. I've thought about the potential use for this but I'm not sure it's there - there are certainly some hacks for which a scripting engine would be very useful, but the number of people who do that sort of thing seems low. You'd really want this for things where a script would be helpful but the desired functionality doesn't justify being added as a feature. I thought of using it for something like procedural generation of buildings or terrain, or processing passes over the entire map to do things like remove duplicate objects or things incompatible with vanilla. EDIT: The actual terrain limit is 600ft, I'm not sure why OpenRCT2 only allows up to 320. Seems the limit was raised, but not as far as it could have been.

OpenRCT2 has always had screenshots. The main difference is that screenshots are now in PNG format. They are stored in your OpenRCT2 user data directory, in a subdirectory called screenshot. OpenRCT2 also has a giant screenshot option that screenshots the entire park at once.

This is still my favourite of the TOGO pipelines. Also the only one with a non-standard layout. TOGO's designs don't do that, so if you're doing that, you're a) actually modelling a different type of ride (Arrow pipeline, maybe?), in which case my preferred option would be to create a seperate object for it, or b) you're not aiming for realism, which is fine, but that would be a use case for a cheat like this IMO. I do think that rides shouldn't get penalized for unusually long layouts as long as they are still safe to ride however. They've been largely obsoleted by modern manufacturing techniques. The novelty they offered was the ability to carry out elements that, at the time, were new and unique, but now, there's just no need for the extra expense and engineering difficulties of building a pipeline coaster because with computer aided manufacturing you can shape steel track into pretty much whatever shape you want. That allows for heartlining the track, which is ubiquitous on modern rides and pretty much eliminates the need to have the riders positioned between the rails. Arrow put a lot of effort into developing a pipeline coaster but they didn't sell a single one. There is also a lone Intamin model.

It's a TOGO, I think that one is deserved (though I haven't actually ridden one, they don't exactly have a good reputation). I think all the hard limits and penalties need to go except those that actually make the ride dangerous. The game needs to stop confusing roughness with intensity - a lot of rough rides have unreasonably high intensity because of it - I'd remove that and just make such rides less popular. I would prefer a rating system that looks at the entire track layout instead of just the aggregate stats - not sure exactly how it would work though. That's clearly the right solution, I think. But it probably requires a new file format. Also, the Intamin 2nd gen drop towers have multiple independent vehicles on the same tower, and that requires not just a new track piece but changes to the underlying logic. I'll probably have to keep using shoestrings for a while yet.

I think there is a use case for both. The rating calculation could do with alteration, but the ability to override it would still be useful because certain hacks play havoc with the ratings. There is a drop tower in my current park that has an intensity rating of 16+, because it's a shoestring and the front car (from which the ratings are calculated) is not the one the peeps actually ride, and it has 300ft drop into unbanked curves (which are needed to switch the car onto seperate brake and lift sections). Of course I'd prefer it if the shoestring wasn't necessary, but for now at least it is. The game's drop tower has a brake run too short to allow a tower of this height.

The heartline isn't really a special case - trains are free to run backward in normal operation but chain lifts and stations only work in the forward direction (except in reverse incline mode). The log flume and reverser coaster are, however, a special case. I did try merging other rides onto log flume track in an attempt to reverse them, it doesn't work. I actually have no idea how hard this is to implement, it's either very easy or very difficult and I don't know much about this area of the code. I expect it would be easier to get trains to dispatch backward and run the circuit in reverse than to actually reverse the train (so that it faces backward while travelling in the same direction as the track was built). On the other hand, it could potentially be achieved just by mucking with the vehicle draw functions and swapping sprites around (though this would be an awkward hack and may well interfere with certain rides) For now, I'd recommend just creating a new DAT with the sprites reversed. That's what the 6 seater wooden coaster is - just an alternate vehicle type, nothing special.

You've selected the wrong directory. The directory you need to select is where you installed vanilla RCT2, not where you installed OpenRCT2. g2.dat is used for extra sprites added by the OpenRCT2 project (such as the fast forward button), while g1.dat contains all the base graphics for the game. If you see g2.dat you're in the wrong place - you should expect to see a subdirectory named "Data" containing g1.dat and the sound files, and another subdirectory contained "ObjData" containing all the object files from the game.

You mean the control key? This was in vanilla, if it's not working in OpenRCT2 then that's a bug, but it's working fine for me on latest develop. Setting the speed of block brakes is a good idea, but don't make them work like RCT3's "instantly stop the train and then accelerate to 60mph" versions. Fast chain lifts work so much better as launches, and when a new file format is created it would be possible to implement actual launch pieces, so I don't think we need to introduce a new way to hack them. Requires a new file format, the four station limit is built into the SV6. Possibly useful but subject to rendering order glitches (as is anything using disable clearance check). Better is to use scenery objects that fit the landscape, but not all sets have these. Requires a new file format. And while you're at it why not remove the limit completely?

This bug applies to tracked rides created with Buggy's ridemaker. The problem originates from that tool, not from OpenRCT2 or the vanilla game, but there's enough of these broken DAT files that I doubt they'll ever all be fixed. Several fields in the ride entry structure are reserved to be populated during load time. When a ride is exported, all these reserved fields are zeroed out. They should not contain any data, so this normally doesn't change anything. The problem is that some of these fields serve a different purpose for tracked rides than do flat rides. Buggy's ridemaker writes three of these bytes as 0xFF, which apparently has something to do with the animation - but only for flat rides. For tracked rides those fields are expected to be zero, and because they aren't, the file gets changed during the export process. The checksum is not updated accordingly, so the file ends up exported with a mismatched checksum. It's still in the savegame, and only the checksum is wrong, which is why you can load it if you allow incorrect checksums. I tried to implement a workaround for this by having the game recalculate checksums after exporting an object so that this issue would not cause a problem (because fixing the original tool is unlikely at this point, it's old and I doubt it's still being maintained). However, the number of DAT files still causing problems indicates to me that my attempted fix was severely broken - I have been meaning to have another look at it but haven't got round to it.

No you're not. "Allow incorrect checksums" forces the file to load despite the incorrect checksum, so you will still have the object. The difference is that if you install the object manually, the object in your ObjData file has a valid checksum, and then it gets corrupted during the export process. If you use "Allow incorrect checksums" to force the object to load, the object in your ObjData folder will be the object post-export version so it has an invalid checksum to start off with. That means it throws a checksum mismatch on load that you don't get if you installed the object manually, but that error doesn't actually prevent the object loading, so I'm not sure if there are any actual consequences of doing it this way, and it's certainly easier than manually copying the files. I agree that this is an ugly way to solve the problem though - the correct way is to fix the broken object before using it in a park IMO.

Is that all it says? Normally, if there's an invalid checksum it prints an error to the terminal saying so ... same if there's a missing DAT. Maybe try running with --verbose (which enables extra logging) - else try uploading the save somewhere and see if others can open it.

SBOX.DAT is a vanilla object (Soap Box Derby racers) - so don't remove it from the ObjData folder. I have no idea why removing it would appear to fix the problem though - is it possible that you have a duplicate of that object, or a different object with the same name that's causing a conflict? This seems rather strange - I'm not sure if it's an issue with the game, the park, or your RCT2 installation.