bugfix: Remove erroneous SlowDeathBehavior from the GLA Demo Barracks

[Stubbjax]

This change removes an erroneous SlowDeathBehavior module from the GLA Demo Barracks, which caused it to incorrectly play the Terrorist detonation effect when destroyed via an +EXPLODED death. This is a clear copy/paste error and makes no sense as the Barracks cannot suicide.

The video below highlights a distinct Terrorist detonation effect when blowing up the GLA Demo Barracks on the right in comparison to the vanilla GLA Barracks on the left.

COMPARISON.mp4

[xezon]

The barracks disappears for one frame when killed:

[xezon]

I cannot tell a difference from the video.

[xezon]

Since this is a bug fix, do you also intend to create change log yaml files so we can generate change logs for user facing fixes?

[Stubbjax]

The barracks disappears for one frame when killed:

This happens in retail.

I cannot tell a difference from the video.

Try listening carefully - the audio is the main distinction.

Since this is a bug fix, do you also intend to create change log yaml files so we can generate change logs for user facing fixes?

Perhaps we should discuss how to best approach this. My preference would be to keep change logs external to the changes themselves and minimise development friction / contributors' barrier to entry.

Change logs can be automated these days, especially with conventional commits, and all of the respective meta data is already contained within the Pull Request aside from the final conversion from the technical git commit message(s) to a user-presentable highlight.

Alternatively, we could look at making use of the Projects feature and adding a change log column?

[xezon]

I agree change log yaml creates a lot of dev friction. I am afraid we will not produce good change logs going forward. Our Code repo also has no proper change log and Generals Online does not either.

[xezon]

This happens in retail.

Can be tracked as bug. I have never noticed this before.

Try listening carefully - the audio is the main distinction.

Ok I heard. Very well.

[Stubbjax]

I agree change log yaml creates a lot of dev friction. I am afraid we will not produce good change logs going forward. Our Code repo also has no proper change log and Generals Online does not either.

This is also my concern, though I'm happy to take responsibility for this.

There will undoubtedly be cases where it will be difficult to typographically convey exactly what a change does in a change log snippet, so any change log we build should always link each change to the respective Pull Request containing the extended explanation (ideally including visual presentations).

Perhaps it's enough to simply use a script to pull the data from the repository like I did for the spreadsheet and include it as a Mod Builder step? That would probably cover 90%+ of the workload. We could create a ChangeLog.json to optionally condense or ignore particular commits, override commit messages, or append meta data as necessary.

[xezon]

git commit history change log:

• automatic, least effort (good ✅)
• immutable, cannot be tweaked and corrected (bad ❌)
• has no labels (bad ❌)
• owned by git history (okay)
• git commit titles often do not contain any description other than the brief title (bad ❌)
• Cannot be silently edited without approval (good ✅)

git pull history change log:

• semi-automatic, little effort (good ✅)
• mutable, can be tweaked and corrected (good ✅)
• has labels (good ✅)
• owned by github.com servers (bad ❌)
• pull request descriptions are practically prone to vastly different format styling and wording style which is not ideal for change logs (bad ❌)
• Can be silently edited without approval (bad ❌)

yaml change log:

• manual, more effort than just creating the pull request (okay)
• mutable, can be tweaked and corrected (good ✅)
• has labels (good ✅)
• owned by repository data (best ✅)
• yaml change log titles and descriptions are intuitively encouraged to be crafted with consistent style and wording (good ✅)
• Cannot be silently edited without approval (good ✅)

---

I would always do yaml change logs again. git history change logs sucks because they cannot be tweaked unless an override format was introduced. yaml change records can be tweaked, removed, corrected. The only downside of yaml is the additional maintenance effort required.

Git pull history change log is a possibility. It gives more flexibility than Git commit history because pulls can be freely edited. But it means that github.com owns the change log source, and not our git repository.

If you have a better idea you can have a go at it.