Author Topic: Yet Another "It's my first mission"  (Read 394 times)

0 Members and 1 Guest are viewing this topic.

Yet Another "It's my first mission"
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.
« Last Edit: May 06, 2017, 07:33:50 pm by Asteroth »

 

Offline AdmiralRalwood

  • 211
  • Mister Subspace Strikes
    • Skype
    • Steam
    • Twitter
Re: Yet Another "It's my first mission"
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.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 
Re: Yet Another "It's my first mission"
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.
Excuse me for any spelling errors I make - I'm still learning English :P

 

Offline niffiwan

  • 211
  • Eluder Class
Re: Yet Another "It's my first mission"
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...)
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Linux OBS Packages: FSO 3.7.0 | FSO BP Build | wxLauncher (?) | PCS2 (?) | wxVPView (?)
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline 0rph3u5

  • 211
  • Stop calling me 'intelligent', I am clearly not
    • Steam
    • Twitter
Re: Yet Another "It's my first mission"
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]
« Last Edit: May 06, 2017, 08:10:41 am by 0rph3u5 »
"As a rebellion fails, a search begins."
- The Lost Generation - Ashcroft coming soon -



"...because they are not Dragons."

 

Offline 0rph3u5

  • 211
  • Stop calling me 'intelligent', I am clearly not
    • Steam
    • Twitter
Re: Yet Another "It's my first mission"
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.
« Last Edit: May 06, 2017, 09:27:27 am by 0rph3u5 »
"As a rebellion fails, a search begins."
- The Lost Generation - Ashcroft coming soon -



"...because they are not Dragons."

 
Re: Yet Another "It's my first mission"
@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.

 

Offline 0rph3u5

  • 211
  • Stop calling me 'intelligent', I am clearly not
    • Steam
    • Twitter
Re: Yet Another "It's my first mission"
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.
"As a rebellion fails, a search begins."
- The Lost Generation - Ashcroft coming soon -



"...because they are not Dragons."