X7123M3-256

A shoestring hack involves splitting off one car from the train and putting it on a seperate track, which is usually hidden underground. You can then use brakes and lifts on the hidden track to control the train on the main track. If you want brakes or a station platforms on diagonal or sloped track, this is the only option way to do it at the moment. However, in order for a shoestring hack to function correctly the two tracks have to be exactly the same length, otherwise the cars get out of sync, which makes this one of the most difficult hacks to make function correctly. It's therefore quite common not to do it, and instead have diagonal track that is made to look like brakes with scenery, but doesn't actually slow the train.

If you mean as a new track piece, what @Broxzier said. If you mean as a hack, diagonal brakes can be done with a shoestring

Ultimately it's virtually impossible to conclusively prove a program isn't malicious - you will have to trust someone, at some level. The source code is open for examination, which is good. But did you actually read all of it? (I certainly haven't) And if you did, are you sure you'd spot any malicious code? (it can be quite subtle). Do you know that the binaries available for download were actually built from that source code? And if you built from source, do you trust your compiler to produce a correct implementation? (you probably do).

Yes, but one sees much more traffic. RCT2 guests overwhelmingly prefer to keep going in a straight line - only a small fraction will take a junction when a straight line path is available. So look at what happens to guests approaching from the left - they'll walk straight past the first entrance, but then they have to turn. 50% of them will turn toward the right entrance, the other half keep going on the path. It looks like for guests approaching from the left, the opposite would be the case - but due to the way RCT2 handles wide paths, those extra tiles are ignored - from the screenshot it appears that most guests approaching from the right also hit the right entrance first. This does not apply for guests that are actively heading for the ride - they will always enter the queue if they walk past it, but they only make up a small proportion of guests.

The problem is not the ride, it's the path layout. That path layout will direct most guests toward the right entrance. The left entrance hardly sees any guests, which is why it's empty.

Show them the source code.

RCT2 sprites are bitmap images. In order to enlarge them they have to be upscaled. This goes for RCT1 as well - LCD screens have a fixed native resolution, if you're running a game in 640x480 mode the graphics driver will upscale the image. OpenRCT2 will upscale with nearest neighbour (I think), the monitor scaling is probably something like bilinear or bicubic resampling, which may account for the difference. @janisozaur experimented with more sophisticated upscaling, which did produce good results but I think it proved too CPU intensive and was not merged.

Custom objects are placed either in OpenRCT2/objects or in your vanilla ObjData folder. If you still play vanilla at all, I'd recommend the latter so you can use the objects with vanilla, otherwise, putting everything in your OpenRCT2 folder keeps your vanilla install clean. Unfortunately, there isn't a centralized place for this stuff like OpenTTD has, so it's quite common for newcomers to ask where to find custom objects. RCT2 is a very old game, so many of the sites that originally hosted the objects are down. Because objects export with the park, they can continue to be distributed and used long after the original download is dead. If you're looking for something specific, New Element is still the best place to look. I did make some improvements recently to make it slightly less painful to use, but you still have to download objects individually so I would not recommend it for downloading a complete set. Instead, the best advice is to download a bunch of parks (or connect to servers) and see what you get. As a starting point, I'd recommend the Xtreme97 workbench (other workbenches exist). Several of the rides you mention sound like rides I've made - you can get those here. Not all of these are in the NE database (NE doesn't add objects to their database until they are used in a park). I do not know where to find a Gerstlauer spinner or ZacSpin, and the latter is a very hard ride to make. You can ask in the custom scenery exchange at NE, many of those guys have been playing for years and if they don't have a copy of the object you're looking for, they may be able to name a park that has it. They don't. However, most of the functionality that those trainers had is provided by OpenRCT2 anyway, so this isn't a major problem. You can open parks hacked with 8Cars in OpenRCT2, so some people still use vanilla to perform these hacks - but this is restrictive, because not all OpenRCT2 features are compatible with vanilla and there's now very little you can do with 8Cars that you can't do with OpenRCT2. It's a game from 2002, almost anything will be good enough. The bulk of the CPU time is spent rendering (the game is software rendered), so I expect your CPU would be the biggest factor. I don't think it requires that much RAM - most of the game's data structures have hard caps on their size - though there are several megabytes of sprites to load in. The game can run on a Raspberry Pi - performance won't be great but you could play it.

No, you don't put them on one sprite, you put several sprites in one large scenery object. If you can create a large scenery object normally, this isn't any more difficult (unless the object editor doesn't support it - I can't test this, see above comment). Actually placing them in game is awkward because you have to delete unused elements, but this isn't something you'll be placing a lot of. Yes, this is possible - 3D signs (but not scrolling signs) do indeed include a sprite for each character. I'm not sure if it's possible to scale them up, but those objects are already 1x2 tiles so you're in luck there. I don't think I've seen one done with a custom font (it may well be that it hasn't been done, as it'll probably be quite tedious unless you automate it). However, the process should be straightforward - provide one sprite for each character you want to support (leave the others blank).

Yes, it is that way for all objects. All map elements are one tile, any scenery object larger than that must be split up. Even track elements must be subdivided, but those are a bit strange (every sprite has a tile to which it belongs, but the corresponding sprite doesn't always occupy only that tile. They have their own rendering logic so presumably that's how they get away with this, but it's something of a mystery to me. Ride sprites are not part of the grid, so they are generally one sprite no matter how large they are, but a handful of them are still split up for other reasons (e.g most tower rides have a front and back half). Not necessarily. As I said in another thread, I am pretty sure you can stack map elements on top of each other, though I haven't actually tried. The tile inspector acts on map elements, you can't split an existing map element in two, but if you know you want to split it up when you make the object you can arrange for them to be separate pieces. Not that there's any compelling reason to do it this way, I don't think - unless there's a maximum size for a large scenery object? I think a maximum element count is more likely, but I haven't looked at this in depth.

No, you can remove each map element individually. I am 100% sure this can be done, the only reason I've not done it is that I've never made a park big enough to hit the limit. Also, I'm not sure how the object editor handles this - it doesn't have a 3D model so it can't split the object into map elements automatically ... do you input each sprite individually?

If you wanted to save object slots, you could pack all the ride signs into a single large scenery object, and then delete the parts you don't need using the tile inspector.

They can't in game, but they would IRL, so it should still be avoided.

You could make them as animated doors, so that they'd be functional when used with the wild mouse and certain gentle rides.

I'm 90% sure there is. I've not tested it, but if it's not possible then it could definitely be implemented without a new file format. Large scenery objects have a list of map elements each with x/y coordinates, so I don't see why you couldn't put more than one on the same tile with different clearance heights. But I actually think OP was talking about a station built out of multiple small scenery objects like the one in the picture, not a single large station object.

IIRC, that demo does contain all the assets (though I've not been through the whole list to check). It's time limited, but that won't apply if you use it with OpenRCT2. The demo linked on the Github page is missing objects, but I think that's a different demo.

I tried that. You can get two sides to match, but the remaining sides then come out wrong. I tried using line search and gradient descent to minimize an overall error function, but I was not able to fit the data well, and even when you have a side that matches by the numbers, the visual appearance is often very different. I've pretty much given up with trying to get the lighting to look remotely decent.

RCT2 cannot use true color images, so they will be converted anyway. I think the problem is that your lighting is way too dark. IIRC, the object editor doesn't dither, so it will pick the closest palette color. The dithered image is a better approximation of the actual color of the model, but it does look noisy when given a shade that doesn't have a close match in the palette. You can try turning dithering off if you'd prefer, but I'd say the light needs to be brighter anyway. Lighting is really difficult to get right, and at this point I've pretty much given up trying.

I have no idea what you've managed to do there, to be honest, but here's what I did: start with the true color image (which is most likely what you are rendering). Open that in RGB mode, then go to Image->Mode, and select "Indexed". Then select the pallete you got from the screenshot, and set "dithering" to "Floyd-Steinberg". That should convert the image to indexed color.

You can find RGB values for the game palette here. (I link this and not the OpenRCT2 source because they assign different values to the remap colors - OpenRCT2 will give you orange colors for the primary remap, but most tools expect green. I'm not sure of the reason for the difference - it doesn't really matter, but consistency would be nice) However, there's a much easier way: open any RCT2 screenshot in GIMP and then navigate to the palette window. It will show you the current palette, and you can save it for reuse. This will not give you the primary remap colors (they are all shown as black), but as mentioned above, you don't need them for this anyway. There are a few other palette values you need to exclude when converting images for use in game. The water colors and the chain lift colors will animate, which is probably not what you want. There are a few other values whose purpose I don't actually know. The colors you want to include are in blocks of 12, from dark shades to light shades.

Sure. The primary remap colors are palette indices 243-254 (0xF3-0xFE in hex). The secondary remap colors are indices 202-213 (0xCA-0xD5) and the tertiary remap colors are 46-57 (0x2E-0x39). The primary remap colors are used only for remapping and never appear in game, so you should exclude them from your palette. There are also non-remappable greens, so this does not mean you can't have green areas, but if your object contains green areas and it's remappable then you'll have to work a bit harder to avoid them getting mixed up. The secondary and tertiary remap colors are only remapped if the object is remappable, so there's no need to remove them from the palette - they should show as the expected colors if they are not remapped.

This was the main reason why I wrote my own renderer. However, there is another approach, which will work fine for objects which are entirely non-remappable (as here), or objects that are almost entirely remappable. The solution is to simply remove the remappable colors from the palette you use when you convert the image to indexed color. The only time this doesn't work is if you have remappable areas and also non remappable areas in the same color. I saw one approach based on splitting the image into two, palettizing with different palletes and then recombining them.

Note that the primary remap colors never appear in game (they are always remapped to another color before being rendered), which makes their actual color somewhat arbitrary. Just about every RCT2 tool (including the object editor) uses green for these remap colors, but OpenRCT2's own sprite importer uses orange. If you are making sprites to be added to g2.dat, that's something to be aware of.

This sounds interesting.

Absolute limit is 10000 sprites, but coaster cars and vomit/litter are included in that. I have been unable to spawn more than about 9600 guests. This limit cannot be increased without a new save format.