resetscript - explain please :)

(damocles) #1

Take a look at this:

frontdoor_trigger1
{
	spawn
	{
		accum 5 set 1			// Initial state is down
		wait 500			// Wait for everything to settle
		trigger frontdoor_trigger1 main	// Open front door of complex initially
	}
	trigger main
	{
		globalaccum 1 abort_if_not_equal 0
		trigger frontdoor_trigger1 up
		trigger frontdoor_trigger1 down

	}
	trigger up
	{
			accum 5 abort_if_not_equal 1	// Ready to run up routine == 1
			resetscript			// return to trigger that called it

			trigger frontdoor_lever1 up
			accum 5 set 0			// Setup accum for up routine
	}
	trigger down
	{
			accum 5 abort_if_not_equal 0	// Ready to run down routine == 0
			resetscript			// return to trigger that called it

			trigger frontdoor_lever1 down
			accum 5 set 1			// Setup accum for up routine
	}
}

It’s a section from battery.script. I am particularly interested in the trigger up routine…

	trigger up
	{
			accum 5 abort_if_not_equal 1	// Ready to run up routine == 1
			resetscript			// return to trigger that called it

			trigger frontdoor_lever1 up
			accum 5 set 0			// Setup accum for up routine
	}

If you notice, the function startes by saying it should abort the function if an accum is not set to 1. This is the opened/closed state of the door and makes sense to me. But then there’s the resetscript call with the note saying it’s returning to the trigger calling it. Obviously it doesn’t do this or otherwise the door would never open, so can someone coughbobcough give me a detailed, not laymens defintion, but in fact using detailed programmer jargon explanation of exactly what resetscript does and why it’s in the door script like that.

(digibob) #2

All resetscript does is basically “wait 50”.

This does however have a cool side-effect which can be used to your advantage.

Due to the nature of RTCW/ET scripting, any command that causes execution of a script event to halt, such as a wait, or a movement command, will set the current event as the only active event for that entity. That is, if that event was called from another event on that entity, in this case up/down being called from main, the script will NOT return to main after up/down are finished ( whichever one hits the resetscript line ).

If you know that either function will definately halt anyway, you can ignore doing this, but it can be benifitial to emphasise what is going on.

(damocles) #3

Ah I see. Great feature, but quite possibly the worst named feature ever :smiley:

(Stektr33) #4

I sincerely apologize for being slow here, and asking you to re-explain this, but I don’t understand what you’re saying as the side-effect is to using resetscript.

I understand:

and that if this example was represented as a call stack that instead of the call stack being:

up (or down)
main

it simply becomes

up (or down)

consequently not returning control to the calling function (‘main’ in this case).

But then you say within this context:

Which leads me to believe that resetscript ALSO makes the current event the only active event as to not returning control back to the caller (main), just as you described what wait does. So what’s the difference then?

EDIT: the only difference I see is that resetscript is a hardcoded “wait 50”

(digibob) #5

RTCW/ET have no call stack, at least not in the normal sense. When you do a “trigger entity name”, it creates a temporary call stack. If execution halts ( even if only temporarily ) somewhere down the line, the current event is set to the top of the call stack, and the rest of the stack gets lost to the ether. Resetscript checks if the frame it was executed on is the current frame, and if so, halts execution ( since a frame ( normally ) is 50ms, this is equivilant to “wait 50” ).

I hope that explains everything.

(sock) #6

Try this link: http://www.planetquake.com/simland/pages/wolftut/tut01_door1.htm the nuts and bolts section. This is a small code section me/djbob did last year exploring the wierd function of “resetscript”.

Sock
:moo: