Quick FREDing question

[Blitzerland]

This should be a fairly simple request, but I've been having trouble FREDing it.

I have six transports. If five survive, command sends a certain message. If three survive, another message. Less than that, another message.

I've been fiddling with this for awhile, and can't get it to work. Percent-ships destroyed doesn't work, neither does percent-ships departed, because it keeps calling multiple sexps.

*five ships survive sexp called*

Sexp called, but because five departed, it also implies that three departed.

*three ships survive sexp called*

Next I tried using this:

And
 
 -Percent-ships-destroyed-or-departed
 -100
 -(ship list)

 -Percent-ships-destroyed
 -50
 -(ship list)
 

Didn't work. Still calls muliple sexps. As soon as the "three ships departed" message plays, the "five ships departed" message follows it.

[Blaise Russel]

Sounds like a job for variables!

[karajorma]

Event 1
when
-and
-Conditions that make it time to check who survived
-percentage-ships-destroyed
-83
-send-message
--Only one ship survived


Event 2
when
-and
-Conditions that make it time to check who survived +1 second
-percentage-ships-destroyed
--50
-is-event-false
--Event 1
-send-message
--Only three ships survived

Event 3
when
-and
-Conditions that make it time to check who survived +2 seconds
-percentage-ships-destroyed
--0
-is-event-false
--Event 2
-send-message
--5 ships survived

That way the 3 ships survive event doesn't play if the 5 ships survived event is true.

If you're doing this in combat reverse the percentages and use percentage-ships-departed instead.

[Nuclear1]

Variables are your friend.

Make a new Variable in the Events section named "Safe Transports" or such. When each transport departs, use "modify-variable" and then add +1.

Set events:
-when
-SafeTransports
-=
-3

That's the cue for the "3 safe" message. To avoid confusion, use another variable for "ships destroyed", using a similar process as above. When the variable for "ships destroyed" equals 2, the "safe transports" variable will go off as if only 3 transports survived (which I assume you want).

[karajorma]

Or you can use variable like the other two suggested

[Blaise Russel]

But they're not quite as elegant as Kara's suggestion.

*suitably awed*

[karajorma]

You're awed by that? I thought that a fairly simple suggestion.

This is some of the stuff I'm more pleased with

[Blaise Russel]

Well, 'awe' may be hyperbole, but it's something that didn't occur to me at all, and I would have gone for a solution that uses three times as many events, so...

[Hippo]

Is it just me, or was almost this exact scenario covered int he walkthrough, except with docking transports?

[Blitzerland]

No, you looney.

Anyways, thanks for the help, all. I think I've got it now.

[karajorma]

Originally posted by Blaise Russel
Well, 'awe' may be hyperbole, but it's something that didn't occur to me at all, and I would have gone for a solution that uses three times as many events, so...

I do worry about that whenever I post a solution. FRED is getting so powerful these days that I wonder if I'm missing a really easy short cut somewhere

[Night Hammer]

id go with kara's suggestion, those variables creep me out:p

[karajorma]

I've never understood why variables scare so many people. I was using them in the first mission I ever made straight after doing the walkthrough

It was only when I got online and visited the VBB that I learned that variables were meant to be something I was supposed to be scared of for years

[Hippo]

I tend to avoid them, just of old habit... My first experience was when i put a space in a variabl name, and managed to destroy the mission...

I prefer to make long, drawn out events... I think for 2 reasons: One, because I enjoy thinking it through and making it work. And two, because i think its easier to debug. I'll compare the second statement to another situation: You are new to a campaign. You 'inherit' a half done mission from someone else. You have the plotline, but have to spend quite some time picking it apart, seeing how everthing was done, and either change your building style to use whats there, or redo everything to fit your standards. Most times its easier to just start over, and build it in a way that you know exactly whats going on. I choose to use long events, because that way i know exactly what is making things work, and often times, not work...

I'm pretty sure most people would use variables if they had to, but personal preference might make them avoid it...

[karajorma]

Thing is that there are several things that can only be done with variables.

Don't use them and you are imposing severe limits on what you can do with FRED (and those limits are getting larger as I think of new things I can do with them almost every time I open FRED)

[Hippo]

True, which is when i will use them. But 90% of the time, when there's something that can be done with a variable, it can be done with regular SEXP's... You also have to figure, that I like many others learned to FRED on FRED1, so its like giving someone an extra option, that they've already learned to live without in most cases.

[Night Hammer]

yeah ill use them if need be, but for the most aprt ill try another route

[Trivial Psychic]

I could condense it all down to one event, one variable, and one message, if the latest version of FSO is used.

variable = convoyships, default value of 0

message: convoy destroyed

"We've lost $convoyships of our transports!"

event name
-every-time-argument
--any-of
---Ship 1
---Ship 2
---Ship 3
--is-destroyed-delay
---< argument >
---0
--modify-variable
---convoyships(0)
---+
----convoyships(0)
----1
--send-message
---#command
---high
---convoy destroyed

[karajorma]

True TP but there are two problems with that.

1) Due to a bug in the way messages are sent the message will just keep repeating ""We've lost 1 of our transports!". The variable $convoyships is resolved into a string the first time the message is used. From then on the string won't change no matter how many times you call it or change the underlying variable.
 Goober's aware of this bug and said he's trying to think of ways to solve it (If he hasn't already! )

2) The message would be rather repeatative. The methods suggested above would allow you to have a different message for each outcome.

That said it's a nice use of every-time-argument

[Hippo]

yeah, combine that with send random message, and its really good