donut-shape trigger. anyone knows how?

[scorpi0x]

i need to do this trigger in the picture i sketched
whereby it adds an action for the player when player is inside the grey zone. and remove the action when at the white area.

i know about addAction ["newAction", "newAction.sqs"] and removeAction here. but apparently i cannot do it by just overlapping a small circle (to remove action) over a big circle (to add action)

not sure the difficulty of this but i'll just ask in here anyway  

[bedges]

the problem (i think) with just overlapping the triggers is that when you're inside the wee one, you're still inside the big one too.

what you want to do is create a global variable - let's call it mmmdonuts - and set it to true in the 'on activation' field of the larger trigger, false in the wee one. then in the condition fields of each, check which value mmmdonuts has before performing any add/remove action.

that should do it.

mmmmmmmmdonuts....

[scorpi0x]

sorry guess i am just too new...
if i can't perform the add/remove action in the 'on activation' field, where do i perform the add/remove action then?

[THobson]

Try:

Inner trigger:
Repeating
on activation: Inner = true; remove the action
on deactivation Inner = false

Outer Tigger:
Repeating
condition: this and not Inner
on activiation: add the action
on deactivation: remove the action

Note you must set Inner = false at the start of the mission, either in init.sqs or in a trigger with condition set to true

I have not tested it but the above should ensure the action is onthe loon when he is in the grey area but not if he is in the inner trigger or outside the outer trigger

EDIT:
Thinking about it bedges is the same as your method?  I didn't think so when I started writing.

[bedges]

m'kay, just tested and this works. set up your mmmmdonut like this -

large trigger:
repeated
condition: this and mmmdonut
on activation: mmmdonut = true; your addaction code
on deactivation: mmmdonut = false;  your removeaction code

smaller trigger:
repeated
on activation: mmmdonut = false; your removeaction code
on deactivation: mmmdonut = true

you may want to stick a couple of hints in after the add/removeaction codes to see (and hear) it working. just separate them from the rest of the code by using another semicolon ( ; )

EDIT - heheheh, touché monsieur T'obson

[THobson]

Great minds. Bye the way: How does mmmdonut get set to be true without first visiting the inner trigger?

[bedges]

by reading your post and putting it in the init file, of course  

errr... no, hang on :hmm:

[scorpi0x]

alright i finally figure it out.
thank you all  ;D
a small error i corrected for all others info.

large trigger:
repeated
condition: this and mmmdonut
on activation: your addaction code
on deactivation: your removeaction code

smaller trigger:
repeated
on activation: mmmdonut = false; your removeaction code
on deactivation: mmmdonut = true

forgot to mention i set mmmdonut to true in init.sqs
and made it a publicvariable.

[RujiK]

Or instead of all that trigger business you could do a .sqs file. Example:

Code: [Select]

_pos = getpos donut

#reset
@((player distance _pos > 30)&&(player distance _pos < 40))
donut = player addaction ["Eat the donut!","donut.sqs"]
@((player distance _pos < 30)or(player distance _pos > 40))
player removeaction donut
hint"Dang! I lost my donut!"
goto"reset"
All you have to do is put a gamelogic where ever and name it donut, or you could do _this select 0 for mulitple donuts.

[scorpi0x]

kinda like ur idea and i tried ur method rujik
but i got this error at start.
'((player distance _pos > |#|30)&&(player distance _pos < 40))': Error distance: Type Array, expected Object

guess i'll stick to the triggers for now

[bedges]

yep, it's because _pos is the position, not an object, which is what distance is looking for to compare.

the script is a fair concept in principle, but i'm not really convinced of the efficacy of using a looping script when two simple triggers will do the same job. especially a script with no pause in it.

that said, i'm no expert. ask the general, he'll be able to tell you on the scripting side of things.

nitenite  

[THobson]

It is a case of 'horses for courses'

Triggers are easy to implement, but consume CPU (the condition is checked many times a second).  Slow(ish) looping scripts can reduce CPU load, but generally do take more thinking about.  They are also intrinsically slower as they are not compiled in the way the code for a trigger is, so I try for a loop of several seconds where I can.

So if it is a small mission triggers are fine.  For a large mission I use looping scripts when I can unless the action is time or spatially critical, and even then I find I can avoid a lot of instances where I used to use triggers by using Event Handlers instead.

[bedges]

that's an interesting point. i had read (in a trigger tutorial i believe) about the number of times per second triggers are polled, compared to the @ command, or looping scripts. the figures being discussed were fractions of seconds and i didn't give it much thought - couldn't be that important could it...

but then, create a mission full of conditional triggers and a whole heap o' loons with waypoints and the lag soon builds up.

bedges looks at his previous mission with a more critical eye...
the mission squeaks nervously in alarm.

heheh, cheers sir, that's something i'm going to take a look at.  

[THobson]

There is a limit to how much you can go back and rework.  I have missions that play quite well that had a squads of loons parachuting from choppers, and each loon had their own trigger!!  I am embarassed to think about it now.  My previous mission I think is quite good - but even there I was detecting the death of individuals using triggers instead of event handlers.  Building a large mission, which as you know I am now doing, really forced me to think about what I was doing, how I was doing it and why, and then when I had an answer to all that, then think: is there a better way?

I know if I so much as look at one of my old missions I will end up re-making it.  "And a good thing too" I hear some of you say!