Screenshot / Intamin LSM initial test
-
08-September 16
- Views 3,679
- Fans 1
- Comments 24
-
Description
This is the first test of my Intamin trains in game. The lighting is wrong - I established that when I did the Mack train but then lost the new parameters I used for it, so I'll have to adjust it again.
These trains are problematic because a realistic layout can't be done without hacks - but at this point, I think it's probable that OpenRCT2 will eventually fill in the missing pieces, having already done so on the junior coaster. -
Full-Size
-
1 fan Fans of this screenshot
-
Tags
Sephiroth Offline
Snazzy, just like all your work. Keep it up!
Looks nice, probably would pref the trains to be slightly (like 5-10% larger). But the models look great.
Just make sure the friction isn't too high this time!
Please make the friction match the Ja227 Giga trains so we can all swap them out for these. Please Please Please
According to this diagram:
the distance between the first and second set of wheels is 2400 millimeters. This agrees almost exactly with with the scale as determined from the track gauge (90cm). I also used this diagram:
Determining the correct friction value for this ride will be very difficult - they are launched rides that often hit the brakes with a great deal of excess speed, so you could choose a wide range of values and still have it look right.I have been looking for a more systematic approach for some time, but I'm not sure how to approach it. It might be that the friction is just left to match the existing trains as it is of little consequence for a ride that hits the brakes at 50mph anyway.
What method are you using to measure the width of the track in game? If its possible I'd just simply it to a ratio of track with to distance between wheel mount.
As for friction, I'd suggest to forgo and perceived "realism" here, and just try to make the friction fit the game the best.
The problem with a lot of your older trains is that the friction is so high they are unusable on most layouts. Friction in game is already a bit low for most trains, and yours are even below that.
Just a suggestion, but I'd hate for your trains to be unusable in game simply due to friction which is 95% a random guess based on perception. To me, friction in game is already pretty much fantasy, and doesn't correlate with real life, so getting all deep into real life accuracy with friction in my opinion is a bit of a waste of time. Just use a value similar to the Ja227 trains, which would allow for optimal usage of the trains. Otherwise, I feel they might be very difficult to use.
I determine the scale used by the game using the "height marks on ride tracks", from which you can establish that 16 pixels along the vertical axis is 1.5m. Taking account of foreshortening due to the projection, you get a scale of 3.67 meters per tile. The input to my renderer is in meters; it takes care of the scaling automatically so I only have to determine what the track gauge of the real ride is.
That can be difficult, but if you search long enough you'll often find some site somewhere that has it. A lot of the this information is pieced together from multiple sources that I wouldn't necessarily trust on their own, or what looks consistent when lined up against photographs or when compared with other measurements I have. In many cases I just can't confirm that it is correct, it's my best guess based on what I have.
I have heard this a lot, but when I suggested going back and changing it, people complained about that too. It is certainly true that the friction is 95% a random guess - but there's a good reason for that. RCT2's friction model is not just a crude approximation, it's completely unphysical. Even if could find out the actual frictional coefficient of the trains, there is no way to determine what that should correspond to in game.
All I can do is to build rough recreations of real life rides, and try to get it so it looks right. Sometimes, the frictional value that looks best seems to vary between rides - when I did the wing coaster, my Thunderbird layout ran too slow whereas my Gatekeeper layout was way too fast. All I could do was set a value in the middle and hope for the best. It's grossly unscientific, the results are little more than a guess, but I don't have any alternative. It can always be hacked lower after the fact if that proves necessary, and I can go back and update rides later if it was clearly completely wrong (and I will be doing so for a lot of the older ridesif I ever get my tool fully finished, so I may well lower friction).
Setting a value close to the default trains assumes those values were reasonable to start with - are they? I will do it in this case, since people have explicitly asked, it would be very hard to do anything else, and this coaster is less sensitive to exceptionally low friction because the entire layout is taken at high speed anyway.
I have never had problems with the friction on any of the trains I've made, but that might be because I mostly build small layouts, and discrepancies in friction become exaggerated the taller you build.
But I'd just go with the values already in game, they might be fictional, however at this point they are accepted and what 99% of layouts are built for.
Introducing a new friction scale at this point isn't really optimal and would require a lot of modification to coaster building to get the correct pacing.
I love the detail you put into your trains. Your use of reference blueprints and drawings gives a nice authenticity to your work, which is what I love about your custom rides. As for the friction values, I'd say just keep them close to the in-game values, because that's what we're familiar with.
I can (and will) if they're recreations, but if they're not, then they'll just be built to work with the existing friction value, whether or not that's accurate, so it'd just be a roundabout way of keeping the existing value.
For this ride I'll set up the friction to match the existing giga coaster exactly, as it doesn't really matter too much for a launched coaster. In future, I hope to get a bit more of a systematic approach going, or at least find some data to justify leaving it at default (I have long suspected that the frictional coefficients of most trains probably don't differ enough to care, but I'm not sure how to go about testing this hypothesis with the data I'm able to find).
Also, do remember that the ability to change friction is a feature of OpenRCT2 (and is compatible with vanilla), so the value I set is not final, just default. If you think your layout really ought to work, you can just hack it lower.
Why does it matter if the friction value is accurate? A very large part of the game is not really accurate. I feel like accuracy shouldn't really matter as long as it looks good.
Anyways, the trains look very cool. As always
.
This. These trains usually look amazing though.
friction accury is a bad thing for this game if you ask me, for noe simple reason, on accurate friction you need to be able to scale your elements to the pacing of the trains, this game however does not offer this kind of system and gives us fixed lengths and elements to work with, for instance the large loops... I strongly believe in the fact that the game has it's "inaccurate" friction values to deal with the lack of true scaling pieces of track to make sure coasters still make a believable representation of the real life thing, on a game like Planet coaster and No limits accurate friction is a good thing because everything can be scaled properly to each elements succesion of the other, here we can't so you're basically making a coaster train that has to race the first large loop at a ridiculous pace in order to make the second wich in my book denies every bit of decent layout building process this game offers... the trains do look really good though, but if friction is an issue I simply won't use them and the same thing applies to the wing coaster cars you've made, they look superb but the friction doesn't allow me to make the layouts I want simply because of the game's set pieces to work with instead of scaling certain pieces and elements.. maybe you can consider the friction as what the game needs instead of what you want to be accurate. also maybe in testing friction values, try to work with a few good layout builders like louis, pacificoaster, cp6, geewhzz and gforce for their input, they have a lot of good insights.
This is a fundamental flaw with the game, probably the most serious issue with it to my mind. It is very possible that the friction values are deliberately incorrect, and I suspect that the G forces are also deliberately wrong for this reason. Which is awful, I know, but nothing can be done about this until there is a new file format. The track pieces are referenced by a 1 byte index, which gives a maximum of 256 pieces. There's no room for more at this stage.
However, I'm not sure how a lower friction is supposed to help with this. With a lower friction, you still don't have the track pieces to build a large layout well, but now your small layout is running too fast.
I am happy to leave friction as default for this train, I don't think that will be a problem. But if the real ride obviously has higher than average friction, as is the case for dive and wing coasters, then I'm going to lower it somewhat - the question is to what degree it should be lowered. I don't really have good data, so I just go by what looks right, which appears to be what people are asking me to do but then they think the result is too high.
Is it because these coasters are travelling faster than I think they are? It could be that what looks fast in game is actually right. I can go back and update the rides if I need to.
Also, I will reiterate, you can set the friction on individual rides. I implemented a command for it so it's very easy to do now. There's no reason to stick with the value I put in the file if you don't want to; yes, it is a bit awkward to keep changing friction values, but you can always test with default trains if what you really want is for the trains to behave exactly as the default ones do.
Ugh, this physics stuff brought back memories of H2H4 when we discussed this and it still feels like I had this discussion yesterday (imagine my surprise that that thread turned to be 10 years old... xD): http://www.nedesigns...nostalgia-vale/
Basically the scale of RCT is not correct, so take everything the game tells you with numbers with a pinch of salt. Simple example, for a school project I once measured a rollercoasters G's. A relatively small looping took around 4 seconds to travers in real life. That ain't happening in RCT for any loop that is taken by a game acceptable speed. Would actually quite hard to even achieve that long in RCT without hacking.
Well, it's not hard to test ... I will do so and report back with my results.
EDIT: Actual speed as measured by the height markers was 50% higher than the speed reported by the game. And the peak acceleration doesn't match by either measure. That's not even a minor discrepancy. Worse, the reported (wrong) speeds do align closely with the actual heights, which means this can't be fixed by changing the display alone - the physics is quite fundamentally broken here, and I'm not exactly sure how it is broken. It's possible that Saywer never actually tried to define a consistent conversion factor between the in game units and real world ones, which is an obvious problem if there is to be any hope of building a realistic park, as it could mean different measurements are on different scales, and everything is out of proportion.
Meanwhile, I'll set the friction to whatever you guys want, as any hope of actually building anything realistic is lost when the game itself is broken.
I know I said this earlier but most people use the Ja227 trains for this type of coaster as opposed to the standard giga which isn't capable of verticals so I would really match those so we can simply swap them out if at all possible.
Plus selfishly I have a coaster that I really want to use these on in my current project. I might use them on the Strata too as it's closer than the Ja227 trains.
I can do that if you want. Of the two, JAGIGLT has slightly higher friction.
I've never really taken the units in game with 100% certainty. So I wouldn't lose sleep over scale and realistic accuracy, trying to make the train with the most believable and realistic aesthetic is more important than any percieved "accuracy".
I respect what you do tremendously. It's really fascinating to see how someone like you approaches the game different due to background, as opposed to the average NE member.
Basically real life units should be used as a guideline, but visual appeal should come first in most cases. Because often time in the end the units are ingnored anyways, as there often times a bit hard to build by.
The game does have its own internal units - horizontal differences are given in units of tiles, and vertical units are given in fractions of a single clearance height (which projects to a distance of 8 pixels in screen space) . This choice of basis scales out the irrational numbers in the projection matrix, so the game can use integer arithmetic throughout.
The problem is that the game converts these to real-world units in three places and doesn't seem to use a consistent conversion factor between them. The height marks would indicate about 3.67m per tile, the ride length would suggest about 4.3m. while the speed measurement would suggest 2.5m. Those are all wildly different scales.
So I'm not sure what to do about this. Attempting to correct the physics isn't a simple task at all. I will most likely finish this train off as originally intended.