Add a proper description with links!

I did, youtube nuked it.

I'm liking these videos! They're giving me ideas

Does this include the 1 line change I suggested in the previous video thread?

Doah, damnit! No, I'm sorry, I completely forgot.

For the next one I'll make sure to do it.

Test beforehand, Im not sure how itll handle your metal extractor weapons

defences look to be incredibly strong.. the crisis was over the moment your first turret was up and shard just kept running small groups into it instead of attacking the ungaurded and accessible extractors below

In vanilla Shard, it counts units, it makes no distinction between 5 power structures, and 5 lightning turrets.

As a result, given 2 grid sectors, it would attack the sector containing 3 turrets, rather than the sector containing 30 power structures.

Also keep in mind that you could not see the actual target of the units. It may have sent them to a heavily undefended region at the back of the base, while the engine pathfinder sends them through the turrets.

All in all Shards attack system was intended as an example, something simple and elegant that just worked. I kept a lot of what you said to me in mind, and left my options open, and there is a lot of room for improvement merely in how it executes the existing behaviour.

For example, at the moment it targets the weakest grid sector:

• It could consider units with no weapons as weaker than units with weapons
• It could evaluate the maximum damage output of a weapon
• It could evaluate units within firing range but not inside the cell
• It could path around defences enroute and use the value of the weakest sectors enroute if defences are unavoidable
• It could have a behaviour that made units avoid enemy weapons ( as demonstrated in a lua widget not so long ago )
• It could evaluate how essential a unit is to the enemies cause, e.g. their only factory, their massive windfarm, their lone super hyper free metal producer etc

There's more to attacking the weakest point, than simply picking the weakest point and attacking it. Its not enough to tell me what Shard should do. In this case it is doing exactly what you are saying it should do, yet the result is not what you expect

actually, I'm pretty sure I specified the need for it to waypoint its movement to the low threat cells in a way that avoids high threat cells.

and yes, performance would improve significantly if you made it only consider units with weapons when counting units (ie, it counts unarmed units as 0.001 when counting). that way, it would gravitate its attacks to defenceless sectors instead of under-populated ones.

I would consider a generic unit with no weapons as 1, remember it culls sectors 0 or less, and I'd rather not deal with floating points if I can. Valuable units can be another setup.

Making weapons count as more than one makes more sense than making ordinary units count as less than one

right, so units with weapons are big number and units without are 1. boom, your attack system is now about 5x more intelligent. For an added bonus, make that number proportional to the DPS of the units in question.

make units that are to be avoided (turrets) give +1 and units that you want to attack (eco) give -1

but then a cell that just contains eco would be a negative number, which will probably cause your computer to explode. I like the idea of giving stationary units with weapons extra threat, since generally stationary with weapons = cost efficent turret

I thought about making valuable units lead to negative numbers, but this leads to a paradox.

Suppose we have 10 super critical resource generators that provide 99% of the enemies resources, giving them a total value of -100.

In that same grid square is a collection of uber super units that have a total value of 100.

This grid sector would be 0, and thus wouldn't even be evaluated. Using the same grid and algorithm to determine both value threat and military power does not work. I've tried it in the past, and ti gives you a little improvement, but introduces a lot of horrible unwanted consequences that make no sense in an RTS AI. Instead this data needs to eb tracked separately and compiled afterwards on a per case basis.

actually, the evo eco structures (the ones with lolskyhaet) actually ahve 3 weapons. Both of which do 1 damage (spring will not allow 0 damage weapons). I jsut had a thought, I'll change all those fx weapons to -1 damage (which spring DOES allow) and see how shard reacts to that.

Oh wait, shard doesn't pay attention to damage numbers. Gah

AF add a unit exception list. These units have weapons but are not considered a threat.

CAI attacks the highest cost economy square that it's scouted and disregards squares with too much cost in defence compared to raiding party cost. This seems to work and is reasonably simple, you just need 2 heatmaps.

A better solution would path around dangerous locations but that's a lot more work.

Indeed that's similar to the obvious optimization I had in mind. Discard all cells on either grid with no value of significance, subtract one from the other, and use that as a basis.

Attack handler is rather simple in it's design, you could easily add an extra file that defined a table of unitnames and their values, then used that in the line I suggested you change earlier.

e.g.



becomes



Coupled with an include somewhere, probably the top of the attack handler file. There's a lot of places in Shard that this kind of change can be made, and can be done in ~1minute with minimal effort. Just remember to make sure that you check there's a value for that unit type in the table and do an alternative calculation/default value. In this case it's the line I originally had in place. An if else should suffice.

And remember forb, all you have to do is copy and paste attackhandler.lua into your evo subfolder and it'll use your version of the attack handler rather than mine, so you can edit to your hearts content.