Custom Scenery Exchange / Custom Rides by X7123M3-256

Man I'm no perfectionist that sounds like a lot of work. 

I'm wondering what parts of the train are colorable?

If you look at the screenshot of the model I posted on the last page, anything in green,magenta, or yellow is recolorable.

I've just finished adding support for setting sound effects through the GUI. I now need to add support for choosing the default color schemes - then it will finally be possible to create a finished ride without touching the source code.

That sounds awesome!

Will you do a video-tutorial how to work with the program when finished? That'd be great for future ride designers!

"MFG"

I was thinking of more of a written tutorial rather than a video, though I could look into doing a video if that would be preferred. I'm thinking of splitting off the background information that applies to any custom rides, and the stuff that's specific to my program into seperate tutorials - especially as there's quite a lot of information that's useful to know but not strictly required.

At the moment I'm trying to get the editor to the point where you don't need to edit the source code to finish a ride - but this is taking some time. The final task is an editor for the default color schemes. This takes a couple minutes to change in the source, but doing it through the GUI will require a whole new dialog. It is probably the last major feature I add before releasing the tool - but I have a lot of bug fixes to do as well.

I can see a day where Designs will require custom made trains...  what a time to be playing RCT.

These trains still take a rather long time to model, and for most trains you don't really get much benefit from redoing it for each design. The wing coaster is the only one I've done so far that typically features custom trains. There is also the choice of color scheme, but I've found that RCT needs some black in the color scheme, even if the real ride doesn't, in order to look any good, so matching the real color scheme isn't always the best idea.

I'm thinking of uploading my Blender and JSON files once I've released the tool, in case anyone wants to customize them. However, the first version of the tool won't have the ability to remove/replace models from an existing JSON file - that might be added in future but it's hard to do with my current architecture, and editing JSON manually isn't that hard

Could somebody who doesn't use OpenRCT2 please try opening this park and tell me if you're getting draw order glitches when the train is on the lift and coming toward the camera, like this (the glitches are more easily seen in game than in the screenshot).

I don't think these glitches are specific to OpenRCT2 (I don't think they've altered this part of the code yet), but I'm sure that I'm seeing more of them than I did when I still used the original game, and I've observed the same glitch occuring on the default Vertical Drop Coaster cars; I'm sure I would have noticed if this was happening in the default game as well,  but I can't get the original game to run under Wine anymore, so I can't test it.

I can remove these glitches by adjusting the z-index, but at the cost of introducing some others. These glitches appear to be specific to this camera angle, while the other glitches are less severe but occur more frequently. If this turns out to be a bug in OpenRCT2 I'll leave it as it is, whereas if it isn't, I'll take the other glitches over these.

OK, I'll revert back to the old z-index value then. Honestly, I don't really know why you can even change it, any value other than 8 seems to make the situation worse.. It's a bit annoying that I can't have it not glitch at all - the Z index has to be increased else bits of track end up drawn before the trains, but then it doesn't seem able to get the draw order of the trains right. I think the width of the trains is the root cause here - the game doesn't seem to like wide trains, even the default VDC trains suffer this same error.

Nonetheless, the other glitches aren't as bad as this is so I'll revert the value. I didn't think this glitch was likely to be an OpenRCT2 specific thing, but I wanted to check since it's clear to me that the z-index should really be higher here.

Thanks for checking, though.

Well, I'd hoped to get this wing coaster finished today, but I've run into a major roadblock. I want the front car to pivot about the wheel assemblies - anything else looks awkward. Unfortunately, the spacing is based on the pivot point of the car, which means that if I want to maiintain a decent spacing between subsequent trains, I'm forced to move the pivot point almost ahead of the bumpers - which looks stupid. What also looks stupid is two trains overlapping because there's not enough spacing between them.

Neither is acceptable as far as I'm concerned. This problem was solved on the dive machine with the addition of an invisible "dummy" car at the back of the ride. That worked well there because the dive machine only has to handle 2 and 3 car trains, but on the wing coaster, that dummy car would have to go at the front, because the rear car slot is already used for, well, the rear car (on the dive machine, the rear car is actually the default car and the rear car is the dummy, then the middle car is the second car and the first car remains the front car).

The problem with putting this dummy at the front is that then the trains don't line up like they should with the front of the station. To make the whole thing even more irritating, you only see the problem if you're not running in block section mode, which I always am, so it doesn't even effect me but I don't want to release the ride with such a severe issue in place.

Another option might be to distribute the extra spacing between the front and rear cars - making both slightly off but neither too bad. Given the amount of extra spacing required though it's not a great solution. I've had a look through the default rides to see if there's anything that might suffer this problem, and there's a couple but none that would be severely affected.

If I don't find a solution, I'll add the dummy at the front, but make it just large enough so the bumpers of the trains are touching, so they don't overlap (which is unacceptable) but are still closer than they really should be. It's not like a real coaster would ever run without a block section either though, so I suppose this isn't too bad. I do hate compromising the general case for the sake of an awkward edge case, but there may be no better way around it.

The B&M wing coaster is now finished. The download link is here. This one has taken longer than expected, but it's finally ready.

There are minor glitches on the lift hill (and other straight, gentle hills) that I can't fix. I also ended up having to add the dummy car in the end so the trains sit slightly further back from the front of the station than would be ideal. Setting the friction values was awkward, I ended up making three crappy recreations of rides, and trying to simultaneously get decent performance on all of them. Without exact figures for heights of elements, this is hard to do well, but I feel the result is reasonable.

The excitement rating may be too high - I felt it should be slightly higher than a floorless coaster, but it seems to be a bit too easy to get 8+ excitement with a short ride. If anyone has an opinion on this, I'd like to hear it.

This is the first ride made with the new animation system and the first to use an altered checksum by default. It's also the first ride for which the JSON save file contains 100% of the information required to reproduce the ride. These things don't affect the end product much, but they make things much easier on my end.

Just downloaded and tested it on my X Flight recreation. For some unknown reason, it has no sound other than the chain lift, the train is silent through the rest of the ride. Also, I don't know if this is intentional or not, but the trains run way slower. My X Flight vallied at a location where the trains I had been using cleared at 17mph.

Shit - I tested the sound, considered it done, and then noticed the silent trains and forgot to go back and fix it. Is your X flight recreation built to the same proportions as the real ride? In my tests, X Flight ran too fast, Gatekeeper ran about right, and Thunderbird was too slow and I had to up the launch speed to make it clear the loop - even with the friction absurdly low. However, my recreations were all built in 5 minutes using whatever dimensions I could pull from Wikipedia and RCDB. If you've got a more accurate recreation (that is to scale) and it's valleying, I'll need to tweak the friction. The values are intentionally lower than what the default game uses, but I found on the dive machine that those values can't be trusted to be accurate - the game's default dive machine runs way too fast when given a layout in the same proportions as Sheikra or Griffon.

I need to fix the sound, but it's nearly midnight - what I'll do is take the download link down and fix it tomorrow.

I know my lift hill is 100ft compared to the real 120ft. I'll have to check and see if the rest of the ride (particularly the Immelmann) is scaled properly.

EDIT: My Immelmann (location of the valleyed train) isn't quite properly scaled based on the lift height. I think if I redo it, the train should run properly, but I won't have time to actually do it until tomorrow.

EDIT 2: Just did a really quick rebuild of the Immelmann. Train clears it fine.

OK. I'm working on fixing the sound now, will have a new download up soon.

Sound is fixed, the download link is back up.

It turns out that despite the fact that sound effects are set on a per-car basis, only the first car has any effect. In this case, the first car was a dummy that I'm using to correct the spacing between trains. I didn't want to it to have any other effect, so I set the sound to silent. I have now corrected this.

I've not adjusted the friction values because I'm not convinced they're wrong, but if anyone else is having problems with recreations or other realistically-sized layouts, it's not too late to alter those values.

A quick question about the friction values. I always thought the wooden rollercoasters in the game weren't really a good reflection of the reality, as they seem to lose too much speed. Have you any thoughts on this?

I'm not sure. I've never had major problems with most of the default rides (except the vertical drop coaster which is far too efficient - when I did my version I dropped the value from 2000 to 600), but friction values can vary quite substantially before the issue becomes immediately apparent - and extra 20mph at the end of the ride doesn't look that bad.

I'm not exactly sure how friction values work in the game. I know a higher friction value means less friction, and the friction from the individual cars is added up to get the total friction (so more cars=less friction). That's all I know right now, and so I end up doing everything by trial and error.

The friction value for PTCT1.DAT (standard wooden coaster trains) is 540. By contrast, my wing coaster uses 500 for the front car and 300 for the others (this was done to reduce the influence of train length variation on the friction). The default Twister coaster trains (BMSD.DAT) has a value of 650 for the zero car, and 525 for the other cars. So the wooden coaster is less efficient than the B&M sit down but more efficient than the wing coaster.

The only mechanism I have for determining what values are reasonable is to build a (not necessarily accurate) recreation of a real ride, in approximately the same proportions, and see if it runs too fast. For the wing coaster I did X Flight, Gatekeeper and Thunderbird. This is a fairly inaccurate way to do it, because I don't have accurate values for the speed of the real ride at various points (and the top speed isn't a good measure because it tends to be the least affected by different values of friction). Therefore I don't really have the means to say for certain whether the game's values are wrong. If you've tried recreating a real ride and found it doesn't make the circuit, the friction values could be to blame. It's also possible that rides from different manufacturers have differing efficiency - for maximum accuracy, I'd compare against rides that run PTC trains and don't have trim brakes.

I've always felt the woodies lose speed to quickly to, one of the reasons why GCI's are so highly thought of on here because they are really difficult to pace well in rct. 

Another thing you could maybe do instead of using realistic layouts is putting the new trains on old designs or something, and seeing how similar it compares to the original, maybe?