End trigger doesn't work

[Serial Killer]

I made a trigger to my mission, type=End#1, condition=end. Then I made a cutscene wich activates when all objectives are done. No problems with this.
But the problem is that the end trigger doesn't activate at the end of the script. (I wrote end=true at the end of it.) Help?

[456820]

how about something like endnow = true since im not sure but end may already be a command so that might be yor problem have a go with that im not sure and of course cahnge the trigger to "endnow" also have you destroyed the camera in the script missions dont end unless the camera has been destroyed atleast i think so

[Kyle Sarnik]

how about something like endnow = true since im not sure but end may already be a command so that might be yor problem have a go with that im not sure and of course cahnge the trigger to "endnow" also have you destroyed the camera in the script missions dont end unless the camera has been destroyed atleast i think so

No thats not the problem. Anyways didn't I allready answer an identical question? Ah whatever, mission End triggers have a delay, you might have to wait a while after you set end to true before it ends. Or, use the forceend command at the same time you set end to true and it should force the end trigger to end the game without the delay. *Note, from my experiences, forceend ONLY works when you also have an end trigger (End#1, End#2, Loose, etc...) and it is ACTIVATED. So... yea.

[Tyger]

So what Kyle is saying is

Code: [Select]

cond: end
onActiv: forceEnd
in your trigger

[Kyle Sarnik]

So what Kyle is saying is

Code: [Select]

cond: end
onActiv: forceEnd
in your trigger

Um, well I don't use that method (it should work though unless the delay effects the trigger's on activation but I don't believe it does), I was thinking more along the lines of:

Code: [Select]

end = true
forceend

[Tyger]

Well, either works ;D

Edit:

(it should work though unless the delay effects the trigger's on activation but I don't believe it does)

It does work. I use it in my mission ending triggers like that all of the time.

[Pilot]

Did you define end as
end=false
in init.sqs?

-Student Pilot

[Kyle Sarnik]

Did you define end as
end=false
in init.sqs?

-Student Pilot

Nah, you don't need to do that unless you check if the variable is false, the trigger only checks if its true, or, in other words, if its anything BUT true it won't activate, so OFP doesn't really care if its false, it only cares that its not true. I guess you can say, OFP is lazy  

[Pilot]

Are you sure?  I thought ALL variables (whether public or private) had to be defined in init.sqs or somewhere in the script before they can be used.  In fact, I'm pretty sure some of my scripts in my missions wouldn't work until I defined the variables.

-Student Pilot

[Kyle Sarnik]

Are you sure?  I thought ALL variables (whether public or private) had to be defined in init.sqs or somewhere in the script before they can be used.  In fact, I'm pretty sure some of my scripts in my missions wouldn't work until I defined the variables.

-Student Pilot

Like I said, that depends on how you use the variable. If you want to know what a variable is equal to, for example:

? Variable1 == 3

You would need to define Variable1 as a number or else OFP will make define it as "scalar bool array etc...." or some form of that, and OFP won't know its supposed to be a number, so it will give you an error (but won't really effect anything). If you were doing something like:

Variable1 = Variable1 + 1

Then you would need to define variable1 somewhere first, or else OFP will be adding a number to nothingness and will confuse itself. If you did this:

? Variable1

Then you don't need to set it to false first, because if you translate this literaly, it means "If Variable1 is true", so its not checking if its false, so it means Variable1 can be equal to ANYTHING and this line will still function currectly. All you need to do is set it to true at ANY time and OFP will pick up on this change. Its like this, if you are creating a new unit:

"SoldierWB" createunit [<yadda yadda>,"NewSoldier = this",<yadda>]

Now suppose you had a script that used NewSoldier:

? NewSoldier <something something>

If this script ran BEFORE the unit was created, OFP would be like "What the heck is NewSoldier?". If you suddenly created NewSoldier, OFP will be like "Oh.... there he is!" and now it works. Same thing applies to true/false variables. I hope that explains it, I can't word it any simpler than that  :-\

[THobson]

The problem with undefined variables - especially booleans, comes not when you create the mission, but when you later change it, on the grounds that the problem I am about to describe would probably occur to you when you make the mission but may be missed later.

If you have a previously undefined varible (say A) set to true at some point in the mission, and you have a trigger that then takes action when A is true it will all work fine.  Later you think - wouldn't it be neat to do something when B is true, providing A hasn't happened yet.  So you create the condition:

B and not A

Then you wonder why it doesn't work.  The problem is that until A is defined, any boolean expression containing A will return the value False.  So B has happened, A has not but still your condition is false, and will remain so until A is defined - but as it will be defined as true: B and not A remains false.

It is good practice to initialise all your variables
Though it is not always essential.

Another less obvious issue is to to with the large savegame bug.  If your mission creates new variables throughout its life how do you know if the bug will hit?  Better is to have all your variables defined from the start so that the number of variables can then only go down.  This will not be relevant to most missions but it is for some.

[Pilot]

@Kyle Sarnik
Ok, I understand.  Although I think I will always initialize vaiables for the reasons THobson said, and it also provides me with a place to check if I have used a certain variable before.  It just seems less messier to me to initialize variables.  But I do see what you're saying.

-Student Pilot

[Tyger]

Some just prefer to not sit and code hundreds of varibles when 90% of them don't need to be initalized.  

Lazy buggers ;D

[Serial Killer]

Destroying the camera worked. Now the end trigger activates without problem. Thanks.