Importing Your Peep Effects As Child Bones

Except for one difference the Importing process is exactly the same for multiple Child bone restraints as it was during a previous session when our restraints were made up of a single Child bone. This time around we need to link our Peep effects as Child bones and set them upon our Parent bone bone_FloorForSeatingEffects. In the next screenshot we show you (in the first 25 lines) how this should look when you've completed setting this up in the Bones dialog in the Importer's Edit Animated Models Window.

After setting up all your Peep effects as Child bones you may choose to keep them all here in one area as shown in the previous screenshot or you may spread them out to use as 'separators' throughout your Bones dialog as we've done in this next screenshot where only the Importer entries required for Peep01 are shown. No one way is better than the other and this will be a matter of your own personal preference.

Meshes, bones, and set points for all twelve sets of restraints will need to be set up, once for each Peep effect. We show you next how we set these up with Peep01. Observe in the hierarchy that

►

the first bone, OneP, is the top bone or the parent bone,

►

the second bone, TwoC, next in order is the top Child bone, second to the Parent bone, and

►

the third bone, ThreeC, is the bottom Child bone, second to the TwoC Child bone, and in this bones arrangement is last in order.

When you've completed setting up the assignments for Peep01 simply repeat this process for Peep02, for Peep03, 04, 05, etc. It's probable you are realizing by now that the only way to process the two hundred bones required for these twelve restraints is to be organized and we recommend you use the up and down arrows at the right of the Importer's Bones dialog to rearrange your bones into the order of your choice before you start assigning any meshes and prior to matching Children to Parents. When you're done setting up your Peep effects and your restraints don't forget to add your wheel effects and your camera bones.

When you're done save your car as an OVL, and there we are, a car with twelve functional restraints each with multiple Child bones.

Adding Personal Notes To Your Animations

Although we've taken care to give our meshes, bones, and set points specifically matching names, six weeks from the date we're done with our XML's we won't remember the reasoning behind most of the entries in each of our animations so adding notes and lines throughout the text written in each XML will be helpful for those times we need to revisit an animation, something that might be necessary if we want to use a known working animation that we've already created as the point of departure for animating the restraints to another car project. Notes and lines included throughout your text will enable you to tell at a glance what it is that you're looking at and why you've used the values that you have.

It is possible to add notes to an animation XML without their content affecting the animation itself. This is easily done by putting a

<!--

at the start of each note and a

-->

at each note's end. Whether your note is ten words or a hundred, each note within this header & footer set will represent one line in the XML.

Your notes may tell you what angle is represented by a radian number without your having to again recalculate the values. Another note may simply represent a dividing line to aid in clarity and organization. If you've created animations for several cars and you're attempting to compare them, it's handy to use such a note at the beginning of each XML to tell you for which of your cars the animation has been written.

Notepad++ is outstanding in this regard because once we've entered information inside our note's header and footer it will appear in this application's display as gray text which tells us that this information is not taken into account by the animation. You will also note that the fields in which we're to enter our animation data are in another color. XML Copy Editor does this same thing but if you're used to Microsoft Word, the text styles in Notepad++ will make you feel more as if you're writing a document rather than cold coding in a specialty application.

Making Robotic Coaster Cars With The ik_robotjoint

This particular type of bone didn't make an appearance in RCT3 until Wild! where it's only used in the Robotic Coaster. This coaster's construction interface comes with an Edit Robot Arm Angles toggle which brings up the Robotic Coaster interface. The ik_robotjoint bone made it possible to create a car with customizable robotic movements along with seats that used the standard bones for restraint animations.

The major difference between bones used for standard animations and ik_robotjoint bones is that the latter allows us to choose our rotation angles while in the game in addition to changing these angles several times during the length of the track rather than our being restricted to a single position that we might code it into any ClosedIdle XML. In view of that, so that your ik_robotjoint bones actually work on your custom car, in the BahnDaten_ the FourAxisRotationFlag needs to be flagged at 1 which will enable the Robotic Coaster interface in the track's Construction dialog. When your track is in construction mode it is in this dialog where we may choose our desired ik_robotjoint rotation angles on our various track sections.

A maximum of four ik_robotjoints are permitted for use in any car and the in-game Robotic Coaster car uses all four of these bones:

►

Parent bone: enabled for the Z axis,

►

first Child bone: enabled for the Y axis,

►

second Child bone: enabled for the Y axis, and

►

third Child bone: enabled for the X axis.

Although these are the axes as represented by the in-game Robotic Coaster car, regrettably, in spite of our best efforts we've only been able to make custom robotic cars with one Z rotation (the Parent bone) and three Y rotations (the three child bones). We believe it likely that this is due to the fact that the in-game Robotic Coaster car is coded to include three bogies that aren't acknowledged anywhere in the CTR Creator data that we reviewed.

When deciding where to put them in SketchUp we've chosen to place our ik_robotjoints in numerical order upwards from the main car body. We haven't done a huge amount of experimentation with this order and we recommend that you follow what we've done unless you're prepared to spend time experimenting with this yourself to see if alternatives are possible. Again, following this numerical order it would seem that ik_robotjoint01 defaults around the Z axis with the other three, ik_robotjoint02, 03, and 04, defaulting around the Y axis. Fortunately this ik_robotjoint01 default rotation around the Z axis is the best axis for an ik_robotjoint bone in that place on the car. Working with ik_robotjoints is certainly easier if they're set up in numerical order in relation to their Parent/Child associations.

This screenshot of the in-game Robotic Coaster interface will show you which of the entries in the list is for what ik_robotjoint. You'll observe that they're conveniently listed upwards from the bottom of the interface to match the Parent/Child hierarchy up from the base of the Robotic Coaster car in our game.

When creating our own custom Robotic Coaster car we should arrange our own ik_robotjoint bones in SketchUp in a similar fashion.

If your guests are sitting on seats being manoeuvred around by ik_robotjoints you'd want them to be held safely into place with restraints which means you'd need to remember at some point to change the AnimNoRestraint entries in the WagenDaten_ so that your restraints are enabled for animation.

These entries are required only for the restraints. No such consideration needs to be made for the ik_robotjoint bones and you'll recall earlier when we worked with ik_wheel bones that they didn't need this consideration either.

Just as all ik_wheel bones were placed in SketchUp at their actual locations rather than at X+Y+Z=0 the same goes for the placement of ik_robotjoint bones which also need to be placed at their actual locations in our modeler. If we imagine all our ik_robotjoint bones as a group, the ik_robotjoint group will collectively be parent bones to the meshes and bones that make up the seats, restraints, and guest sitting positions in our car, while the car body, the part that follows the track, is 'parent' to everything else.

As you see the car body is made up of standard meshes. Any meshes for the restraints each need to be assigned a bone with all the restraint bones placed in SketchUp at their actual locations with them being assigned ik_robotjoint04 as their parent bone. To affix the peeps in their seats while those seats follow the Robotic Coaster cars as they're maneuvering and wending their way around your track, any of the seat meshes not being used for restraints needs to be assigned a Parent bone (we'll call this one Parent bone A) at X+Y+Z=0, the Peep Effects placed at their actual locations as usual, and the Peep Effects linked as if they're Child bones to Parent bone A. The matrices of all effects that are parented by ik_robotjoint04 will need to be further Translated and Calculated in the Importer.

  Coordinates Fallout!

Considering the number of ik_robotjoints, restraint bones & their accompanying set points, and the required meshes placed in relation to the bones, the Importer needs to keep track of and collate a great deal of information to produce an OVL that enables us to use CTR Creator to make a functional Robotic Coaster for use in our game. It is probably due to this that the Importer will occasionally drop the Coordinate System we've selected and replace it with the default one. If your car suddenly appears in the game reversed on the track or up on one side chances are the coordinate system has been dropped and has reverted to default so your car will need to be re-Imported with the correct coordinate system. It's only when Importing Robotic Coaster cars that we've noticed the Importer to drop coordinates.

Because several meshes need to be assigned to specific bones and because of the complex Parent/Child bone hierarchy required by this car design, designing a robotic coaster car can be challenging in that it's difficult to determine how early in your car's design to replace test textures with your actual textures. Applying your actual textures too early will probably require their re-application after you've tested your car in the game and need to re-scale and rearrange your car model shapes. Applying your textures too late will require that you re-think which texture is assigned what mesh when you finalize your bone & mesh associations - and may require that you re-name your bones in your modeler so you can stay organized in the Importer. This is a balancing act that only you will know how to organize in a way that best suits you.

Thought may be given at this time regarding the differences between the FourAxisRotationFlag and the CarRotationFlag, the latter being the setting which activates the rotation icon for rotating cars such as the Spinning Steel coaster. The rotation flag usually puts the car into a constant spin for which the only adjustments possible are a choice as to whether our car is facing forward without a spin, facing rear without a spin, or rotates freely. Conversely, the FourAxisRotationFlag allows us to control the rate of spin due to the distance between the various rotation enabled track sections in addition to the angles that we choose for those sections in the Robotic Coaster interface. Larger angles and shorter distances between enabled track sections will result in a faster 'spin' unless the data is entered in the interface in smaller increments.

With custom Robotic Coaster cars and the Spinning Coaster cars you'd likely want to change the value of the CameraLATiltfactor in the WagenDaten_ to 0.

When testing ik_robotjoints in your game it's best to make a little circuit of your test track, to use a flat track, and to set up your BahnDaten_ to get a track at a constant speed so you can get right into testing without any track design fuss. To activate track sections with ik_robotjoint rotations, open the Robotic Coaster interface in Construction mode, select the track section to which you want to add a robotic movement, enable that track section by checking the box, and then set your ik_robotjoint angles from the interface there.

So that you may view your car in its default position without any ik_robotjoint angle modifications your station should start from the place that the track ends with a 0° rotation enabled station section and exit the station at the place where the track begins with a 0° rotation enabled station section. Because coaster cars are coded to 'anticipate' the movement required in the next track section and will turn slightly to match this movement, the first track section out of the station should also be 0° rotation enabled. Of course, after your track is tested, if you wish for your car to exit and enter the station at another configuration this your personal choice.

Beyond the station you should place the desired number of rotation enabled track sections each a few track sections apart. Start out by adding one rotation at a time to each of these rotation enabled sections so you may observe in the game how each of your ik_robotjoints turn in relation to where you've placed them in SketchUp. When you've gotten the knack of setting up these few robotic car movements with your car you'd be in a better position to expand your track design, add special track sections, and combine your rotations.

When in Construction mode, while we're editing the positions of our ik_robotjoints, unlike the in-game Robotic Coaster car, the blue ghost image of our custom car won't twist & turn to show us what changes we've made nor will our ik_robotjoint rotation choices display in the white ghost image that comes when we test our track during Construction. In view of this the only way to see what we've done with our joints is to test the track while the game is not paused. While in the Robotic Coaster Construction interface we will also be unable to view the yellow axis indicator when we hover over each of our ik_robotjoint bone choices.

Do remember that your ik_robotjoints will spin & turn to match the requirements of the track section that is being approached. Once it passes over that track section your ik_robotjoints will begin to move into the positions you've selected for the following track section. After your train has passed the final rotation enabled track section it will start to move into the 0° rotation enabled station section position like we indicated three paragrphs back. Again, if after the initial track testing you find want something other than all 0° rotations at your station that's just fine.

Again, after you've become familiar with how best to set up your custom robotic coaster car on its track you may get elaborate with your track layout. You'll find that interesting effects can be achieved with the robotic coaster car's movements on different track types combined with special track sections such as the barrel roll and any other track section that includes an inversion.

Any restraints set up on your robotic coaster car will need to be assigned as child bones to ik_robotjoint04 so the restraints will exactly match the movements of the car.

►

Multiple bones/meshes assigned to any ik_robotjoint will take on an arc formation - the farther away from the ik_robotjoint04 bone that these individual objects are, the larger and wider an arc they will form. Because guest seats are generally some distance from the actual ik_robotjoint04 bone this is particularly noticeable for ungrouped Robotic Coaster car Peep sitting effects and will result in guests that float ahead of any front seats and drift behind any rear seats. Therefore, meshes parented by ik_robotjoint04 need to be in a single group so that the ik_robotjoint will treat the grouped meshes (we'll call them Group A) as a single entity.

►

Peep sitting effects or any additional Child bones, e.g., restraints, will then need to be parented by Group A's bone which, as just mentioned, will be parented by ik_robotjoint04.

Except for the most senior of Parent bones and also for ik_robotjoint01, all Robotic Coaster Car bones will need to be Translated and Calculated.

Drag the above toggle to a

convenient place on your screen.