I've edited my first post to reflect this but the events I've written (with the possible exception of the 3rd) are all for the most part correct. They all contain a single flaw which is breaking them. The goal is not to say how you'd solve the original problem but instead how you'd fix what is in front of you. (Or at least why it doesn't work as intended).
We FREDders often get to test our event creation skills but the event debugging skills in the community are rather poor in general. I'm sure each one of us can name an occasion where an event we thought would work hasn't and we've simply tinkered with it a little until it did never understanding why it failed the first time but works now. A coding book I once read referred to this practice as superstition and in many ways that's especially apt when it comes to FRED. I've often seen people say that you need to do really outlandish things to make a SEXP work because they had to do that for a mission.
More often than not we'll shrug and say it's a bug.
But none of the questions I'm putting up will be based on a bug. In a few cases the SCP has improved the SEXP so you can make it work the way it would have been expected to work but in all cases the SEXPs are working as designed.
Anyway. Here are the answers to the first 4 questions.
Question 1 - AnswerThis is a perfect snapshot of mission development and a good example of when superstition actually would give people the right answer (I didn't want to reveal the previous step cause I felt it would make things too easy). The mission development has gone like this.
I wanted to make the Ulysses stealthed so the first event I tried was this.
when
-true
-ship-stealthy
--Beta 1 etc
But in the mission the ships were still visible. I then replaced the ship-stealthy with friendly-stealth-invisible as shown in the question and got the same result. The next step for most people would be to do both. And this is the correct answer. Friendly-stealth-invisible does not make ships stealthy. It is a toggle that makes ships already stealthy invisible if they are friendly. Regardless of whether or not you use it enemy ships will still think the ship is stealthed.
Question 2 - AnswerThis one confuses a lot of people when they first encounter it. The problem is that the 3rd optional argument to is-event-true-delay is missing. In the same way that is-destroyed-delay directives won't appear if the ships are not present in the mission, directives using is-event-true-delay won't appear unless the event is true (IIRC this is so chaining works since a chain is basically an is-event-true-delay SEXP). The optional parameter allows you say "Only use this SEXP to determine when the event is true, not when the directive should be displayed).
Question 3 - AnswerAgain another snapshot of mission development. But this is a case of superstition leading the FREDder down the wrong path. To all those who suggested going from Not > to < sorry but that's not going to help. In fact in the hypothetical example that's actually what I did first. The point I was trying to make is that a superstitious FREDder might simply think that if less than doesn't work then Not Greater than might work. The problem here is that we read the SEXP from top to bottom and that's a dangerous mistake when the NOT SEXP is involved. Not Greater Than 3000m sounds perfectly reasonable but that's not actually what is being tested in this case.
The problem comes from the way the distance SEXP works with teams or wings. As several people spotted the distance SEXPs work out the distance between the closest ships when a group is involved. This will give you the right answer when you use >, < or = but as soon as you use NOT, all bets are off.
If we work our way from the bottom of the SEXP chain upwards the problem will become clearer.
when
>
-Distance
--Alpha 1
--Cancer
-3000
That SEXP returns true when the distance between Alpha and the member of Cancer wing closest to him is 3000m. The SEXP simply doesn't care where the other two are as long as it's further away. So when we NOT the SEXP the event returns true if the closest ship isn't more than 3000m away. Again we don't care where the other two are.
Question 4 - AnswerThis one is just plain nasty. In fact it's even caught out the
FREDders. If you look at the mission objectives in Bearbaiting it's obvious that they've added an is-subsystem-destroyed-delay after hits-left-subsystem didn't work.
The basic problem is that hits-left-subsystem does something rather odd internally. When called for any subsystem you have multiples of it will take the average of their hit points. So in the case of the rakshasa it is taking the average of all the turrets hitpoints rather than just those for Turret01. Since the other turrets aren't being destroyed before the Rakshasa is you'll never see the event trigger. There is a third optional argument in 3.6.10 that tells the SEXP not to be so silly and to give the actual hits-left of the subsystem.
This doesn't affect all subsystems BTW. Only subsystems containing the following words will display this odd behaviour. engine, radar, turret, navigation, communication, weapons, sensors, solar, gas or activator.
