X7123M3-256

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.

ZLOG.DAT is the Junior coaster log trains. Maybe that DAT got deleted somehow?

What is the specific error you get? While an incorrect checksum is a possiblity, I think it's more likely that you are missing one or more of the objects required to load the park. It is possible that the park has a hack that doesn't work in OpenRCT2 (in which case, it's a bug in OpenRCT2 that would need to be fixed), or it could be that the save is actually corrupt.

That exists. Also exists. If you want inversions on it you need to merge tracks, but that's something that can probably be changed once the game is fully implemented (a new file format would not be required and neither would new sprites). Select "Disable support limits" and you can make anything 400ft. I don't know if there's an appropriate Intamin accelerator train to go with it (there's JAGIGLT which appears to be an Intamin train, not sure what kind). Sort of exists, but only on sloped track. Proper launched pieces are still missing, and something I'd like to see as well, especially on the Intamin track. I think this will probably require a new file format to implement.

Somewhere on your system there should be a directory containing the file "rct2.exe" and the subdirectories "Data" and "ObjData". This will be created when you installed RCT2. Exactly where this is located depends on what version of the game you have - on Windows it will usually be somewhere in C:/Program Files - if you are using Wine to install the game on another OS you'll need to find out where Wine places the emulated C drive. On my system (which is Linux), it's at ~/.wine/drive_c. It might be located somewhere else on Mac, I don't have a Mac so I can't check. You need to edit game_path in the config.ini file to point at this directory (not the actual rct2.exe executable file - you want the whole directory).

I am 99% sure that's possible. I'll look into implementing it now. EDIT: Definitely possible, I've just implemented it and I'll submit a PR after I clean up the code (which will probably be tomorrow). All aboard the hypersonic warp train: (this causes the train to go so fast that the speed repeatedly overflows back to zero. Also, it travels so far in one frame that it skips over the station entirely and keeps going. At one point I recorded the speed as negative 7000 mph.)

Why would you want to do that? I can't think of any examples of a ride with a reverse incline and a launch. There's a couple that have three launches in alternating directions though, like the Premier Sky Rocket and that new Intamin in China.

Many Intamin launch coasters use a hydraulic launch with a catch car that attaches to the train. I'm thinking you could have a special piece that, when placed, turns the preceding straight run of track into a launch run. It could function exactly like the cable lift does now, but faster and entirely on level track (the cable lift piece can only be built on a slope).

Question: once everything has been implemented, how hard do you think it would be to implement a launch for the Intamin track that behaves like the cable lift? (i.e with a catch car)

The Twister coaster already has it. It probably could be added to the others without the need of a new file format because it's an element that's already in the game, but I doubt it will happen. Most coasters that have launches have them on level track though, and for that you'd need a new track piece. We'll have to stick with using chain lifts as launches for now.

There is only one spinning coaster with an inversion: Veil of Dark. The Blue fire video above was only a test; it does not run with that train normally and it was never open to the public with the spinning car. It does hint that Mack might try something like that with their spinning coasters in the future though.

Here's the PR for the lighting code. This is probably the most interesting feature being worked on at the moment IMO - all the stuff I thought was impossible is being implemented (I'm sure there must be a 32bpp frame buffer involved somewhere in this).

I was playing around with setting the friction values really low, and made this coaster. It takes all night to complete a single cycle (the animation is obviously sped up). The friction is set as low as it can go before the counter overflows.

I think I've seen this bug reported before. As a workaround, what happens if you enable "Show vehicles from other track types"? Can you select the other trains then? Failing that, the console can change ride vehicles as well, at least until this bug is fixed.

It has a sprite limit, and guests are sprites, so yes. The limit is somewhere around 10000 I believe.