@Novus-Wojtek LOUD is based entirely on the original EXE, so that points to some differences that aren't currently resolved.
Marlo has indeed made considerable progress in putting together a version of this project which is entirely compatible, which would be a potential boon for both LOUD and users of the Steam version of the game. My personal feeling is this - if this work can reach to all the many players who don't use FAF, or LOUD - then it's only good for both communities.
@Nuggets FAF is not the entire Supcom world. While it is popular - the bulk of the audience are solo players who never touch the FAF environment. ModDB is an excellent repository - and one that generates a tremendous amount of traffic and visibility. All modders, with non FAF-specific mods, like this one, will reach a far broader audience there.
LOUD is much like FAF, but primarily aimed at players versus AI games, rather than PvP. Also, like FAF, it is it's own environment so it's a bit of a shift. You can find it at https://www.moddb.com/mods/loud-ai-supreme-commander-forged-alliance
Having made my usual pitch, I'll point out that the code used, to do this, is entirely portable to FAF - but you'll have to find someone to do that.
LOUD has an edit box that lets you enter any value you'd like.
@Szasz Map markers are still important for many things such as defensive points, expansion bases, etc. Some of the FAF AI take advantage of a method which makes pathfinding free of markers, using a zoning method - but that's where it stops.
Pathfinding is important, and the marker method is very effective - but - only if the map maker understands how the AI uses the markers, and places the markers with that knowledge. That's the missing part for most AI, as it's not a very interesting subject.
The placement of the many other marker types has a dramatic impact on the AI's gameplay, but again, it requires a thorough understanding of how the AI uses those, and the intelligence around how they are evaluated, that makes all the difference. It's a subject that also requires a real understanding of how the particular map plays - there simply is no universal rules that work for any large segment of maps out there.
Historically, map marking has been neglected, with many map authors either doing nothing but the bare minimum, which brought about the creation of the zone method as a way of getting around the sheer number of maps that were badly marked.
Historically, believe it or not, this has been an audio issue and is usually associated with the 'Surround Sound' issue. Your game log file will likely reveal that you have an XACT:SND error.
You hit the nail on the head - nukes have a targeting limit - and once targeted by a 'ready' anti-nuke, other anti-nukes will NOT fire at that missile. This is what keeps your anti-nukes from all firing at the first nuke to come in range.
If however, that anti-nuke should miss - or be unready to fire - while still targeted on the nuke - you get this result.
As I recall, going to Idle State will NOT break the target lock, leaving you vulnerable.
The use of mass, for veteran levels, is purely a FAF based change. It supplants the original kill based mechanic. The healing mult is likewise, a FAF-only change. In the original game, when a unit made a vet level, it would have it's HP set to a % of it's new HP max, based upon how damaged it was. In FAF, this gets replaced with a fixed % of healing, based upon the HP of the unit at the time it makes the level.
There was a mod, many years back, called Total Veterancy - that extended the concept pretty much along the lines described above. It was quite popular, balance issues aside.
The primary drawback of this method is performance. Unit buffs are very memory intensive - especially when considering stacking multiple unique buffs, and even moreso when you consider that buffs are stored per unit - this adds up VERY quickly, not just for adding and removing the buffs, but the amount of memory consumed by each buff, for each unit, grows very quickly and will grow to a point where it will lead to memory cap crashes.
The mechanics for doing this work are pretty sound, but fairly code heavy.
Splitting a single projectile - into multiple 'child' projectiles, is currently done in a couple of already existing weapons. The Cybran T2 Mobile Tactical Missile launcher unit, and the AEON T3/T4 Artillery Experimental.
You should look at how those scripts deal with creating new projectiles, based on the trajectory of the old one - while in flight.
There are several moving parts at work here.
First off, the GC is not on the Land layer, it's still technically on the seabed - and you don't have Water Vision, so to you, it's not visible. If you had WaterVision, in your blueprint, you'd be able to see him. Even though the GC is underwater, it still has normal Vision, so it can see you.
Second, your weapons are not likely allowed to hit units that are on the seabed AND below water. Whereas the GC's Eye beam weapon is allowed to fire when it's above the water level at targets that are above the water. This particular situation, might be improved by insuring that the bone, on the GC, that is above the water, is listed as one of it's 'Target Bones', as found in it's blueprint. In this way, your weapons would have a bone, that they can target, when it gets above the waves.
@destroier6 It's not a bug - and it's not the AIx Omni setting.
The stock campaign AI is almost entirely 'scripted' and isn't really doing anything but following the plan written for it.
There is a flaw in the targeting process, where an empty launcher will remain 'locked' on the target - which prevents other launchers, which are loaded, from firing at that missile - it's called the 'shooter cap'.
What needs to happen, is that shortly after firing (even when there are additional rounds in the launcher), the launcher needs to go 'offline', and drop it's target - which will allow other launchers to engage the missile. Now, this is how the launchers are meant to work, and most of the time they do this, but - if there are a lot of launchers involved, and the primary happens to go empty - there's little to no chance that the target will drop, in time, for another launcher to perform an intercept.
This is the same mechanic that keeps all your SMD's from firing at the same inbound missile - so it's not something to be disabled.
@Laso That's essentially how M28 (and many previous AI as well) performs. It has information it shouldn't, and does things with units that you would find it either impossible or incredibly difficult to do. It's not, and doesn't claim to be, a level playing field.
There have been several attempts over the last decade+, to loosen the source code from it's rights holder. All have been denied or rebuffed, even with significant monetary offers. The game still provides a small, but steady, revenue stream, so it's still viewed as a productive asset. While that situation is most certainly declining, year over year, I don't imagine that any offer south of $100k is going to get a whole lot of notice.
I'd like to hope that I'm wrong, and sometime soon - but that's how it stands.
Interesting - I'll have to check if we even use SinkLower in our units.
LayerChangeOffsetHeight can alter which weapons will fire, and when they are seen as 'above water' - so quite likely this value exposes those bones that would otherwise be targetable. I've often worked this value carefully (especially with multi-weapon units) in order to get a better response to weapons firing when actually out of the water - so yes, it's a finnicky thing.
There's nothing quite normal about it - and it's a relatively easy fix.
In this circumstance, the spider's weapon is 'above water' and is allowed to fire. The body, however, is likely on the 'Seabed' layer - and as a result, your weapon is not likely allowed to target that layer.
Weapons aim at 'target bones', and in many cases, a unit will only have one, which often defaults to the 'root' bone (often around the base of the unit). Large units, like the spiderbot, should have multiple target bones specified - and ideally, there should be one up near the top of the unit, which would be targetable.
In order to check this, refer to the blueprint of both your unit (to see if it's allowed to target 'Seabed' targets - but is restricted to 'AboveWater' targets only) and the spiderbot, to insure that it has a targeting bone that would be above water when the weapon it has is.
It's not 'micro' at all - it's just lax coding.