Balshor

[ QUOTE ]

[ QUOTE ]
<ul type="square">[*]I Loved You Once in Slices (Not quite Camelot, but close.)[/list]
[/ QUOTE ]

Have no idea what that has to do with Camelot.

[/ QUOTE ]

Ahh, I guess you weren't in the musical version of Camelot. "I Loved You Once in Silence" is the song that Lancelot and Guenevere sing right before being caught by Mordred. See here for a Marin Mazzie/Nathan Gunn performance of it.

Well, occasionally building on the idea that your character is wielding a big ol' sword, here's a quick take on your top five:

<ul type="square">[*]Nick a lass, nick a boy. (Equal opportunity slicing and dicing. Alternatively, cross-gender alting.)[*]Inherit the Windups (Dancing Clockwork!)[*]The Good Woman of Set IOs (WW is kind of like a stage....)[*]Aggravating Searches (Got to love PUGs.)[*]I Loved You Once in Slices (Not quite Camelot, but close.)[/list]

The units used are the inches different from 6 feet, which is the default height in the character creator. So, to make a 20 foot tall character, put 168 (=12x(20-6)) in there. Using 500 would be a little over 47 feet tall, which sounds about right for a five-story character.

Try the following:

<font class="small">Code:[/color]<hr /><pre> 'Perform the roll.
JointCos = Cos((-Pi / 2) + ((JRoll + JointRoll(JSrc)) * (Pi * 2)))
JointSin = Sin((-Pi / 2) + ((JRoll + JointRoll(JSrc)) * (Pi * 2)))
JointX(JDest) = JointX(JSrc) + (JointCos * JLen)
JointY(JDest) = JointY(JSrc) + (JointSin * JLen)

'Perform the pitch.
JointCos = Cos(JointPitch(JSrc) * (Pi * 2))
JointSin = Sin(JointPitch(JSrc) * (Pi * 2))
JointY(JDest) = JointY(JSrc) + (JointCos * JLen)
JointZ(JDest) = JointZ(JSrc) + (JointSin * JLen)

'Perform the yaw.
JointCos = Cos(JointYaw(JSrc) * (Pi * 2))
JointSin = Sin(JointYaw(JSrc) * (Pi * 2))
JointZ(JDest) = JointZ(JSrc) + (JointCos * JLen)
JointX(JDest) = JointX(JSrc) + (JointSin * JLen)
</pre><hr />

This is entirely unchecked, and you'll probably need to add some constants into the JointCos and JointSin variables to get the angle offsets correct. However, give it a shot and tell me how it looks!

Hey, Leandro --

I'm jumping in here just after skimming this thread and without actually playing with any actual EntRagdoll commands. However, if I can get a good understanding of how the PYR commands for each joint works, I think I might be able to help you with the math part of the code.

Here's my understanding of how things are supposed to work, based solely on several unsupported assumptions:
<ul type="square">[*] Pitch defines a rotation around a horizontal axis running "left" to "right."[*] Yaw defines a rotation around a vertical axis.[*] Roll defines a rotation around a horizontal axis running "front" to "back."[*] The joints are attached to each other in a tree. Each joint inherits the rotations from all parents joints in this tree.[*] When more than one of the PYR rotations is used, they are applied in the order of R-P-Y.[*] The axes of rotation are absolute (meaning that each axis is independent of rotations about the other two axes).[/list]The last bullet point is the one I am most uncertain about, although it would be much simpler for the algorithm to be programmed this way than the other. Are these assumptions correct?

On a side note, are the second and third entries of the EntRagdoll command well-understood?

It depends. If you want to change multiple costumes to the same NPC costume, you can do the following with my editor:

(1) Create a filter to display only the "NPC" or "COSTUME" lines of the characters you want to change. Besides putting "NPC" as the command, you can either do this by selecting a list of references or with a specific argument.

(2) Hit the "Change All" button.

(3) Put the new NPC line in the dialog and hit okay.

(4) Clear filters, then filter to display only the "PARTSNAME" lines of the characters whose COSTUMEs you changed. Hit "Delete All."

I don't think there's fast way for changing multiple costumes to the same player costume or multiple costumes to different costumes.

Yeah, movement needs to have both POS and PYR to work. This is especially true for the camera, since PYR determines which direction you're looking.

Can you post exactly what numbers you're using to generate the POS commands? Alternatively, can you post the demo you're having trouble with? (If you need a quick place to host the demo, you can upload to www.mediafire.com without registering.)

Actually, in this case, the use of the music is perfectly legal -- Nine Inch Nails is sponsoring a film festival on YouTube, where fans are supposed to make music videos based on their most recent album.

The relevant information you want for using City of Heroes footage is at the following link:

http://www.plaync.com/help/eula_posting.html

From that link:

[ QUOTE ]
Members are permitted to make use of Game Content in noncommercial contexts, including in connection with the creation of noncommercial fan fiction and fan sites and using game audio and video for creating noncommercial media....

A simple rule of thumb is if the Member is receiving anything of value in exchange for a work created by the Member based upon, or related to any of the NCsoft line of games, it is likely to such use is an impressible commercial use of the exclusive rights held by NC Interactive (and its related Game Content Providers).

[/ QUOTE ]

IANAL, so don't take the following for actual legal advice.

So, the question becomes whether your use of in-game footage is commercial or noncommercial. Are you receiving anything of (monetary) value in exchange for the video? Well, Trent Reznor specifically states that this is not a contest and there are "no elaborate prizes." The winning of the contest itself has no monetary value. However, Reznor also says that they're thinking about using the winning videos in a broadcast TV special or in a live concert. This use would almost definitely be considered commercial and be prohibited. So, you can probably enter, but you most likely won't be allowed to have your video "win."

If you're serious about pursuing this, you really should get better advice than is available on these forums. You can submit a support ticket (go to http://www.plaync.com/us/support/ and hit "Ask a Question" at the bottom) and ask NCSoft if your use is permitted. Alternatively, you can try PMing Lighthouse or Ex Libris for advice. Finally, if you want actual legal advice, there are a number of organizations that help artists with legal issues -- one place to try would be the Volunteer Lawyers for the Arts. You can find a list of their chapters at http://www.vlany.org/resources/vladirectory.php.

Ordinarily, I'd just tell somebody to figure it out from my previous post. However, I thought that the person who wrote the Splasher deserved a bit more. So, try this. (Besides, I think the formulas I posted before were a bit off, which makes me think that nobody actually tried to use all that trig. So much for that.)

I haven't verified the formulas in this spreadsheet, either, so tell me if points stuff in the wrong direction. It should be self-explanatory to use.

I'll put it on the list.

[ QUOTE ]
[ QUOTE ]
So, if any of you have requests for new wizards, feel free to make them.

[/ QUOTE ]

Okay, how a version of Translate POS that uses an absolute start or ending location rather than an offset? And you could enter either the beginning direction of motion.

To use your example above, take the motion of your character running north on the park road, have him run instead the east-west road, headed west. You'd extract the motion, enter a starting location, and enter some kind of Yaw coordinate that means "westbound", or pick a location somewhere west of him that he will run towards. (whichever is easiest for you to code.)

Also - or instead - what if you could enter a reference instead of a direction, so he runs towards the specified character? If you set the CAM as the reference, the character will run towards the camera. Cool, huh?

[/ QUOTE ]

Expanding "Translate POS" to "Affine Transformations of POS" (which is basically what you describe) is fairly straightforward. The "Running Towards a Certain Character" should be doable with the right input parameters -- I'd need to think a bit about how exactly to do that.

I'm in the midst of a big project right now, but I'll see if I can fit in some programming time in the next few weeks.

"Translate POS" just adds the offsets to every single visible (ie, ignores lines that are filtered out) POS command. You use it when your movement path isn't correctly positioned in the zone.

For example, let's say that you have a hero running north along the road that's on the west side of City Hall Park in AP. You want to make him run north along the road that's on the east side of City Hall Park in AP. To do this, you want to add some offset to every one of the hero's POS commands. "Translate POS" will do this for you.

If you're moving a list of POS commands from one zone to another, it's highly unlikely that they're exactly where you want them in the new zone. So, you'll need to use "Translate POS" to move them all.



The "Extract Movement Path" wizard just automates the process of using tells to figure out when the motion you care about starts and stops. It's basically just the following procedure:

(1) Filter for chat messages. Record the times. Remove the filters.
(2) Display only the POS and PYR commands between those times.
(3) Extract the visible commands.

Ahh, sorry...missed that one:

Extract Movement Path

This wizard helps you record movement in-game and easily transfer it to a new demo. It works by using self-tells; you'll need a "start" tell and an "end" tell. Log on to the game, start recording a demo, send yourself the "start" tell, move around, then send yourself the "end" tell. Load the resulting demo in the editor, and this wizard will automatically extract the movement between your "start" and "end" tells.

So, let's say that you want to create a demo of four heroes traveling from point A to point B, and we want them to have slightly different movement paths so it looks like they're moving naturally and not in formation. We'll create a few macros:

/macro 1start "tell $name, EMPW start1"
/macro 1end "tell $name, EMPW end1"
/macro 2start "tell $name, EMPW start2"
/macro 2end "tell $name, EMPW end2"
/macro 3start "tell $name, EMPW start3"
/macro 3end "tell $name, EMPW end3"
/macro 4start "tell $name, EMPW start4"
/macro 4end "tell $name, EMPW end4"

Now, go to point A and start recording a demo. Hit the 1start macro, move to point B, and hit the 1end macro. Move back to point A and repeat for the other 3 pairs of macros. Stop recording and load the demo in the editor. Run the "Extract Movement Path" wizard four times, putting the appropriate start and end tells in each time. Each time you run the wizard, it will extract the appropriate POS and PYR commands, using the "start" and "end" tells to figure out where to start and end and which character is the player.

It's a bit unwieldy, as it really should allow you to use only a single start and end tell to grab all four paths at once, but it was the first wizard I wrote and I hadn't quite thought the whole thing through. If I ever need to mass-extract a lot of movement paths from a demo, I'll probably rewrite it to work a bit easier.

[ QUOTE ]
Now all you need to add is a self contained preview loader where you can move objects and characters around in 3d

[/ QUOTE ]

You know, I was actually planning to do something like this before I realized that I don't actually know anything about using 3d computer graphics.

If you have any issues working with the editor, please feel free to PM me.

Here's a basic rundown of the ones you don't have a description for.

The wizards infrastructure was intended to be an easy way to add new functionality to the program without having to mess around with the UI too much. I originally designed the editor to be easily extensible with wizards with the intention of eventually releasing the API so others could write their own wizards. The functionality is there, but I decided that the amount of work required to document and explain the code sufficiently to the few other people who could and would write wizards would be larger than the amount of work necessary for me to just to write wizards for them.

So, if any of you have requests for new wizards, feel free to make them. Requests will be filled based entirely by my comparison of their feasibility and difficulty with my interest level and free time.

Fix Ghosts Wizard

Occasionally, demos have orphaned lines in them that can cause mobs to hang around after they're supposed to be gone. They're called "ghosts" because this usually happens when the player defeats a mob and it fails to despawn correctly in the demo. This wizard fixes that.

Generate PYR from POS

This wizard can create PYR commands in two different ways.

First, it can point the object in the direction of motion. This is useful if you've generated a movement path and just want the character or camera to point forward. You can also use the offsets to adjust the angle of the object, so you can make the camera (for example) constantly point 45 degrees right of the movement path.

Second, it can point the object at another one. I've found this most useful for aiming the camera at the player, although you can also use it to make characters face one another. The offsets here allow you to always face a point with a certain displacement of the target, so you can (for example) always aim at a place five feet to the west of the target. The most useful offset here is the option to auto-calculate the Z offset from the character's height, which will attempt to aim the camera at the head of a character instead of the feet (where the POS commands reference). Note that this only works for characters
with COSTUME commands. I think the button assumes a height of six feet for NPCs, but it may just do nothing for them.

Generate PYR/POS from formula

Allows you to generate PYR or POS commands via parametric formulas. If you have no idea what that means, stick to the interpolation wizard. If you do know parametric formulas, this should be fairly straightforward to use.

Large File Filter Wizard

Huge demos are kind of awkward to work with in my editor, as it's not terribly efficient with memory and such. (AFAIK, it doesn't leak memory, but it has a few redundant representations of things to make manipulating the demo commands easier.) This wizard basically allows you to define a set of filters, then extracts the corresponding commands from a demo file without loading the whole thing into memory. I use this to do things like pull all the player costumes out of multi-hour-long Hami raid demos.

POS Analysis Wizard

This shows the maximum and minimum of the XZY coordinates of the POS commands in the demo. (Not the zone -- there aren't any physical limits on the zone. There was a thread a while back about some players who, on a whim, flew out a hole in the map and tried to fly to the sun. GMs caught them before they made it.) I use this to get a feel for how large the action is. For example, if I want a camera rotating around a battle, I'll export the relevant commands for the characters in the battle into a new demo, use this to find the min and max of their XZY positions, then create a circle that encompasses all of them.

Dummy Player Wizard

The client only renders things within a certain distance of whatever character is marked with the "Player" command in the demo. This creates an invisible NPC that has the same position of the camera and designates it as the player. This is basically just a hack to simulate making the camera itself the player.

I suspect that the DVD case packaging is mostly for the retailer's convenience, as it's the same size as all those other DVD cases that sit on the shelves and easily compatible with the store's DVD security measures.

Well, I'll try to avoid getting into the trig too much.

POS stands for position. In CoH, we often call the coordinates XZY, because the first coordinate corresponds to east-&gt;west, the second to down-&gt;up, and the third to north-&gt;south. The arrows here tell you what direction you'll move if you increase one of the coordinates. If you increase the first coordinate, you'll move west. If you increase the second coordinate, you'll move up. If you increase the last coordinate, you'll move south. (As a quick way to remember these, they all go in alphabetical order: EW, DU, NS.) The units appear to be in feet, but the scale in the game isn't terribly consistent.

So, the line in the demo

POS 74.0625 6.015625 247.640625

refers to a position about 74 feet west , 6 feet above , and 248 feet south of the origin.

PYR stands for "Pitch, Yaw, Roll". The first tells the camera (or anything else) what elevation to point at (to look up or down), the second tells the camera what compass direction to point in (to look left or right), and the last tells the camera how much to tilt the view (so you can look at them sideways, for example). In practice, you usually won't see anything but a zero for roll in CoH.

The units used are radians, which are a way of measuring angles similar to degrees; they're more natural to use in many settings with angles, but they're a bit less intuitive than degrees. There are 2*Pi radians in a full circle, and most PYR angles will have a value between -Pi and Pi. (Remember, Pi is approximately 3.14.)

Pitch and Roll numbers are pretty simple...as you increase pitch, your camera will aim up. Decreasing will do the opposite. For roll, it's easiest to just keep it at zero, but increasing or decreasing it will cause the camera to tilt to the left or right without changing the direction it points in.

Yaw is complicated, mostly because it works differently for the camera and for everything else. For everything but the camera, 0 yaw points south. For the camera, 0 yaw points north. In both cases, increasing yaw turns to the right, and decreasing yaw turns to the left. (Again, LR is alphabetical.)

So, the line in the demo

CAM PYR 0.372 2.452646 -0

means point the camera .372 radians up (about 21 degrees), 2.45 radians to the right of north (which is 140 degrees, so you'll end up facing 40 degrees east of south) and not to tilt the camera at all.

Okay, so that explains what all the numbers mean. How do you move the camera closer to Actor2?

Well, we need to look at the positions of Actor2 and the camera. Subtract their corresponding coordinates (always take the direction you want to travel minus the location you start with):
<font class="small">Code:[/color]<hr /><pre>
70.15625 5.6875 245.640625 (Actor2)
78.639275 10.694046 237.711502 (Camera)

-8.483025 -5.006546 7.929123 (Difference)
</pre><hr />
The difference is the direction vector that you want to move in. There are some ways to figure out an exact distance (travel 3 feet in this direction), but for a quick estimate, you can just multiply all the numbers by the fraction of the distance you want to move from point A to point B.

For example, if you want the camera to be half as far in the close shot as the long shot, just multiply all those numbers by 1/2 to get:
<font class="small">Code:[/color]<hr /><pre>
-4.2415125 -2.503273 3.9645615
</pre><hr />
Add these numbers to the camera's starting location, and you'll get the new POS command
<font class="small">Code:[/color]<hr /><pre>
POS 74.3977625 8.190773 241.6760635
</pre><hr />

Now for the hard part: figuring out the PYR command. You need the camera's location and you have the location that you want to point at. We just computed the camera's location. The tricky thing about the place you want to point is that POS coordinates usually refer to the place something is standing. To point at the chest, you need to point at a location a bit higher than the actual POS of Actor2. If we assume that Actor2 is six feet tall, the chest will be about four feet above the POS location, so just add 4 to the middle coordinate to get the place we want to aim. Again, take the place you want to aim and subtract the position of the camera:
<font class="small">Code:[/color]<hr /><pre>
70.15625 9.6875 245.640625 (target)
74.3977625 8.190773 241.6760635 (camera)

-4.2415125 1.496727 3.9645615 (difference)
</pre><hr />

Since you're a bit uncertain about your trigonometry, I'm just going to throw the formulas out there for you. The variables X, Z, and Y are the three coordinates in the difference above.

Pitch = arctan( Z/sqrt(X^2+Y^2) )

If Y&lt;0, use
Yaw = arctan( Y/X )

If Y&gt;0, use
Yaw = arctan( Y/X ) +/- 3.14

(If X is zero, your YAW is either 0, if Y is negative, or 3.14, if Y is positive. For +/-, pick the opposite of whatever the opposite sign of the arctangent. In other words, add to a negative number, subtract from a positive one. "arctan" is the inverse tangent, which may be written "tan^-1" on your calculator.)

I'm only about 80% sure that these formulas are correct. I figured them out once over a year ago and promptly programed them into an editor so I'd never need to do so again.

How comfortable are you with trigonometry?

If you leave your recipe window open, you can continue to craft in it after the table explodes. Given that, I wouldn't mind if the table hung around longer to reduce window clutter.

The jumper has four different steps: running, jumping up, falling down, and landed. These correspond to the MOV commands RUNPRE, C_JUMPPRE, C_JUMPAPEX, and C_JUMPPOST. The first, second, and last ones of these are easiest: they go at times 1, 1189, and 2971. Scroll down to the POS command at each of these times (use a filter for reference 101 to make it a bit easier), insert a new command, and edit it to have the appropriate time, reference, command, and argument:

1 101 MOV RUNPRE
1189 101 MOV C_JUMPPRE
2971 101 MOV C_JUMPPOST

To find the apex of the jump, scroll through the list of POS commands for the jumper. (Again, use filters to make your life easier.) We're looking at the middle coordinate to find the largest, which should be about 75 -- this occurs at time 2179.

2179 101 MOV_C_JUMPAPEX

We should now have a demo of the jumper running parallel to the truck and jumping on top of it.

Let's do some slightly fancier camerawork -- we'll position the camera slightly above and to the right of the truck and make it track the jumper. We're going to re-use the truck's POS commands to do this.

Create a filter for the truck's POS commands (Reference 100 and Command POS). Hit "Export Commands" to move these to a new demo. In this new demo, select "Change All" to change the reference to -1 (which is CAM, in my editor). Now use "Translate POS" to offset all of the POS commands at once. We'll use an offset of (-5, 15, -30), which will put the camera 5 feet to the right of the truck, 15 feet in the air, and 30 feet in front of the truck. Head back over to the original demo, delete all the CAM commands (create a filter for CAM commands, then "Delete All"), and import the new CAM commands in. (Don't forget to resort!)

Next, use the "Generate PYR relative to POS" wizard again. This time, we want to make PYR commands for the camera. On the last page of the wizard, change "Orient according to movement path" to "Orient on another reference". Pick our jumper, and make sure both "Use CAM coordinates for yaw" and "Delete existing PYR commands" are selected at the bottom of the window. Hit finish.

There's one final thing to do: we need to move the game's focus to the jumper to make sure that everything is being rendered. Find the "Player" command and change the reference from the hero you used to record the original demo (1372, in my case) to the jumper (101). I moved this command to directly above the NEW command for the jumper -- I'm not sure if it's necessary, but that's where it is in game-created demos.

Now, we watch the demo! In my case, there was a small gap visible underneath the jumper's feet after he landed, probably because I used a slightly different truck model than the one I measured the height of. I corrected this with the "Translate POS" button: filter for the jumper's POS commands (ref 101, cmd POS), hit "Translate POS", offset by (0,0,-10), redo the "Generate PYR relative to POS" to make the camera point at his new location, and he now appears to be standing solidly on the truck. Note that this is a perspective trick, as I moved him closer to the camera instead of down -- this is so I don't have to be exact about how far down I move him.

And that's my first from-scratch demo! If you have any questions about the process or if the explanation is unclear at some point, feel free to ask below. If you want some homework, you should be able to use this process to get a shot of a /dev blaster leaping from a building onto a moving Rikti dropship, planting a time bomb on the top, and jumping away before it explodes....

Now let's add some movement for the Jumper. We'll start by having the jumper just running parallel to the truck, then add in the jump and landing. You can just repeat the entire process from above, or you can switch back over to the list you generated in the last step and use the "offset POS" button to just shift the whole thing over a bit. (The correct offset to use would be [51.9,0,0].) Either way, you should be able to get the hero running next to the truck, starting at (1228.7, 41.5, -287.4) and ending at (1228.7, 41.5, -1134.1).

I decided that my hero would jump at time 1189 and land at time 2971, which is 54 frames later. His maximum height would be 75, which is a little more than 30 feet (75-41.5=33.5) above the road. (These were all just arbitrary decisions on my part.) We need to figure out where the hero starts the jump and where he ends the jump. Add a filter for POS commands for the jumper. (Reference 101, "POS" as the command.) We scroll down the list until we find time 1189, and we find that the jumper is located at (1228.7, 41.5, -487.4). Clear the filters and add one for the truck's POS. Scrolling down the list to time 2971, we find that the truck is located at (1176.8, 41.5, -787.4). Remember that the truck is 11.7 feet tall, so we add 11.7 to the Z (middle) coordinate to get that the jumper lands at (1176.8, 53.2, -787.4).

Open the interpolation wizard again -- this time we want "Parabolic". The start time is 1189, 33 ms per step, and 54 steps total. Enter the start, end, and max height, and hit finish. Again, we should get a new demo with the appropriate POS commands.

Before we import these into the original demo, we need to clear out the jumper's unneeded POS commands. Clear all filters (if you have any) and add the following:

T: 1189-50000
R: 101
C: POS
A:

This will display all POS commands after 1189 (until 50,000, which is way past the end of our demo). Hit "Delete All" to get rid of them. You can now import the jump into this demo, just as we did before. Remember to resort the demo!

The last step is to make the jumper move along with the truck. This is just another straight-line interpolation, starting where the jump ended (1176.8, 53.2, -787.4) and finishing 11.7 feet above where the truck finishes (1176.8, 53.2, -1134.1). We compute the number of steps by subtracting the start time (2971) from the end time (5017) and dividing by the step time (33) to get 62 steps. Use the linear interpolation wizard to make a new demo of POS commands, import them into the first demo, and resort.

Finally, we can either keep the hero facing forward the entire time or use the "Generate PYR relative to POS" wizard to make him face in the direction of travel. I just left him facing north.

Next, we'll add in the MOV commands....

The final demo will last 5 seconds. We'll target 30fps, which works out to one frame about every 33 ms. A quick division shows us that 5 seconds equals about 152 frames. We'll need this to use the interpolation wizards in this section.

The truck is the easiest. Hit the wizards button again and choose the "Interpolation Wizard". Since the truck is travelling in a line, we want linear interpolation. Enter the following information:

Start time: 1
Time per step: 33
Number of steps: 152
Reference: 100
Start POS: 1176.9 41.5 -287.4
End POS: 1176.8 41.5 -1134.1

Unselect the "Create PYR" (we'll deal with PYR later), and hit Finish. You should have a new demo with a list of 152 POS commands in it. Head back to "camera.cohdemo" and use the "Import Commands" button to copy this list into the main demo. Hit "Resort" to put everything in chronological order -- you'll want to do this every time you import new commands.

We now need to add PYR commands. Since the truck is moving straight north, we could do this manually, but I took the easy way out and used another wizard. This time, select "Generate PYR relative to POS", select the demo and the truck, and just use the default settings on the last page of the wizard. This will automatically face the object in the direction that it's moving, which is overkill for something moving in a straight line but very nice when movement is more complicated.

That's it for the truck! You can save the demo and load it in CoH at this point (using either the built-in launcher or whatever you normally use to view demos) and you should have a truck driving towards you down the street.

Open "camera.cohdemo" in the editor. We're going to add two new characters, so we need to find a couple of unused reference numbers. Looking at the list on the left, I picked 100 for the truck and 101 for the jumper...it doesn't really matter, though, as long as you use unused numbers.

The truck is easiest. Start by selecting the first line below the CAM lines and hitting the "Insert Command" button twice -- you should see two "NUL" commands appear. (We could add these almost anywhere, except at the very top, as demos need to begin with Version, Map, and Time commands.) Select the first and, in the "Command Information" box on the right, enter the following:

Time: 1
Reference: 100
Command: NEW
Arguments:
(ie, leave the arguments empty)

Hit "Commit".

Now select the second command and enter the following:

Time: 1
Reference: 100
Command: NPC
Arguments: Car_Truck3

This will create a new truck in the demo.

Add two more lines immediately below (or above...again, it doesn't really matter, as long as it's below the first three lines) and put the following:

T: 1
R: 101
C: NEW
A: Jumper
(Jumper is the name of the hero who's going to jump. Feel free to call him something more creative. If you dare.)

T: 1
R: 101
C: NPC
A: Jumper

Now, there isn't really an NPC model called Jumper -- this is just a placeholder for importing the actual costume we'll be using. Head up to the "Wizards" button and select the "Costume Import/Export Wizard". Both the source and the destination demo will be the current one (camera.cohdemo). We want to export the costume from the player's hero and import it onto the new "Jumper" we just created. The process should be fairly straightforward:
<ul type="square">[*]Pick camera.cohdemo as the source.[*]Scroll down until you see your hero. It's reference 1372 in my demo, and it should have a [P] next to the number to indicate that it's the player. Pick that as the source.[*]Pick the first NEW command. Occasionally, there's more than one, but there shouldn't be for the player character.[*]Pick camera.cohdemo for the destination.[*]Select reference 101.[*]Pick the first (and only) NEW command.[/list]Voila! Your hero's costume has now been copied to "Jumper".

Set-up is complete, now on to movement....

The first order of business is to figure out the truck's NPC model and the MOV commands for running and jumping. We'll start with the truck's NPC model.

Load truck1.cohdemo in the editor. We're looking for a particular NPC command, so hit "Add Filter" in the lower right and enter "NPC" (without the quotes) in the command box. Hit okay, and we should have only the NPC lines visible in the center of the window. Scrolling down, there's a "Car_Truck3" at reference 680 that looks promising. (There are a number of different truck models, so feel free to use a different one if you like.)

Next we want the MOV commands for running and jumping. Load up your running/jumping demo. This time, we're looking for the player's MOV commands. Again, we'll create a filter to help. Open the "Add Filter" dialog again and click on the "References" button. Type in your character's name (Balshor, if you're using my demos) to find the correct reference number. Then type "MOV" as the command (again, no quotes) and hit "Add". You should now see a short list of MOV commands for your character.

The names should be fairly self-explanatory. What we want is:

RUNPRE (to make a character run)
C_JUMPPRE (to start a jump)
C_JUMPAPEX (for when you hit the top of a jump)
C_JUMPPOST (for when you land)

Don't ask me what the "C_" prefix is for -- I don't know, and it doesn't really matter. That's all the information we need out of these demos, so feel free to close them. On to the editting!