New Versions of (RAS) Notify

[CodingSquirrel]

I've just put V3.4 up onto the vault. As mentioned above, the biggest feature is gaining access to higher tech while the upgrade is still in your queue. Full notes below.

• When a new Engineering Suite is queued up, you will gain access to the higher tier construction tabs (this should respect all unit restrictions)
• Fixed an issue where increased sim speed could cause a finished upgrade to be interpreted as a cancel
• Fixed an issue where clicking an upgrade for a group of SCUs, if they already had the upgrade they will remove and upgrade it anyway
• Fixed the annoying selection sound being activated when queueing upgrades on multiple SCUs
• Fixed an upgrade being incorrectly highlighted if you have a group of SCUs and the one at selection index 1 has an upgrade already
• Fixed an issue where a group of SCUs, when given a "clean" command to start an upgrade, only one of them would actually receive the command as "clean"

[CodingSquirrel]

One other outstanding issue I have, that I don't think I'll be able to fix while keeping this UI only, is if you try to do a "clean" command while on an upgrade the mod will think you have canceled your upgrade despite the fact that it is still running. What I mean by "clean" command is if you try to issue a command without holding shift, which would normally reset your orders and issue the new one only. It technically does that, but will also leave your current upgrade running. The problem this causes for me in tracking what's going on, is that even though the upgrade is still running, the unit's queue completely forgets about it. I just don't know a way to interpolate that missing information accurately. Any solution I tried to come up with, I could also come up with scenarios where the data I had available could mean multiple things. So basically unless this can be fixed sim side (such as doing a full cancel on an upgrading ACU/SCU if given a clean order set), don't issue clean orders if you want the notify to properly print to chat. I believe right now it will result in a notification of the upgrade's cancellation, and will remove the upgrade from your displayed build queue, despite the fact that the upgrade is still running.

So I ended up fixing this after all. I will likely hold off on submitting this fix for now, just in case something else comes up, so that I'm not submitting so many versions. That is, unless people report that this is causing some issues for them. (everything below here is a bit technical)

The behavior is a bit different than I had originally understood. If you are currently upgrading and attempt to issue a clean command, it will issue that command like it always does, and as far as how the engine reports it that's exactly what happens. Except, since you are upgrading this clean command fails, so the commands revert to their previous state, which includes your entire previous queue of commands. So unlike what I previously thought, it doesn't actually clear all commands and forget about it, it just forgets about it when it tries to issue the command which ultimately fails. Another oddity to it is that when you click and drag a line of orders, they're actually given one at a time. So even if the first is a clean command, all of the others are issued as non-clean. This means that only the first in the line (the one that wasn't clean) is actually canceled, and the rest are just appended to your original queue as if you had been holding shift. The fix for this is actually quite simply, if I'm upgrading and a clean command comes in, I ignore it. If it's just a single command then it would be ignored anyway. If it's a line of commands, they'll be processed on their own as a non-clean command anyway and will be handled like normal.

[CodingSquirrel]

Alrighty, so I guess it's a good thing I held off on uploading the bug fix last night since I've got some more goodies today to go with it. It's up in the vault as Notify V3.5

Changes are as follows:

• Hotbuild now works with the queued advanced engineering upgrades
• Added commands to enable and disable the ally notify portion of the mod. /disableNotify will turn it off (saved), /disableNotifyOnce will turn it off for the current game, /enableNotify will turn it on (saved), /enableNotifyOnce will turn it on for the current game
• Fixed/changed the behavior so that if you deny the prompt for removing existing upgrades for a group of SCUs, ones that didn't conflict with the choice will still get the upgrade
• Fixed the issue with issuing non-clean commands during an ACU upgrade. The game's behavior is unchanged though, and will cancel the first building/command and append the rest to your existing queue. See previous comment for more details.

The code that allowed for '/command' functionality was graciously borrowed from Crotalus' ecomanager mod.

[Krachbummente]

Could you change the name of the Folder the Mod automatically is installed in? It bites with other notify Mods I am using often, too. If i rename the folders Manually the game wont start properly after that (if one of the notify mods is activated). That would make it easier to compare future mods, too.

[CodingSquirrel]

What mods are you having conflicts with. If it's the same folder name then it's probably the same mod but an older version.

[CodingSquirrel]

Alright, here comes version 3.6! So many versions.

• The chat commands have been changed and added to. The commands are now: /enableNotify and /disableNotify will turn on and off both the chat notifications and the ETA/Percent overlay, /enableNotifyChat and /disableNotifyChat will turn on and off just the chat notifications, and /enableNotifyOverlay and /disableNotifyOverlay will turn on and off just the overlay. Adding "once" after any of these commands will keep the settings from being saved, it will only keep the changes for the current game (e.g., typing "/disableNotifyOverlay once" into chat will turn off the overlay for this game only).
• Fixed an issue where hitting 'Stop' with an upgrade queued, but while you're not currently upgrading (e.g., you have a building queued up first, or a move order first) caused the notifications to display incorrectly for the next upgrade
• Fixed an issue where having an upgrade queued (but not started) which requires an upgrade removal first would cause problems with the displayed queue
• Fixed an issue where if you are not currently upgrading, but have an upgrade queued, and then issue a clean command to upgrade to the higher tier version of the already queued upgrade, it would fail to do the new upgrade that was issued
• Fixed a very small window that would allow a clean command while upgrading to still cause issues for the ACU
• Fixed the clean command while upgrading issue from happening to SCUs

[Sir Prize]

Just adding my suggesting that I said in aeolus - if you have the time and it's easy it might be good to be able to switch between talking to allies and talking to yourself for unlocked team FFAs such as PhantomX.

Again, awesome work Squirrel .

[Downlord]

+1 for integrating this into standard FAF! It has always been a pain not to be able to enqueue upgrades.

[CodingSquirrel]

I just discovered today that the UEF nano-repair upgrade is actually not being picked up by the mod correctly. This is due to a slight typo in the name of the upgrade in the code (not my code). It's called "DamageStabilization" for the other commanders, but for the UEF it's "DamageStablization". It's an easy fix (and I've already fixed it for myself), but I don't think it requires a new upload. Almost no one uses that upgrade anyway.

[CodingSquirrel]

Uploaded Version 3.7.

Now supports UEF Nano-Repair upgrade.
Fix to make the mod compatible with FAF 3641.