X7123M3-256

OpenRCT2 requires RCT2, not RCT1. You should point it at the directory which contains the rct2.exe executable and the subdirectories "Data" and "ObjData". The "Data" folder should contain the file "g1.dat" and several files of the form "css<number>.dat", and the ObjData folder should contain a large number of DAT files with names in all caps.

Oh, OK, I understand now. That's... really strange. I have no idea what 3DS max is doing there, but that is definitely the correct projection. I think the simplest way to set the correct scale is to make a single square, and then make it the size that you want a tile to be (which seems to be arbitrary, anything between 3 and 4 metres is a reasonable value). Then adjust the camera until the image is 64 by 31 pixels, as this is the size of the tile sprites in gam.

Yes, of course. Blender works the same way, even if the camera is orthographic it still has a 3D position. But with an orthographic projection, the distance doesn't matter, so you can just choose whatever value is convenient. Your projection does look correct, so I'm not sure why you're finding that the distance matters - are you sure you're not using a perspective projection with a long focal length? An orthographic camera does not have an FOV (or perhaps another way to think of it is, an orthographic projection is a limiting case of a perspective projection as the FOV angle tends to zero). If you use a perspective projection, the field of view looks like a pyramid, and the FOV angle is the angle that the sides make with with each other. With an orthographic camera, those sides are parallel. Here's a picture I found that illustrates this:

These appear to be two screenshots taken at different zoom levels. That is not moving the camera, it's rescaling the sprites, so it shouldn't be surprising that it changes the size of the sprites. In fact, RCT2's "camera" only stores two coordinates, so there's no way to change it's z coordinate, it doesn't even have one (since it would do nothing). If the game was using a perspective projection, then placing two pieces of scenery, one towards the back of the visible area and one at the front, would result in two different images because one is further from the camera. Now, if the projection you're using is not the correct one then it's close enough that I can't tell the difference, so if you are using a perspective projection it must have a very long focal length. It looks to me like your camera is set up correctly, but if you are finding that the distance matters then it definitely isn't. This property of an orthographic projection is the reason you can't look inside a building, and why you can get confusion where two roof pieces appear to connect but are actually in completely different places. A game like this would not work with a perspective projection - similar games with a perspective projection are all rendered in real time. Sorry, I think I might have confused you a bit - you have to render the background of the sign, the scrolling text is what gets inserted automatically.

The distance of the camera from the object should not have any effect on the scale of the image. If the position of the camera has any effect besides translating the image, then your projection is wrong - only the orientation is important. If the object looks smaller when the camera is further away, that's a perspective projection. Large scenery is a seperate object type. (I've never used the object editor so I really don't know if it's supported, but if the option doesn't seem to be there, it's possible that it isn't. I expect someone else will know one way or another). Entrances are another object type. The only thing you need to bear in mind when making multi-tile objects is that each sprite can only occupy one tile; you will need to split your sprites up. This can be done by splitting up the model and rendering three images.

With an orthographic projection only the angle matters. An orthographic projection is equivalent to transforming the scene into camera space then dropping the z coordinate. It doesn't matter what the z coordinate was because you discard it. If you find that moving the camera further away changes the image, your projection is not orthographic. This is the reason the game uses an orthographic projection in the first place - if it had perspective projection, you would need a different sprite for every possible object position. No, that text is added by the game, you don't need to render it.

I know nothing of 3DS Max, but are you sure those settings are for the camera and not the viewport? If those settings are for the camera, why do you have "top" selected? Wouldn't that position the camera to look down the vertical axis? A dimetric projection is an orthographic projection where 2 coordinate axes are equally foreshortened. I gave you the angles to use, if you have the camera set up like that (which it looks like you do) then your projection must not be orthographic. Try rendering a cube - that will make it immediately apparent if your projection is orthographic or not. It's the model that needs to be made taller, nothing to do with the projection. If you change the scale you'll make it taller, but you'll also make it wider and it's pretty much the right width already.

Are you sure you're using an orthographic camera? In your image, the entrance doesn't line up with the tiles properly (look closely at the bottom corners). An incorrect scale would not cause this, either your view angle is wrong or you are using a perspective projection. The easiest way to test that would be to render a wireframe cube - if the projection is orthographic, all lines that are parallel in 3D space are parallel in the image. You're forgetting that RCT2 uses a dimetric projection, not isometric. If you are going by the height marks on the terrain, then size of a tile should be 1.5√ 6m≈3.674m . However, do note that RCT2 doesn't use consistent units throughout, so you are to some extent free to choose a scale. I use the height marks and stick to that; I do not trust anything from the ride stats window as they disagree not just with the measurements used elsewhere in the game, but with each other. Changing units should not change the ouput at all as long as you use the correct conversion between them, and even if you get that wrong it cannot be the cause of the misalignment, because this would just make the image larger or smaller, not change angles. Internally, RCT2 does not use metric or imperial - horizontal distances are measured in fractions of a tile and vertical distances are measured in fractions of a clearance. I sometimes find it useful to work in these units (because it scales out all the irrational numbers from the projection), but I mostly use SI units. You can set the game to use SI in the options (I think this was an OpenRCT2 addition).

For the camera angle, it should be angled 30 degrees down and then rotated 45 degrees about the vertical axis. If it is correct, horizontal lines should have a 2:1 gradient on screen.

It'd need some pretty hefty supports to stand up in a flood. Moving water is extremely powerful, and even if the structure holds up, the foundations can be rapidly eroded away.

Have you tried changing the settings back?

You can hack the speed faster. I had implemented a console command for it but it never got merged.

1) I don't believe so, but what documentation exists is on Github 2) Max platforms per ride is 4 3)As many as will fit in the shortest platform, but never less than the minimum specified in the DAT, and not so many that the friction would be reduced below a set threshold. The absolute max is 255.

I'd say a queue line should be long enough to fill two trains. A queue line that can't accomodate a full train of passengers will lead to the ride running under capacity, and you want it a bit longer to absorb variations in the rate at which guests arrive. But anything longer than that is pointless - once you have the ride running at full capacity, all a longer queue is going to do is make guests complain. Of course this goes mostly for scenario mode - in a sandbox park you would generally build whatever would be a typical length for that queue IRL.

Fresh doesn't mean still, it means it's not salty. Lakes are usually freshwater, because they are continuously replenished by rainfall, but this isn't always the case. Some lakes have no outflow, so they lose water primarily by evaporation. Dissolved salts do not evaporate so they become concentrated in the lake.

That's interesting. How does this look on more realistic terrain (fractal noise for example)?

Interesting, how did you approach the problem of choosing the best slope for the tile? I took the approach of minimizing the squared differences between the corner points of the tile and the heightmap. Results were generally good on smooth terrain, but on rougher maps there'd be a few tiles with a poor choice of slope, because my algorithm treats each tile independently.

Actually, I made a slight mistake - although water only has 5 bits of precision, each unit stands for two clearances, so the total range of the water is 62 clearances, or 1/4 that of the land. Max land height is 255 clearances, but land heights should be even so that's 254 clearances, which is 180m or 600ft. The highest the game will let me raise the water is 56 clearances, but in principle the limit should be 62 so a small increase is possible, but you're never going to be able to raise the water nearly as high as you can raise the land. The reason why the land height could be increased is because the game artificially limited it to less than what is actually supported (and still does - the cap was increased, but for some reason not removed. It currently stands at 106.5m or 320ft). Land heights could therefore be increased much further than they are now, but water heights are almost as high as they can possibly be without a new save format.

The code you're looking for is here. Water only has 5 bits of precision, so it does not have the same range as the base height (which is a byte). Therefore, the water height is limited to about 1/8th of the max land height.

It was recently pointed out to me (by @Broxzier) that it is now possible to create disconnected entrances entirely within OpenRCT2. I'm sure most of you were already aware of this (or saw it in the other thread), but it was useful to me, so I thought I'd put together this guide in case anyone else hasn't been paying attention to the new capabilities of the tile inspector. The goal is to move the entrance and exit from their current locations to the purple and yellow tiles: The first step is to select the existing entrance, and copy it: Then select the destination tile, and click on paste: If the station platform is on a different level to the path, then adjust the base height until they line up. When the entrance and station platform are on different levels like this, the level that the guests will walk on is that of the entrance, not the platform. This works out well for this skycoaster, and also for the SCAD tower nearby, whose loading platform is at the bottom of the drop, but guests board at the top because that's where the entrance is placed. Without this behaviour that ride would have needed a shoestring. Then repeat the process for the exit. Now build a queue line in front of the original entrance, and copy the path tiles tothe new location (again, the base height may need adjusting). This is required because paths do not connect properly to the new entrance (I'm not sure exactly why). The tile inspector doesn't let you edit the path's associated ride directly, but you can connect a suitable path to the old entrance and then copy and paste it, so that's what I'll do here. It's not necessary to copy each tile individually - if you have a long run of straight path you can just copy one tile and then paste it multiple times. Do not, however, edit queue tiles connected to the new entrance with the path tool - this will disassociate the queue from the ride. If this happens, delete the affected path and try again. Now you can delete the original entrances: The last step is to make sure the queue is connected. Because it was placed using the tile inspector, it won't connect automatically, so check the final queue tile and the path tile it joins onto, and connect them if they aren't already. This is done by checking the boxes corresponding to the sides on which there should be a connection (again, don't use the path tool to do this). Now open the ride and ensure guests can board. If they don't, check the sign on the queue line - if it is not present or does not display the ride name, something has gone wrong. If the sign is there but guests don't seem to be boarding, the paths may still be disconnected. You can now proceed to make the rest of the ride invisible: This hack took most of the day to set up when I made this park originally, so I think it's great that it can be done with the tile inspector alone now. I'm sure most people will have noticed this already, but maybe this will save someone the effort of doing this the long way round.

Just tested it, it works perfectly. I forgot there was a copy and paste feature now. Only thing I'd add is that you have to copy the queue tiles as well, as they are also associated to the ride and if you build new queue with the path tool it does not register as connected to the entrance. Otherwise, it works exactly as the method given above does but is an awful lot quicker, so the post I made above is obsolete. You don't even need to build a dummy platform with this method.

The approach that was originally suggested to me by otsdarva was: First build your layout. Build the station platform but no entrance or exit Then build a new ride with the station postioned where you want, and merge it onto the layout When the train reaches the station platform of the other ride, it will stop there as normal, but the passengers will be accepted from it's own station. However, because it is not on it's own track, block sections will not work. You may delete the additional track, but do this in the tile inspector, otherwise the entrance/exit buildings are removed as well. You may choose instead to just make it invisible, because if you ever have occasion to close the ride you will need it again. The approach I took: Build the layout. This time, it has to be completed and opened, so you'll have to place entrances adjacent to the station to do that, but you can then delete them Build a new ride with the station positioned where you want. This is only needed to get the entrance/exit buildings on the map and you can delete it as soon as that's done (I was unable to place an entrance/exit on the map without doing this, even using hacks, because the game automatically deletes entrances that are not adjacent to the station platform). Now you need to change the ride IDs so that the entrance/exit buildings you built belong to the actual ride and not the dummy station platform. To do this, I made note of the X/Y coordinates of the target elements in the tile inspector, and wrote a script to make the changes (the best place to put this is in /src/interface/console.c, so you can run it from the in game console). You will also need to update the queue paths with the new ride in a similar way. If done correctly the ride should now function with the moved entrances. If done incorrectly you may get weird bugs - at one point, the SCAD tower could fit 50 people in it's single tile queue (I don't remember if I ever fixed that). If you only want them at a different elevation, maybe - I didn't try that. If you want them on a totally different tile I don't think you can, but I'd like to be proven wrong, as the approach I took is rather fiddly.

It definitely works in RCT2, I just tested it to be sure. I cannot test in RCT1 because I don't have it, but given the way the game works I think it's highly likely it works the same way. The game checks for a complete circuit by iterating forward from the station until it reaches the point it started at. If it does, the circuit is complete. If there is a totally disconnected track section the game will never see it so it doesn't count.

Operating mode is irrelevant and this doesn't affect blocking; as long as the main track is a complete circuit you can have as many extraneous track pieces as you want.

It definitely can work. It was done several times in my park "Gravity Gorge". Both the SCAD tower and skycoaster have entrance huts disconnected from the station and on a different level. It was done on the skycoaster because I wanted guests to wait outside the ride area and then walk to the loading platform when it's their turn to ride. The station platform is elevated (so guests don't hit the ground when swinging) but the entrance is built at ground level at the edge of the ride. Peeps walk from their to the spot directly underneath the train, then board the train. The SCAD tower does a similar thing because the entrance platform is actually at the bottom. This was because I needed the guests to board the ride on a vertical track section, but I really did not want to use a shoestring because they are a pain to make work. Instead I added an invisible leading car, and put it far enough ahead that the visible car is sitting at the top of the tower while the other is at the bottom. This also allowed me to have the guests brake on a vertical section of track - the actual brakes are level, but the invisible car hits them before the visible part of the train is off the drop. Here's a picture of the park with corrupt elements removed so you can see where the entrance/exits sit in relation to the station platforms: This could not be done in the tile inspector alone, and for the same reason OP stated - paths would not connect with the moved entrances (I still don't know why this is). My solution was to edit the path elements to make them connect (this still can't be done in the tile inspector even after the additional functionality was added). There is actually an easier way to get disconnected entrances - introduced to me by otsdarva - that can be done with ZC and corrupt elements alone. However, it will not work in block sectioned mode and ended up mucking with the functionality of the skycoaster, so these were both done the awkward and hacky way.