Falling crates.

[riceplant]

I want to make some. I tried making a crate into a func_train, which moves along it's path and "falls" on some troopers below when the player uses it, but it starts moving as soon as the level loads. Also, using a func_train, there is no way to make it rotate about the X-axis, as happened in ns hideout in JO. Does anyone know how I can make this work?

[SMoKE]

Have you noticed the first part in t3_rift.bsp, where you'll have to use Push to move the rock which is blocking your way out? It's done with some scripting, but *sigh* I don't know how...

[riceplant]

The main thing is the train starting up by itself, even though start_on is cleared. The rotation would just be a bonus. All these problems, and on my birthday, to.

[SMoKE]

Is it? HAPPY BIRTHDAY :clap2:

[wedge2211]

Func_trains can't rotate, and in MP, they always start on. Use a func_door for the simplest falling action, but if you want any more complex control than straight-line movement, you'll have to use scripting--perhaps reusing one of the Raven scripts will work well enough.

[riceplant]

Thanks, SMoKE.

 

As for the crates, a door wouldn't work, as they need to move sideways before falling. I don't get it, because I'm in SP, and the train is still starting on. I've just started on BehavEd, but can't find a tutorial beyond basic camera movement.

[kessno11]

I have GTK Radiant 1.4.0, once you have it opened in JA go to help then Jedi Academy, there should be a " ISCARUS" manuel there. (That's BeHavEd;)

 

It's got some good advice for scripting there.

[lassev]

Search for some scripted elevator threads here at LF (also for JO, because it's the same). Just add a rotate command if you want rotation.

 

The main issue would then be the choice between linear and nonlinear movement. Linear would look strange in the beginning, because of the instant full speed, but at least the crate wouldn't decelerate before hitting the floor.

 

For truly great and smooth movement a custom roff would be the best solution... But those are hard to come by...

 

 

Originally posted by kessno11

...there should be a " ISCARUS" manuel there.

Hmm..? Icarus, from the myth of Daedalus & Icarus.

[riceplant]

Okay, I scripted the move, but when I use the crate, it just vanishes. I know it's good that the script is doing something, but it would be better if it did what I wanted it to do. Here is the code as generated by BehavEd (and edited by me so it would compile. It originally generated "affect ( $crate$...". I don't know why, but I was right to change it, right?).

//Generated by BehavEd

rem ( "comment" );

affect ( "crate", /*@AFFECT_TYPE*/ FLUSH )
{
move ( $tag( "crate", ORIGIN)$, < 1096.000 872.000 296.000 >, 1000.000 );
rotate ( < 0.000 0.000 90.000 >, 1000.000 );
wait ( "1000" );
move ( < 1096.000 872.000 296.000 >, < 1096.000 872.000 -64.000 >, 1000.000 );
}

 

And those vectors are copied and pasted from the ref_tags I was using before I decided to try it with raw vectors to see if that would fix the problem.

 

EDIT: I think I found where it is going to using r_showtris. I see a crate-shaped object located below my level, but whenever I enter the void to look for it, it vanishes again. I checked in radiant, and there is nothing where it goes to.

[lassev]

I spot some pecularities here.

 

You said you wanted to use absolute vector values, yet you have the tag in your first move command.

 

Your use of the rotate parameter in the move commands is twisted. Keep in mind that icarus only uses absolute angles for rotation, never relative. So, < 1096.000 872.000 296.000 > (and the other) are wrong, although I suppose they would do something.

 

Also, your naming conventions could use some enhancing. Although "crate" for the crate entity would be a script_targetname and "crate" for the ref_tag would be a targetname, it's still unwise to use the same name twice. At least I would never do such a thing in fear of a conflict.

 

Well, in case you just don't know the correct syntax for the this particular move command you are using, it's:

 

move <target coordinates>, <target angles>, <time for operation>

 

And when you enter void in game, the game doesn't draw any entities anymore.

 

And make sure your crate entity has an origin brush, if you move it with scripting. Otherwise it uses the map origin as it's origin, and that's less than convenient most of the time, especially for rotations...

[riceplant]

OK, well, it's improved... I think... It now just slides into the wall rather than vanishing completely, but still doesn't fall on the stormtroopers.

//Generated by BehavEd

rem ( "comment" );

affect ( "crate", /*@AFFECT_TYPE*/ FLUSH )
{
move ( $tag( "crate_1", ORIGIN)$, <0 0 0>, 1000.000 );
rotate ( < 0.000 0.000 90.000 >, 1000.000 );
wait ( "1000" );
move ( $tag( "crate_2", ORIGIN)$, <0 0 0>, 1000.000 );
}

[lassev]

Ah... The classic error. I only spotted it now, since I don't really have an eye for that particular one, as I've never made it myself (well, maybe once, a long time ago...).

 

Your wait command is a task wait, not wait for time. It means the script stops there for indefinite time, as the task called "1000" will never be finished, as it doesn't exists. Change that wait to the other one in BehavEd.

 

And confirm the entity you are trying to move does have a proper origin brush (I'll keep bugging you with this until you verify it does have it ).

[riceplant]

I've fixed the wait command, though I thought it unlikely that would fix my problem. I do have an origin brush (Now), and the location the crate is moving to has changed, but is still not where I want it. It's funny you say that about the move command, as I got the syntax from the manual. You must be right, however, as the crate doesn't fly off to <0 0 0>. That said, it doesn't move to my tags either. I remember someone elses problem where something flew to an empty space instead of a ref_tag, but can't think why that would happen.

[lassev]

Yeah. As you noticed, the manual is a bit faulty over there. Now, I'll tell you a secret: If you have to choose between info from the manual and info from me, choose the latter!

 

Anyway, what comes to the entity moving elsewhere than intended, it's most of the time either an issue of a missing origin brush or an issue of a faulty tag. I might be wrong, but it's a good guess that a call to a nonexisting tag from a script would produce a vector value of <0 0 0>. That would mean the object flies to the map center instead of the intended place.

 

Take care your target ref_tags have just ordinary targetnames without any too elaborate names, and you call those targetnames exactly right, with capitals and all in place.

 

If it doesn't seem to work, have a look at the Raven example maps. They are filled with scripted, moving objects, after all.

[riceplant]

In responce to your first statement: I totally believe you. I actually noticed the manual says that 'else' is not available in BehavEd yet. I just did some analysis of the system in game, and I think everything points to an incorrect origin (Like you thought). Here is a transcript of the console:

]where func_static
func_ststic (0.00 0.00 0.00)
func_static (0.00 0.00 0.00)
func_static (0.00 0.00 0.00)
func_static (1096.00 872.00 -64.00)
]where player
player (1136.84 855.42 -71.88)
]where player
player (2180.43 1781.12 288.13)

Firstly, the first three func_statics are actually static, so don't have an origin. The fourth set of coordinates is where the crate is actually supposed to move to, and the second set of player coordinates is where it actually moves to. Could you just run through how to create an origin one more time for me, please? I can only conclude that I'm doing it wrong.

[yangyan]

how to create an origin? dont you just make a brush and texture it with system/origin or something?

[riceplant]

Okay, it works now. Seems that my origin brush wasn't working, so I added an origin key and it works just fine. The only issue now is how to make the movement look more realistic. Does anyone have any suggestions?

[yangyan]

uhh.. make it bounce when it hits the ground, make it swing around while in the air if its being held by somthing loose, do alot of rotations, lots of bouncy things, make it perfect, study physics, do the exact calculations and dedicate your life to making a crate look cool.

[lassev]

Originally posted by yangyan

uhh.. make it bounce when it hits the ground, make it swing around while in the air if its being held by somthing loose, do alot of rotations, lots of bouncy things, make it perfect, study physics, do the exact calculations and dedicate your life to making a crate look cool.

 

Hmm..?

 

Originally posted by riceplant

Could you just run through how to create an origin one more time for me, please?

 

- - -

 

The only issue now is how to make the movement look more realistic. Does anyone have any suggestions?

Draw a small brush with system/origin shader selected. Then select both the actual visible crate brush and the origin brush, and turn them into a func_x.

 

Unfortunately a really good looking falling crate would require a custom roff file. Icarus commands are only good for linear movements with clear start and end points and no acceleration / deceleration, for example a lift, or some simple machine part, and things like that.

[riceplant]

That's how I thought you made an origin, and that's what I did. I don't get why, but it didn't work, and an origin key does. As for roffs, they are the reason it took me so long to figure this scripting out, as there are no uncompiled versions! I don't suppose you know how to make them, by any chance?

[lassev]

Well, I know something of the theory of roffs, but since they can only be made with 3D Studio Max v4 or v5, I haven't ever made them myself... But they shouldn't be hard to make, if you happen to have either of those two 3DS Max versions and know how to use it...