This is a continuation of this:
http://spring.clan-sy.com/phpbb/viewtop ... 857#190857
Long story short, the last time I checked, the moveinfo was the authority on what places a unit could go or not go. Is this no longer the case? Was it EVER the case? I could swear that when I first began working on porting AA to Spring, I found that the unit FBI values just drew the green square, while the moveinfo was what actually mattered.
I'm posting this here because I need a definitive answer and I'm not sure what developer would be the best one to ask. You all do different things.
I'm totally prepared to go to the effort of redoing my entire pathfinding setup, that's a little daunting but I'm up to it. I just don't want to find out it's not something that has been changed by accident or will be changed in the near future.
And just for reference then, I could have one movementclass:
footprintx=1
footprinty=1
And assign it to EVERY unit that I wanted to have the same slope/water tolerance values? I need a completely certain answer on this before I go forward. Thanks for your help.
FootprintX/Y in moveinfo vs. unit FBI
Moderator: Moderators
I think your setup is already pretty optimized. I tried to reduce the movement classes in CA, with no success.
As far as I know, The FBI footprint determines when the unit bumps into stuff, and the movetype footprint is used to make the red and green F2 map.
If movetype footprint > FBI footprint, the unit won't even try to go in the red area, and won't be able to slide through closely spaced DT when it should.
If FBI footprint > movetype footprint, the pathfinding will think the unit can go in places where it really can't, so the unit will get stuck often.
As far as I know, The FBI footprint determines when the unit bumps into stuff, and the movetype footprint is used to make the red and green F2 map.
If movetype footprint > FBI footprint, the unit won't even try to go in the red area, and won't be able to slide through closely spaced DT when it should.
If FBI footprint > movetype footprint, the pathfinding will think the unit can go in places where it really can't, so the unit will get stuck often.
No devs around? I've got a whole weekend to blow on AA.
If what was posted in that thread I referenced is accurate, it turns all my "optimizations" on their head. I can get by with a handful of movementclasses, rather than 20+.
It's not that I think what's been posted by users is wrong, but it might not be completely right from a code point of view.
If what was posted in that thread I referenced is accurate, it turns all my "optimizations" on their head. I can get by with a handful of movementclasses, rather than 20+.
It's not that I think what's been posted by users is wrong, but it might not be completely right from a code point of view.
Pretty much. For example, my mod's commander has a movetype footprint that is one or 2 units smaller, and thus it attempts to path through gaps between buildings that it cannot actually traverse.Fanger wrote:what he said, the FBI footprint tells the unit how BIG it is, the movetype footprint tells the unit how BIG it THINKS it is..
Here were my test files.
Sorry for not packaging these as add-on mods, but meh, this was faster, and I have a lot to do this evening.
At any rate, here were the tests performed, and the mod builds used to do so. I used Small Supreme as the test site, building 5 of each unit from one Autofac and sending to the back of one lake, then pathing the entire group to the opposite of the opposite lake, to make sure all units passed through varied terrain and lots of tree-filled areas.
1. Used one MoveType, with a footprint of 1X for all units in the mod, regardless of their Footprints in the FBIs. This causes pushing and shoving galore, and traffic-jams, and causes units with large Footprints to fail pathing around trees.
2. Used four MoveTypes, each matching the sizes of the Footprints in the FBI. This worked better for all Units at or below the Footprint size of 2. However, the results with Footprints of 3 or higher left much to be desired! They frequently could not steer through local clusters of trees, and had to be given new orders. I assume that this would be the case with Wreckage, too.
3. Used four MoveTypes, all matching, and made the collision spheres significantly smaller than the Footprints. This had zero effect on collisions. In fact, the collision sphere is absolutely NOT used to determine when units have collided. The sole determinants, I have found after some experience, are the coordinates 0,0,0- note that this is not necessarily the true origin of the S3O- and the four corners of the Footprints. Testing results were the same as with 2.
4. Used four MoveTypes, and made the collision spheres significantly larger then the Footprints. Same results as 3.
5. Used one MoveType, using a Footprint size of 4 for both the Units and the MoveType.
This was really horrible. I thought to myself, "meh, they'll just be really spread out, but at least they might be able to path without severe problems". Not so! Because of vast spreads in speeds, acceleration and deceleration rates, horrible collisions abounded, and many of the smaller, faster Units piled up in terrible collisions, or got stuck in sections of trees! In fact, only the slower-moving Units didn't have this problem, because they would eventually steer out've the trees. Small Units with high acceleration rates just got stuck.
I did one more test, which I'm not going to bother to post, where I set the Footprints for both Units and MoveTypes to 0. Yes, 0. And yes, it won't crash Spring. Aside from the lack of collisions, this performed the best of all the setups, but the clipping was really obvious.
Final conclusions:
1. CPU hit was worst with test 1. This was not unexpected- there was a lot of pushing and shoving and generally-horrible collision behavior going on, and the steering code occasionally went mad trying to get it all sorted out, only to fail again and again in chokepoint areas.
2. CPU hit was best with test case 6 (which interested parties can duplicate very easily, using case 5 as the model). Second best with cases 2, 3 and 4, in no particular order. Cases 1 and 5 both occasionally caused large spikes, which is a sure sign that they would cause lag in a real game. As I predicted earlier, using fewer MoveTypes is less CPU-intensive than more of them, but the spikes caused by borked steering was a much more significant factor, frankly.
3. Steering around trees was, by far, worst with case 5, best with case 6, middling-to-bad with cases 2, 3 and 4, and pretty bad for larger things with case 1.
I guess my biggest disappointment was seeing that the collision spheres don't actually do anything at all. It's so dumb to use the squares as anything more than rough guides for steering, when the collision spheres could provide more accurate guesses. But the biggest thing I saw is that the steering code is terrible, when you get above Footprints of 2, and it doesn't handle the turning-rates of Units or their relative velocities correctly.
Sorry for not packaging these as add-on mods, but meh, this was faster, and I have a lot to do this evening.
At any rate, here were the tests performed, and the mod builds used to do so. I used Small Supreme as the test site, building 5 of each unit from one Autofac and sending to the back of one lake, then pathing the entire group to the opposite of the opposite lake, to make sure all units passed through varied terrain and lots of tree-filled areas.
1. Used one MoveType, with a footprint of 1X for all units in the mod, regardless of their Footprints in the FBIs. This causes pushing and shoving galore, and traffic-jams, and causes units with large Footprints to fail pathing around trees.
2. Used four MoveTypes, each matching the sizes of the Footprints in the FBI. This worked better for all Units at or below the Footprint size of 2. However, the results with Footprints of 3 or higher left much to be desired! They frequently could not steer through local clusters of trees, and had to be given new orders. I assume that this would be the case with Wreckage, too.
3. Used four MoveTypes, all matching, and made the collision spheres significantly smaller than the Footprints. This had zero effect on collisions. In fact, the collision sphere is absolutely NOT used to determine when units have collided. The sole determinants, I have found after some experience, are the coordinates 0,0,0- note that this is not necessarily the true origin of the S3O- and the four corners of the Footprints. Testing results were the same as with 2.
4. Used four MoveTypes, and made the collision spheres significantly larger then the Footprints. Same results as 3.
5. Used one MoveType, using a Footprint size of 4 for both the Units and the MoveType.
This was really horrible. I thought to myself, "meh, they'll just be really spread out, but at least they might be able to path without severe problems". Not so! Because of vast spreads in speeds, acceleration and deceleration rates, horrible collisions abounded, and many of the smaller, faster Units piled up in terrible collisions, or got stuck in sections of trees! In fact, only the slower-moving Units didn't have this problem, because they would eventually steer out've the trees. Small Units with high acceleration rates just got stuck.
I did one more test, which I'm not going to bother to post, where I set the Footprints for both Units and MoveTypes to 0. Yes, 0. And yes, it won't crash Spring. Aside from the lack of collisions, this performed the best of all the setups, but the clipping was really obvious.
Final conclusions:
1. CPU hit was worst with test 1. This was not unexpected- there was a lot of pushing and shoving and generally-horrible collision behavior going on, and the steering code occasionally went mad trying to get it all sorted out, only to fail again and again in chokepoint areas.
2. CPU hit was best with test case 6 (which interested parties can duplicate very easily, using case 5 as the model). Second best with cases 2, 3 and 4, in no particular order. Cases 1 and 5 both occasionally caused large spikes, which is a sure sign that they would cause lag in a real game. As I predicted earlier, using fewer MoveTypes is less CPU-intensive than more of them, but the spikes caused by borked steering was a much more significant factor, frankly.
3. Steering around trees was, by far, worst with case 5, best with case 6, middling-to-bad with cases 2, 3 and 4, and pretty bad for larger things with case 1.
I guess my biggest disappointment was seeing that the collision spheres don't actually do anything at all. It's so dumb to use the squares as anything more than rough guides for steering, when the collision spheres could provide more accurate guesses. But the biggest thing I saw is that the steering code is terrible, when you get above Footprints of 2, and it doesn't handle the turning-rates of Units or their relative velocities correctly.
So argh If I may sum up your findings, It works best when every size of unit has its own moveclass that has a matching size, assuming you dont want to allow clipping.
Additionally this really doesnt matter in the pathfinding and so on, but my general thought would be to make 3+ sized units crush trees for ease of use, this generally makes sense as well given the size of a 3+ units usually..
Basically for optimum setup im sure we can all agree (excusing minimizing pathing time) you want a movetype for all sizes, and for balance reasons for all units you wish to have a different slope tolerance..
Additionally this really doesnt matter in the pathfinding and so on, but my general thought would be to make 3+ sized units crush trees for ease of use, this generally makes sense as well given the size of a 3+ units usually..
Basically for optimum setup im sure we can all agree (excusing minimizing pathing time) you want a movetype for all sizes, and for balance reasons for all units you wish to have a different slope tolerance..
Basically, I think that the steering code could use improvement, but I said that over six months ago, with less testing, and I simply don't have enough time to get into the code and mess with it right now.
I'd say that the main conclusions I reached is that anything that moves fast needs to either run trees over, or it needs to use a footprint smaller than 3. Anything with a footprint over 2 should probably run over trees, and you're going to see things that big get hung up in groups no matter what, so there's no point in worrying about it, it's just a part of how Spring works.
I haven't torture-tested the real effects of slope values for performance purposes. I used identical values for each of the 4 classes used. So, I can't draw any meaningful conclusions about the performance hit, and I'd really prefer that somebody actually tested it before coming to conclusions, because, quite frankly, I've never really investigated that.
Personally, I think that the idea of wasting seconds of a player's life every time they fire up a new map, because my idea of "balance" is so completely stupid that I'm using something like that, instead of all of the obvious stuff we have to use (like, say, BOS code) ... to be completely abhorrent and disrespectful of my players. Can Caydr defend having 20 different movetypes? I dunno- tbh, I'll bet I could cut it in half, without being noticed by 90% of the players, and even the leet players wouldn't get too riled up, once they got used to it, just like they always do when a change ultimately makes sense. Oh, sure... on certain maps, certain uber-leet strats wouldn't work any more... so the hell what? They can learn new ones. That's how things work, every time you change anything anyway.
I'd say that the main conclusions I reached is that anything that moves fast needs to either run trees over, or it needs to use a footprint smaller than 3. Anything with a footprint over 2 should probably run over trees, and you're going to see things that big get hung up in groups no matter what, so there's no point in worrying about it, it's just a part of how Spring works.
I haven't torture-tested the real effects of slope values for performance purposes. I used identical values for each of the 4 classes used. So, I can't draw any meaningful conclusions about the performance hit, and I'd really prefer that somebody actually tested it before coming to conclusions, because, quite frankly, I've never really investigated that.
Personally, I think that the idea of wasting seconds of a player's life every time they fire up a new map, because my idea of "balance" is so completely stupid that I'm using something like that, instead of all of the obvious stuff we have to use (like, say, BOS code) ... to be completely abhorrent and disrespectful of my players. Can Caydr defend having 20 different movetypes? I dunno- tbh, I'll bet I could cut it in half, without being noticed by 90% of the players, and even the leet players wouldn't get too riled up, once they got used to it, just like they always do when a change ultimately makes sense. Oh, sure... on certain maps, certain uber-leet strats wouldn't work any more... so the hell what? They can learn new ones. That's how things work, every time you change anything anyway.
I know you're busy Argh, but could you give examples of where you'd cut movement classes?
So of the 21, there is 1 potential candidate for removal, and it's probably only a candidate because I can't be bothered to do a find-in-files to see what units use it.
Less strategic options, but people will just adapt? In my opinion, it seems shortsighted to say that unique units can be removed without any impact on gameplay. There needs to be diversity. A lot of AA's most interesting units rely on specific, unusual movement classes. Of course, I can't say that for sure until I've seen what you would change and why.
Code: Select all
[CLASS0] <<< Used exclusively for fleas (I think), gives them the flea effect. Larger footprint and they can't move like water the way they do. Necessary or else get rid of fleas.
{
Name=KBOT1;
FootprintX=1;
FootprintZ=1;
MaxWaterDepth=5;
MaxSlope=80;
CrushStrength=1;
}
[CLASS1] <<< Basic 2x2 kbots. Obviously necessary.
{
Name=KBOT2;
FootprintX=2;
FootprintZ=2;
MaxWaterDepth=22;
MaxSlope=36;
CrushStrength=10;
}
[CLASS2] <<< All-terrain 2x2 kbots. AA's got several. Either I remove all-terrain units or this one is necessary.
{
Name=AKBOT2;
FootprintX=2;
FootprintZ=2;
MaxWaterDepth=5000;
MaxWaterSlope=50;
MaxSlope=36;
CrushStrength=50;
}
[CLASS3] <<< 4x4 Kbot. Necessary unless you want all kbots to be 2x2.
{
Name=HKBOT4;
FootprintX=4;
FootprintZ=4;
MaxWaterDepth=22;
MaxSlope=36;
CrushStrength=250;
}
[CLASS4] <<< Amphibious 4x4 Kbot. Used by only two units, but they are significant: Marauder and Shiva.
{
Name=HAKBOT4;
FootprintX=4;
FootprintZ=4;
MaxWaterDepth=5000;
MaxWaterSlope=80;
MaxSlope=36;
CrushStrength=250;
}
[CLASS5] <<< All-terrain 4x4 Kbot. Used by only two units, but they are significant: Vanguard and Karganeth.
{
Name=HTKBOT4;
FootprintX=4;
FootprintZ=4;
MaxWaterDepth=22;
MaxSlope=80;
CrushStrength=250;
}
[CLASS6] <<< Very Large 5x5 Kbot. Krogoth. Need I say more? It's freaking huge.
{
Name=VKBOT5;
FootprintX=5;
FootprintZ=5;
MaxWaterDepth=5000;
MaxWaterSlope=30;
MaxSlope=24;
CrushStrength=1400;
}
[CLASS7] <<< I honestly don't remember. I don't remember a specific example but AA must have 3x3 kbots. Sumo, Fatboy? That's probably it. They're needed because 4x4 is too large to exit the arm advanced kbot lab but 2x2 would have them clipping each other and other units and it would be fugly.
{
Name=TKBOT3;
FootprintX=3;
FootprintZ=3;
MaxWaterDepth=22;
CrushStrength=15;
}
[CLASS8] <<< Run of the mill 2x2 tank. There's gotta be a dozen or more. Note that they do not have the same slope climbing ability. That's, unless you want all units to climb the same slopes, meaning that they're just different in their appearance and equipment, as opposed to where they can be deployed effectively.
{
Name=TANK2;
FootprintX=2;
FootprintZ=2;
MaxWaterDepth=22;
MaxSlope=18;
CrushStrength=15;
}
[CLASS9] <<< 3x3 tanks. There's tons.
{
Name=TANK3;
FootprintX=3;
FootprintZ=3;
MaxWaterDepth=22;
MaxSlope=18;
CrushStrength=30;
}
[CLASS10] <<< Heavy 3x3 tank, probably Goliath and similar ones, with high crushstrength allowing it to bulldoze through common wrecks. Unless you want everything bulldozing wrecks.
{
Name=HTANK3;
FootprintX=3;
FootprintZ=3;
MaxWaterDepth=22;
MaxSlope=18;
CrushStrength=250;
}
[CLASS11] <<< 4x4 tanks. OK Maybe this one's goliath and the one above is more common heavy tanks. Meh.
{
Name=HTANK4;
FootprintX=4;
FootprintZ=4;
MaxWaterDepth=22;
MaxSlope=18;
CrushStrength=250;
}
[CLASS12] <<< Amphibious 3x3 tank. No amphibious tanks needed?
{
Name=ATANK3;
FootprintX=3;
FootprintZ=3;
MaxWaterDepth=5000;
MaxWaterSlope=80;
MaxSlope=36;
CrushStrength=30;
}
[CLASS13] <<< 3x3 Hovercraft. Need this or all hovercraft can be removed.
{
Name=HOVER3;
FootprintX=3;
FootprintZ=3;
MaxSlope=22;
BadSlope=22;
MaxWaterSlope=255;
BadWaterSlope=255;
CrushStrength=25;
}
[CLASS14] <<< 4x4 hovercraft. THIS one might be removable, since I think I may have removed 4x4 hovers. I think that was a while ago though... there's probably a reason why it's here.
{
Name=HOVER4;
FootprintX=4;
FootprintZ=4;
MaxSlope=22;
BadSlope=22;
MaxWaterSlope=255;
BadWaterSlope=255;
CrushStrength=25;
}
[CLASS15] <<< 4x4 vanilla boats.
{
Name=BOAT4;
FootprintX=4;
FootprintZ=4;
MinWaterDepth=5;
CrushStrength=40;
}
[CLASS16] <<< 5x5 vanilla boats.
{
Name=BOAT5;
FootprintX=5;
FootprintZ=5;
MinWaterDepth=8;
CrushStrength=50;
}
[CLASS17] <<< 3x3 boats requiring deep water.
{
Name=DBOAT3;
FootprintX=3;
FootprintZ=3;
MinWaterDepth=15;
CrushStrength=30;
}
[CLASS18] <<< 6x6 boats, require deep water.
{
Name=DBOAT6;
FootprintX=6;
FootprintZ=6;
MinWaterDepth=15;
CrushStrength=70;
}
[CLASS19] <<< 8x8 boats.
{
Name=HDBOAT8;
FootprintX=8;
FootprintZ=8;
MinWaterDepth=20;
CrushStrength=1400;
}
[CLASS20] <<< Spies. They have their own movementclass because no others are suitable - they need to move around without disturbing their environment. Crashing trees are a dead giveaway that there's something cloaked headed your direction. This is a new one in 2.4
{
Name=SPY;
FootprintX=2;
FootprintZ=2;
MaxWaterDepth=5000;
MaxWaterSlope=50;
MaxSlope=36;
CrushStrength=0;
}Less strategic options, but people will just adapt? In my opinion, it seems shortsighted to say that unique units can be removed without any impact on gameplay. There needs to be diversity. A lot of AA's most interesting units rely on specific, unusual movement classes. Of course, I can't say that for sure until I've seen what you would change and why.
Yeah this much I know is true.SinbadEV wrote:I think colision spheres are used for A: weapon collisions and B: airplane pathing. again, not a dev, sorry Caydr