Hard Light Productions Forums
FreeSpace Releases => Mission & Campaign Releases => Topic started by: Asteroth on May 06, 2017, 12:01:33 am
-
Yep, it's that time of the month when a wide-eyed hopeful inexperienced FREDer puts their horrible BoE "left all the dogfight weapons in the loadout" mission for all to see and rip to shreds.
Anyway, I had a lot of fun making it, my hope is of course it doesn't commit too many cardinal sins. It's a single mission that fits neatly into the FS2 campaign storyline, shortly after the discovery of multiple Sathanas Juggernauts and the GTVA is pulling out of the nebula for the second time. Go and play it, it's attached below and about 10-15 minutes long depending on how much of a perfectionist you are.
So, now that you've played it and aren't being naughty and looking forward and spoiling yourself, I have some question about FRED and mission design in general.
1. The only actual bug I was embarrassingly unable to fix. Briefing text keeps spilling over outside of the UI box it's in and looks horrible. I couldn't figure out any way to fix it, putting in line-breaks myself only had disastrous effects.
2. Making capital ships prefer certain targets was annoyingly difficult to implement. I can beam-protect all the things I don't want it to shoot, but that prevents anyone from shooting those rather than a certain ship not shooting it. Telling it to "Attack" its target works, but also cause the ships to move around, which in this case wasn't what I wanted to happen. I didn't try also ticking "Does not Move", since I figured this would probably also have some unintended effects.
3. And finally chaining events. This is nice, but it seems to only work linearly, rather than multiple branching paths. Now normally I got around this by just have an is-event-true-delay in the condition for dependent events. But this isn't always possible. See the attached image for a particularly annoying example.
"all ships done?" (both of them) count up all the mission critical ships and returns true if they're all dead or departed. The idea is that this triggers the Ishtar to say "gtfo" if it's still around, and Command to say it otherwise, and to enable a return to base directive. "Return to base" should only be activated after "gtfo", but it can't be chained because the "gtfo" condition might be true or false, so I had to make it dependent on the condition before that which was "all ships done?", resulting in the obviously unideal situation of two completely identical events in the mission.
Any input on how you guys handle these situations would be appreciated.
EDIT: Whoops think I solved 3. Didn't realize the result of a 'when' can itself be a conditional. I feel silly now, but that's extremely useful.
EDIT 2: Updated and fixed a few problems.
[attachment stolen by Russian hackers]
-
Briefing text keeps spilling over outside of the UI box it's in and looks horrible.
Make sure you have spaces after all of your color tags; screwed-up wordwrapping is a common symptom of not putting spaces after tags.
-
I'm wondering if #2 can be solved by giving the capship these orders (either via "Initial Orders" or via SEXPs):
- Follow waypoint path, priority 100
- Attack A, priority 90
- Attack B, priority 80
And so on. Nah, I didn't play it yet.
-
I... don't think that'll work, the attack orders won't be used until the waypoint path order is complete (not that I have any suggestions on solving the problem...)
-
2. Making capital ships prefer certain targets was annoyingly difficult to implement. I can beam-protect all the things I don't want it to shoot, but that prevents anyone from shooting those rather than a certain ship not shooting it. Telling it to "Attack" its target works, but also cause the ships to move around, which in this case wasn't what I wanted to happen. I didn't try also ticking "Does not Move", since I figured this would probably also have some unintended effects.
Try approaching it from a different angle. What you are currently trying to do is implimenting broad rules with "beam-free"/"beam-protect", but the engines allows much more fine tuning.
The "fire-beam" SEXP is you best friend in this situation has allows you to micro-manage the firing of the main beam cannons rather than allowing the AI free reign.
This will certainly increase the number of events you have in there but the effect is worth it.
[note I am getting an example ... stand by]
-
Sorry for the delay... loading a mission with the HTL Colossus in it takes time...
I cut out a bit of the trigger because the logic hidden behind the "not" is a bit complicated to explain (and that part hasn't been tested*), suffice it to say that the event doesn't trigger if either the An Luchan or the Fronde are not/no longer in the mission.
What it does is to fire the turret59 of the Colossus (a BGreen) at the An Luchan, if it is still around. If the An Luchan has been destroyed already it should fire at the Fronde instead, as long as the ship hasn't been destroyed yet either.
Using the additional "when"s should cut down on the number of events you have to use; HOWEVER if you run an "event-true-delay" it will only check the highest trigger not the condition-bound actions. this means the event will read as complete and true/false even if the additional conditions for the "fire-beam" to be executed have not been met.
(How to get them: you can replace the "do-nothing" of a new event with "when" via Replace Operator > Conditionals.
*EDIT: I was experimenting with mechanics for a persistent fleet at the time I made the mission originally and I kept it in during a recent update. While it is rather basic here it is still a complictated mess as you have to include checks if the ship actually arrived in the mission - as opposed to have been destroyed in the previous one.
[attachment stolen by Russian hackers]
-
@0rph3u5: I like this idea. I had previously only considered fire-beam in very restrictive, highly choreographed scenes, but with the proper scripting it appears it would work for this as well.
My only worry in this case is making the fire sequence event broad enough that the ship in question should be able to fire indefinitely while it's around, that is, indistinguishably from "normal" firing. I would presume to use a high repeat count, with a delay equal to its rate of fire, is that what you did? Random refire delay would also be a casualty of this method without another chunk of scripting.
Also there were two other issues I forgot to note:
4. Are there any ways to mess with wave mechanics through SEXPs or otherwise? Like modifying numbers of waves, wave threshold, delay between waves, etc? Grouping ships into many waves of a single wing greatly simplifies a lot of operations, but you also lose some precision in how you can use them without also being able to modify those things.
5. I noticed several times ships use capital-size beams to shoot down bombs! This is obviously a bit overkill and very silly.
-
My only worry in this case is making the fire sequence event broad enough that the ship in question should be able to fire indefinitely while it's around, that is, indistinguishably from "normal" firing. I would presume to use a high repeat count, with a delay equal to its rate of fire, is that what you did? Random refire delay would also be a casualty of this method without another chunk of scripting.
I didn't use a repeat count. In that example only one or two shots each would suffice so I just dublicated the event for the required ammount. But basically it should be possible to use a repeat count.
Random refire delay can be introduced too, I think ... I have something similar in the works ATM, that relies on repeating events with a randomized delay between executions. But there has been a hang-up that still needs to be properly diagnosed:
http://www.hard-light.net/forums/index.php?topic=92675.msg1832054#msg1832054
(Ignore the inital mistake with the triggers that's fixed)
4. Are there any ways to mess with wave mechanics through SEXPs or otherwise? Like modifying numbers of waves, wave threshold, delay between waves, etc? Grouping ships into many waves of a single wing greatly simplifies a lot of operations, but you also lose some precision in how you can use them without also being able to modify those things.
To my knowledge there is not.
While using waves seemingly simplifies a lot, it does have an adverse effect I didn't consider for a long time as well: Using more wings instead of waves provides better feedback to the player regarding their progress in the mission. As FREDer you usually don't notice because you know the information for each wing, players do not have that information so fighting seemingly endless waves can break the motivation to go on.