X7123M3-256

The best sources for information on the games file formats are the RCT Technical Information Depot, and of course the OpenRCT2 source itself. I am not aware of a flag that marks a scenario as requiring expansions (though that doesn't mean there definitely isn't one), but I think the park you found almost certainly failed to load because of missing objects and not any flag in the file. Why would someone flag their scenario as requiring expansions if they didn't use any expansion objects? Not to mention, I don't believe there's a tool that does that, so they'd have had to edit the SC6 file manually just to add an unnecessary constraint. It doesn't seem likely, even if it were possible.

No. You can verify this yourself by checking in the scenarios folder. There aren't any mysterious files there. You found the scenario descriptions because you installed the WW/TT objects - and that includes the scenario text objects (these are used to provide translated text, the name in the SC6 is only in English). They aren't included with the base game either, they were part of the download you linked. The objects in that download are not the ported versions - they are the actual WW/TT objects. This can be determined by looking at the first nibble in the file - it is 0x8 for vanilla, 0x1 for Wacky Worlds, 0x2 for Time Twister, and most custom objects set it to zero. The last nibble of the first 32 bit word in the file is 0xC for expansion pack objects. The only effect this has is that those files will not export with saved games. The ported versions (which are not the ones you've linked) have these flags zeroed, to make them export. They are usually also given a different name, so they don't conflict with the default ones. While you could modify the WW/TT scenarios to use these objects, I don't see the need to do so. The only difference is that they export with the park.

You can't. You can't add new track pieces or track styles as a custom object, and there is no booster piece in RCT2. The only thing that could be ported would be the rafts, but they're similar enough to the existing dinghy slide that I'd ask if you really need them. Adding a new (hardcoded) track style to the game might be possible in a somewhat hacky way now, but booster pieces will definitely have to wait until a new save format is implemented. For now you can hack them with a fast chain lift as @imlegos suggested.

This is the issue in question, and as you can see it everything to do with your problem because it's the same bug - assertion failure at line 1280 in localisation.c. There's no point in having two open issues for the same bug, so yours was closed as a duplicate. The original issue remains open, so it's not that this bug will not be fixed, just that the developers already know about it.

The commit hash identifies the commit from which the game was built. It should be displayed in the bottom left corner of the screen when the game starts up, along with the version number and OS. An assertion is a condition that is assumed to always hold at a certain point in the code. It's checked at runtime, and if it is violated then the program immediately terminates. The assertion that was triggered here is just "false" which seems to indicate that this branch was assumed to be unreachable, or possibly that this case isn't implemented. I am not familiar enough with the codebase to know which.

Bugs should be reported on the Github issues page. Include your OS, commit hash, the assertion that failed and any errors that were logged to the terminal. What do you think it would be? It's the line on which the assertion failure occurred - specifically this one. Looks like an unhandled case in some string formatting code.

Yes, in exactly the same way you save a coaster - once the ride has tested there will be a save icon underneath the ride statistics page. You cannot save flat rides though (because that would be pointless - there's nothing to customize, they are all the same).

Open the cheat menu, select "Allow arbitrary ride type changes". Then open the console and type "rides list". Note the number of the ride you want to make invisible. Then type "rides set type 47". This will set the track type to crooked house track, which is invisible. If you want to make the track cross over itself, turn off clearance checks in the cheat menu. Be careful not to accidentally merge the track; using brakes at the crossing points can help prevent this.

Note you can also make track invisible by setting the track type to crooked house, and anything can be made invisible using the tile inspector.

OpenRCT2 should find any custom objects you installed for use with vanilla. However, objects saved by OpenRCT2 go in your OpenRCT2/object folder. If objects are not showing up in your object selection, check that the filter is not set to show only vanilla objects.

Wait, how did you implement changing support type? I thought the current save format didn't allow support type to be set independently of path type. Are you just hardcoding the names of different DAT files, and if so, how does it generalize to custom objects? Or does it automatically generate a new custom object every time the support type is changed?

Note you can have a track and make the track invisible with crooked house, but I also prefer to let them wander randomly. One reason you might not want to do that is if you find the guests aren't using the whole area of the pool or are sticking too close to the station. Then an invisible track gives you more control. You can make the invisible track very long and have it cross over itself repeatedly to disguise the pattern.

For scenery there is the RCT2 object editor, for paths there's Buggy's pathmaker, and for rides there's Buggy's ridemaker (be careful using this for tracked rides, it has a bug that makes them unexportable). There's also my ride generator, which is higher level and has more functionality but is also buggy, incomplete and only handles tracked rides.

The top hat and immelman are merged to LIM launched coaster track, and the final heartline roll is twister track. I hope to replace those pieces with actual track sections at some point, but for now, it's merged.

No command is implemented to show the current friction value. It would be a bit awkward because I took a shortcut with implementing the friction command - friction is actually set per-car, not per ride. So you'd have a different friction value for vehicle to show. You could cut that down by assuming all trains have the same friction value - it is a pretty safe assumption but it isn't necessarily the case. If you only want to reset to default, you can just double close and reopen the ride. If you want to know exactly what the default value was, easiest way is to take a look at the rides .DAT file. The only other command that acts on rides is "rides set type" for changing track and vehicle types. I implemented a command to change the speed and acceleration of powered rides, but it never got merged. If you want to know all the console commands, the best place to look is in console.c, since it's always up to date and there doesn't seem to be much documentation on this.

There are modified versions of some expansion objects that remove the expansion pack flag - this makes them exporting so that people without the expansion packs can open the park. That might be why it's showing as custom, especially if that object appears to be listed twice.

I have some (primarily coasters, a few water rides) here. There's also Amazing Earl's site, with a number of flat rides and some coasters. New Element has lots of objects but no easy way to search them. Sadly, it seems the best way to find custom objects is still to download parks that use it heavily.

Now that the game is fully implemented, I'm working on adding the missing track pieces required for the Intamin LSM train and other Intamin layouts. So far, all I've got is verticals, but it's a start (note, the vertical to steep piece is not implemented but the train hides it; the Twister track is acting as a stand in until I have an appropriate sprite):

If you upload the object I can have a look to see if all sprites are present in the file and laid out correctly, and that the animation indices aren't out of range or incorrect.

Recurious' work is of much better quality than anything I can produce. He draws them by hand, pixel by pixel. But I intend to develop the method I used to render the RMC track instead - it will not produce anywhere near as good a result (the output looks as bad as my rides because it's the same renderer), but once implemented it's much faster to generate the pieces, and with this method, once I've done the pieces for the giga track, it would be trivial to add them to another track style. The main things that need changing are: The original renderer was based on defining a profile for the tie and then extruding it along the track profile. Extending this to cover complex geometry like the Intamin track isn't easy - and I soon realized it was entirely pointless, as it would be better to treat the track profile as a non-linear transformation of a straight track piece. This method is actually easier to implement, and can trivially handle any track geometry. I had previously assumed that the sprites were split up according to the tiles they cover. This is not the case; I don't know how it's done but I suspect it's done in screen space. This is the major unknown, and will probably be the factor that determines whether this is at all successful. I expect Recurious will probably get his pieces implemented before I can get anything working, because he already has the sprites. I don't have a good track record of actually finishing projects like this.

I meant altogether new track pieces (like diagonal loops), not new sprites for those already in the game. That isn't to say that adding existing elements to more track types isn't a good idea - and now that almost all the track paint is implemented, we should be able to start doing that to a lot more rides. I'm planning to take a look at the giga coaster track - I'd really like to add inversions and verticals to it.

Right now, the game is still dependent on the vanilla code, which means we can't change the data structures used to represent the map, and are therefore subject to all the existing limits they impose. We cannot remove the limit on loaded objects, placed map elements, total rides, train count, station count, sprites, and many other things. We also can't implement new ride types or track pieces, or anything else that cannot be saved in the existing format. Dependence on the original code also means that the game can only run properly on x86. However, it's getting close to the point where the game will no longer include any vanilla code. At that point, it's a question of what we want to change, rather than what we can. Some things would require more work than others. The developers aim to remain compatible with save files from vanilla, which means that even if the save format changes there will be limits on how drastically it can differ - some hacks rely on the specific manner in which RCT2 handles map elements. Changing and adding sprites is already possible - the fast forward button and junior coaster steep-to-flat piece are sprites that were not present in vanilla. At this point, any change to the game that doesn't touch the save format can probably already be implemented.

Yup, absolutely. There are two ways to do it: Make the train one car shorter than it would otherwise be and then change the zero car subtype back to a normal car. You will also need to set the capacity back to 4 to get guests to board it. Make the zero car invisible. This has some difficulties; the Twister coaster does not have an invisible car type, which isn't itself a problem because you can use the invisible car from any other object you have loaded (most single car coasters have them). I'm not sure which of these I'd prefer - the main difference is that an invisible car would give you control over the spacing between the trains, but also, your train is one car longer than it appears to be which affects friction (you can adjust this though). Alterations to friction, capacity, and subtype may take place after the trains have been spawned and you may find that easier. If you want to change spacing, it is easiest to do it while the train is being created (i.e actually in vehicle_create_train). If you do it after that, it will have no effect. All of these hacks will be reset if you respawn the trains - I usually create a seperate branch with the modifications needed to perform this hack. Then, if I need to redo it later I can switch back easily.

Is SDL2 available for those platforms? If so, I can't see any theoretical reason it couldn't be ported, but until the vanilla code is fully implemented you would be missing some of the drawing code.

You're using the stable build. Stable builds are only released every few months, so 0.0.4 is really out of date now. Most servers use the develop build, and you need to be as well in order to connect to them.