X7123M3-256

Change the window scale factor (in the options) to something bigger than one.

Even with a new file format, the existing coaster trains do not have sprites for this.

Booster tracks are implemented now. Right now, there are no sprites for them, but @YoloSweggLord is working on that.

You don't need to port forward in order to play, only to host. Two points need making: firstly, port forwarding is not something the OpenRCT2 dev team have any control over. It has to do with internet architecture, and specifically, the fact that most home networks use network address translation, which assigns every device on your network it's own private IP. The router does not know which machine to direct incoming requests to unless you tell it, and that's what port forwarding does. You do not need to port forward if you are connected over LAN, only if you want to be accessible to players on the wider internet. Why do we use NAT so widely? Because the IPV4 address space is all but exhausted and there simply aren't enough of them to give every device a globally unique IP. It's successor, IPV6, has a lot more addresses, but adoption has been slow (I guess if you're using IPV6 then you don't need to port forward? Someone with better networking knowledge than me please tell me if that's true) That said, there exists a technique called hole punching, which can be used to establish a direct connection without the need to port forward. My understanding is that both servers first make outbound connections to a third server, which then relays details of the connection back to the clients so that they can connect directly to each other through the NAT. I have no idea if it is a viable option for OpenRCT2, but I think there are other games using a method similar to this, so maybe someone who works on the networking code could comment. Secondly, I'm not sure if this would improve security. My understanding is that simply port forwarding is not a security risk, it's having something listening on that port that is - because that server may have exploitable vulnerabilities (and there is no reason to believe OpenRCT2 is any exception). But, if you want to act as a server, you have to allow people to connect somehow, because that's what a server does. There may be other concerns that I'm not aware of, but you should be aware that the only totally secure machine is one not connected to the internet.

Adding "egyptian god" to the query gives more relevant results.

Because the old branch was forked from a really old version and wouldn't merge cleanly with develop. The guy who originally submitted the PR had stopped developement, and it wasn't (and isn't) ready to be turned on by default. Why it's a compile time switch and not a config option I don't know, but presumably @IntelOrca does (maybe it wasn't easily done or they don't want it in the binaries they distribute?). My understanding is that the plan is to eventually fix the issues with it and then remove the ifdef. This is the PR that merged the light effects

It's not in the config file, it's a compile time switch. You need to define __ENABLE_LIGHTFX__ when you compile the game, and then in the options window make sure you have "Drawing Engine" set to "Software (hardware display)", and the day/night cycle enabled. I've found that that sometimes it doesn't seem to work properly and not all the lights come on - I've been trying to trace the cause of that issue because I never had the problem before it was merged.

It's in develop now, so you don't need to use that old branch anymore. It's a bit temperamental (sometimes path lamps fail to illuminate and I'm not sure why) and it still has the same issues it did before (performance, lights showing through the GUI), which is why it isn't turned on by default, but it more or less works and is still worth having IMO, particularly for viewing finished parks (it's a pain when building, but it turns off if you disable day/night cycle which you can do from the options).

This is already implemented, it's just not enabled by default.

You put that as your worst coaster? That's one my favorites. Plenty of sharp drops and airtime, and it's unusual too - not many wooden wild mice left around. Also has a unique layout, and not the standard one that all the others seem to have. I would have to list the (now defunct) Corkscrew at Alton Towers as the worst coaster I've been on. Absolutely awful, a headache from start to end. It was the first looping coaster I ever rode, and I rode it again a few years later to see if it was as bad as I remembered, and it was worse. The SLC I rode was comfortable by comparison. I don't miss it.

Is it a scenario from the base game or one of the expansions? If so, it does have a text object, so make sure that's unloaded first. If not, then maybe upload the scenario here so we can have a look. The text object is the only thing I can think of that would prevent you changing the scenario name, so if it's definitely not loaded, then perhaps it's the result of a bug or corrupted file?

For the tables thing, I think that could be implemented as an additional path object type, like bins and benches.

I'll add a few (mostly related to the object files rather than savegames): Track: * Track sprites could also go in object files (and so should terrain). Like coasters, it would make sense to divide the track sprites up into groups, and allow some or all to be provided. I don't think there's any easy way to avoid hardcoding the set of available track pieces, but we should leave plenty of room for more to be added in future. * Brakes could be added as a flag instead of a seperate track piece, so they can be set on any track piece. Rides: * Flat rides could be a distinct object type from tracked rides and their animation sequence should go in the object file, similar to animated scenery items. The base size could also be adjustable. * All flat ride sprites in g1.dat could be moved into object files (as it is I don't know why they're there) * Swimming pools and water rides. Of all of them this is very ambitious, I think it would be the hardest to support not least because of the number of new sprites required. Would be really cool if it were done though. You've got Exactly. Though it should be pointed out that boosters were added via an awful hack, and are also next to useless because they're so weak (apparently this is for RCT1 compatibility). So better boosters (and additional track pieces in general) is something I'd like to see support for.

In OpenRCT2 (but not in vanilla), scenario text objects appear in the object selection dialog, so you can load/unload them there the same way you load any other object. I don't think most people bother with these in custom scenarios, so it's only really if your scenario is based on a default one that you need to do this.

That response has been given so often now, I think we need a list of all the stuff this new file format is going to have to do.

Do you have a scenario text object loaded? Those override the scenario name and description and you won't be able to change it in the scenario editor unless you unload it.

He might be referring to Shockwave, the near clone at SFGA

RCT2 did not have those, that was an 8Cars feature.

This seems entirely redundant now there's the "Allow construction while paused" cheat.

If you want to kill guests without the rating hit, put the exit underground and don't build a path leading from it.

Because lifts are not a seperate track piece - there is a flag that marks a piece as a lift. It has always been possible to make any piece a lift in RCT2. There is no such flag for brakes, you would either need to introduce one (which means changing the file format), or add additional brake pieces. I asked @Gymnasiast whether we could do the latter, and he said that while it would be possible to do through a similar hack to the one used for boosters, that is too hacky, and they will wait until a new file format is introduced to do this.

They were created with vanilla RCT2, which has been around more than a decade (and sometimes RCT1, which has existed even longer). There are posts on NE more than a decade old, I wouldn't be surprised if it is as old as the game itself. No. OpenRCT2 is a relatively new thing for NE. (and 2014 isn't quite four years ago yet) Same places they get it now (and others that have since gone offline). There are new objects being made all the time, but the bulk of those in widespread use predate OpenRCT2. OpenRCT2 also hasn't done anything to make custom content more flexible or easier to create so I'm not sure why this should be surprising. There are workbenches with a selection of scenery preselected. Then you can just add in objects as you need them (this was done with ParkDat before OpenRCT2 existed). Most of the scenery they use is custom; expansion pack objects are pretty awful and rarely seen in parks on NE (but for some reason, they're all over the multiplayer servers).

This is impossible without a new file format

I am not aware of any cheat that prevents rides automatically closing after a crash. There is "no test crashes" which automatically resets a ride if it would otherwise crash, but I think it only works in test mode. You can reopen a crashed ride immediately after a crash. However, very few guests will ride a ride that has recently crashed. You can override this behaviour with the "Reset crash status" cheat.

The chain lift cheat was implemented in June, so if you don't have it you're on a really old version (if it's because you're using stable, there was a new stable release quite recently, you should update).