Basic "Fired" EH problem w/ variables

[Lean Bear]

OK, I've got a pretty complex script I'm working on, but its the simple easy things I keep slipping up on

I've got an Event Handler in my script as follows:

_unit addEventHandler ["fired", {unitFired = true}]

but incredably OFP doesn't like it. It alwasy comes up with some sort of error that cahnges to another error no matter how I cahnge the syntax. All I want to do is when the unit fires, the global varibable unitFired switches to "true".

I've tried almost every possiblity, but I'm beginning to think that EHs can't handle variables (at least, not global variables).

I really don't want to make a loop like:

_unit addEventHandler ["fired", {goto "Loop"}]

#Loop

unitFired = true

because the script looks messy enough. But it looks like that's the way its going...

[Planck]

Have you tried declaring unitfired = false in your init.sqs to initialise the variable first?


Planck

[Lean Bear]

Of course

Does OFP read the init.sqs when you do a mission preview in the Miss Ed?

[bedges]

just tried it myself, works fine.

i set up the fired eventhandler to make 'varfired' true, and set up a trigger to give me a hint when 'varfired' was true. hit preview, fire, and ping, the hint appears.

sorry to give just this "mine works and yours doesn't", but perhaps the problem lies elsewhere?

edit - all this without defining 'varfired' first too....

[Planck]

In my experience......yes......it does read it in the mission preview.


Planck

[Lean Bear]

Hmm, I can't think of any reason why it wouldn't work.

Its right at the start of the script as well. As I say, OFP always found a problem with the syntax and then just didn't want ot continue wih the script (well - that EH was pretty vital to the rest of the script running porperly anyway).

The next line reads:

@unitFired
goto "Loop"

So I can't see anything wrong with that - or at least nothing that wouldn't make the EH work properly.

[bedges]

unitFired isn't a reserved variable is it?

if you can get a copy of the error generated, that may help...

[Lean Bear]

Whu-oh, looks like my last post didn't make it through the wires.

Basically, I was going to say that there wasn'tmuch point as whatever I change the syntax too, there's always an error.

The most common ones are:

"Error: 'addEventHandler' expected Object; found Array"
"Error: '=' unknown operator"
"Error: '' " //don't get this one :-\

[bedges]

well, as far as my eyes can see, the syntax is fine, like i say it works for me no problem. the only other element that could be the cause is _unit.

how is _unit defined? are you pulling it from the [variable] exec "script.sqs" call, or is it defined elsewhere?

[Lean Bear]

Yeah, you got it.

[_unit] exec "script.sqs"

Then, in "Script.sqs"

_unit = _this select 0

[bedges]

mkay, i'm embarrassed to ask this, but you are using the name of a unit as [name_of_unit] exec "script.sqs" right? not [_unit]....  

of course you are, that's a silly thing to ask, but without seeing your whole situation, i'm clutching at straws here...

[Lean Bear]

Again, you're spot on bedges.

For example:

"west1" exec "Script.sqs"

[Killswitch]

Again, you're spot on bedges.

For example:

"west1" exec "Script.sqs"

If that is how you want to use Script.sqs, the line that reads

Code: [Select]

_unit = _this select 0will of course not work. The select command operates on arrays, not strings. You are passing a string as parameter to the script, not an array.

However

Code: [Select]

_unit = call (_this select 0)will work.

If you really do want do use "_unit=_this select 0", you'd have to execute Script.sqs using

Code: [Select]

[west1] exec "Script.sqs"

[Lean Bear]

Sorry, I wasn't being clear about that last post.

I just put that as an example to show bedges that I'm not using:

_unit exec "Script.sqs"

to call the script.

I'm using an array anyway, something like:

[_unit, _vehicle, _a]

So when I call the script, it would be like:

[west1, bmp1, 20] exec "Script.sqs"

[Chris Death]

You should check all your variables, if there isn't some
dbl-use of variables somewhere in your mission.

Exec syntax looks fine but the error message leads to
that west1 is not what it is intended to be.

Is west1 maybe used as something else too?

:edit - try to debug by using hint format to display the
context of the your variables too  
Sooner or later you'll find the bugger then

~S~ CD

[bedges]

indeed, try the usual debug techniques - which you most likely have already - and if all else fails, try to replicate the error in a missionette, and post it here.