Let's say we're wrong about this and it is indeed entirely random. That just makes us incorrect about something and then we will most likely change the rules.

However, you suggest that we are malicious and want to spite you and other runners because we got screwed over by bad RNG in the past and cannot control our emotions. You don't see how that is aggressive and offensive?

I'd like to point out Marcel is making guarantees while providing nothing to back them up.

I have looked into the OpenRCT2 code and while that's not the RCT1 code, I am quite confident that the two work in similar ways as that has been the case in the past. The game cycles through all the rides in a predetermined order (probably by ride ID) and updates the ratings. This might take a little while and is influenced by other things that need to calculated as well, so depending on where you are in the cycle the stats can get calculated quickly or it might take a while.

I did a test where I built the looping coaster Stingray both in an empty park and in an already built up park. I then saved the game right before the ride finished testing and then reloaded the saves several times to see how long it took before the EIN stats popped up.

It differed between the two save files as they were different parks, but within the same save file it always took the same time, even when restarting the game. This proves that in OpenRCT2 there is no randomness to it (although it can feel random), and that means that that is very likely the case for RCT1 as well.

Assuming this is indeed the case for how it works, it is incredibly hard to take advantage of this system, but not impossible.

The game works on tick system, so this "random interval" is just a part of the game and a part of the speedrun.

This is the most important thing. Almost all games work on a sort of tick system. In Super Mario Bros you can only save time on every level in intervals of 0.35 seconds, and in RCT1 the park value is recalculated only once ever 12.8 seconds.

I don't know how it exactly works, but I can guarantee that the stat calculation of the rides and the subsequent beating of the scenario works in a similar way. It is the speedrunner's job to learn the system and work around it.

I like this idea and I've had the same issue with big scenarios like extreme heights. Determining who's the fastest shouldn't be difficult, we can just use the completion date for that. There are two issues with this though.

The first is that there are a few scenarios where this results in the same time for everyone. An example is Sherwood Forest, where you can only complete the scenario at the end of each month because of the goal, so everyone will have the same result of 31 in-game days.

The second issue is the pause button. How do we want to treat it? You can save a lot of in-game time by pausing the game in between actions but it also takes forever for the game to progress if you use the pause function a lot. A speedrun scenario like Extreme Heights or Amity Airfield will take a very long time if you want to minimize the in-game time by pausing the game, which kind of takes the speed out of speedrun.

I agree. The RCT1 scenarios are the most famous so they might also be the most popular.

To make life easier I have an autoclicker that can click about 50 times a second which helps speed up certain tasks of the game. I also have a small script that helps me quickly build things. I would assume these are all not allowed, but I wanted to make sure anyway.