Unit pushing preference...

[Das Bruce]

In the test square function in pathfinder.cpp I noticed that spring increases the cost of going through a square if its occupied by a unit by decreasing the speed it uses when calculating the quickest path.

Code: Select all

	
if(testMobile && (blockStatus & (CMoveMath::BLOCK_MOBILE | CMoveMath::BLOCK_MOVING | CMoveMath::BLOCK_MOBILE_BUSY)))
{
     if(blockStatus & CMoveMath::BLOCK_MOVING)
          squareSpeedMod*=0.65;

     else if(blockStatus & CMoveMath::BLOCK_MOBILE)
          squareSpeedMod*=0.35;

     else
          squareSpeedMod*=0.10;
}

I've been playing around with these values and found that ones much lower tend to have units behaving in a less asshat fashion. For example if you turn down the second one to 0.01 units will go around a lined up battle group rather than just pushing through and being a general pain in the ass.

I'd suggest turning them down to 0.30, 0.02, and 0.01. Thoughts?

[Forboding Angel]

In the test square function in pathfinder.cpp I noticed that spring increases the cost of going through a square if its occupied by a unit by decreasing the speed it uses when calculating the quickest path.

Code: Select all

	
if(testMobile && (blockStatus & (CMoveMath::BLOCK_MOBILE | CMoveMath::BLOCK_MOVING | CMoveMath::BLOCK_MOBILE_BUSY)))
{
     if(blockStatus & CMoveMath::BLOCK_MOVING)
          squareSpeedMod*=0.65;

     else if(blockStatus & CMoveMath::BLOCK_MOBILE)
          squareSpeedMod*=0.35;

     else
          squareSpeedMod*=0.10;
}

I've been playing around with these values and found that ones much lower tend to have units behaving in a less asshat fashion. For example if you turn down the second one to 0.01 units will go around a lined up battle group rather than just pushing through and being a general pain in the ass.

I'd suggest turning them down to 0.30, 0.02, and 0.01. Thoughts?

Seconded +1

[Argh]

Can you put up a compiled version to test with?

[Das Bruce]

Sure as soon as I find somewhere to host it.

[Das Bruce]

http://www.yousendit.com/transfer.php?a ... 421430B28E

I don't think I made any other changes.

[Argh]

Tested, with 100 XTA PeeWees. Conclusion: whatever this code does, the final result was significantly more CPU usage for pathfinding than with the default values. We're talking 20% or so, or the difference between 34% at max load in current when doing a random to square sort vs. 44% with your code. I didn't see a very large change in overall behaviors, either, although with everything the same size, that might not have been the best test setup, I dunno.

[Das Bruce]

I'm pretty sure the extra cpu usage is because the units go around rather than just through. It was only a stop gap solution but if its that big of a hit for performance then I'll look at the second option. Thanks Argh.

[Argh]

Yeah, it's almost certainly that, now that I have looked at it again.

A better solution, imo, would be better code to keep units waiting a bit if they cannot reach their path without collisions occuring over the prediction length. That would cause better behavior during "four-way-stop" collisions, where units are hitting each other on the flanks, etc., but everybody is basically just piling into a traffic jam, instead of waiting for the units ahead of them to pass through their zones. Much less wasteful than the current approach, which seems to let them both use pushback and attempts some needlessly-complicated traffic-routing stuff. I'd say have the "winner" of such collisions be the smaller or faster unit, every time- that way, a group of Zippers passing by a herd of Gollies will cause the Gollies to stop, instead of mixing with the Gollies and effectively slowing both groups to a halt. I would think that this would improve collision pathing for large swarms traveling around by a lot...

[Das Bruce]

I actually did some more testing myself and the main reason that peewee's didn't show any change is because they are small enough to fit through each other when lined up. When using larger units, such as ravens I noticed a larger increase in the likelyhood of them actually lining up successfully and no more than a ten percent increase in cpu usage of pathing. I still think units should give greater weight to a square being occupied but maybe not to the extent I suggested first.

I'll look into a pause state for now.

[Caydr]

A lot of the problem could just be with the values used by the mod for push strength. I don't know what you were testing with, but I honestly just pretty much thought up random values that seemed sorta consistent when I did the push strength on AA units.

[Das Bruce]

If these are set to abismally small values will a unit go around or try to push through fruitlessly?

[Caydr]

Depends on what it's set to... A lot of people are saying that the crushstrength/push system does more harm than good, but I think they'd realize how wrong they are if it was turned off. Maybe in the future only larger units would need to have it, but for now, pathfinding isn't good enough.

Does anyone know how crushstrength relates to wreckage? I have to use completely over-the-top values when I want things like goliaths to smash through wrecks, but then they smash through ones that they really shouldn't be...

[KDR_11k]

Isn't it just crushstrength > feature value => crunch?

[Caydr]

What's the feature value? metal worth? maxdamage? some weird combination of the two multiplied by x/y size?

[KDR_11k]

What's used to determine reclaim time?

[Das Bruce]

Builder's power and metal value.

[Caydr]

Ugh.... we need a wiki page that explains how all the stuff relates. BADLY.

[Peet]

Ugh.... we need a wiki page that explains how all the stuff relates. BADLY.

QFT