Continue(), NoAction(), and the empty RESPONSE

[Blucher]

Was checking out the IESDP info on the scripting stuff there. Don’t know if this is the right place to talk about it, but since the old eGroups/Yahoo Groups archives have been wiped...

 

Anyway, about Continue(): this will "break" any valid script blocks with an empty RESPONSE.

 

For instance:

 

IF

True()

THEN

RESPONSE #100

Continue()

END

 

IF

ModalState(STEALTH)

THEN

RESPONSE #100

END

 

IF

See(NearestEnemyOf(Myself))

THEN

RESPONSE #100

Attack(LastSeenBy(Myself))

END

 

...will result in a character breaking stealth to attack a visible enemy.

 

And this:

IF

ModalState(STEALTH)

THEN

RESPONSE #100

NoAction()

END

 

...also doesn't work if the idea is to keep the character in stealth as NoAction() is, despite its name, also an action. (Ignoring for the moment the unaesthetic "tensing up" it causes characters to do.)

 

This would be how to do it if you want Stealth (or whatever) to remain unbroken and still use Continue():

 

IF

ModalState(STEALTH)

THEN

RESPONSE #100

END

 

IF

True()

THEN

RESPONSE #100

Continue()

END

 

IF

See(NearestEnemyOf(Myself))

THEN

RESPONSE #100

Attack(LastSeenBy(Myself))

END

 

Okay, this is *hardly* new info or anything, but it's pretty useful stuff to know.

 

P.S. Any good sub-forum or forum around to talk about scripts? (Or is that too specialized an area of interest?)

[Avenger]

Ok, you mean that an empty response block lets the script flow through?

 

I already knew NoAction() turns modal state to 0.

 

So, an empty response block is good only for pre-targeting. It doesn't even require the False() as the last trigger in the block?

 

I just don't understand how your last example would work differently from the first one then.

It would still let through the empty modal state block, then go through continue, and reveal when attacking.

 

Or, it is ONLY continue that forces us through empty response blocks?

Yeah, i guess this is what you wanted to say.

But it sounds sooo improbable.

I'll check it out.

[Blucher]

Or, it is ONLY continue that forces us through empty response blocks?

 

Well, I don't know if it's only Continue(), but yeah, basically. Any empty RESPONSE preceded by a Continue() acts as if it also has a continue.

 

For instance:

IF

True()

THEN

RESPONSE #100

Continue()

END

 

IF

See("Sarevok")

THEN

RESPONSE #100

END

 

IF

See("Imoen2")

THEN

RESPONSE #100

END

 

IF

See("BotSmith")

THEN

RESPONSE #100

END

 

IF

True()

THEN

RESPONSE #100

DisplayStringHead(LastSeenBy(Myself),16394) // What?! What is it?!

Wait(12)

END

 

...will display the string over the head of whichever CRE was seen last, and is still within sight.

 

Whereas this (replacing the first block):

 

IF

False()

THEN

RESPONSE #100

Continue()

END

 

...will only display a string over the head of the last seen CRE, but only if they are all currently out of sight.

 

EDIT: I suppose it could be used for targeting, but the False() triggers under the See()s work as well or better. The best use for the empty RESPONSE imo, is when you want a CRE to do absolutely nothing (no even a NoAction()) as long as a set of conditions are valid. And that's just the sort of use that a preceding Continue() breaks.

[Smoketest]

Here's my theory, from a programming standpoint...

 

Perhaps Bioware didn't envision anyone using empty RETURN blocks, so they let the action queue be flushed by actions in the next RETURN block, or by reaching the end of the script.

 

If so, an empty RETURN block would not flush the action queue. If it's triggers evaluated to True(), the empty RETURN block would execute whatever happened to be in the action queue at the time, which in this case is Continue().

[Sofus]

Actually it says so in the IESDP, depending on how you read it:

 

"... to continue looking for actions for the Action List"

 

Since "END" isn't an action but the end to a possible list of actions, it is ignored. What we need is an "EndScript" action, my solution is sometimes to use a dummy global and just do a SetGlobal().

 

ex. A no enemy cutoff, which has to be an empty response, setting the global each time will cause stuttering.

IF
True() 
THEN
RESPONSE #100
SetGlobal("Cutoff","LOCALS",1) // in every continue() block prior to the cutoff.
Continue()
END

IF
True() // in my case !Detect([ENEMY])
Global("Cutoff","LOCALS",1)
THEN
RESPONSE #100
SetGlobal("Cutoff","LOCALS",0) 
END

IF
True() // !Detect([ENEMY])
Global("Cutoff","LOCALS",0)
THEN
RESPONSE #100
END