scripting weirdness in a scripted switch

(]UBC[ McNite) #1

Ok what I want is a switch: it either enables something or disables it. And while the thing is disabled, you shouldn’t be able to disable it again…

What I want to use is: a script that triggers 2 events. Both have an accum check in the first line, and only 1 can get executed completely.
In the map I have a func_invisible_user targeting a target_script_trigger which works fine. So when the user uses the func_invisible_user it activates the script_trigger which fires the “used” scriptblock.
This is the script:

radio01
{
	spawn
	{
		wait 150
		accum 7 set 1
		disablespeaker sd_abradiooff
		enablespeaker sd_abradioon
	}

	trigger used
	{
		enablespeaker sd_abradiotr
		wait 100
		trigger radio01 on
		trigger radio01 off
	}	

	trigger on
	{
		accum 7 abort_if_not_equal 2
		disablespeaker sd_abradiooff
		enablespeaker sd_abradioon
		accum 7 set 1
		wm_announce "ON: accum 7 set 1"
	}

	trigger off
	{
		accum 7 abort_if_not_equal 1
		enablespeaker sd_abradiooff
		disablespeaker sd_abradioon
		accum 7 set 2
		wm_announce "OFF: accum 7 set 2"
	}
}

Only what happens is:
Start of map: switch and sound is on… everything fine.
I activate the func_invisible_user, and get “OFF: accum 7 set 2” and the sound switches.
Upon activating the func_invisible_user again, I get both messages which means both blocks get executed completely.
And that can’t be… (or I just don’t see it)

I did already check whether the scriptblock gets started more than once, but there is only 1 entity in the map which the scriptname radio01. Also accum 7 gets only used in the script radio01.
As far as i can see, this scriptsetup is NOT linear, and both the OFF block should not be executed after the ON block, right?

Ideas anyone?

(nUllSkillZ) #2

Try to add a “wait” command between:


...
      trigger radio01 on
      trigger radio01 off
...

I think the script is executed very fast.

(kamikazee) #3

@nUllSkillZ: They simply get run one after another, no matter at what speed it runs.

@ ]UBC[ McNite:
The “on” trigger gets run, sets accum 7 to 1. After that, the script returns to the “used” trigger and it calls the “off” trigger. Accum 7 is now set to 1, so it runs as well.

Way to fix this: make sure the “on” and “off” trigers do not return by adding “resetscript” or a “wait 10” command to both.
They both stop the script from returning to a trigger in the same script block, I found out the hard way.

(sodsm live) #4

if i take your meaning - ie, “press button, turns radio on, stays on. press button again, turns radio off, stays off. and so on…”

the ladder hatch switch in sea wall battery acts like this. it operates a script mover but can be used for anything. i’ve used that code a few times in different situations and it works well. wouldn’t really call it stealing code since it’s basic programming logic from the 50’s adapted to ET script.

if i’m off base then nevermind.

(]UBC[ McNite) #5

The tipp with the wait did the trick. Put a “wait 20” at the end of both of the 2 blocks… problem solved. Thx Kami!

(kamikazee) #6

@sodsm live:
I think it works there because the script has an implicit wait from the “faceangles” statement.

@]UBC[ McNite:
You’re welcome. :slight_smile:
My first post on this forum was about a similar thing, back then the wait worked against me.

(sodsm live) #7

there i go again, cluttering up someone else’s thread

(]UBC[ McNite) #8

Hmmm how am I supposed to start 2 or more scriptblocks AT ONCE in case i need them executed simultaneously then? Since what I did above makes them run one after another (as long as I don’t put a wait in them).

(Shaderman) #9

You can trigger a trigger_event in all scriptblocks with trigger global <trigger_event>.

(Chruker) #10

Hmmm how am I supposed to start 2 or more scriptblocks AT ONCE in case i need them executed simultaneously then?

If I remember correctly:

  • When you trigger a routine in another scriptblock, a hole ‘new’ processing thread is created, which runs simultaneously.
  • When you trigger a routine in your own scriptblock, the game processes the new routine and then returns to the caller if a few conditions are met.

Anyway resetscript would in your case be the cleanest way to make sure it doesn’t return.