Script doesn't reset properly

[Boothand]

I have two scripts, one that opens a door and one that closes it. And one button for each script. The buttons get deactivated while the door is moving, and only the button that will send the door any way is active at any point. The problem is that when the door gets back down and my button for sending it up again becomes active, the door doesn't move anymore. How do I make it reset itself properly?

 

Here are the scripts:

 

 

Door opener: (this one is affected by the "upwards" trigger)

//Generated by BehavEd

rem ( "opens door in beginning of map" );


affect ( "bbdoor_trigger_downwards", /*@AFFECT_TYPE*/ FLUSH )
{
set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "true" );
}




affect ( "bbdoor_trigger_upwards", /*@AFFECT_TYPE*/ FLUSH )
{
set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "true" );
}




affect ( "bb_door1", /*@AFFECT_TYPE*/ FLUSH )
{


task ( "moveup" )
{
move ( $tag( "bb_doortag2", ORIGIN)$, < 0.000 0.000 0.000 >, 1000.000 );
}


dowait ( "moveup" );


affect ( "bbdoor_trigger_downwards", /*@AFFECT_TYPE*/ FLUSH )
{
set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "false" );
}


}

Door closer:

//Generated by BehavEd

rem ( "sends the door down again" );

affect ( "bbdoor_trigger_downwards", /*@AFFECT_TYPE*/ FLUSH )
{
	set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "true" );
}


affect ( "bb_door1", /*@AFFECT_TYPE*/ FLUSH )
{

	task ( "movedown" )
	{
		move ( $tag( "bb_doortag1", ORIGIN)$, < 0.000 0.000 0.000 >, 1000.000 );
	}

	dowait ( "movedown" );

	affect ( "bbdoor_trigger_upwards", /*@AFFECT_TYPE*/ FLUSH )
	{
		set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "false" );
	}

}

Both of my triggers have the use_button checked, but nothing else. Scriptrunners have no spawnflags.

[Asgarath83]

mmmm instead of set_inactive parameter of icarus, try to using two target activate and deactivate, a couple for each door.

make they with a script_targetname key, so icarus can recognize they four. every door need a target activate and a target deactivate and they need to be linked to the door.

 

target activate1 -> door1

target deactivate1-> door1

 

target activate2 -> door2

target deactifvate2 -> door2.

when using the button yu run the script. into the script you setting a deactivation of the door and after, a reactivation through the targets entitities. i think should be work, i remember a map when i used activate and deactivate for 2 target prints. praticallythe character need to destroy 2 artefact for down a elemenal shield of darkness and complete the level.

for each demolition appear a script of advice. but the advice are different, so i was need that the second destruction deactivate the first print to show again. well, was very complicated to do. however i supppose that deactivate and activate entity target can manage your doors better of icarus. yu need simply to put in the script

"use "target deactivatename" and after a lot of time... use "targetactivatename" so the door still reset.

[Boothand]

Actually there is no problem with the activating and deactivating. The problem is that the "move" command doesn't happen the second time the "upwards" script runs. I'd much rather solve this issue with Icarus because I have the same problem in other scripts.

 

For example, I have one script that runs a looping animation on a brush. Then when you press a trigger, it will run a different script on the brush, and in the end of it, it will run the idle script again. This almost works, because when it runs the idle script again, it only runs the animation once, and the loop never happens. So instead using workarounds, I'd rather just know why the scripts don't run as they should

[Asgarath83]

Actually there is no problem with the activating and deactivating. The problem is that the "move" command doesn't happen the second time the "upwards" script runs. I'd much rather solve this issue with Icarus because I have the same problem in other scripts.

 

For example, I have one script that runs a looping animation on a brush. Then when you press a trigger, it will run a different script on the brush, and in the end of it, it will run the idle script again. This almost works, because when it runs the idle script again, it only runs the animation once, and the loop never happens. So instead using workarounds, I'd rather just know why the scripts don't run as they should

Oh, is easy to fix: yu need simple to use the flush function (the red symbol, not the affect, entity, flush) in your script. this delete and reset every script are running on your entity for avoid overwriting and sovrapposistion of the commands. i am a bad coder, but i know well icarus. i setted t1_fatal level for is a time level LOL. so, if the player not disarm the 5 bombs in 25 minutes of game... BOOOMMM...! like t1_rail if yu pass over the bomb on the hovertrain LOOOL if the five bombs are deactivated i used the red flush command for delete the deadly count to the total destruction if work for a bomb, work surely for 2 doors. use flush and reset all scripts. every script are running on the entity, with flush command are deleted and the entity is clean for new istructions.

 

otherwise, if doors was NPCS, should works SET_ANIMHOLDTIMEBOTH : 0  but they are not NPC, so yu need something that reset the looping. the red flush command of icarus should be work.

[Boothand]

Unfortunately I've tried using flushes and they make no difference, it seems no matter how I do it!

 

Here's a test map you could try, to see exactly what happens + the source files. https://dl.dropboxusercontent.com/u/58757568/scripttest.pk3

Just go behind those brushes and press use.

[Asgarath83]

Ok now i look.

[Asgarath83]

Ok i see.

3 errors.

1: in the opendoor script, yu set the closetrigger as inactive, true. setting on on inactive, false. because need to work for closing the door.

2: yu need to create the door as func_door setted for used in up \ down direction, yu can specify this with the angles. not as func static. yu need to set the door as toggled. yu not need the ref tag with a toggle door, a toggle door stay open until not be used again.

3: yu use deactivation script when the door run, so trigger cannot influence it move. yu need to create a target_activate named with script_targetname and targetname parameters. the activator need to be connected to the trigger of opendoor script.

in the script of closedoor, yu need simply to set at the end

USE "target_activate name". the trigger for re open the door is reactivated by the target_activate entity.

 

is an issue of the func_static, however, is better if yu use func_door for that kind o things. is more adapt of func_static. to me func_static has ever done some troubles. i try to avoid to use func_static as entity, a func_door is more controllable.

[MoonDog]

I usually use a single script for this, and just setup parameters on my entities. That way I can have like 292929292 doors, but only one script to work all of them.

//Generated by BehavEd

rem ( "First block checks is door down" );

if ( $get( FLOAT, "SET_PARM1")$, $=$, $0$ )
{
	set ( /*@SET_TYPES*/ "SET_PARM1", "1" );
	rem ( "If it is, set to up" );
	set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" );
	rem ( "Turn off the trigger" );

	affect ( $get( STRING, "SET_PARM3")$, /*@AFFECT_TYPE*/ FLUSH )
	{
		rem ( "script_targetname of door" );
		move ( $get( VECTOR, "SET_PARM1")$, $get( VECTOR, "SET_PARM2")$, $get( FLOAT, "SET_PARM3")$ );
		rem ( "Vectors set on parms on door" );
		wait ( $get( FLOAT, "SET_PARM6")$ );
		rem ( "parm6 is the wait time, set on the func_static" );

		affect ( $get( STRING, "SET_PARM7")$, /*@AFFECT_TYPE*/ FLUSH )
		{
			rem ( "String parm7 is the script_targetname of trigger" );
			set ( /*@SET_TYPES*/ "SET_INACTIVE", "false" );
		}

	}

}


else (  )
{
	set ( /*@SET_TYPES*/ "SET_PARM1", "0" );
	set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" );

	affect ( $get( STRING, "SET_PARM3")$, /*@AFFECT_TYPE*/ FLUSH )
	{
		move ( $get( VECTOR, "SET_PARM4")$, $get( VECTOR, "SET_PARM5")$, $get( FLOAT, "SET_PARM3")$ );
		wait ( $get( FLOAT, "SET_PARM6")$ );

		affect ( $get( STRING, "SET_PARM7")$, /*@AFFECT_TYPE*/ FLUSH )
		{
			set ( /*@SET_TYPES*/ "SET_INACTIVE", "false" );
		}

	}

}

 
It's been a while since I used this, let me see if I remember what's going on.
 
parm1 is the status of the door. 0 being down and 1 being up. This parm is set on the trigger_multiple initially as the key "parm1" value "0". The trigger_multiple is also given the key "usescript" and the value of this script's name and file path. At this point the script sets the trigger as inactive before continuing. This is mostly to help prevent player error.
 
Now, the script looks at key: parm3 on your trigger. This is a string that tells it the name of the func_static you wish to move. (The script_targetname on the entity you are going to be moving.)
 
Example:
 
Key: parm3
Value: myCuteDoor1
 
Now, we are running a block of commands on myCuteDoor and thus can now fill out the parms on your cutedoor func_static entity.
 
Parms 1 and 2 on the func_static are vectors. 1 being an origin, 2 being an angle. Parms 4 and 5 are the same. 4 being an origin, 5 being a set of angles.
 
(This is optional. For me it's easier to do just one script to effect multiple doors. If you'd rather manually specify tags in the script, you may do so yourself.)
 
Parm3 is a float that specifies the time it takes for the door to move. Set this to whatever you want. It's shared by both the move up and move down blocks of command.
 
Parm6 is also set on the func static door. This is the time you wish to wait before reactivating the trigger that we initially turned off.
 
And finally, parm7 is a string signifying the script_targetname of the trigger_multiple that was deactivated in the beginning. This parm is also set on your func_static door. This means we are running another block of commands on the trigger_multiple. This time, the only command is to make the trigger_multiple usable by setting inactive to false.
 
 
 
There you have it! After all of that, parm1 on the trigger_multiple is no longer 0. It is now 1 and the door is up. That means the next time the trigger_multiple runs the script it will run the else block, which should have values that indicate the doors down origin.

[MoonDog]

I must ask though, why are you set on scripted doors? You could accomplish this easier with regular old entities.

[Asgarath83]

I usually use a single script for this, and just setup parameters on my entities. That way I can have like 292929292 doors, but only one script to work all of them.

//Generated by BehavEd

rem ( "First block checks is door down" );

if ( $get( FLOAT, "SET_PARM1")$, $=$, $0$ )
{
	set ( /*@SET_TYPES*/ "SET_PARM1", "1" );
	rem ( "If it is, set to up" );

	affect ( $get( STRING, "SET_PARM2")$, /*@AFFECT_TYPE*/ FLUSH )
	{
		set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" );

		affect ( $get( STRING, "SET_PARM3")$, /*@AFFECT_TYPE*/ FLUSH )
		{
			move ( $get( VECTOR, "SET_PARM1")$, $get( VECTOR, "SET_PARM2")$, $get( FLOAT, "SET_PARM3")$ );
			wait ( $get( FLOAT, "SET_PARM6")$ );

			affect ( $get( STRING, "SET_PARM7")$, /*@AFFECT_TYPE*/ FLUSH )
			{
				set ( /*@SET_TYPES*/ "SET_INACTIVE", "false" );
			}

		}

	}

}


else (  )
{
	set ( /*@SET_TYPES*/ "SET_PARM1", "0" );

	affect ( $get( STRING, "SET_PARM2")$, /*@AFFECT_TYPE*/ FLUSH )
	{
		set ( /*@SET_TYPES*/ "SET_INACTIVE", "true" );

		affect ( $get( STRING, "SET_PARM3")$, /*@AFFECT_TYPE*/ FLUSH )
		{
			move ( $get( VECTOR, "SET_PARM4")$, $get( VECTOR, "SET_PARM5")$, $get( FLOAT, "SET_PARM3")$ );
			wait ( $get( FLOAT, "SET_PARM6")$ );

			affect ( $get( STRING, "SET_PARM7")$, /*@AFFECT_TYPE*/ FLUSH )
			{
				set ( /*@SET_TYPES*/ "SET_INACTIVE", "false" );
			}

		}

	}

}

It's been a while since I used this, let me see if I remember what's going on.

 

parm1 is the status of the door. 0 being down and 1 being up. This parm is set on the trigger_multiple initially as the key "parm1" value "0". The trigger_multiple is also given the key "usescript" and the value of this script's name and file path. At this point the script sets the trigger as inactive before continuing. This is mostly to help prevent player error.

 

Now, the script looks at key: parm3 on your trigger. This is a string that tells it the name of the func_static you wish to move. (The script_targetname on the entity you are going to be moving.)

 

Example:

 

Key: parm3

Value: myCuteDoor1

 

Now, we are running a block of commands on myCuteDoor and thus can now fill out the parms on your cutedoor func_static entity.

 

Parms 1 and 2 on the func_static are vectors. 1 being an origin, 2 being an angle. Parms 4 and 5 are the same. 4 being an origin, 5 being a set of angles.

 

(This is optional. For me it's easier to do just one script to effect multiple doors. If you'd rather manually specify tags in the script, you may do so yourself.)

 

Parm3 is a float that specifies the time it takes for the door to move. Set this to whatever you want. It's shared by both the move up and move down blocks of command.

 

Parm6 is also set on the func static door. This is the time you wish to wait before reactivating the trigger that we initially turned off.

 

And finally, parm7 is a string signifying the script_targetname of the trigger_multiple that was deactivated in the beginning. This parm is also set on your func_static door. This means we are running another block of commands on the trigger_multiple. This time, the only command is to make the trigger_multiple usable by setting inactive to false.

 

 

 

There you have it! After all of that, parm1 on the trigger_multiple is no longer 0. It is now 1 and the door is up. That means the next time the trigger_multiple runs the script it will run the else block, which should have values that indicate the doors down origin.

Wow, yu are more espert of me with scripting

 

[Asgarath83]

I must ask though, why are you set on scripted doors? You could accomplish this easier with regular old entities.

if is refer to me, because is first time that i go into a community of JA for getting help, so many things i learned by my self experience and maybe not all is correct.

or maybe because simply i like the func_door entities because with that i can do a large amount of things. there are func_door that i not used only for making "doors" but simply moving object in a two sense.

[MoonDog]

if is refer to me, because is first time that i go into a community of JA for getting help, so many things i learned by my self experience and maybe not all is correct.

or maybe because simply i like the func_door entities because with that i can do a large amount of things. there are func_door that i not used only for making "doors" but simply moving object in a two sens

 

No one is talking to you.

 

@ I updated my original post due to errors I accidentally placed in the script.

[Boothand]

Polarity, I will try the method you showed, thanks for that! But to answer your question, I'm building this from the foundations so to speak. If I can't make a script reset itself in such a basic form, I cannot truly utilize the potential of scripts and use them for other things. When that's said, it might be I'll use the method you showed me, but I would still like to know how to solve the problem I have on the current script I'm using, since it's highly relevant to further scripting mastery

[Asgarath83]

No one is talking to you.

 

@ I updated my original post due to errors I accidentally placed in the script.

Well in that case, i leave the topic. Nice script, however.

However, i was trying to help Gnur, and he was talking for me, so "no one is talking for me" is a form a lot offensive that get me unconsideration. In every case, your script is interessing. i admit that i never understood the function related the parim1,2,3, etc etc command, but i see that in the game are used about switch and door. pratically the "parm" with a number is a key associated qith an eneity of the game, so setting the parm to 1 is like activate the entity? is that the functions of parms?

[MoonDog]

Polarity, I will try the method you showed, thanks for that! But to answer your question, I'm building this from the foundations so to speak. If I can't make a script reset itself in such a basic form, I cannot truly utilize the potential of scripts and use them for other things. When that's said, it might be I'll use the method you showed me, but I would still like to know how to solve the problem I have on the current script I'm using, since it's highly relevant to further scripting mastery

 

 

Well in answer to that, I'll hint to you that your script is structured incorrectly. Look at mine for clues.

[Boothand]

Ok i see.

3 errors.

1: in the opendoor script, yu set the closetrigger as inactive, true. setting on on inactive, false. because need to work for closing the door.

2: yu need to create the door as func_door setted for used in up \ down direction, yu can specify this with the angles. not as func static. yu need to set the door as toggled. yu not need the ref tag with a toggle door, a toggle door stay open until not be used again.

3: yu use deactivation script when the door run, so trigger cannot influence it move. yu need to create a target_activate named with script_targetname and targetname parameters. the activator need to be connected to the trigger of opendoor script.

in the script of closedoor, yu need simply to set at the end

USE "target_activate name". the trigger for re open the door is reactivated by the target_activate entity.

 

is an issue of the func_static, however, is better if yu use func_door for that kind o things. is more adapt of func_static. to me func_static has ever done some troubles. i try to avoid to use func_static as entity, a func_door is more controllable.

 

Sorry, didn't see the post before now.

 

The close-trigger is activated again after the movetask has happened. I have re-structured my script, like @ said, but maybe not in the right way. I did notice some obviously bad things, like the trigger inactivating itself before running the task, and affects within an affect (for some reason the task was carried out either way though).

 

My scripts now do:

 

affect door - move

affect open trigger - inactive

affect closing trigger - active

________________________

 

affect door - move

affect closing trigger - inactive

affect open trigger - active

 

I thought this would fix it, but the same thing happens (was this what you referred to, @? Or was it directed to the strict use of affect and lack of use of if/else? - which I don't see the use for in this context).

 

And Asgarath, what you're presenting with the func_door is a workaround. I'm interested in making this very possible thing functional, and to learn scripting. I don't want to redirect the attention to something that works, but doesn't let me learn what's not working in this method I did try to switch out the static with a func_door though, but they acted the same way.

[Asgarath83]

Sorry, didn't see the post before now.

 

The close-trigger is activated again after the movetask has happened. I have re-structured my script, like @ said, but maybe not in the right way. I did notice some obviously bad things, like the trigger inactivating itself before running the task, and affects within an affect (for some reason the task was carried out either way though).

 

My scripts now do:

 

affect door - move

affect open trigger - inactive

affect closing trigger - active

________________________

 

affect door - move

affect closing trigger - inactive

affect open trigger - active

 

I thought this would fix it, but the same thing happens (was this what you referred to, @? Or was it directed to the strict use of affect and lack of use of if/else? - which I don't see the use for in this context).

 

And Asgarath, what you're presenting with the func_door is a workaround. I'm interested in making this very possible thing functional, and to learn scripting. I don't want to redirect the attention to something that works, but doesn't let me learn what's not working in this method I did try to switch out the static with a func_door though, but they acted the same way.

Ah, well, now i think i had understood.

So you not wanna know alternative solution about that issue, but Why radiant and icarus do this strange bug.

Mmm, i have no answer for that on your special case, i am sorry for that. I can only suppose that those kind of script create some indersidate looping of idleing of fhe inactive function. I suppose is the inactive function itself that has a strange behavour in that case. Is not however only a your bug, is an interessing leak of icarus system. i try your map and i see youyr script and project. to do to me the same things yu have explained. i am here too for learn more about that for my project, and because i am not good like cooder i am forced to learn more about mastery of the scripting. So i am too interessed to this strange issue of the SET_INACTIVE function. i suppose is something inside the icarus funcionality itself. but yes, is an odd thing.

HHowever, not worry for have not see my post. is a strong discussion and is easy to lose something.

[MoonDog]

Alright, different hint.

 

 

This is the door opener you posted above fixed. See the difference? Try copy and pasting this into a txt file and save it as whatever.icarus. Open it in Behaved.

//Generated by BehavEd

rem ( "opens door in beginning of map" );

affect ( "bbdoor_trigger_downwards", /*@AFFECT_TYPE*/ FLUSH )
{
	set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "true" );

	affect ( "bbdoor_trigger_upwards", /*@AFFECT_TYPE*/ FLUSH )
	{
		set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "true" );

		affect ( "bb_door1", /*@AFFECT_TYPE*/ FLUSH )
		{

			task ( "moveup" )
			{
				move ( $tag( "bb_doortag2", ORIGIN)$, < 0.000 0.000 0.000 >, 1000.000 );
			}

			dowait ( "moveup" );

			affect ( "bbdoor_trigger_downwards", /*@AFFECT_TYPE*/ FLUSH )
			{
				set ( /*@SET_TYPES*/ "SET_INACTIVE", /*@BOOL_TYPES*/ "false" );
			}

		}

	}

}

@@Asgarath83 You seem to be answering questions without actually knowing what's causing the errors or how to clearly fix them. Refrain from that behavior. 

 

He's not experiencing a "bug" or a "leak" in the "Icarus system". It's simply an incorrectly structured script.

[Asgarath83]

Ok ok polarity, keep calm. :\ I avoid to take part on topics when i not have the clear answers for help, okay? I have the bad abitudine to help also when is not the case, so i pass for inappropriate or pedantic. You are not the first that tell me that. Well, it's late, sorry for distub. i go. 'night.

[Boothand]

Alright, different hint.

 

 

This is the door opener you posted above fixed. See the difference? Try copy and pasting this into a txt file and save it as whatever.icarus. Open it in Behaved.

 

 

Yeah I see the difference. Actually that was what I thought I had to avoid - affects within affects. Affecception. Everything looks like it's the minion of downwardstrigger.

 

But believe it or not, it still doesn't work. Same behavior, after I changed both scripts' hierarchy like this. Tested on two different maps, with slightly different scripts.

 

Here is a pk3 using the same method you showed. I tried your exact one on my other map, but with the same result. https://dl.dropboxusercontent.com/u/58757568/scripttest.pk3 (same link as earlier, but with new content)

[MoonDog]

lol. Whoops.

 

Give both of your scriptrunners key: count  value: -1

[Boothand]

There we have the answer! This works Thank you!

 

(Is the accept as answer feature gone?)

[Circa]

There we have the answer! This works Thank you!

 

(Is the accept as answer feature gone?)

That's only for the Modding Assistance section. I'm going to add it to this one too though, since it consists of mostly questions anyway.