Jump to content

X7123M3-256

Members
  • Posts

    1081
  • Joined

  • Last visited

Everything posted by X7123M3-256

  1. 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.
  2. He might be referring to Shockwave, the near clone at SFGA
  3. This seems entirely redundant now there's the "Allow construction while paused" cheat.
  4. If you want to kill guests without the rating hit, put the exit underground and don't build a path leading from it.
  5. 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.
  6. 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).
  7. This is impossible without a new file format
  8. 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.
  9. 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).
  10. 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.
  11. 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?
  12. 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.
  13. 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.
  14. This sounds like a buffer overrun to me. Not sure what might be causing it though.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
×
×
  • Create New...