X7123M3-256

I think, if we are to add a feature that affects the whole track piece, then it doesn't belong in the tile inspector. I think the tile inspector is best kept as a tool to directly edit the tile data. A raise/lower sprite option makes sense here; it's just providing a means to edit the values the tile inspector already gives you, and it wouldn't be limited to just track . If we were to implement a tool to raise/lower a track piece as a whole, I think it ought to be a seperate thing. Perhaps a tool that allows you to select an area, a type of object to operate upon (track, scenery, path etc), and then choose an operation to perform on those objects, like raising/lowering it, making invisible, etc?

When you build a track piece, the game highlights all affected squares. You can just click each one in the tile inspector looking for the relevant elements. Sometimes there's more than one on each tile - all of them have to be moved. The only time it becomes difficult is if you have tracks crossing each other, but you can usually tell from their position in the list which is which. It's the same process you currently go through when making tracks invisible.

Haven't tested it with guests on board yet, but I did not move the entrance and exit, just the track, so you can still build a path up to it. I don't think there would be a problem, but for my purposes I don't need guests to ride this ride, so I didn't test it.

Interesting... but I'm not sure why that means it couldn't be done in the tile inspector. As long as you raise every map element belonging to the track piece by the same amount, you shouldn't get any weird effects like that. I've been using a script that does the same thing (modify every map element), and I haven't encountered any ill effects - you can even open a ride that has been moved this way.

I found out about it when it was announced on the RCT subreddit 2 years ago, but I didn't actually install it until later, because at that point it was mostly inline assembly calling out to the base game, and I couldn't figure out how to build it on Linux.

As I understand it the map elements are all there is - raising every map element belonging to a track piece is equivalent to raising the whole piece - at least, that's what the script I'm using at the moment does, and it seems to work fine - you can even open the raised ride, but construction mode doesn't work.

I agree that this would be a useful feature; I just had to do this for a park I'm working on and ended up having to edit the SV6 with an external script, which is not ideal. I think this would be most easily implemented with a button in the tile inspector that allows elements to be raised/lowered 1 unit. There could also be a console command to do it to an entire ride. I will probably try and implement something like this when I have the time.

I don't know, but I think the answer is probably not. It seems trains have to face the same direction as the track. You could build the whole ride backward, but then things like chain lifts would go in the wrong direction. I think the easiest way to reverse a train is to create a new DAT with the original seats reversed, like Sawyer did for the 6 seater wooden coaster. Once you have such a reversed train, this hack could be used if you wanted to reverse individual cars rather than the whole train.

Sometimes, when you build paths with zero clearance, they don't connect up to things properly. It tends to just build through things instead of connecting to them. For example, if you built a path on the same square as the entrance, the queue might connect up to the path you built instead of the entrance. I find the easiest thing to do is to avoid building paths with clearances disabled - instead, build the path first and then zero-clearance the scenery you need on top of it.

There's a number of objects that don't export correctly due to a bug in the tool used to create them. You can force such objects to be unpacked in OpenRCT2 by selecting "Allow loading with incorrect checksums". If the park was not exported at all, you still need to install the objects manually. Parks that have been saved with OpenRCT2 should have the problem objects fixed so they will unpack correctly, but this doesn't always work at the moment.

Not sure what you mean by this. You can have any vehicle from any of the available objects in your park on any track. As far as I'm aware, you can have different trains with different vehicle types on the same (though this is untested). You can even put some of the vehicles of the same train on one track and some on another (this is known as a shoestring). IIRC the front car is used - so if the front car is side friction, the whole train crashes. If the front car is twister, no crash occurs. There's a couple of other parameters that are specified per-vehicle but only the front car matters (such as sound effects) - I'm not sure why these weren't specified per-ride instead, but that's the way it is. I don't think theres any way to set it up so that only part of a train crashes - even if you split the front car off onto a different track and crash that, the rest of the train just randomly explodes in the middle of it's course.

I've not seen it done before either. I'd be surprised if this was the first time it's been done, but then before OpenRCT2 this hack would have been very difficult to pull off, and it wouldn't have been obvious that it was possible. There's a lot more that could be done with this, like messing with spacing or friction, but none of it seems particularly useful, except for certain hacked flat rides and shoestring coasters.

This is not a bug in OpenRCT2 (well, it sort of is since OpenRCT2 is supposed to fix this problem, but that's not the root cause of it). It does not mean your park file is corrupt. This error occurs because the AE tracked rides were created with Buggy's ridemaker, and Buggy's ridemaker has a bug that causes it to write 0xFF in three locations that are supposed to be zero. When the object is exported, those bytes are set to zero, but the checksum is not recalculated so you end up with a checksum mismatch when you load the park. The error doesn't occur if you don't export the park because it is the object included with the SV6 that is broken, not the one in your ObjData folder. I tried to fix this problem by having the game recalculate checksums when exporting objects, and padding the file with extra bytes that force the checksum of the fixed file to match the original. Unfortunately this code doesn't seem to be working properly in all cases - I will need to have another look at it at some point. If you have the DAT file in your ObjData folder, you don't need to worry - the game will simply load that one instead - but if you post the park online it's a good idea to also post or link the custom ride so that people who don't have it can download it. If you don't have the DAT file in your ObjData folder and can't open the park because of it, you can select "Allow loading with incorrect checksums" to ignore the checksum mismatch and force the park to load.

I was experimenting with the train code, and I found you can have vehicles taken from different rides in the same train. You can also override the normal vehicle order, e.g to create a train that consists entirely of zero cars. I don't know if this has been done before, nor do I have a use for it, but I thought it was interesting:

I've noticed that parks don't get exported when I click "Save", only "Save As". I don't know if this is the same for other people, but I've mistakenly saved parks without exporting many times because of it. Also you can download RMCT1.DAT here, if that's the only object you're missing then that should allow you to open it.

Like YoloSweggLord says, you cannot install cheats by adding a file to the OpenRCT2 folder, implementing a cheat requires modifying the existing code. I have already implemented a cheat for changing train length. It has not been merged into the main develop branch, so if you want to use it you need to use that version instead of develop for the time being. Note that using that cheat will leave you unable to connect to multiplayer servers - please don't change the network version to circumvent this as you might cause problems for other clients.

It's probably the most-requested feature but it can't be done just yet. I believe they do plan to do it at some point, but it's still some way away because so much existing code depends on these data structures.

This has to be the most frequently asked question ever. Increasing these limits is planned for the future, but because it requires the alteration of existing data structures it cannot be done until all the original code has been reverse engineered. When it does happen, it will require that the SV6 file format be changed also because SV6 files are essentially just a compressed version of the game's internal data structures, with the map size limit hardcoded. This has nothing to do with whether the code is compiled for a 64 or 32 bit target.

You can make the track sprites into scenery objects, but that takes up scenery slots whereas actual track doesn't.

Track pieces don't have different clearance heights per quarter square, they have one clearance height per sprite (or so it appears in the tile inspector at least). I believe scenery items are the same in this respect. You're correct that scenery items use the same clearance height for each sprite and track pieces don't. Track sprites also have their own draw code and don't seem to be split up in the same way scenery items are (scenery items have 1 sprite per tile, track pieces can have more than that). I think OP is asking if you can place track pieces without building a ride, not whether you could convert track pieces to scenery items, so I'm not sure either point is relevant. I think the answer is probably "yes", but it may require alteration to the code (I'm not sure though, I haven't actually looked).

Found the relevant code. It seems that only angry peeps vandalize, and only when there is no security guard within 7 tiles of the peep. The sprite that is shown in the window is decided here - the angry face is shown if var_F3 is nonzero. var_F3 is set to 16 when the peep vandalizes a path object, and decreases by 1 on each update until it is back to zero. I am not sure if this unsets the angry flag or not. So it seems that the red face is shown only once a peep has actually vandalized an object - angry peeps that have not yet vandalized (or have gone long enough without vandalizing) are not visibly angry. Also interesting is that naming a peep "Eilidh Bell" will instantly make them angry.

Sure there is, they show up with a red face in the peep window:

Hacked rides often mess with the E/I/N ratings and while they are ultimately inconsequential I wouldn't mind having the option to tune it manually. For example, train length factors into excitement rating, so when playing with long trains you can easily get 11+ excitement which is absurd. Also,rating calculation is different for every track type, so putting a train on a different track type from the one it was designed for will often result in an excitement rating that's too high or too low. Worse, while individual objects can increase ratings beyond the hardcoded base, you can't decrease them, so if you make a ride based on giga coaster track the excitement will probably come out higher than you'd like, even without the use of cheats. I think the best way to deal with this problem would be to make it possible to adjust ratings down as well as up in the object file, rather than on a per-ride basis, but I don't think this can be done easily without a new object file format. I'm not sure how easy it would be to implement as a cheat, either, and I don't think it's particularly important, but if it was there, I'd probably use it.

I mean, you're not going to get a new Arrow looper today (a relocated one maybe), so most installations are getting old now, and technology has moved on. It was just meant as an example of an old ride style - I didn't mean to say "guests should not want to ride Arrow loopers". I think rides should get less popular with time - people do get bored of rides they've ridden many times before (at least I do), and new rides attract people to the park (otherwise parks wouldn't build them). Without this mechanic, there'd be no incentive to keep expanding the park.

If such an option is implemented it should be a cheat. People do get tired of older rides- a newly opened ride will almost always have the longest queue, and old rides get rough and unpopular with time. In 1980 an Arrow looping coaster would be new and exciting; today, not so much.