Custom Formations 2

[ginekolog]

For ppl that still dont know how to use this new V2 functionality:

Let say enemy has 5 fusions in L shape. Select 30 bombers, press A(and releise it) now press space (meta) and draw a line with left click over 5 enemys fusions. BAM now they die :)
I find this command usefull only for bombers.. any other idea?

Same goes for unloading.

tata

btw this ver still crashes from time to time.. but rarely.

[TheFatController]

btw this ver still crashes from time to time.. but rarely.

Figured it would, I did try to debug the original but only managed to pinpoint the function with the error not fix it yet..

[el_matarife]

I could see line unload being super useful for airdropping on top of cliffs. I'm guessing line attack could be useful for artillery, since people tend to line up their defenses and mix in units.

[Jazcash]

Yeh, I'm sometimes having a bug sometimes when I do it with too many units they instead just ignore the formation and huddle together.

Other times, I do it and this happens:

[el_matarife]

I've seen this and I've sometimes seen them reverse their order, meaning they move from one side to the complete other side instead of just turning around in whatever their minimum turning radius is. I think the widget needs to be "smart" enough to take into account turning radius when it assigns units to positions.

[Das Bruce]

I think the main problem is that they end up bumping into each other and your formation turns to shit.

[Jazcash]

Hmm yeh, that's true too. I think putting a unit on "Hold Position" should actually hold it's position and not move at all unless it's being hit with force.

[Das Bruce]

Last I checked upping the weight you give units in the path finder helped enormously, that was years ago however.

[Wisse]

I've seen this and I've sometimes seen them reverse their order, meaning they move from one side to the complete other side instead of just turning around in whatever their minimum turning radius is. I think the widget needs to be "smart" enough to take into account turning radius when it assigns units to positions.

That was always the case. You have to start drawing line from same direction as previous one.
I guess it could (should) be changed to work as you propose tho.

[Niobium]

For ppl that still dont know how to use this new V2 functionality:

Let say enemy has 5 fusions in L shape. Select 30 bombers, press A(and releise it) now press space (meta) and draw a line with left click over 5 enemys fusions. BAM now they die :)
I find this command usefull only for bombers.. any other idea?

Same goes for unloading.

tata

btw this ver still crashes from time to time.. but rarely.

Line nuking/juno'ing is also fun. Or mine clearing with levelers.

As for crashing, make sure you are using the last uploaded version, which is the one on springdownloader, I've uploaded quite a few versions on the way to current.

As for the whole messed up line at times, thats to do with the algorithm it uses. The most efficient algorithm is very costly, so its only used when the number of units are small.

For anyone interested:
1-18 units = Optimal orders
19-74 units = Optimized orders (Rarely gives optimal)
75+ units = Random

The problem is that unless its optimal, you end up getting units crossing paths, which quickly turns the whole thing into a mess. But if you always do it optimal, then people with slow computers are going to have issues with ordering large numbers of units quickly.

Edit: Found a bug in how it adjusts thresholds for the various algorithms based on past performance. In that no matter how fast it is doing the optimal algorithm it will never increase unit cap for it. So I'll fix that and upload a new version soon..

[ginekolog]

great!

btw this is best formation system in all RTS games ever. Its really had to play without this widget now that we all got so used to it :)

[TheFatController]

I wonder if it would be possible for large groups of units (cause it already knows you have 75+ units selected when you start drawing the line) to work out a semi optimised (ie attempt at better than random) spread while the line is being drawn by the user to spread the CPU load...

Also one thing I noticed was it may be possible to remove all the sqrt's (and leave the values hueg) if i'm not mistaken as only comparisons are taking place.

[Niobium]

I wonder if it would be possible for large groups of units (cause it already knows you have 75+ units selected when you start drawing the line) to work out a semi optimised (ie attempt at better than random) spread while the line is being drawn by the user to spread the CPU load...

Also one thing I noticed was it may be possible to remove all the sqrt's (and leave the values hueg) if i'm not mistaken as only comparisons are taking place.

Yeah, I believe there is room for improvement/optimization. You are correct about some of the sqrt's, so I'll remove those, next version should be all about optimizing, when I get some time.

[Argh]

For 18+... instead of doing a giant sort... why not break it up into several sorts over the next few frames?

Then you'd get all of the advantages of a perfect sort, and none of the performance hit. Only issue then is breaking up the line drawn by the player into several sub-sections for each sort.

[Beherith]

For 18+... instead of doing a giant sort... why not break it up into several sorts over the next few frames?

Dont introduce unnecessary command lag.

[Niobium]

For 18+... instead of doing a giant sort... why not break it up into several sorts over the next few frames?

Then you'd get all of the advantages of a perfect sort, and none of the performance hit. Only issue then is breaking up the line drawn by the player into several sub-sections for each sort.

The current limiting factor is that the algorithm can't run for over about 1/20th of a second as it freezes screen while it works and it becomes annoyingly noticeable. So if splitting across gameframes does give spring time to render some frames inbetween, then this could raise the total time cap for algorithm, will investigate.

Ideas for improvements are great btw.

[Argh]

Dont introduce unnecessary command lag.

You can't have it all- you can have it fast and incorrect, slower but correct. I'd rather have it correctly set facing, etc. with a small amount of time-lag between the first and last command sent, than have it do random stuff. We're talking a frame here... not seconds.

I think that if you break the line up and limit the number of units per segment enough, that the algorithm will get sped up enough that it'll be hardly noticeable except with huge groups.

IIRC, 10 Units runs with practically no latency, vs. 20, where a bunch of n^2 stuff starts rearing its ugly head.

With optimization, I think that groups of 10, with further ones held one frame back and so forth might be the way. Hardly noticable control lag, will scale to any number of units.

[TheFatController]

Another thing you could do i suppose is order the random move then correct it over the next few frames (ie alter the orders) to keep units moving in better lines

[Jazcash]

You know what would be nice? When you move the units backwards, they stay looking and shooting at their target if they can. For example, Stumpies have 360 turn cannons so they can travel in any direction whilst shooting in any direction so it would be easy for this. Then there's the units like Thuds and Hammers, I won't go into detail but a widget which keeps all the units facing their targets all the time would be really useful.

I hate it when you're microing Hammers and Thuds and they turn backwards when you micro them backwards, it wastes so much precious shooting time. This is the same for many many units.

[Argh]

That is entirely outside the realm of this Widget. Moving backwards requires an engine change. I'll make another feature request for this.