Classic Battlefield Modding Wikia
(Created page with "This tutorial will explain the Botinator Strategic Area problem and how to fix it. Based on information provided by Apache Thunder After fiddling with the StrategicArea size...")
Tags: apiedit Visual edit
 
Tag: Visual edit
 
Line 10: Line 10:
   
 
But the main concern is that Botinator gets the position/size wrong. I'm not sure how the original creator of Botinator interpreted these numbers, but it definitely seems he got it wrong. I think I finally got them figured out. Here's an image from the debugger from as an example:
 
But the main concern is that Botinator gets the position/size wrong. I'm not sure how the original creator of Botinator interpreted these numbers, but it definitely seems he got it wrong. I think I finally got them figured out. Here's an image from the debugger from as an example:
  +
{| class="article-table"
 
 
![[File:XxeyHvs.jpg|thumb|692x692px]]
[SA example image]
 
  +
|}
[[File:XxeyHvs.jpg|thumb|692x692px]]
 
   
 
- In that image I explained how the numbers translated to the resulting boxes shown in the debugger when AI debugging is enabled. The boxes are now perfectly centered and the exact size of the capture radius of the CP they are tied to now that I applied my interpretation of how the numbers work.
 
- In that image I explained how the numbers translated to the resulting boxes shown in the debugger when AI debugging is enabled. The boxes are now perfectly centered and the exact size of the capture radius of the CP they are tied to now that I applied my interpretation of how the numbers work.
Line 20: Line 20:
 
I took the capture radius of each flag and "subtracted" it from the position of the control point and used that as my first set of vectors while the second set remained unedited. (basically just the absolute position vectors of the control points copied and pasted over.)
 
I took the capture radius of each flag and "subtracted" it from the position of the control point and used that as my first set of vectors while the second set remained unedited. (basically just the absolute position vectors of the control points copied and pasted over.)
   
I applied this to all my CPs and now it looks like the SAs are EACTLY how they should be. So I'm pretty sure this is the correct formula for setting up SAs manually. Until today I always thought the second set defined the top right corner of the box while the first set defined the bottom left. (perhaps this is how the landing zones are setup and I just got the two mixed up?) Thus I did some unneeded math to "divide" the capture radius by 2 and subtract that from the first set of numbers but add that to the second set. This always resulted in SAs that were the right size but slightly off center. It didn't seem to bother the bots too much at the time, so I forgot about the issue. If Landing Zones are set up to have the bottom left corner be the first set of numbers with the second set being the top right, then the formula having the size of the box being divided by 2 then subtracted from first set and added to second set. Obviously if you want to produce rectangles instead of squares, you'd use differing values for the X/Y. (example subtracting 10 from X vector but only subtracting 5 from Y vector. This would then produce a rectangle)
+
I applied this to all my CPs and now it looks like the SAs are EXACTLY how they should be. So I'm pretty sure this is the correct formula for setting up SAs manually. Until today I always thought the second set defined the top right corner of the box while the first set defined the bottom left. (perhaps this is how the landing zones are setup and I just got the two mixed up?) Thus I did some unneeded math to "divide" the capture radius by 2 and subtract that from the first set of numbers but add that to the second set. This always resulted in SAs that were the right size but slightly off center. It didn't seem to bother the bots too much at the time, so I forgot about the issue. If Landing Zones are set up to have the bottom left corner be the first set of numbers with the second set being the top right, then the formula having the size of the box being divided by 2 then subtracted from first set and added to second set. Obviously if you want to produce rectangles instead of squares, you'd use differing values for the X/Y. (example subtracting 10 from X vector but only subtracting 5 from Y vector. This would then produce a rectangle)
   
 
Well after working on BF242, it cropped up again and I decided to re-edit them to try and get them exactly where they should be and this turned out to be the correct way. The reason I posted this here is that Botinator gets these numbers wrong by quite a bit. Not only would they be off center, they appear to be nearly double the size they should be. This would result in idling bots near the flag because they think they are close enough to capture the flag, but they aren't. Odd since I thought the setOrderPosition code defined where they should stand inside a SA zone? Either case, having the SAs the size and position correct would definitely get bots capturing CPs better and Botinator gets this wrong. 
 
Well after working on BF242, it cropped up again and I decided to re-edit them to try and get them exactly where they should be and this turned out to be the correct way. The reason I posted this here is that Botinator gets these numbers wrong by quite a bit. Not only would they be off center, they appear to be nearly double the size they should be. This would result in idling bots near the flag because they think they are close enough to capture the flag, but they aren't. Odd since I thought the setOrderPosition code defined where they should stand inside a SA zone? Either case, having the SAs the size and position correct would definitely get bots capturing CPs better and Botinator gets this wrong. 
Line 26: Line 26:
 
Which honestly makes Botinator pretty useless. I always used Botinator for the purpose of automating the creation of SAs and seeing that it's getting them wrong, I have little reason to use Botinator any more. Not only that Botinator is already known for getting the setOrderPositions wrong too. At this point I just copy and paste the AI code from my other maps on a new map and just edit them to match the map's CPs and such. It practically takes the same amount of time (or even less) then firing up Botinator and then having to go in and fix the mistakes Botinator makes. I have to replace all the values Botinator puts in the SA position/size vectors anyways. 
 
Which honestly makes Botinator pretty useless. I always used Botinator for the purpose of automating the creation of SAs and seeing that it's getting them wrong, I have little reason to use Botinator any more. Not only that Botinator is already known for getting the setOrderPositions wrong too. At this point I just copy and paste the AI code from my other maps on a new map and just edit them to match the map's CPs and such. It practically takes the same amount of time (or even less) then firing up Botinator and then having to go in and fix the mistakes Botinator makes. I have to replace all the values Botinator puts in the SA position/size vectors anyways. 
   
Also, the first set of numbers must always be less then the second set. If they aren't, the debugger will throw up an assert saying "isInside?" or something to that effect. It would be as if the SA was not in a valid pathmap area. 
+
Also, the first set of numbers must always be less then the second set. If they aren't, the debugger will throw up an assert saying "is Inside?" or something to that effect. It would be as if the SA was not in a valid pathmap area. 

Latest revision as of 13:43, 5 December 2018

This tutorial will explain the Botinator Strategic Area problem and how to fix it.

Based on information provided by Apache Thunder

After fiddling with the StrategicArea sizes and positions, it turns out Botinator gets this wrong. The SAs are created off center and appear to be too large when created by Botinator. This isn't game breaking, but in many instances this may make it harder for a bot to get close enough to a flag to capture it. You may find bots idling outside the capture radius of flags. Since they aren't close enough to actually capture it, they idle there until someone else comes along (usually a human) and captures the flag instead.

The severity of this issue depends on the lay out of the map. If you have CPs positioned in such away that a no go area of the pathmap covers much of the off center area of the SA but the other side is on valid spot on the pathmaps, then the bots just happen to be routed close enough to the flag to capture it. But many of the CPs in my map had this situation reversed. The no go areas happen to be near the flag on the small end of the box while the off centered larger area was exposed to more valid pathmap points so the bots ended up too far from the CPs in many instances.

I don't know if this is mentioned elsewhere since I haven't seen this command specifically mentioned. I now got the first and second set of numbers figured out. The third I believe might set the "importance" of that SA? Thus far I have only been using the CP radius size as the value for that and it hasn't caused issues, but seeing that Botinator defaults to a rather high value, (all SAs were set to 60 for this number after Botinator got done with them), so I have to guess this actually means the value of that SA. I suppose in most instances just copy and pasting the team value setting from each control point template would be suitable.

But the main concern is that Botinator gets the position/size wrong. I'm not sure how the original creator of Botinator interpreted these numbers, but it definitely seems he got it wrong. I think I finally got them figured out. Here's an image from the debugger from as an example:

XxeyHvs.jpg

- In that image I explained how the numbers translated to the resulting boxes shown in the debugger when AI debugging is enabled. The boxes are now perfectly centered and the exact size of the capture radius of the CP they are tied to now that I applied my interpretation of how the numbers work.

It seems the first set of vectors defines the position of the bottom left corner of the box while the second set of vectors defines the center position. (generally this is where the control point is positioned)

I took the capture radius of each flag and "subtracted" it from the position of the control point and used that as my first set of vectors while the second set remained unedited. (basically just the absolute position vectors of the control points copied and pasted over.)

I applied this to all my CPs and now it looks like the SAs are EXACTLY how they should be. So I'm pretty sure this is the correct formula for setting up SAs manually. Until today I always thought the second set defined the top right corner of the box while the first set defined the bottom left. (perhaps this is how the landing zones are setup and I just got the two mixed up?) Thus I did some unneeded math to "divide" the capture radius by 2 and subtract that from the first set of numbers but add that to the second set. This always resulted in SAs that were the right size but slightly off center. It didn't seem to bother the bots too much at the time, so I forgot about the issue. If Landing Zones are set up to have the bottom left corner be the first set of numbers with the second set being the top right, then the formula having the size of the box being divided by 2 then subtracted from first set and added to second set. Obviously if you want to produce rectangles instead of squares, you'd use differing values for the X/Y. (example subtracting 10 from X vector but only subtracting 5 from Y vector. This would then produce a rectangle)

Well after working on BF242, it cropped up again and I decided to re-edit them to try and get them exactly where they should be and this turned out to be the correct way. The reason I posted this here is that Botinator gets these numbers wrong by quite a bit. Not only would they be off center, they appear to be nearly double the size they should be. This would result in idling bots near the flag because they think they are close enough to capture the flag, but they aren't. Odd since I thought the setOrderPosition code defined where they should stand inside a SA zone? Either case, having the SAs the size and position correct would definitely get bots capturing CPs better and Botinator gets this wrong. 

Which honestly makes Botinator pretty useless. I always used Botinator for the purpose of automating the creation of SAs and seeing that it's getting them wrong, I have little reason to use Botinator any more. Not only that Botinator is already known for getting the setOrderPositions wrong too. At this point I just copy and paste the AI code from my other maps on a new map and just edit them to match the map's CPs and such. It practically takes the same amount of time (or even less) then firing up Botinator and then having to go in and fix the mistakes Botinator makes. I have to replace all the values Botinator puts in the SA position/size vectors anyways. 

Also, the first set of numbers must always be less then the second set. If they aren't, the debugger will throw up an assert saying "is Inside?" or something to that effect. It would be as if the SA was not in a valid pathmap area.