Questions re gotomarker and faceangles - timing

(Irrelevant) #1

OK, I’ve got a few questions here. I’ve been saving them up again. :stuck_out_tongue:

Just for reference, the manual says:

gotomarker <targetname> <speed> [ACCEL/DECCEL] [turntotarget] [wait] [relative <position>]
faceangles <pitch> <yaw> <roll> <duration/GOTOTIME> [ACCEL/DECCEL]

For clarity (where necessary) I have included square brakets “[]” in this post. These should be read like brackets “()” are in mathematics, showing precedence. For example, in the ambigouous “a man eating chicken”:
“[a man] eating chicken” refers to a male human who is eating a piece of chicken.
“a [man eating] chicken”, however, refers to a chicken that eats people. :smiley:

First, does faceangles block? That is, when you use faceangles, does the script stop executing until the script_mover has finished turning? I’ve got some very inconsistent results trying to find this out myself.

When using ACCEL or DECCEL with faceangles, does this have any effect on how long the rotation takes, or is <speed> still the time in miliseconds?

If I have rotated something <n> degrees in <m> miliseconds using ACCEL, and I want to rotate it a further <n> degrees at constant speed, how many miliseconds should I make this turn take to get smooth movement? To put it another way, how many times faster is [a mover rotated with ACCEL] at the end of its rotation than [one rotated over the same distance and time without ACCEL]?

The help file states that if you use a blocking command, all other scripts running on the current object will stop, and “the stack will not return”. What will happen to [a script on another object] that has triggered [a script on the waiting object] and is waiting for it to finish? Will it just be cancelled, or will it start running again immediately?

Finally, what is the connection between the <speed> parameter of gotomarker, the distance being travelled, and the time it takes to get there? Does the time increase if you increase the distance without changing the <speed>, or what? Exact figures would be nice. (“Moving at a <speed> of 100 over a distance of 32 map units would take 1 second” or something.)

Hope someone knows the answers to some of these… :???:

(grizzlybear) #2

tried to get back to this last wk but mrs banned me from the pc while on holiday :wink:

accel/decell

use this on first(accel) and last(deccel) parts of the mover

i think it needs at least 1 move inbetween to enable it to work
eg:-
accel to point 1 (0 to set speed)
move to point 2 (at set speed)
deccel to point 3 (set speed to 0 where it stops)

it looks good when working (had it working on a dingy a while back)

First, does faceangles block? That is, when you use faceangles, does the script stop executing until the script_mover has finished turning? I’ve got some very inconsistent results trying to find this out myself

depends on where the wait is placed

gototime will make the script and engine work out how long and what speed the mover rotates to get to the finish point at the right angle depending on what speed you set it to move at
(used to blip out if unable to twist in the given distance reletive to speed)

best way i have found to set this correctly is to run et in a window andcrimson editor (notepad)
tweak the script then do /map_restart
and see what changes have taken place and how smooth it looks

(kamikazee) #3

I’m still working on it, but up to now it seems ‘faceangles’ and ‘gotomarker’ mess up the stack in my script… (I’ll post the part I’m talking about when I don’t find a solution in a few days)

My script is one of those target practice ideas (again, god knows how much maps are being made out there with the same theme)

Now what I mean with messing up the stack:
It calls a trigger called ‘move’ for a script_mover. At the beginning of that trigger I call the trigger named ‘reset’, which moves the target back to it’s initial position, flips it upright and resets the “moving” flags. The code in the ‘reset’ trigger is then finished, but my script won’t return to the rest of the code in the ‘move’ trigger.

Are there some particualer things to notice when calling triggers containing ‘gotomarker’/‘faceangles’, is this just a bug/limitation of ET or is it simply a matter moving some commands from one trigger to another? (last thing results in double code, which I hate from coding C )

Anyway, if someone else has seen and/or even found a solution, I would be happy as well to see some answers.

Greetz,
Kamikazee

(LaggingTom) #4

Remove the trigger reset from the move trigger, and have whatever triggers the move trigger trigger the reset trigger, and then the reset trigger should trigger the move trigger.

Whoa… that’s a lot of triggering.

(kamikazee) #5

It’s true, but that won’t work in my code since I have 2 different moves going on (a rotation and a slide), the reset trigger is there to make sure the flags get cleared and the target moved back into place if the script should lockup. That happens, that’s why I needed the reset trigger.

Thx for the reply though, gonna look somewhat to it, maybe I’ll find my mistake.
I’ve looked to the code in railgun and it has nothing to do with gotomarker or faceangles.

About accel, gototime etc. :

gotomarker uses ACCEL/DECCEL to accelerate the object, or deccelerate it. With ACCEL it starts with speed 0 to speed <speed>. I think it is calculated so that when it reaches its destination, it reaches it’s maximum or a zero speed.

gototime: <pitch>, <yaw> and <roll> are no speeds, but the angles the object must be rotated to when the animation finishes. gototime just describes how long the object will take to reach that position, so all speeds are calculated for you.

(kamikazee) #6

I fixed my code, copied some statements so I didn’t need the reset trigger anymore. (If you’re comming from a C background where you put re-used commands in a function, this is ugly coding)

@Irrelevant: Don’t know where you read it about blocking statements, but it is true. Seems it isn’t listed in the old LDR, nor in version 1.1 or did I overlook something?
Anyhow,’ wait’, ‘faceangles’ and ‘gotomarker’ with ‘wait’ as a parameter are blocking commands, and the stack doesn’t return as you said. That was the problem in my script, which is fixed now.