GLA Terrorist is stuck when ordered to attack into the bounding box of a structure

[xezon]

Sometimes GLA Terrorist does not attack after given instructions. Happens regularly when targeting terrain close to buildings. Terrorist will walk in place and does not suicide.

Issue can be reproduced by force firing Command Center at this position:

Related Terrorist issues:

• 26

• 31

• 30

• 196

• 502

• 503

• 504

[xezon]

Issue might be related to geometry size of buildings. If collision box is larger than the visual presentation of the model and user tries to attack too far inside the geometry bounding box, then infantry unit might not be able to move there.

According to Enlima29, NProject does tweak geometry sizes of buildings and units (accurately). We could look into that.

[xezon]

It is definitely caused by the Geometry as per INI Object definition.

Tested with Object GLACommandCenter:

GLACommandCenter Original

  GeometryMajorRadius = 65.0
  GeometryMinorRadius = 65.0

Issue is reproducible.

GLACommandCenter Test 1

  GeometryMajorRadius = 50.0
  GeometryMinorRadius = 50.0

Issue is still reproducible, but you have to force fire VERY close to the building, making the bug no big deal.

GLACommandCenter Test 2

  GeometryMajorRadius = 80.0
  GeometryMinorRadius = 80.0

Issue becomes very easy to reproduce. Terrorist will get stuck within a very generous margin of the structure.

Conclusion

To mitigate this issue as best as possible, Geometry size needs to be perfectly aligned with the mesh size. I assume GeometryMajorRadius is X and GeometryMinorRadius is Y or vice versa.

[xezon]

To measure structure sizes, it would be nice to have a test map with a giant grid

[xezon]

Enlima29: many buildings are not centered correctly

[xezon]

Ctrl+W = Show Wireframe Alt+6 = Show Bounding Box

1 terrain tile corresponds to 5 length units that Geometry is specified in. This means we can use Wireframe or Terrain tiles to reliably measure structure sizes. In this Airfield sample, GeometryMajorRadius is 83, and tiles are 16.6 (16.6*5 = 83).

[xezon]

Enlima29:

[Fixing W3D model centering] involves manual model reexporting because unlike newer sage engine (like bfme) zh sage don't have geometry offset parameters that allows you to adjust the hitbox center position without manually editing the model itself. Which is why I cried blood when fixing all these off-centered civilian buildings. https://www.moddb.com/mods/nproject-mod/images/fixed-building-collisions

I usually use 3dsmax for object size measuring, because they use the same unit as the game's geometry size unit. It is much [more] reliable this way because of the aforementioned reason where many models are actually off-centered.

[xezon]

Use models from NProject as a base before applying recenter fixes, as they already contain other fixes too.

[xezon]

Gmax setup for W3D editing: http://www.cnclabs.com/forums/cnc_postst16946_Generals-Modding-Resource.aspx

Enlima29:

Basically turbosquid's gmax is a discounted/fork version of Autodesk 3ds Max. It is what EA team used when developing renegade/generals/zh using their own renx plugin (not to be confused with the RenegadeX the indie game) to be able to rig Westwood 3D file (aka W3D) for the SAGE engine.

Later on EA team were using 3dsmax7 when developing Lord of The Rings: Battle For Middle Earth, which is why they are releasing the BFME2 Mod SDK plugin to work with widely used 3dsmax back then, which also works for ZH models because they are essentially the same engine your choice if you want to use the gmax or 3dsmax one, just make sure to use the corresponding plugin.

Zeke:

3dsmax handles better than Gmax and it can actuallt make renders. The optimal max version is 8 though not 7, because the UVW unwrapper is much better in 8.