Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: Wet Orange Ostrich Toilet on September 14, 2016, 04:24:10 am
-
I ask way too many questions, don't I?
Alright, I planned to release smaller, 5-mission campaigns or just singular missions now. For said singular mission, I got a great idea but no way to put it in practice as far as I know.
Here's the plan: You have to destroy cargo containers with something unpleasant inside it, which can kill your ship over time, requiring you to stay at maximum distance when firing.
Now, the key word here is "over time". I don't want the ship to get destroyed instantly, I'd much rather have it take progressive amounts of damage, starting at 7 seconds.
How it should be:
7 seconds - A subsystem gets destroyed
14 seconds - Another one gets destroyed
21 seconds - Third and last one gets destroyed
28 seconds - ship takes massive hull damage
and so on.
-
Do you need to avoid LUA for any reason?
With LUA this would be pretty straightforward.
-
With SEXPs it would be pretty easy too though. Unfortunately I'm on my phone so I can't type out a full solution but all you need to do is something like this.
When-arguement
-any-of
--subsystem 1
--subsystem 2
-- ...
-- hull
-in-box (or distance from something)
- sabotage-subsystem
-- argument
- when
-- hits-left-subsystem
--- argument
--- 0
-- invalidate-argument
If you add some system to make that system trigger more often than once a second the player would watch their subsystems strength slowly tick down followed by their hull.
Now this isn't exactly what you asked for, but I think it actually looks better than subsystems at 100 percent suddenly exploding every seven seconds.
-
With SEXPs it would be pretty easy too though. Unfortunately I'm on my phone so I can't type out a full solution but all you need to do is something like this.
When-arguement
-any-of
--subsystem 1
--subsystem 2
-- ...
-- hull
-in-box (or distance from something)
- sabotage-subsystem
-- argument
- when
-- hits-left-subsystem
--- argument
--- 0
-- invalidate-argument
If you add some system to make that system trigger more often than once a second the player would watch their subsystems strength slowly tick down followed by their hull.
Much appreciated. Thank you. That solves one part of the thing.
Do you need to avoid LUA for any reason?
With LUA this would be pretty straightforward.
I didn't specifically avoid LUA for any reason. It's just
1) I am terrible at coding
2) I forgot about LUA. In fact, I never knew it could be used here.
-
Lua would be waaay overkill for that kind of thing, unless you plan to reuse it every two missions.
A SEXP solution would make a lot of sense.
Adding to Kara's solution, you could use a variable to keep track of the "stage" of the kill-over-time, then use multiple if-then-else / when to apply the relevant effect.
-
For timing it, I'd do something like this...
when in-box or distance or whatever
modify-variable
SOMEVARIABLE = mission time
when in-box AND mission-time >= SOMEVARIABLE + 7
do the subsystem destruction stuff
-
For timing it, I'd do something like this...
when in-box or distance or whatever
modify-variable
SOMEVARIABLE = mission time
when in-box AND mission-time >= SOMEVARIABLE + 7
do the subsystem destruction stuff
Okay, I'm probably being a total idiot and am totally not doing it right. I "think" I did the correct setup but when closing the Events window it threw an error at me, saying the variable can't work.
(Screenshot is the current setup)
Sorry for being a bother again, I am terrible when it comes to the more complex stuff of FRED.
(Side question: How can I use time related operators? They're always greyed out for me.)
[attachment deleted by admin]
-
Your variable needs to be a number variable not a string variable. Default value can be anything you want as long as it's a number.
-
Also there's not much point in setting your variable to the mission time + 7 and then comparing mission time to the variable + 7 (which appears to be what you were trying to do), because that would add up to 14 seconds before anything happened.
-
:shaking:
Ok, you're...you're typing stuff in that doesn't quite...work the way you think. Open up a mission that uses variables and examine how they're handled.
I will try to talk out/pseudo-SEXP how this SHOULD look:
Create a new variable, using right click on events editor -> add variable. Make it a numeric variable. Call it missionTime, default value 0.
Your first event should read
When
(is-in-box [as you have it set up])
modify-variable
-missionTime(0) [make sure to right click on this and use Replace Variable to be sure you're setting it to @missionTime(0), do NOT just type it in]
-mission-time [right click on the default number, go to Replace Operator, go to Time]
Your second event should read
When
and
(is-in-box) [as you have it set up]
has-time-elapsed
+ [right click, go to Replace Operator, go to Arithmetic, choose +]
- missionTime(0) [remember to use Replace Variable to get this]
7 (the value being added to missionTime(0)
destroy-instantly Alpha 1
UNFORTUNATELY this event setup is wrong, you were misled. It will cause Alpha 1 to self-destruct 7 seconds after it has entered the box for the first time, if it is still in the box, or if it ever goes back to the box again.
What you NEED to do is create a variable called something like 'boxTime', have it increase by 1 every 1 second Alpha 1 is in the box, and set up other events to do various things when boxTime = 7, =14, =21.
Need any help figuring that out?
-
Seriously just open up a mission with some basic variable use and study how the events are set up. Best way to learn.
-
I'm still not sure what was wrong with my example that everyone had to go and do it a more complicated and uglier way. Here, download this (http://fs2downloads.com/Misc-Downloads/DangerZone.7z) and see how I'd have done it. For a bonus I threw in a system that makes it play a warning sound whenever you're within 1km of the radiation source and taking damage.
There are a couple of issues I'll cover.
1) The game crashes if you try to pass Hull as an argument to hits-left-subsystem-specific. Hence why the call is wrapped in a check to see what the argument is. I'm not entirely sure why that is, and since this isn't the only time it's an issue, I might look at the code and see if that can be fixed.
2) The game refuses to pop up the damage gauge unless the ship takes actual damage no matter how much I use sabotage-subsystem. For this reason I set the player to 99%. This definitely seems like a bug and I'll look into it or Mantis it.
3) Neither my version (or anyone else's for that matter) will cope with the player calling in a support ship to fix them after they take subsystem damage. If you don't want to disable support, you'll need to decide what to do about that.
4) The system currently destroys a subsystem around every 5-6 seconds. Fiddle with the modify-variable -> ClockTick section of the first event to set it to whatever you want. I suspect a value only a little bit over 100 will do what you want.
5) You don't have to use Kenny Loggins as your warning sound, but lets face it, whatever else you do use will be less awesome. :p
-
I'm still not sure what was wrong with my example that everyone had to go and do it a more complicated and uglier way. Here, download this (http://fs2downloads.com/Misc-Downloads/DangerZone.7z) and see how I'd have done it. For a bonus I threw in a system that makes it play a warning sound whenever you're within 1km of the radiation source and taking damage.
There are a couple of issues I'll cover.
1) The game crashes if you try to pass Hull as an argument to hits-left-subsystem-specific. Hence why the call is wrapped in a check to see what the argument is. I'm not entirely sure why that is, and since this isn't the only time it's an issue, I might look at the code and see if that can be fixed.
2) The game refuses to pop up the damage gauge unless the ship takes actual damage no matter how much I use sabotage-subsystem. For this reason I set the player to 99%. This definitely seems like a bug and I'll look into it or Mantis it.
3) Neither my version (or anyone else's for that matter) will cope with the player calling in a support ship to fix them after they take subsystem damage. If you don't want to disable support, you'll need to decide what to do about that.
4) The system currently destroys a subsystem around every 5-6 seconds. Fiddle with the modify-variable -> ClockTick section of the first event to set it to whatever you want. I suspect a value only a little bit over 100 will do what you want.
5) You don't have to use Kenny Loggins as your warning sound, but lets face it, whatever else you do use will be less awesome. :p
Thank you!
Seriously. You're awesome! That is exactly what I needed. (Not that the others weren't helpful, thank you too everyone!)
Also, the warning sound made me laugh so hard I forgot to check up on my ship and ended up dying.
Again, thank you.
(PS: sorry for responding so late, I know it's 6 AM according to HLP Forums but over here in Europe it's noon.)
-
I'm in China so it doesn't really matter to me. No one here really cares if it takes a day or two for a response.
Glad the warning sound made you laugh.
-
(Not that the others weren't helpful, thank you too everyone!)
Probably a case of too many cooks in the kitchen :)
We've all got our ways of doing things, so when someone comes with a problem to solve, everybody thinks up a different solution.
When in doubt, listen to kara. Or Axem.
-
(Not that the others weren't helpful, thank you too everyone!)
Probably a case of too many cooks in the kitchen :)
We've all got our ways of doing things, so when someone comes with a problem to solve, everybody thinks up a different solution.
When in doubt, listen to kara. Or Axem.
No, dude, that wasn't the problem at all. The problem was woot (understandably) hadn't got any experience with variables yet, so the advice people were giving him wasn't specific enough.
-
Like, Kara's readymade solution uses arguments, which is yet another layer of complexity to grasp.
-
It's awesome that kara presented a super cool polished solution, but also, woot needed to pick up some tricks like 'how to add a variable' and 'how to change a variable'.
Really not a case of too many cooks.
-
Point taken.
EDIT - But did you really need to triple post it ? (or is that a post-from-phone thing ?)
-
Like, Kara's readymade solution uses arguments, which is yet another layer of complexity to grasp.
Just be glad the container code isn't in trunk yet. I had a solution involving those first. :p