X7123M3-256

If you mean the turnaround immediately after the drop (which is the only thing that looks like a helix), there was a similar element on Son Of Beast - I believe it was referred to as a rose bowl. I've not heard the term "Inverted helix" used to refer to this element though, so maybe you meant something else.

If I revisit this project I'd likely take a different approach to the sprite generation. For those sprites, I extruded a 2D cross section of the track shape along the shape of the track. It works for relatively simple tracks, but doesn't generalize well. A better approach would be to start with a full 3D model of a straight section of track and transform it to match the desired track profile. Another issue is the splitting of the sprites - that code assumes it's one sprite per tile, like for large scenery, but I know now that that's not the case - track pieces have their own draw logic. I don't fully understand what that is yet.

I don't think the object editor can edit g1.dat, it is, as the name suggests, meant for editing object files. The images themselves are in the same format, but object files contain a lot of additional data on top of that. Also, some g1.dat sprites use several flags not used in object files, so a loader for object files may not be able to handle them correctly (mine did not, and I only found out what was wrong fairly recently). I am not sure if Trigger's Graphics Extractor can modify the file either, but it's something that could probably be added if you wanted to do that. The way recolorability is handled is that certain palette indices are marked recolorable - wherever those colors appear, they can be substituted for another according to a lookup table that I can post here if you want. The primary two remap colors are always remapped and never show up in the game, while the third set of remap colors doubles as the yellow pixels. Usually, there are flags to set on the object to enable each remap color, but not in g1.dat - it is sufficient to use the correct palette indices. Here's a dump of all files associated with that project. This includes the modified g1.dat and the code used to generate it. Be aware that this will break your terrain sprites, because they are missing a field I did not know was required. I know how to fix it now, but this code is unchanged from what I had when I did this originally. Do back up your original g1.dat somewhere before trying this out.

Most people get custom scenery by downloading parks. Many parks are available for download at New Element. I would recommend downloading the Xtreme97 workbench, as it has a decent selection of the most important objects. NE also has a large database of individual object files available for download, but it carries very little information about them, so it's only really useful if you already know the name of the object you're looking for.

I implemented that command. I didn't document it because I'm not sure where documentation for console commands is supposed to go (I think the help command could do with extending to include descriptions of commands instead of just a list) The command is "rides set friction <ride index> <friction value>". The appropriate ride index for your ride can be determined by typing "rides list" at the console. This command will loop over every ride vehicle and set the friction to the supplied value; this means it can only be applied once the ride is testing and doing anything that causes the trains to respawn (e.g changing train length) will reset the friction back to default. Lower values mean higher friction, the maximum is 65535, and very low values can sometimes cause bugs, especially in vanilla. Saving before using this command is advisable.

In RCT3 objects are represented by actual meshes, there is no pre-rendering and no use of sprites. The need to split objects across multiple map elements is gone because you have a depth buffer (I have no idea how RCT3 stores the map, but it certainly doesn't need to do it the way RCT2 does). While you can argue that RCT2 is a 3D game since the objects have coordinates in three dimensional space, the sprites themselves carry no depth information and the rendering techniques are closer to what you would see in a 2D game than something like RCT3. The image RCT2 produces is the same as what you'd get if you replaced the sprites with 3D models, yes, but in order to make that so the game has to be designed around certain restrictions: The impossibility of correctly sorting objects for rendering using the painter's algorithm forces the objects to be organised into a grid, and objects that take up more than one grid square have to be split up into multiple sprites to avoid violating the constraint. To dispense with the grid you'd have to use an expensive topological sort, and you would get rendering glitches in cases of cyclic dependencies. Without any depth information, you can't resolve this problem - that's why you can't just place objects anywhere in RCT2 and why circumventing these restrictions with zero clearance will frequently cause rendering glitches. In RCT3, this restriction is artificial - there's no fundamental reason you should be confined to a grid. You are limited to one viewpoint. To get the other four viewpoints, the object has to be rendered from four angles. You could add more viewpoints at the cost of rendering more sprites but there is no way to change the viewpoint arbitrarily. You cannot use a perspective projection, because then you wouldn't be able to pre-render a sprite even with a fixed viewpoint - the object is distorted according to it's position in relation to the camera. A consequence of this is that RCT2 can never have a first person viewpoint. Real time lighting isn't possible. The implementation floating around is a post-process where pixels near a light are brightened - it doesn't properly shade objects and it cannot computer proper occlusion or shadows.

Are you sure the game is actually installed? Some people have tried to point OpenRCT2 at the installer or the disk mount point- OpenRCT2 can't make use of those files directly as they are in compressd format, you need to actually run the installer. For me, the game was located at C:/Program Files/Infogrames/RollerCoaster Tycoon 2. This was the disk version, if you got the game online it might be installed somewhere else. If you have a shortcut for RCT2 somewhere on your desktop, you should be able to right click it and see where it points to. If all else fails you could try reinstalling RCT2 and making a note of where it's installing files to.

The log flume and splash boats do not actually have a lift hill. That's why you don't see a chain lift button in the editor. What looks like the lift hill is actually the normal upward slope sprite for that track. The boats climb the hills because it is treated as a powered ride. This is also why they do not slow down on long flat sections. Therefore, there are two ways to speed up the lift: You can either enable "Allow chain lift on all track pieces" to put an actual lift on the ride, or you can increase the acceleration and/or the speed of the boats (there is no cheat in OpenRCT2 to do this yet, however).

That wasn't the first time someone was confused by the preview image - I think at least 4 people have asked how to get the IBox, but you do not want it - it's glitchy and incomplete. I thought it was common knowledge that custom track styles weren't possible, but apparently not. If anyone wants to see just how bad it is, I could upload the file. Also, you can put anything you want in a preview image, you could put a photo of a real ride in there if you want. It does not have to be a screenshot of the game, that's just convention. I generally avoid using anything custom in the preview images except for the trains themselves, but the RMC just looks so awful on wooden track I chose to keep the IBox, even though I never released it because it was not usable.

I'm hoping that when there is a new save format this will be possible. I still have the code used to render the IBox track for the that video, but I've since thought of a much easier way to do it that's flexible enough to handle more complex track styles. @Duncans_pumpkin has now completed reverse-engineering of the Junior coaster track, so we have an example coaster that's fully implemented (but lacking many track pieces). In theory, you could do it without a new save format but at the cost of permanently breaking backward compatibility - by changing the dive machine to use twister track, adding the elements from the dive machine to the twister track instead, and you'd free up a ride type to be used for a new track type. However, this would result in all savegames prior to the change being loaded incorrectly, and all new savegames with a vertical drop coaster being incompatible with vanilla. I think it's best to wait until there's a new format.

I had a go - but ultimately this would require a new save format to do properly as there's no way to create custom track types at the moment (the linked video used a modified g1.dat). Therefore, I would say RMCs are easily one of the hardest coaster types to build - they have unusual elements hard to reproduce with the current set of pieces, and the track style differs so dramatically from anything else that nothing really works as a substiture, even with extensive hacks. A decent RMC can just about be done, but you'll need zero clearance, at least three different track types, and custom scenery.

While technically true, the amount you could earn this way is tiny - and the problem could be solved by deducting the cost of the item from your money whenever your guests purchases something.

It was possible, there was a hidden option for it. You had to edit a file called options.txt somewhere in the game directory to enable it. I can't remember the specifics, it's a long time since I played RCT3. There isn't much need for hacks in RCT3 because the game engine is more flexible and so a lot can be done with custom content without relying on hacks, but this was one that's useful to have.

I implemented a feature a while ago which allows changing the speed of powered rides, including elevators. I made a pull request for it but it was never merged as the code was a bit of a mess. It's still open, I could probably clean it up a little. All powered rides have their speed stored seperately, but as it this value is in the vehicle struct and not the ride it's a bit difficult to make it adjustable in the ride window if that's what you're thinking of (though it's probably possible, just a bit hacky and hard to do in a consistent manner). What I did was implement a command that directly sets the speed and acceleration value for all vehicles currently on the ride. Changing the speed of rides in this manner can sometimes break their functioning, so be careful. It's usually only the case with extreme values and it can normally be rectified by double closing the ride, but I would still save before doing this.

Why wouldn't it? If a ride has sprites for a track piece, they will be rendered if you use it, regardless of whether the ride normally allows that track piece. All coasters have the flat turn sprites, since they include the flat track sprites which essentially everything requires. There isn't a single coaster in the game without that sprite group; I haven't tested what happens if you try to create a ride without it. I don't know about that but I'd love to find out more if you have any information. I also think the pipeline coasters look pretty cool with turns. The Arrow version was in RCT3 but not RCT2. TOGO trains are a poor substitute IMO but I guess that's the best you can do.

They weren't designed to go upside down and neither were the real ones. However, an interesting quirk of the game is that any ride that has sprites for vertical slopes must also have sprites for vertical loops. So those sprites were rendered but apparently never intended to be used. An even more extreme example is the reverse freefall coaster - it has sprites for turns, sloped turns, steep turns, verticals and loops, but it can't do any turns or loops. It has hundreds of sprites and only uses a small fraction of them. I don't know why they bothered rendering these sprites instead of just leaving them blank, but those images have to be present in the file in order to have the vertical slopes. TOGO pipeline coasters don't turn. They're also pipeline coasters - they wouldn't be able to run on traditional coaster track, hence the unusual tubular track design. All but one is a stock layout, though there is one with a dive loop in place of one of the reversing sections. They're limited in game because they're limited in real life, but they're even more limited in game than they are IRL. The real ones have a vertical elevator lift to start the ride - since this can't be done in game and you don't even have a vertical slope with which to fake it, you'd have to use a track merge just to make a realistic layout. I also like building 4D coasters - one of the most interesting designs to work with for certain. However, the real life layouts are very large, all very similar, and difficult to do well in game, which doesn't give a lot of flexibility, so I usually build mine based on the Arrow concept layouts instead of the designs actually found in parks today. They're smaller, more practical, and have more diverse layouts so you can do things like put a raven turn straight off the lift hill. I wish one had been built.

Few of the default rides are hard to build with when they're used to represent the rides they're intended to represent (rather than as a stand in for a ride not in the game), but one that stands out is the Air Powered Vertical coaster. It's missing basically all the track pieces, so the only layouts you can build are different sized versions of the track that comes with the game. It's true that Thrust Air coasters weren't much more than that, but the lack of even gentle slopes makes it hard to make it look good. I expect the one in the game is based on the prototype, where there were no gradients apart from the top hat and the curves were flat on the ground. Another obvious one is the heartline twister coaster - no elevator lift means you can't build a realistic layout at all. Even with hacks it's difficult to make work well.

You need to edit config.ini and change game_path to the location where RCT2 is installed (if you use the launcher, I think you can set the game path there instead). The directory you select should contain the rct2.exe executable, and the subdirectories "Data" containing the files g1.dat and several files of the form css<number>.dat, and "ObjData" containing a large number of .DAT files. It is not the directory where you installed OpenRCT2 (some people seem to have got those mixed up). It is also not the location of the game disk or installer. The path to this directory depends on where you got the game from - normally, it would go somewhere in C:/Program Files, but if it's installed in the default location OpenRCT2 will normally find it automatically, so this probably means you've installed the game somewhere else (on another drive, perhaps?). If you can't find it, search your computer for rct2.exe.

These limits have not changed from vanilla. I think you may be confusing two things: the limit on the number of ride types is 128, but the limit for the number of rides is 255. You can have up to 255 rides on the map but only 128 ride types can be loaded at once, so if you have more than 128 that means you have multiple rides of the same type.

I don't think they get distracted - but if they are unable to find the ride, after a while they choose a new destination.

Yeah, @jensj12 pointed that trick out above; I hadn't heard of it before. It's a useful workaround in some cases, but so far as I can tell it only works if the stations are seperated only horizontally - can that still be done if the stations point in different directions?

We know that but nobody has been able to fix the problem. If you would like to have a go, feel free. The AI was pretty primitive in RCT2, though there are definitely cases where OpenRCT2 causes problems and vanilla doesn't. OpenRCT2 does fix the maps so peeps can choose destinations further away than they could in vanilla, and that makes them more likely to get lost. This might be the only cause of the problem, or there might have been a mistake made when implementing those functions. Seriously? Nobody is sabotaging the game. It is still very much incomplete, they haven't even finished reverse-engineering the vanilla code yet. Until we have our own save format there are hard limits on what can be changed. A rework of peep AI will happen eventually but not right now. Not everyone is online all the time, it's very possible that Cascadia is asleep or has something else to do.

It used to be free for everyone, then trolls came on and ruined everything. The permissions system at least helps cut down on that. You can still create a public server and give everyone every permission if you want to.

I believe this is not possible - even with cheats. I wasn't aware of a workaround but the technique suggested by @jensij12 sounds like it should work, at least where the stations are only seperated horizontally. Another option is to make a mobius loop and use block brakes to sync it. I have not tested what happens when you start reassigning stations or having trains arrive at a station that belongs to a different ride - but I am doubtful that either would make this work. This probably needs a new feature to be added to work properly, but I'm not sure that it can be without a new file format.

Could you set up your firewall to drop all requests from his IP? Even if he's using a proxy it would slow him down somewhat because he'd have to keep changing IP addresses before rejoining.