[Doko]

I'm trying to add a mechanic into a mission where depending on how much hull durability a ship has left, its turrets will fire at different rates.

Example:
if ->
hull > 70
fire-rate = 200

if AND ->
hull <= 70
hull >= 40
fire-rate = 150

and so on for other intervals

I could make a bunch of different events, all with a condition of an event to be true right before so the fire rate is set when I want it.

event
Time to check for HP!
do-nothing

and -> is event true delay (time to check for hp!)
       -> hp => 70
fire-rate = 200

and so on for others.

My question is, is there a way to keep this all in one event should I want to do it that way?

[General Battuta]

Easy. Answering on IRC.

[mjn.mixael]

SEXP puzzles are best puzzles. They have ruined all other puzzles for me.

[niffiwan]

Easy. Answering on IRC.

Plz to post solution here for posterity! 

[General Battuta]

Set up a when-true-do nothing. Change the 'true' to a trigger that tells the event when to fire

Replace the 'do nothing' with another when. Right click the event, hit 'add operator', add as many more whens as you need.

For each 'when' nested inside the main 'when', you can say 'if hull is between X and Y, set rof to Z'

So you might have

When
(ten minutes have passed)
(when Bob has hull 100, set rof to 100)
(when Bob has hull 80-99, set rof to 80)
(when bob has hull 50-79, set rof to 50)

And so on.

[Shivan Hunter]

I was about to post before but was in a hurry, I thought it might have been that. (nested conditionals are incredible and everyone should know them)

but I was going to suggest - you may want these intervals specifically, so if you do then ignore me, but if you don't (and are using them to simulate a continuous decline in turret efficiency), it might be more elegant to set the fire rate directly based on the hits-left, from whatever equation you want. So if you want it starting at 100 and decreasing to 0 as HP decreases to 0, you'd just use (when (condition) (turret-set-rate-of-fire (Bob) (hits-left (Bob)))).

Also battootles didn't mention it ITT but you'd need a high (or infinite, since apparently you can do that now) trigger count to make the event keep updating after the condition is true.

[Doko]

Thanks battuta and everyone for the suggestions.

Regarding auto updating the fire rate. Originally thought of this but decided against it as I'm using player performance up to a certain point to generate a weapon overload on a ship that will allow you to complete a bonus objective. To balance this I need break points that are easy to test.

[General Battuta]

I was about to post before but was in a hurry, I thought it might have been that. (nested conditionals are incredible and everyone should know them)

but I was going to suggest - you may want these intervals specifically, so if you do then ignore me, but if you don't (and are using them to simulate a continuous decline in turret efficiency), it might be more elegant to set the fire rate directly based on the hits-left, from whatever equation you want. So if you want it starting at 100 and decreasing to 0 as HP decreases to 0, you'd just use (when (condition) (turret-set-rate-of-fire (Bob) (hits-left (Bob)))).

Also battootles didn't mention it ITT but you'd need a high (or infinite, since apparently you can do that now) trigger count to make the event keep updating after the condition is true.

He was specific he only wanted it to trigger once tho

[karajorma]

@Shivan, if you want a step down, you shouldn't be using nested when in the first place. What you should do is something like this. 

when
- >=
-- hits-left
-- TriggerHullReduction[100]
- Set the fire-rate from the TriggerHullReduction variable too. As you said you might need to use some algorithm to multiply it until you get the number you want but that's fairly easy )
- modify-variable
-- TriggerHullReduction[100]
-- -
--- TriggerHullReduction[100]
--- Let's say 20 so that we trigger this at 80% 60% 40% and 20%

Give the event a trigger count of 5 because you want it to happen a total of 5 times and you're done.


Now Battuta's solution wouldn't be wrong in any major way for the problem it solves. I even suspect Doko would find it much easier to use than the solution I typed up. But as a coder, we're always taught that you should never copy and paste code when you can instead make it do the same job twice instead. If you wanted the event to trigger more than once, this way has a few advantages.

1) If Doko realises he wants something else to happen every time those turrets get hit (play the same message, play a sound, update a gauge on screen) he's going to have to change every single nested when (In fact he's actually going to have to get rid of them and go back to separate events). Using my solution, he only needs to change the event once and all the other times the event triggers it will still do it.
2) It doesn't require an infinite trigger count. So the code is slightly more efficient than a nested when. And although speeding up the FPS isn't really a consideration during FREDding, it's not a bad thing to do either.

[Shivan Hunter]

That does seem a much better fit for Doko's use case, yes (and the only good way to do something else when the slowdown triggers as well). The main drawback is it doesn't take into account the case where the ship's hull is repaired, but if Doko only wants it to trigger once I guess that's not a concern.

[General Battuta]

FRED really can destroy performance, mostly when using every-time-argument — massive massive frame drops every few seconds.

[karajorma]

It depends on what you are doing, but yeah, you can seriously degrade performance if you choose to do the wrong thing every frame. That said, if you have some simple test missions, I'd be willing to take a look at profiling them to see if there is anything we could do in code to speed them up.