X7123M3-256

I suppose this layout might work better as a traditional wooden coaster than an RMC, but I set out to make an RMC so I ended up with this. I still think it's better than my previous attempts.

IIRC it was suggested in the original announcement that there be a CSO and an NCSO pack. I wouldn't say ongoing. Someone started one, did one ride, and hasn't done anything since. Nobody is actively working on it, as far as I'm aware. I think there are a number of things currently considered cheats that ought not to be. There are some track pieces that currently can't be built without cheats that should be available by default (though not pieces that the current ride type explicitly suppresses, like inversions on a hyper), and entrance rotation could go in the ride construction window rather than in the tile inspector as it is now. But I have no idea if there are any plans to change this. Personally, I wouldn't design a scenario that requires a player to use these features in order to complete it, as some people won't want to use anything that's considered a cheat when playing a scenario. But it's actually quite difficult to engineer a situation in which a scenario can't be completed without using those features, so I wouldn't worry about it too much. Scenario unlocking is an optional feature, it's up to the player to decide whether they want to enable it. I don't see anything wrong with using trackitecture, but if your intention is that it eventually be replaced by an object, I would just make that object. Modifying game speed doesn't make the game any easier - all it does is save time. I would say that if your scenario is only difficult because most people would get bored and give up before the goal is reached, it's not a good scenario. I don't see why you'd need to wait. If a new save format is introduced, there will be a way to convert old save games to it.

I tried rerendering this with specular enabled. I think it looks a bit better this way:

Yeah, generally you do, but you can then switch it back again after you've built it - you don't have to merge the two ride types together. The latest version has a cheat that removes some of the track piece restrictions - I would test if it allows you to build those pieces, but I'm currently using an old version that doesn't have that cheat.

The twister track has all of those in OpenRCT2. In vanilla, it does not, so you used to have to merge.

So today I decided to build an Intamin mega coaster. I used LSM trains, even though this ride shouldn't run them, because I didn't have the right train and I didn't want to make a new one just for this. I could have used wing coaster trains, but I don't like them. Also I couldn't find a steep catwalk object that doesn't glitch horribly, so I gave up on the catwalk. But other than that, I quite like how it turned out.

In OpenRCT2 the twister track has every element that the vertical drop coaster has and vice-versa. You should never need to merge a twister track with vertical drop track unless you want compatibility with vanilla. These are all the same ride type.

They generally don't. There's a few edge cases where they would, but there are ways around that too. There's a flag that has to be set on the vehicle to make that happen. I don't know if you can override the value with a cheat or whether you would need a custom train.

I doubt the vehicle physics have been changed. When I ported the RCT1 junior trains to RCT2, I found the physics to be an exact match - as in the train would be going exactly the same speed at different points on the track. There's still room for some error, since speeds are stored internally to a higher degree of precision than they are displayed - but I would be surprised if it was enough to make a ride stall that didn't before. I think the difference is probably because you're running RCT2 trains on a ride designed to run RCT1 trains, and the mass values are probably different. But you can override that with the console.

I put 5 different car types on one train. One of which has a wider track gauge and would not be able to run on the same track as the others. I can't think of any coaster IRL that does that - there's a few that have both a stand up and sit down train, but I can't think of one with different vehicle types in the same train.

@saxman1089 A download link was posted in the original thread.

A few of mine (I've posted almost all of these before)

It's not ideal but not a big problem either - much better than not using block brakes. If this is happening when the ride is running empty, it probably won't when the ride is running with riders (because it waits in the station longer). If you want to prevent the train waiting at the top of the lift, you can set a minimum wait time.

Installing expansion packs will only fix the problem if it's expansion objects that are missing. I imagine most people asking this question will not know where the objects are from (you can search this on NE though).

There are no researchable track pieces in RCT2. The launched lift hill should be available from the special pieces menu whenever you build a twister coaster. You need to be building an upward slope to select it.

Yeah, this doesn't sound like a bug - it's just impossible to judge depth in this projection. The scenery object can look like it's in the right place and not be. Sometimes I actually place markers on the ground level to mark out where specific support pieces are located, so that others can be positioned next to them. Frequently rotating the viewport when building tricky scenery is pretty much the only solution. And if building lots of pieces at the same height, always use CTRL and not shift. Once you constrain your building to a single plane, this problem disappears (as long as you get your first piece in the right place, of course).

By "view to the left" do you mean rotating the view? As in, the object appears to be in the right place from one perspective? Since RCT2 is in an orthographic projection, it's impossible to judge depth from a single angle - so it's very easy to misplace scenery when you build from one viewpoint only, and only notice when you rotate the view. I find this happens a lot when building supports.

I extracted the RCT1 sprites and put them into an RCT2 object file. The process is fairly straightforward, if tedious. The sprites are in the same format, but the RCT1 sprites are in a different order and must be manually reordered to match what RCT2 expects (you could probably automate this process, but it's not really worth it). @Gymnasiast sent me video of the actual RCT1 trains so I could adjust the spacing and friction to match. The awkward thing is that RCT2 expects 32 angles of the train, whereas RCT1 only provides 16. I worked around this problem by simply doubling up on the RCT1 sprites, but it does result in some minor visual issues on turns. I am hoping that if a new object format is implemented, it will fix this because I think @Gymnasiast mentioned better support for RCT1 sprites as a possibility. I also did the RCT1 ladybird trains but they weren't used on this ride.

The launcher is a separate program - the main advantage to using it is that it will keep the game updated automatically. If you don't use the launcher, you can set the game path in the config file. Not sure what's going on with your track files.

If you don't want to pollute your object folder with those awful objects, but still want to view the park, you can use ParkDat to substitute the expansion object with something else. Since most coasters from the expansion packs are just shitty reskins of existing rides, there's usually a convenient substitute available. I'm not sure how well this works for scenery; it'll probably glitch but it should allow the park to open. In fact, since expansion objects won't export, it's entirely possible to edit the park without having the object. You'd need to swap the object to open it, but you can then swap it back afterward because the file doesn't have to contain the actual object (I don't think ParkDat will do this though, you'd have to do it manually).

RCTC uses different file extensions and different save formats in many cases, so it's possible that the file is called something else and/or is located in a different directory (I don't have RCTC so I don't know if that's the case here). As I understand it, OpenRCT2 should be able to load assets from RCTC but not scenarios. It's the other way around, RCTC is an RCT2 port with some of the maps from RCT1. It doesn't contain RCT1 assets nor any RCT1 features except for the boosters (which are also implemented in OpenRCT2).

I think those track designs are from RCT1. If you have RCT1 installed that might explain it.

The game considers the cars as one train so it sums up the forces on each car as if they were still connected. If you have half the train on a downward slope and half on an upward slope, the net acceleration is zero. It is of course stupidly unrealistic to use it in that way - normally, you only split off one car so that the effect on the physics is as small as possible, and you use that extra car to speed up and slow down the real one when you need to. It's useful if you want brakes/launches/station platforms on diagonal or sloped track, and you can get a triple launch this way as well (though I think you can do that much more easily with boosters now).

That, then, is why it works. Track pieces of different types cannot merge.

If you want the trains to actually sync at the top of lift, that's going to be a bit awkward. You can't do this with two seperate tracks, you can only do it if you have one continuous track set up as a Mobius loop. You then need to have one train wait in the block at the top of the lift, with another block just at the rear so that both blocks are occupied by the one train. As soon as the first train moves off the top of the lift, it will clear the previous block and that allows the other train to move. You can get trains to sync at any point in the layout this way - the prebuilt "Great White Wail" has trains synchronized in the loops. But, to put a block midway down a lift is awkward - the only piece that counts as a block is the top piece, so you would have a bump in your lift. You could alternatively have a flat section with brakes at the top, which you may get away with on some layouts but otherwise looks awkward. What I do is sync the trains with brakes at the bottom of the lift - if the lift hill speeds are set the same (which they have to be if it's only one track), then they will still be synced at the top - but only if they don't have to wait there. If you want them to wait at the top and yet remain synced after, and don't want to put up with an awkwardly shaped lift, I can't think of any solution (other than a shoestring which is massive overkill for something like this).