Author Topic: DefCynodont VS The Mission bug of Misery.  (Read 1239 times)

0 Members and 1 Guest are viewing this topic.

Offline DefCynodont119

  • Moderator
  • 210
  • Ascended GTSC-Faustus Artist
    • Steam
DefCynodont VS The Mission bug of Misery.
This is a long story, and it's considerably longer when I tell it.   :warp:  So I will start with what I think is the important part.

So there I was FREDing, everything was almost going fine for the most part,  in fact, I was just about to add the part of the mission that is really hard FUN, It involves some hostile bombers attacking “a thing”, I'll just alas it as “Target-W”, and the class of bombers I was using, I shall refer to as “Redacted-Class” I added the bombers, and set them to attack target-w.

Some added preface: I have 2 wings of “redacted-class” bombers here, one set to attack target-w, and another set to attack any, I'll call the wings, “Wing-A” and “Wing-B” for now.

But in my play test, the Wing-A bombers generally preferred to attack whatever was closest, not target-w. “No matter.” I thought, I'll just flag them to use no-dynamic-goals, but they still ignored target-w, so I set them to have an attack priority of 75, but still, target-w was unbombed. “Okay, something is up”

I then made sure that target-w was unprotected, and indeed it was, the other ships had no trouble attacking target-w. . .  But setting Wing-A's “Attack Target-W” goal priority to 200 still did nothing.

So Naomi (known here as Xenocartographer) Asks me if it has something to due with the object type, a fantastic question, I have bombers of other classes in this mission, and they don't act like this. . BUT MjnMixael confirms that the Redacted-Class bombers work fine in one of his missions. . .

So I do a test, I make Wing-B (the same class) attack Target-W, annndddd

They don't attack it.  “INTERESTING” I think, perhaps the issue is the class of object target-w is?
I'm naively happy, I think I'm getting to the bottom of this, it's been narrowed down, I should have this figured out soon. . .

I then make a test mission, but the Redacted-Class bombers (as well as some other fighter and bomber classes) attack Target-w just fine, as would be expected, I even try adding a few distractions in the form of warships and fighters obstructing their attack path, but still! They act the way they should!

And that is what I did next, At this point, I was convinced it had to be something my mission was doing SEXP-wise, or perhaps Ship-Flag wise, that wasn't playing nice with the bomber AI, Now why that would only effect Wing-A, I had no idea! But as it turned out, that wasn't it either! Collision groops had no effect on the bombers!

So I was confused about how to move forward, but Xenocartographer made a good suggestion.

It was time to bite the bullet and do this, time to make a copy of the mission file and rip it apart, I knew the problem was likely confined to this mission, and this was a good way to find out what it was, be it a FREDing mistake or a Code bug.

“hmmmmmm” This was the sound I made as I set Wing-A and Wing-B of Redacted-Class bombers to arrive at the start of the mission, that would save me some time, I also Highlighted them Via some IFF coloring, I confirmed the issue still occurred at the beginning of the mission, and started messing with various things, from changing what they attacked, to messing with the goal priority again, and moving them to different places in the mission. As I did this, I made an observation:

Why was this? WHY? Was the AI just being incredibly fickle? Was the AI Just so distracted by all the juicy targets that it refused to acknowledge target-w EVEN with no-dynamic-goals and 200 priority?

I decided I had enough, I was going to see if I could FORCE the AI to attack Target-w in this mission, so I did the extreme, I made a repeating event that protected EVERYTHING THAT WASN'T TARGET-W. If something was actively stopping Wing-A and Wing-B of Redacted-class bombers from attacking Target-W, this would confirm it.

WELL NOW. I already knew that Target-W was not protected because the other things were attacking it.

So I did as she suggested and cleared the orders. . AND THINGS GOT WEIRD.

I watched in perplexed wonder, as Wing-A 1 made the attack run, but Wing-A's 2 though 6 made no effort to do anything at all, just drifting around while their wing leader did all the work.
Not unlike Alpha wing's default behavior funnily enough. . .

I was now questioning my sanity. could this be because of the number of ships?! No that makes no sense! Why was this happening here and not the empty test mission?? Did FSO just hate this mission!!??? WHY WHY WHY WHY WHY!!!!!!!????

This wasn't even the first time this mission gave the BtA team this much trouble, but more on that later. . .

So I tried something I had not done yet, I changed the Redacted-Class bombers to another class, and AND: NO CHANGE IN AI BEHAVIOR. I set them to Disarm instead of attack, AND NO.

So I keep going, doing things, anything I could, regardless of how reasonably it could be related to the issue.

False lead after False lead had left me weary, this AI bug was evading me, 
The next afternoon, I made a list of my observations, I could put it here but it would be redundant, All you need to remember is that the two (now three) wings of bombers were refusing to attack target-w. . regardless of what class they were, or what their orders were. But only if they were in wings. . . And the first bomber wing placed in this mission still attacked normally. . . .

Then I did something I had already done: I moved the distance the bomber Wing-A was at.

And after a play-test. . . Wing-B and the new wing were now attacking correctly.

What. . That. What?

I changed them all back to redacted-class, and moved all bombers wings back to the original positions, and: The AI was no longer acting weird! All wings were now attacking target-w without issue! But WHY? WHAT CHANGED?

I should have been happy, but it was now Schrodinger's Bug, my worst fear come to light. I had no test case for this, so I just started editing the now properly functioning copy of the mission to make it more like the original, but nothing I did made it have the issue again!

I had been at this for 2 days, and now I was just kinda, sitting there, making edits, running the mission, making edits, running the mission, making edits, running the mission, making edits, running the mission. Hoping in vain I would find the exact cause.

In hindsight, I now know that I had already found a workaround, but had no way of knowing that yet. The copy of the mission was now nearly identical to the original file in almost every relevant way. With the exception of the Wing-A and Wing-B not attacking Target-W. . . . (and a few removed event triggers to make testing faster) but I lacked an understanding of why. .

Then a something possessed me to try something, but before I talk about that, I must now explain that this mission indeed had a different problem, one I had dismissed as unrelated, with perfectly sound logic as well. Oh yeah, if you dear reader thought this was the end, we have yet to go my dear. .

About a weak ago, SOMEONE had allowed the release of a nightly build that caused our wonderful creation to DIE at mission load. And no other mission in BtA2, or BtA1 for that matter, had this issue, it would simply crash with no error in the log. The crash dump hardly revealed anything useful, but some digging by the Source Code Project revealed it was a
Code: [Select]
Wings[ai_wingnum].special_ship_ship_info_index = -1 error. I was prevented from working on this mission because of it. The coders then created a fix for this, a fix that SOMEONE broke just before it released. Forcing me to use an experimental build just to run this specific mission.

Past Frustrations aside, it was now that I, a broken husk of my former self, tried running the copy of the mission that lacked the Bomber AI issue with one of the regular nightly builds.

And I was beside myself when it ran without crashing. I exited the mission and ran the original, and that one crashed like always.

Life flushed back into my soul, I had it. I was in disbelief, but:

I would have to spend some time making sure the “torn apart and rebuilt” version of the mission worked fully when all the debugging events I added were removed, but it was worth it, as I now not only had the bombers acting as they should, but I also no longer needed to worry about using the experimental build!

Although I did have to re-balance it as the bombers were seemingly not the only ships effected, the hostiles now pay far more attention to their AI goals in general. The original cause is still unknown, but I suspect it is/was some form of bad data in the mission file that manifested differently as either a CTD at mission load and/or misbehaving ship AI.

But that was not important at the time because EVERYTHING WAS GREAT. THE CURSE WAS LIFTED.


And I still have no clue how it resolved itself. I did delete a few events and wings to shorten the mission for testing, however none of that was related to the bombers themselves.

In closing, I can now say that I am back on track to finish making this mission. And that FSO is an indifferent force of darkness that does not know justice and will gladly feed on the free time of those who did it no wrong if it is not kept sated with a diet of working code.

The End.   for now.
« Last Edit: November 22, 2022, 03:24:19 pm by DefCynodont119 »
My gift from Freespace to Cities Skylines:


Offline DefCynodont119

  • Moderator
  • 210
  • Ascended GTSC-Faustus Artist
    • Steam
Re: DefCynodont VS The Mission bug of Misery.

Sorry about that.
My gift from Freespace to Cities Skylines:

Re: DefCynodont VS The Mission bug of Misery.
This is why I stick to mechanical design.  The laws of the physical substrate don't usually change the engine they are being run on in between tests!

...Although a couple of times I've been tempted to think they did.
"Wouldn't it be so wonderful if everything were meaningless?
But everything is so meaningful, and most everything turns to ****.
-David Bazan