X7123M3-256

Chain lifts are not a seperate track piece, they are a property that a track piece can have. Therefore you can hack a chain lift onto any track piece. I think it's highly unlikely there is no chain lift set on that track; rafts are powered but they are painfully slow on verticals, as they weren't designed for that. To make this work with an unpowered ride like a coaster you need a chainlift, there's no alternative. Normally the tile inspector will tell you if the selected track piece has a lift, but you seem to be using an old version that doesn't. If this is indeed the case, you will probably want to update, there are lots of useful features in the new one. No idea what you mean by "replace tiles". But you can force a chain lift, yes. If you have a recent version you can also do it through the tile inspector.

As Broxzier said, this is almost certainly invisible vertical track. I can't think of any other way something like this would be done. Raft cars don't have sprites for verticals so they appear flat on the vertical track. Rollercoasters need lift hills. Did you enable chain lift on the vertical track?

The game (like vanilla) supports up to two custom music files, which should be saved in .WAV format, and saved in your RCT2 data folder as CUSTOM1.wav and CUSTOM2.wav. I don't think OpenRCT2 extends this functionality beyond what was present in RCT2, but I don't see why you couldn't do that if you wanted. If you want music files to be custom objects, that would require a new object file format.

Yeah, I can't see this ever being feasible, even with a new file format, unless support for importing parks from vanilla RCT2 is dropped.

This sounds like a buffer overrun to me. Not sure what might be causing it though.

The main advantage is that you can do it one section. You can approximate a circle arbitrarily closely with cubic splines but you'll need more than one - a single cubic spline can't get anywhere close to a circle. I'd only use it if support is built in, because they are harder to implement (not that I've ever had to do it). Rendering with reflections and shadows enabled really bothers me, but these are things a replacement graphics set could fix.

The way I see it, there are a number of reasons: Replacement assets would make OpenRCT2 a standalone game. Since OpenRCT2 does not distribute the assets it requires, you have to have RCT2. The demo works but it doesn't contain all object files so it will be unlikely to work with parks others have made. We don't have access to the original models, which presents a consistency problem. It's extremely difficult to make custom content that keeps the visual style of the original assets, and as the game expands, we're going to need more and more custom sprites. If we want 32bpp graphics or extra zoom levels, we have to replace the assets (and both of these have been requested in the past). Replacing the assets used by the expansions could make them not shit. I was unaware of this feature. It does essentially the same thing as my track rendering script does. However, not all the track pieces are Bezier curves; in particular, many curved pieces are circular. You can approximate them pretty well though, and I think Blender might have support for NURBs, which can represent circles exactly. No matter what size the model is it won't fit all track sections exactly, because many of the ratios are irrational. The way I handle this is to calculate how many track sections will fit, and then scale the model to absorb the leftover. It seems to work out well in practice - and I'm pretty sure a similar approach must have been taken for the original sprites.

That's not my repository, it was set up by someone else. It does provide a toolchain you can use to render sprites though. I'm not sure how it handles x/y offsets - those are difficult because standard image formats don't support them, which is one reason why I wrote my own rendering code (and the other is remap colors, something most rendering tools don't support). The problem with my approach is that the quality of the output is not up to par, and if I can't improve it I'll likely have to give up with any attempt to replace the base sprites, or perhaps delegate the rendering to a more sophisticated renderer (but it would need to be something command-driven - maybe POV-Ray?). Another issue is consistency - we'll probably need more than one person to work on it, and we want those sprites to have a consistent look, so having everyone using a different toolchain isn't desirable from that perspective either. However, I can see track sections especially being very tedious to do without automation (perhaps it would be better implemented as a Blender plugin, but I have no experience with that). I think, if we want to do this, we should first find out who is interested, and then create a single repository for the effort. We should put together a list of what needs replacing (I'd start with the sprites in g1.dat, because that's the bare minimum to run the game), and what models are needed to do that. We should agree on a single toolchain for rendering, and work to make it as straightforward to set up as possible. It would be nice to have a repo full of models, and then a shell script you can run to generate g1.dat. Then as soon as you've made a model, you could see it in game. I might look into getting something like that set up, if I have time and if anyone is actually interested.

It'd be nice to have the game not dependent on vanilla assets, but I think the primary reason to do this is that trying to make custom sprites match the existing ones is really difficult - sometimes, I feel like a total replacement of everything might actually be easier in the long run. It would be a lot of work to replace them all, but once done, we could add new ones easily.

Not always. I've not yet worked out exactly when it works and when it doesn't, but it definitely doesn't always work, and sometimes it works but only from one camera angle. Steep slopes are particularly awkward - the distance between the place you'd like to put the support and the base height for the sprite is so great that it almost always draws the support first, no matter what you do. I just avoid placing supports there.

This issue arises because you turned zero clearance on. The reason why the game has clearance checks and a grid in the first place is to exclude configurations where it cannot determine in which order to draw the sprites. RCT2 is a 2D game with no depth buffer. All the game knows about the 3D shape of an object is it's bounding box, and even if the bounding boxes do not overlap (which they do, if you had to disable clearance checks to place it there), you can have a configuration where it is impossible to get correct occlusion: RCT2 gets around this problem by splitting any object larger than a tile into tile sized pieces, so the above situation does not occur (you would have 6 cubes instead of 3 cuboids, and then you can draw them correctly). However, if you disable clearance checks then the cubes may overlap, and then it cannot be relied upon to get occlusion correct. The game knows nothing of the shape of the object, only the tiles it occupies, and the vertical space it occupies within those tiles. Sometimes, you can influence the draw order by rearranging map elements in the tile inspector (I believe that would probably work here). If you can't, your only recourse is to move the support to somewhere where it does not glitch. There is no way to fix this without introducing a depth buffer, which would require replacing every sprite in the game.

My understanding of game networking is gleaned entirely from this website, so I could be wrong, but I believe this would be difficult to implement. The way multiplayer works in OpenRCT2 is, all clients send the server their inputs, then once all inputs have been recieved, all clients advance the game state simultaneously. The complete game state is not transmitted to clients except when they first join the game, so if they get out of sync, they remain out of sync unless the client leaves and rejoins. Implementing client side prediction means the clients will get out of sync with the server. If two people tried to build on the same tile, for example, the local action would succeed before the one from the remote player, so each player would think they were first and end up with a different object on that tile. Therefore, the server must be able to transmit corrections to clients to resynchronize them. The complete game state for OpenRCT2 is quite large, so transmitting the entire thing several times a second would presumably use too much bandwidth. You could save bandwidth by only transmitting the differences between the current state and the last update received from the server, but this requires the server and client to keep track of the last state the client has recieved. Given the number of global variables currently permeating the codebase, I think it would be very difficult to implement this reliably - there are problems with desynchronization already with the existing networking code.

No, I would not like more options unless there are more scenery groups to go with them. As it is, many of the existing entrances are difficult to use because there isn't enough scenery to go with them (e.g the space and jungle entrances). I would, however, like to see the existing plain entrance redone. It looks awful, so I use the invisible entrance almost exclusively. A simple gate like in RCT3 would be better.

Looks like lrflew has taken a look at the file format. It is apparently an extension of the format used with RCT2. I don't know exactly what was added.

Are you sure? Someone on Reddit said the opposite.

Has anyone looked at the save files yet? Someone said it can import SV6 files, but is that what it writes?

That's what the advertise button does. It makes it show on the master server list.

Check the box marked "Advertise" when you start the server

It's mentioned at the start of this video.

I find Blender is good for modelling.

No brake run on the coaster (though a ride of this size may well not have one, any larger coaster should) Two lift hills is too many for a coaster of that size (possible exception is if you have one lift hill immediately before the station and one after, but this would be more typical of a terrain layout) Plain entrance and exit buildings aren't great. I suggest setting the entrance type to "invisible" and building your own loading platform with scenery. No scenery or foliage in the ride area - it looks plain with no additional detail (though I suck at this as well, I usually just add custom supports and a few weeds and call it a day). Vertical landslopes left exposed. Dirt can't stand vertical - either add walls or use a different land type. Flat ride built elevated for no good reason. Real parks aren't going to waste money on all that additional support structure just to build a path underneath the ride. Your food court has no windows, and is missing a section of wall. Your brick walls end abruptly and for no apparent reason.

Well, I think I'm going to have to give up with this for now. The default shading defies all reason and mine is never going to match. All I can hope to do is create entirely new tracks, but as that's not supported yet I see little point in pursuing this further until there is a new file format.

It can't be removed until a new file format is introduced

Some more incremental improvements - anti-aliasing was a big improvement (though it had the side effect of making my renderer painfully slow). Specular shading is not so promising. Adjustments to the geometry seem to have fixed most of the misalignment and glitching (though I've just noticed one of the track pieces is backwards). The lighting is still proving difficult - I can get it to look almost perfect from one angle but then it's completely wrong from the others.

It's "Guests ignore intensities" in the peep section of the cheat window.