Most parks seem to have a Von Roll designed Skyway- quite different from a ski area chairlift or gondola in how the lift's detachable grip works. In playing around with different styles of grips, I've realized that this Von Roll design is easiest to duplicate and keep polygon count low. I have designs for other types of grips but they tend to be higher in polygon count in order to look believable.

So, I think that the first type of Skyway to work on should be the Von Roll type of design, and here are pics of the terminals I've com up with:


I still have some work to do on the textures for the drive unit's motor, and will upload these once I get that done.


Other types of lift designs can eentually be made, and the different bails or chairs should be able to interchange with the different grips.

Beautiful design. Looks exactly like the skyway they have at Great America in California.

Thank you for the comment (I was wondering if anyone cared ). The Von Roll system should look vary familiar to a lot of folks, since they seem to have cornered the Sky Ride market early on. That might be due to a simpler construction of the system, even though the design was the first detachable grip to carry passengers.

Since the terminals were generally on the same level (within a few feet) gravity did all the tensioning of the cable, removing costly couterweight (and more modern hydraulic) systems that ski lifts use.

I've see bits of this Von Roll design in many older photos, and after examining the grips in many pictures of different gondola designs, I realize that even today there are new(er) Skyrides that are still using the Von Roll design.

Today I had lunch on top of Killington peak, and riding the modern Poma gondola gave me fresh ideas for more modern lift designs.

What I am worried about to some degree is interchangable parts. The Von Roll system should be a standard, I think, for all regular Skyrides. Other ride designs, like one with hot air baloon themed bails, would need much more clearance, so this terminal could be offered in several heights.

I have traditional track designs for the terminals and I've also come up with a rather unique track switching system should the builder wish to make a fancy terminal where multiple directions can be chosen.

Modern lift designs more commonly found at ski areas (with the exception of a basic chairlift found at many boardwalks) should be held off for now, perhaps made ready for a Winter Theme/Ski Resort add on...

Wow, havent bee in in a wile, realy busy. but great job! glad to see you making rides. this will make the game better!

Ah Yes. Great work there vohdin. I have a friend that works for this company and he was telling me the other day that they have landed a few park builds here in the US and abroad. They also have some other transport systems that might be of interest..

Mike

http://www.pomagroup.com/

I'm not sure if Poma got Von Roll- Von Roll still exists, making specialized machinery and industrial electronics...

None the less, thanks for the link

This model is ready save for texture work. I just have yet to make a good machinery texture for the innards (been lazy, actually). One thing I've been thinking about is changing the track's turn-a-round- instead of the bulbus shape, I might just have it come straight in and turn around at the end... seems simpler.

Both designs will be available for consideration, perhaps both will make it into the game.

The original design


The modified design



Both will be included in the upload I'm about to make.

The pictures are just two red x's inside a box.

What happened to Voodhin? This was all before I was here. Did he quit or is he secretly still working on this? This is one of the most important rides for a theme park...

I am here. (wow, that's some kind of Zen thing, isn't it?) I haven't quit, but I have not had much time for modeling- or rather, for digging around to learn what must be done to make these work: The GDD tells us what "can" (as in what we want to be able to do) but doen not have any information as to what we modelers need to include in the models, in the way of joints, bones, or other 'mechanicals' needed to make the ride actually interface with the rest of the game.

In other words, do we need to include specific, predefined joints, bones, or armatures in the model components in order for the game to activate the model or are we making our models independent of the rest of the game? The former assumes that the game can control actions/animations in the ride, while the later might exclude cross ride compatibility and means that the models animate only as designed by it's creator. I assume that we're aiming for the former statement.

I'd get back into modeling if I had more information on how we're supposed to make these things work


******
Now for some critism/suggestions:

Quote:1.2.2.3.2.6 Arial Tram

call it the propper industry standard term: "Aerial Ropeway"

Quote:The Arial tram can be either a loop or an end to end track.

One way loop (Ski lift style, cars return empty), round trip loop (skyway, ride either direction), and switchback (Tram, like Roosevelt Island).

Quote:The terminal point can be either a station or a turntable The player can select the vehicle as a gondola (squared, round bucket with roof, or bubble), a ski lift chair (single, double, triple or quadruple seat) or a large aerial tramway.

Track and grip should determine car type and stations: you should not be able to put a large Aerial Tram on a ski lift cable.

Large Aerial Tram designs should also require a completely different terminal design and track as compared to small trams and skilift/gondola type rides. Large Aerial Trams should also be able to syncronize each station (as in real life, typically one haul rope loop moves both trams), or individually (each Tram can travel when ever it is ready to do so).

There are 3 basic terminal designs used for Ropeways, determined by how a bail (car) is attached to the cable. There is the fixed grip for endless loop and switchback loop designs, detachable grip used for endless loop gondolas and high speed chairlifts, and the trolley truck used in Aerial Trams (The bail hangs from a truck that rides on a pair of fixed cable 'tracks' with a third haul rope to pull the truck).

Not mentioned but should be an option: the player should be able to choose left side/clockwise or right side/counter-clockwise travel over the cable.

So, I propose these types with these rules:

Chairlift, Fixed Grip: a continuous endless loop.

• Riders load/unload while ride is in motion
• Bails must be designed to load/unload in motion (e.g. no doors)
• Length of ride divided by speed of cable should equal a load wait of 5-6 seconds (by number of bails)
• Can be one way or round trip
• Load/unload can happen at same time (each side of bullwheel)
• Detachable Grip/enclosed bails not allowed
• Can have one-way lines of travel, but must loop back to first terminal
• Haul Rope is Track
  

Chairlift, Detachable Grip: a countinuous endless loop

• Riders load/unload while ride is in motion
• Bails must be able to load in motion, but a slow speed
• Length of ride divided by speed of cable should equal a load wait of 5-6 seconds (by number of bails)
• Can be one way or round trip
• Load/unload can happen at same time (each side of bullwheel)
• Terminal speed is 1/3 of ride speed
• Can have special station pieces for cable interchange
• Bails move through station via automatic mechanism
• Fixed Grip bails not allowed
• Can have one-way lines of travel, but must loop back to first terminal
• Haul Rope is Track
  

Gondola: a countinuous endless loop

• Riders can load/unload while bail is in motion
• Bails can load/unload at slow speed or stopped
• Bails can have doors
• Length of ride divided by speed of cable should equal a load wait of 5-6 seconds (by number of chairs)
• Can be one way or round trip
• Load/unload can happen at same time (each side of bullwheel)
• Terminal speed is 1/3 of ride speed
• Can have special station pieces for cable interchange
• Can have storage rails
• Ride popularity decrease moves extra bails onto storage (visual clue)
• Terminal design could allow for either attendant or automated movement of bails
• Fixed Grip bails not allowed
• Can have one-way lines of travel, but must loop back to first terminal
• Haul Rope is Track
  

Aerial Tram, Small Fixed Grip: a switchback endless loop

• Riders load/unload while ride is stopped
• One Bail (small Tram) per travel direction
• Bail does not pass bullwheel
• Should be one way trip, riders can ride either direction
• Load/unload must happen at same time at each terminal
• Both bails travel in sync (they're on the same haul rope)
• Detachable Grip/Open-air (e.g. chairlift) bails not allowed
• Haul Rope is track
  

Aerial Tram, Large Trolley Grip: a switchback ropeway

• Riders load/unload while ride is stopped
• One Bail (Large Tram) per travel direction
• Bail does not pass bullwheel
• Should be one way trip, riders can ride either direction
• Load/unload can happen at different times at each terminal
• Both bails can travel in sync (they're don't have to be on the same haul rope)
• Detachable Grip/Open-air (e.g. chairlift)/small Tram bails not allowed (only ones that have trolleys)
• Haul Rope is additional to track (See here)
  

Obviously, terminal design will be tied into the type of Ropeway the player is building, with a few cross-overs: a chairlift terminals can be used for a Small Switchback Tram ride, and Gondola bails can ride in any Detachable station. Terminal designs ultimately determine how a bail travels through it, moved by an attendant or automated, and wether it comes to a stop or travels slowly for loading/unloading.

Quote:Track types include end piece, straight, horizontal curved and vertical slopes. The end piece is a turntable which lets the cars move in a semicircle to return to the station. Vertical slopes allow the cable (track) to change vertical angle. Horizontal curves allow the track to change horizontal angle by an amount specified by the player. A horizontal curve and vertical slope can be combined into a single track segment. Turntables, horizontal curves and vertical slopes each require a support post. Straight pieces span the distance between those special pieces. Support posts are auto generated if the span is greater than ten tiles. The player can choose to place support posts manually.

There are very few Ropeways with horizontal direction changes because of the physics involved and safety issues. I have ridden two: one is a mid-station, detachable type (the old Killington Gondola - Current Mid Station), where the bail enters a terminal and actually switches on to a different cable, and an in-between station with two 8 degree turns (Killington South Ridge Tripple) which - even at a moderately slow speed) scared the bejeebes out of you as you were flung from side of the chair to the other. I can design "safe" and believable horizontal turn elements for all types of Ropeways, and they won't be the unrealistic types found in RCT games.

Vertical/height angle variations might seem easier, but they are not- read on:

Quote:Manually and auto generated posts are flagged internally so that the game can remove an auto generated post if a manually placed post makes it unnecessary.

What is the "Flagged Internally" bit? Do I need to include special bones/joints/code of some sort? If the towers auto adjust in height, should I use bones to group verticies togerther to keep parts from distorting? How is the texture used for the tower handled? is it repeated or distorted? Are actual model sections added/removed to change the tower? what about lattice towers? They widen at the base as they get taller, usually requiring more cross pieces or longer cross pieces- I've built these types of towers with alpha textures: the texture must match the tower's shape or you face serious distortion. Do we just drop lattice style towers?

Vertical Angle changes: There are some real world rules, too, that should apply to towers and terminals, in order for our ropeway simulations to look right. When a cable goes from flat to vertical, the sheaves (pulleys) are almost allways on top of the cable- Compression sheaves. That means the tower/terminal needs to have some modifier to raise the height of the sheave train (pulley group) enough to be on top of the rope, and the sheaves would need to rotate in the opposite direction. The modifier might be nothing more than a spacer added to the sheave train when compression is needed.

Also, the real world calculation is one sheave for each 1.5 degree of maximum change. In the US and other countries, the moden Ropeway must have a minimum 3 degree negative cord angle at loaded weight on a level span (ropeway systems are designed to 'give more slack' as the load increases- we don't need to worry about that). That formula creates a minimum of 2 sheaves on each side (forward/back, not left/right) of a tower.

What that means is that we should have a way to add sheaves to a sheave train as the angle of vertical change increases, and perhaps have a way to group additional towers together should the number of sheaves increase beyond a limit "per tower". The more sheaves, by the way, will mean greater lateral distances between the tower section and the cable connection. These suggestions might seem over the top, but in actuality you will want it or face steep angles that look absurd, not to mention trouble when you want to make a lift that goes up a hillside and not have the cable either drag on the ground or ride above the towers.

Alternately, chairlift (Fixed and Detachable) and gondolas could be "Build in each direction" - instead of building sections that have both travel directions on a tower, it could be that you place a terminal, build out to the next terminal, then build your way back to the first (adding any other station pieces in-between). Something like this: Click Here. Building a standard ride (both directions on the same tower) would be easy, too: just click a "auto return" button once the end terminal is reached. It would build the return cable up to the pervious terminal station. Repeat as needed.

Quote:Each station has engine noise for ride. This is only found at station.

I don't think I've ever been on a Ropeway with motors at both ends. Typically there is a Drive terminal (with motor, and hence, motor noise) and a Return terminal, generally as silent as the towers.

Quote:Additional ride noises occur when the car is on the cable (whizzing noise, very slight) or where the cable the car is attached to passes over a tower support and the bogey wheels that move the ride along (thump thump noise, slight).

Not really. No need for car noises at all. Towers should have a basic noise and a secondary noise: the basic noise is a repeating hollow hum with slight squeaky/sticky rubber noise that is from the sheaves (the pulleys) that support the cable. The scrondary noise is the thump when a grip passes over/under each sheave (it's actually the sound of haul rope slapping back down into the rubber boot of the sheave after the grip passes over). There should be one thump for each sheave. So towers and stations only need sound, and you'll hear as you pass them.

Quote:881.2.2.3.2.6 Aerial Tram - Propose Change ...

Vodhin Wrote:I'd get back into modeling if I had more information on how we're supposed to make these things work

I guess this is where I should say something.

With respect to Skyways, the answer is that I don't know at the moment.

There is support in the graphics engine for bones and animations, but there is not yet support within the import mechanisms which are still quite primitive. The FRCS uses static meshes and animates the bones in the hubs through a sequencer mechanism.

Skyways are a tracked ride. The mechanics of tracked ride haven't been developed yet, therefore I can't say what is needed in terms of spatial positioning for the cars to ride along the track (the cable). The details of triggering doors and restraints is also unknown, assumption is something somewhere says which animation should be used to manipulate the relevant bones.

Would you like me to develop ideas for the Ropeway system? While I cannot code, I can experiment with joint/bone mechanisms that your code could manipulate: e.g. I have an idea that can alter the length of a tower's arm based on the size of the bail. Also, I have ideas on how the sheave train can be altered and perhaps control different angles of elevation.

Sounds like is might be best to model the sheaves, pulleys and towers as pieces that get assembled according to a rules base.
Vodhin, Sounds like you gathered are know the engineering data. This along with parts of the coaster tracks could use the rules base to engineer sections to meet near realistic results.
Stations, drive systems, tower bases and other static structures can be modeled now. Leave all the track pieces until later.
I can see the cable dip between supported sestions but the games engines will take care of that.

No Grid!

Well, I will think about things and reply later, perhaps with some models for the coders to examine. Right now I have to run a few errands

Track, including towers should be procedurally generated. This will all make more sense once we've got through landscaping and into the building generator code. As well as generating buildings the bg code will also be used to generate track.

I need to get back to the animation code and have a think about how we're going to import bones and animations. I'll try to post again once I've gone back over it.

I assume that we'll be using animated textures for some things like the cable and the sheaves? If so, I could also assume that the ride's speed will controll the animation speed of the texture?

If so, then may I make a suggestion that we use base 5 for ride texture animation (assuming a 30FPS base rate)- that would make for simple frame stepping (e.g. Sheaves and wheels would only need 5 frames in a quarter turn, each frame a 15 degree rotation off the previous). Dang... out of coffee and can't even tell if I'm making sense...

First 2 questions are important... suggestion isn't...

Yes, animated textures will be used for the cable and sheaves. Animation speed can be controlled by the game engine, but it's not something that I've fully tested nor produced example objects for.

The game is currently set up to run at 25clock ticks per second, the actual graphical redraw speed might be less if it's fully loaded but the underlying physics work on the 1/25th of a second interval. However I can appreciate that 25 ticks is difficult for rotational movement because there are no common factors of 25 and 360. There's no reason why I can't move the underlying rate tick rate to being 1/30th of a second other than additional processor overhead.

well, 15 FPS is actually the start of "persistence of vision" and 18 would be great, because that divides into 360 twenty times (five 20 degree rotations per quarter turn) and it's well into the Persistence of Vision range

(Useless but interesting info: Silent 35mm and 16 mm movies are at 18 FPS. The only reason that film went to 24 fps is beacuse it's the slowest speed to get good sound on an optical soundtrack. NTSC video adopted 30 FPS because the TV picture gets drawn using 2 interlaced fields, each field arriving at 1/60th of a second, and matches the AC power here in the USA (AC power is actually off 60 times a second, if it were at any other rate, the power in the TV would not be there for some of the fields). other video systems use 25 FPS, matching the 50 Hz power in their countries.)

If 30 FPS is too high, then 18 or 20 would be good rates when it comes to animations. 25 could still be done, but rotation aanounts would need to be in multiples of 3.6 degrees.

Thinking about cyclical animation, the "end frame" is allways the same as the first, and therefore the sequence needs to stop one frame earlier, lest the last frame and first frame appear as a "stutter" when the sequence repeats this is actually good, because the 5 frame sequence becomes 4, which means less memory usage...

more to think about...