crane in SP_rocket


(kat) #1

mmmm… ok so I tried to decompile the SP_rocket level to take a look at the crane (the one at the start of the level) and how that works, only non of the ‘script’ related stuff shows in the decompile (bad bspc…!)

I have a crane in an SP map I’m doing and although I have a basic understanding of what to do to get things moving what has really been puzzling me is this… if you watch the crane move in the SP_rocket map the ‘hook’ moves up and so too does the ‘cable’, it doesn’t project out the top which I was expecting. Same goes for when the crane moves over the hatch and drops down, the cable seems to ‘extend’… where does this ‘extra’ brushwork (the extended cable) come from, is it an automatic process so that with the whole crane as a script_mover (not sure about this which is why I tried the decompile) it simply ‘extends’ the way it does??

I’m ‘worried’ as my crane covers a loooong distance from top to bottom… any ideas??


(digibob) #2

it’s made out of multiple little script_movers, which is kinda messy, but it’s what you gotta do to get around the fact that a single brush would stick out of the mecahnism.

welcome to our humble little forums Kat :wink:


(kat) #3

ah so that would explain why the script for that section is so big… all the little script_movers are ‘tied’ together in the script, I thought it might be someting like this, just wasn’t sure… [goes into shock as realises what needs to be done for the script to work]

Thnx for the ‘welcome’ djbob, sock put me onto this place from Q3W… seems like very nice hang out if somewhat quiet at the mo…!


(sock) #4

When I first saw the rocket map file I was amazed at how they did the crane as you rightly say it does not poke brushes out of the top of the crane when lowering/raising the hook. Its certainly a very complex section of scripting and very very time consuming to setup.

The crane top section is made up of 2 sets of solid brush script_movers called “crane1coil” and “crane1arm”. (Please note the origin brushes are down at the same level as the fuel cage for both script_movers)

Underneath the crane is the fuel cage with an origin brush (at the top of the brushes) for linking purposes. The cage walls are also coated in “common/ai_nosight” brushes so that the AI characters cannot see the player when the crane cage is moving around.

The crane’s hook and wire is made up of 12 script_mover brushes called link1-12. They consist of a 16x16x16 (X/Y/Z) origin brush and a 2x2x32 brush for the wire.

Finally the crane hook is made up a wire brush 2x2x93 with a brush hook at the bottom and a origin brush below that. This script mover is called “crane”.

Probably worth mentioning at this point that most of the crane operation is triggered via dummy script_movers. Because the way the script system works you cannot have multiple running threads inside of one script_mover entity. You can have multiple script_mover sections of script running at the same time but not within the same routine. (eg entity states like spawn, trigger, death etc)

So with most of the SP maps, Greymatter created dummy script movers called (counter1-5 in the rocket script) which control most stuff in the map.

Counter1 - controls the starting of the crane routine via the AI script.
Counter2 - controls various level wide speaker stuff. Like rocket test and final countdown of rocket.
Counter3 - German character AI checks on states of various bits around the map.
Counter4 - Controls the way the rocket room blows up in 4 DIFFERENT ways! (talk about flexibility :wink: ) Also blows the bridge on the way back to the exit. Will also stop the crane if the mech dude is dead or has run off due to gun fire. (Also worth mentioning is that the way the script stops the crane components with the stop/resume functions. This could come in useful. :wink: )
Counter5 - Deals with the alarm system, various misc global sounds and destroying the v2 rocket. Script movers cannot destroy themselves so its done via another script_mover routine.

As you can see alot of stuff is done via these dummy script_movers in the map. They simply consist of 1 “trigger” texture brush and an 1 origin brush.

Before anything happens in the map the script has got to put all the components together. So these script sections put everything together.

Crane1 (Line 924-1131) moves to the clspot6 path_corner directly above the fuel cage. The wait before this move is so that all the map entities spawn first. Sometimes entities do not spawn in the right order in the map so its always good practice to put in a slight pause in the script before any entity movements.

This script mover controls the crane movement throught the whole sequence has various routines here to move the above script_mover components around. With the above knowledge of script_mover components this script section is self-explainatory.

Cranecoil1 (line 1133-1171) entity really just follows the crane entity around and has very little script stuff to do.

Crane1arm (line 1173-1199) entity again is mainly controlled from the crane 1 script_mover.

Fueltank1 (line 1201-1479) entity has to follow the train around the map so it has alot of stuff for movement around the track. Most of the early movement is controlled via the crane script_mover.

Link1-12 (Line 1831-2525) are the tricky bits of the map and when they start up they are all moved to the same location called “link1spot1a” (path_corner entity) Some of the links are used for picking up the fuel cage and then the rest are used over the rocket bay doors. The script movers are moved one by one to various path_corner entities like a extending a telescope and back up again afterwards. the key here is to note the speeds at which the entities are moved and to keep them consistant during the creating of the crane wire.

BTW kat welcome to the forum and I hope that helps. :razz:

Sock
3d Brush Monkey


(kat) #5

Thnx for that sock, it helps a great deal. I kinda assumed the crane was split into ‘sections’ (as bob mentioned) as you can see this in the script, just wasn’t entirely, 100% sure…!

I think I may making things a tad difficult for myself as I was trying to set up by ‘default’ a trigger brush that triggers (by the playing walking thru) the crane sequence (bots, talking, movement and crane up), but also once the player had killed the bots he could then trigger the crane sequence (on pressing the button the crane would have to comeback down if he allowed the sequence to play - so it also means setting up ‘and’, ‘or’, ‘if’ statments)…

mmmmm, boy… talk about jumping in at the deep end…! I can just about manage to get a bot walking between two points…!!


(demonspawn) #6

Wow, holy crap!!!
I, like kat need to come up for some air.
Thanks sock and djbob for the great insight and info.

If this is the kinda support you guys give during development, you’ll have every mapper on-board when you ship.

Map on


(sock) #7

On 2002-07-08 22:52, demonspawn wrote:
I, like kat need to come up for some air.
Thanks sock and djbob for the great insight and info.

Thanks, glad you liked the explaination. If you have a question on how something works in the orginal maps then just ask. Its hard enough mapping for RTCW without the mystery of how things work in the original maps.

Sock
3D Brush Monkey


(kat) #8

well… just thought I’d update you on crane progress… after (several times) reading what you guys wrote I understand a bit better what’s going on… I mentioned my crane had a long distance to cover…!!! well hows about this 75 script_movers making up the ‘cable’ sections 2x2x64(ish), I now see what you ment sock about it being a long and fiddly process to set up… :roll:

(ooo also got my bots talking for the 1st time… as a scriptmonkey friend keeps telling me “it’s keeping track of it all that’s difficult”…!!)


(sock) #9

Kat: If you are using 75 small sections then maybe try larger sections to reduce the crane cable length and the burden on your script. All the script_mover sections are stored in the same space and extend like a telescope so you could condense the amount of sections to accomodate the final length of the cable.

Sock
3D Brush Monkey


(kat) #10

I did try longer sections but when test moving them in GTK to see what would happen they stuck out the top of the crane, its an arse to have this many S_M’s but it’s the only way I can do what I need to do …


(digibob) #11

make the crane taller then :razz:


(kat) #12

mmmmm, crane’s behaving funny now…!!
I’ve got a basic script running between 5 'marker’points, when I 1st started it ran thru all of them but for some reason now it’s missing 'marker’points out, I’ve not commented anything out, the crane has an origin brush (script_mover) but it has under gone several ungroupings / re-groupings as I change the way it looks… that wouldn’t effect it’s movement would it???

[EDIT - sometime later] I think I figured out what was happening… re-read thru the scipting defs and there the ‘wait’ param (on the same line as the ‘gotomarker’) that can be used to stop the script running ahead of itself, I didn’t set this so maybe that’s what was happpening

[EDIT even later] yep needed the ‘wait’ on the same line as the gotomarker command…


(cacabunny) #13

Hey guys, my name is Mike Denny, I work for Gray Matter Interactive Studios. I just want to thank you for taking the time to look thoroughly through the Rocket map. The rocket map is my favorite map out of the entire game, just because I tried to put a lot into it. I like the other maps I scripted, but for me I think Rocket is my fav.

The process of making the crane work is not as difficult as you may think… The hardest part I think is just setting up the entities (path_corners and script_movers) not really scripting, just making sure they will line up in the map.

If you notice, when the cable/hook actually go down, they overlap a bit, that’s because of the timing with the Wolf engine… It bothered me forever, but that’s besides the point.

Another thing to mention is that the hook (attached to the cable) is 113 pixels long, because that piece never goes inside of the crane. So, we can cheat a little there.

Uhh… Let’s see. Once you get the main peice moving (cable with hook) it’s all pretty much copy and paste. You will have to setup a final destination path_corner for each cable link, which kind of sucks, but it’s the only way in wolf.

Oh! :smile: The gotomarker blahspot 50 wait. :smile: You forgot the wait, yea, the reason for having no wait is if you wanted to rotate while the script_mover is moving. Thus having a truck turn around a corner or something…

Well, let me know if you guys have any questions at all… I will try to look at this forum often.

Thanks,
Mike


(kat) #14

ah ha…!!!
so the culprit has returned to the scene of the crime to marvel at the carnage…!!!

as I’ve been building the map and got the various sections sorted out for the crane and the thing I’ve noticed is the timing… to me that’s the hardest thing to get right… each section has to be sync’d so it all works as a single unit, so I’m finding myself spending a lot of time ‘timing’ how long things take to do what they’re doing.

thnx for the additional comments… :o)


(cacabunny) #15

Hey Kat. :smile:

Cool, well, don’t TIME it… Trigger it.

So, once the 1st link hits a certain path_corner, then trigger then next one to go.

Example and reason:
Each link has an origin at the same point on the link. So therefore you will need to put a path_corner where each link will be going (final destination). So you should have a like a path of path_corners from the ground to the crane.

This is how you know when to trigger the next link to go. Since each path_corner will be evenly spaced apart from one another, just have it so when the 1st link is at the first path_corner (under the crane, going down), then trigger the 2nd link to go. Then when the 2nd link is at the first path_corner (under the crane, going down)trigger the 3rd one to go, and so on.


(cacabunny) #16

<FONT FACE=“Courier New”>


|Crane|


 [] &lt;- Path_corner of last link final destination


 []


 []


 []


 []


 []


 []


 [] &lt;- Path_corner of 1st link (final destination)

Link:

| <-Brush
|
[_] <- Origin

So, again… The 1st link will trigger the 2nd link to go when it gets to the path_corner of the last link.


I am cacabunny
</font>

<font size=-1>[ This Message was edited by: cacabunny on 2002-07-23 00:50 ]</font>


(kat) #17

ah ha…
I had the basics positioned (as per your l33t ascii art) but I was wondering whether there was an easier way to ‘sync’ eveything, that really clears things up a couple of things ( a lot actually…!)… :cool:

[EDIT] bear with me on this one as I’m still trying to get my head round scripting… does that mean that each ‘link’ has it’s own script section??

So if you have a player actived button (for example) you’re triggering the chain of events to happen from there, so you’d include all the events you wanted to start at the same time from that event (like the crane and the cable starting at the same time??)

trigger player_button
{
trigger link1 go_to_next_point
trigger crane_section go_go
}

link1
{
trigger go_to_next_point
{
gotomarker path_corner wait
trigger link2
}
}

link2
etc…
etc…

crane_section
{
trigger go_go
{
gotomarker…


(sock) #18

On 2002-07-22 22:19, cacabunny wrote:
The rocket map is my favorite map out of the entire game, just because I tried to put a lot into it. I like the other maps I scripted, but for me I think Rocket is my fav.

Welcome to a our little corner of the internet, glad to have you around.

Yep rocket SP map is certainly the most feature rich of all the Wolf maps. Its a shame that the scripting features of rocket did not make it to some of the maps. Very few exmaples of complex lift designs. :razz:

Sock
3D Brush Monkey


(cacabunny) #19

Hey Kat,
Yes that is exactly correct.


(kat) #20

[Homer]woohoooooo…! me crane works…!!![/Homer]

just a bit of tweeking and it’s there :grin: big thnx for the help guys