[Guide] Attaching to Moving Entities

Additional Team Weapon Crew Info

Because team weapon crew is so complex there's bound to be many issues that arise from us doing what the game isn't meant to do. Although it may not be possible to get everything perfect, we can mitigate and fix some of the problems that team weapon crew presents.



Hit Points

Normally how team weapon tp_mobile works is that the team weapon itself does not have its HP displayed within the squad. Instead the squad HP bar is split evenly between all its members. We can trick the game into making the HP bar behave as a normal entity though. Add a blank team_weapon_ext to all child entities with tp_mobile. You can then just delete health_ext and that will make the child entities invincible. Weapon targeting should be off in type_ext.


Squad Count

Unfortunately I don't think it's possible to fix this one.




Terrain Kick Up

If you're dealing with multiple child entities you may have noticed that there's a lot of material that the wheels kick up because of the many stacked entities. To fix this use the above state on child entities.


Clean Up Your Extensions

Since child entities are purely for visuals you should probably remove everything that isn't necessary. An example would be shot blocking or some similar unintended consequence.


Smoother Movement

Because there's a movement delay between parent and child you'll have much better results by just making all the visuals as child entities. This comes at the cost of not having any turrets move but we can somewhat get around that which will be explained later.

Set the damage_state of the parent to crush or some similar state that hides it. Ensure that the movement_ext as well as the simvis attributes of all entities are the same. If your entities have a hold remove the garrison state action as I believe this interferes with movement somehow.

There will still be some desyncs, especially if the unit travels over long distances, but it will be much better than before.


Moving Turrets

There are 3 ways to have turrets with team weapons, each with certain advantages and disadvantages.

• The 'vanilla' system. This is the default system that requires set up and tear down that was explained in a previous post. It only allows firing when not moving and is prone to many bugs if not implemented correctly. Possible issues are the ignoring of cooldown on rapid attack moving among other things.
  
• The replacement system. Like the previous method it only allows firing when stationary. This will create an unattached entity with offsets when stationary allowing you to bypass some of the undesirable behavior of team weapons. However, you will not be able to order attacks directly and kills will not be logged as the firing entity isn't part of the squad. This system would be recommended if you've run out of hold blueprints or would like to add multiple turrets to a parent.
  
• The garrison system. This will superficially match most of the behavior of a normal turret and does allow attacking whilst moving unlike the other two methods. However, because it is a garrison, it will suffer from similar problems as the previous method of not being able to order attacks and having kills logged on the garrisoned squad. It will also create a decorator besides the team weapon squad although we can remove the decorator in the top right UI.
  

Normally a garrisoned squad will choose a random combat slot as well as have a diagonal facing rotation which of course isn't ideal for making a turret. Luckily there's a way around these two issues. Some types of buildings have combat slots for mortar, hmg, and other types. These differ from the normal infantry slots as they are exclusively reserved for these hold types. For example a mortar combat slot will only allow mortar hold type units in it.

There are many different buildings that have these special combat slots but the ones we will be focusing on are those that do not normally hold units to prevent conflicts as we will be using offsets. Keep in mind that because garrisons wont be able to show their held units if you use a different abp name than the original you're hard limited to a certain amount of holds. Below is a list of some buildings that A, only have a single combat slot per hold type and B, do not natively hold units. There may be more but I'll leave that up to someone else to look for.



To correctly position your offset you'll need to look at the mua marker and adjust the offsets accordingly. You can change the hold type with holdable_ext in ebps for the garrisoned entity and hold_ext for the garrison. The red cells mean that there's multiple markers for that hold type so it's probably not compatible with this specific purpose.

You can learn more about combat slots in the hold_info within the tuning tab. Type will refer to the same string within the mua file. Use_slot_heading means if the garrisoned entity will use the same direction as the parent. Everything but "infantry only" and "mortar" have limited angles so keep that in mind. In short, the mortar type combat slot should generally be the preferred combat slot for turrets. Others will only be useful if you're fine with a 120 degree firing angle.

The medium combat slot can hold several types of entities. This means there can be issues which slot the entity is assigned to depending on the other types of combat slots available for the hold. For example for the Soviet base_building_2 you should probably have the garrisoned squad have 2 entities. One with a hold_large_gun type to occupy the medium slot, and another with your desired combat slot such as hmg.

Infantry only is not ideal for turrets because the use_slot_heading is false. The only instance where I can think of this being useful would be if the hull is hidden either through skins or being obscured by something else, showing only the turret part of the tank. Another use would be to use this for an extremely slow moving unit as the lag in updating position will be obscured by its slow movement.

You can delete moving_ext for garrisoned entities to prevent them from turning to face targets. This will allow only the turrets to turn whilst the hull will keep the direction of the parent. If you use an infantry holdable type it will have some visual issues turning as they use their own movement but without a moving_ext it wont update correctly. To fix this just add the moving_ext but also know that the entity's direction will always face its target. If rotation is set to 0 then the entity's rotation will be locked, regardless of the parent entity's rotation.

The angle_of_fire will override the values within tracking in the weapon category.


Facing up, mortar. Sov base_building_1 left GER base_building_1 right.


Landkreuzer from my mod.

The above picture shows the garrison system in action. There are 7 garrisoned squads in addition to a team weapon. Each turret is able to fire when moving.


World builder

World builder is a great tool to save time and design your models. However there's a couple of limitations with vehicles that unfortunately cannot be worked around. Vehicles cannot have their x or z axis rotation changed, presumably because world builder reads the simvis attributes and thus make the blueprint have gravity. Similarly if you change the y position the vehicle will fall 1 meter but you can simply account for this when setting offsets. These impediments will make designing models more difficult.

Have you ever experimented with attach action chains? Like, make the attached child spawn an attached child of their own? In my limited testing, I could never get the child of the child to stay around as it would despawn for some reason after a few ticks. My thinking was that if child A is turned backwards, child B (child of child A) will be faced forwards using the same attach marker.

Presumably attaching to an attached entity doesn't work correctly because child entities do not have their position updated fully, as evidenced by them only attacking where they have spawned. What happens is that the child entity will switch between its spawn point and the position where it's attached to. I've done some testing but didn't dig that deep into it.

In most cases this is not helpful at all but an interesting thing of note would be that trailing effects such as smoke from a projectile will travel between these 2 positions. You could then use this to have visuals of linking 2 separate positions to one another.

Alright, strap in, this will be a long one.

What can we actually create with this if we go all the way? I tried to find out and made an SdKfz 234/1 for CoH2. Here's how.



Note: We are using the team weapon attach method. Read the guide in this thread for further information. Some of the images here might be too small to read on your screen. Just copy the image link and go to the source.

1. We'll be using a custom skin pack to hide parts of the Puma and 222 to combine them into the new vehicle. Hiding parts requires alpha layers. Shoot me a DM if you want to use my textures and alpha layers and I'll share them with you. Shout out to Starbuck for tips, tricks and layer mask textures to make these.

2. Once your skin pack is set up, we create custom abp's. Clone the 222's abp and name it something like "sdfkz_234.abp". This is necessary to adjust the offset values, so that the turret appears at the right place in game. Copy this into the new file:

Show Spoiler

Now, clone the abp of the Puma and give it a custom name too, mine is called "puma_sdkfz_2341.abp". As for the 222, the Puma's offset values need to be adjusted. It should look like this:

Show Spoiler

3. In the AE, create 3 new entities. I cloned the 222 and cleaned up all the upgrades, abilities and such that we don't want.

3A: The hull. This one uses the new puma abp.
Apply our new skin in the UI extension
give it 1 HP and make in invincible
It has no weapons
Make sure it is both a team weapon and team weapon user
Here are the important extensions and animator states:Show Spoiler

3B: The turret during driving. This is a non-functional 222 turret that we show when the vehicle is moving as the one that will be firing would "wobble" too much on the move.
Apply our new skin in the UI extension
give it 1 HP and make in invincible
It has no weapons
Make sure it is both a team weapon and team weapon user
Add an obscure unit type to it's list of types. I chose "urban_assault_pg". This is for a later step.
Here are the other important extensions and animator states:Show Spoiler

3C: The actual turret. To avoid the desync of turret and hull, we can only allow this vehicle to fire when static. This is a trade off for better visuals, but it really works well in game when properly set up. This entity is our "real" team weapon, with all the combat hardpoints and roles copied from an at gun in the team weapon ext. It has actual health and armor and upon death, I added a target that finds and kills all 222 types nearby (the hull and fake turret have the 222 unit type). Note that we have to add the real Puma abp in the "alternate_sua" so the vehicle has physics ingame. Show Spoiler

4. The hardpoints are crucial. As in the guide earlier, Harpoint 01 needs to be a dummy weapon with an unused parent hardpoint to stop the hull and fake turret from moving around with the main gun. Harpoint 02 will hold the main gun, while Hardpoint 03, with 02 as parent, will be the coaxial. Here is the dummy weapon, a clone from the existing machinegun dummy: Show Spoiler and here the main gun Show Spoiler Pay attention to behaviour elements such as attack ground permissions and non_moving_setup. Also remember to add a short wind up and setup to the main gun for functionality with good visuals.

5. Create a squad with a team weapon extension and assign the three entities in this order: Show Spoiler

6. To make our real turret replace the fake one seamlessly, we need an always_on ability and add it to the real turret entity. This ability will wait for the vehicle to move and then hide the real turret and show the stable fake turret. When static, the real turret is revealed. This uses a target function to hide the fake turret. The function is looking for a specific unit type: the obscure one we set on the fake turret earlier (urban_assault_pg). These are the two start_self_action entries:
Show SpoilerShow Spoiler

7. Clean up UI stuff (new icons, portraits, symbols, text) and enjoy your new vehicle. Note that the UI now considers the vehicle a team weapon and will show it in the infantry row in the top right of the screen. It will also have a "2" for crew members shown. This can't be fixed afaik.

There is a lot of details to pay attention to with these methods, so it's entirely possible I missed something. Just let me know if you have questions. Thanks again @Sie_Sayoka for discovering all of this and providing so much guidance.

Well done, those look perfect.

Alright, strap in, this will be a long one.

What can we actually create with this if we go all the way? I tried to find out and made an SdKfz 234/1 for CoH2. Here's how.



Note: We are using the team weapon attach method. Read the guide in this thread for further information. Some of the images here might be too small to read on your screen. Just copy the image link and go to the source.

1. We'll be using a custom skin pack to hide parts of the Puma and 222 to combine them into the new vehicle. Hiding parts requires alpha layers. Shoot me a DM if you want to use my textures and alpha layers and I'll share them with you. Shout out to Starbuck for tips, tricks and layer mask textures to make these.

2. Once your skin pack is set up, we create custom abp's. Clone the 222's abp and name it something like "sdfkz_234.abp". This is necessary to adjust the offset values, so that the turret appears at the right place in game. Copy this into the new file:

Show Spoiler

Now, clone the abp of the Puma and give it a custom name too, mine is called "puma_sdkfz_2341.abp". As for the 222, the Puma's offset values need to be adjusted. It should look like this:

Show Spoiler

3. In the AE, create 3 new entities. I cloned the 222 and cleaned up all the upgrades, abilities and such that we don't want.

3A: The hull. This one uses the new puma abp.
Apply our new skin in the UI extension
give it 1 HP and make in invincible
It has no weapons
Make sure it is both a team weapon and team weapon user
Here are the important extensions and animator states:Show Spoiler

3B: The turret during driving. This is a non-functional 222 turret that we show when the vehicle is moving as the one that will be firing would "wobble" too much on the move.
Apply our new skin in the UI extension
give it 1 HP and make in invincible
It has no weapons
Make sure it is both a team weapon and team weapon user
Add an obscure unit type to it's list of types. I chose "urban_assault_pg". This is for a later step.
Here are the other important extensions and animator states:Show Spoiler

3C: The actual turret. To avoid the desync of turret and hull, we can only allow this vehicle to fire when static. This is a trade off for better visuals, but it really works well in game when properly set up. This entity is our "real" team weapon, with all the combat hardpoints and roles copied from an at gun in the team weapon ext. It has actual health and armor and upon death, I added a target that finds and kills all 222 types nearby (the hull and fake turret have the 222 unit type). Note that we have to add the real Puma abp in the "alternate_sua" so the vehicle has physics ingame. Show Spoiler

4. The hardpoints are crucial. As in the guide earlier, Harpoint 01 needs to be a dummy weapon with an unused parent hardpoint to stop the hull and fake turret from moving around with the main gun. Harpoint 02 will hold the main gun, while Hardpoint 03, with 02 as parent, will be the coaxial. Here is the dummy weapon, a clone from the existing machinegun dummy: Show Spoiler

and here the main gun Show Spoiler

Pay attention to behaviour elements such as attack ground permissions and non_moving_setup. Also remember to add a short wind up and setup to the main gun for functionality with good visuals.

5. Create a squad with a team weapon extension and assign the three entities in this order: Show Spoiler

6. To make our real turret replace the fake one seamlessly, we need an always_on ability and add it to the real turret entity. This ability will wait for the vehicle to move and then hide the real turret and show the stable fake turret. When static, the real turret is revealed. This uses a target function to hide the fake turret. The function is looking for a specific unit type: the obscure one we set on the fake turret earlier (urban_assault_pg). These are the two start_self_action entries:
Show Spoiler

Show Spoiler

7. Clean up UI stuff (new icons, portraits, symbols, text) and enjoy your new vehicle. Note that the UI now considers the vehicle a team weapon and will show it in the infantry row in the top right of the screen. It will also have a "2" for crew members shown. This can't be fixed afaik.

There is a lot of details to pay attention to with these methods, so it's entirely possible I missed something. Just let me know if you have questions. Thanks again @Sie_Sayoka for discovering all of this and providing so much guidance.

the process is too advance, but result is outstanding. Im looking forward for more, like, a Black Prince is now do-able, right ?

the process is too advance, but result is outstanding. Im looking forward for more, like, a Black Prince is now do-able, right ?

Yes, but it might not be perfect. The team weapon attach method will only give you good visuals if you settle for my method of making the vehicle essentially work like a more nimble 251 flak. It can't fire on the move.

Alternatively, you can try the marker attach method and see how the Comet's turret aligns with the Churchill's body. You'd need to attach an alpha layered (hull only) Churchill to an alpha layered (Turret only) Comet with a bulldozer or passenger attach action. If the hull doesn't align well on the 0,0,0 of the Comet, you will have to find a marker in a small object that you add to the abp. There are very few markers in projectiles, props and weapons (all small objects) that actually give you useful offsets without flipping or turning the hull around.

One that I found to be useful for a -0.2 negative z offset is the gunner_sync marker of the M2 .50cal team weapon object.

The replacement system. This system is detailed in a post by Dar below. Like the previous method it only allows firing when stationary. You will not be able to order attacks directly and kills will not be logged as the firing entity isn't part of the squad.

From the first post on this page. Just want to clarify this is not entirely accurate. The system that I used will HIDE the original entity, which is the parent team weapon of the squad and has all the hardpoints. It's hidden when the entity is moving, where it reveals a fake turret that is attached as a child/role to the team weapon.

As the vehicle becomes static to engage enemies, the fake turret will be hidden and real one revealed. Hiding/revealing is done by a target action in an always_on ability that sets the animator state to crush or healthy respectively. No new entity is being spawned in or removed in this process. See my post for details.

My vehicle does count kills, take persistent damage even on the move, it does accumulate experience and it does receive attack move, attack target and attack ground orders.

I see, so it's a more sophisticated version, my mistake.

Some more combinations, this time two versions of the Panzer III, with some visual liberties of course.

I was using a bulldozer attach function and syncing to the gunner_sync marker of an M2 .50cal that's added to the turret's abp. That way the unit plays like a regular vehicle, but animating the treads is tricky. I used a filter action that requires the turret (Pz IV) to be moving, then a velocity variable will be applied to the hull (StuG) to move the treads.




Now, unfortunately, there is a big issue with AI. The AI can't spawn attached entities it seems, so this method will not work for AI-controlled vehicles. The vehicle has to have the "abandoned" critical removed from its health_ext, as on death or takeover by AI, the vehicle will lose any attached entities.

If anyone has found a way to make the AI spawn attached entities, let me know.

To circumvent this, I created team weapon-style copies of the Panzer III for the AI - these work exactly like the SdKfz 234 I made, see the guide above. This leads to two more issues:

1. The AI will never build team-weapon-attached vehicles. Maybe because it identifies the dummy weapon as useless, I don't really know. This can be fixed by having the AI build a regular Panzer IV as a dummy, that despawns and in its stead spawns a team weapon attached vehicle

2. Once the AI has built a team-weapon-attached vehicle, it will not use it properly. The moment it takes control, it will reverse the vehicle into its own base, drive up to the HQ and drive out again, about one sector, then reverse back and so on in an endless loop. I observed this behavior in several tests.

@Sie_Sayoka: You have experimented with these methods more than anyone, do you maybe have a solution or a pointer how to fix this, especially No.2?

Wow those tanks look amazing.

Attached entities are able to be seen on AI controlled units but it is inconsistent. I'm not sure what the cause is but I haven't looked into it as only 1 AI unit within my mod uses it. This may be related to the attached entity not updating its position fully and having it spawn within the FoW somehow prevents them rendering but this is only a theory.

I'm not entirely convinced that the dummy weapon itself is the issue at hand but I don't know enough about AI to say for certain. Several units natively have dummy weapons and since the other weapons on your entities are useful the AI should use the units normally.

An easy way to test if the weapons are causing the issue would be to replace the dummy weapon with a normal one. A time-consuming way I would test if this isn't the cause would be to make a test mod and clone a team weapon. Then slowly start changing the extensions. Because you know the AI would build the vanilla unit it will be easy to determine the specific cause of the issue.

I'm probably not the best person to ask about AI behavior. Sneakeye or Zycat should have more insight into this.

If anyone has found a way to make the AI spawn attached entities, let me know.

Sneakeye or Zycat should have more insight into this.

The AI is very unpredictable how it chooses unit. I found it is heavily influenced by the amount of HP and the cost/HP ratio. The dps also has some influence, but I am not sure which exact settings are used for that. Once I made a new sniper and gave it a custom weapon with different settings but the same dps as other snipers. Somehow the AI never uses it while it spams other snipers.

Also the AI considers two types of units, capture and support. Units with team_weapon_ext or 0 capture_rate are support units and those are build less frequent due to the setting ai_settings > skirmish_settings/army/min_non_support_units_to_support_units_ratio. I gave tanks 1 capture_rate and locked the capture ability with a modifier and now the AI builds much more of them throughout the entire game.

Utility values for a specific unit can be set in ai_economy/complete > squads/squad_utility/utility; keep per_unit_scale and per_unit_scale_historical at -1. This increases the chance that the AI will build it, although in some circumstances the AI still refuses to build it. (This settings is very useful for player owned upgrades)

The moment it takes control, it will reverse the vehicle into its own base, drive up to the HQ and drive out again, about one sector, then reverse back and so on in an endless loop.

Does one of the entities have a dummy weapon? The Katyusha for example has a custom hardpoint 1 and the AI uses it very well at long range due to that. I use this weapon for other artillery units like the Priest too which improves their behavior massively, so a single dummy hardpoint can have a lot of effect. It might be the case that one of your entities has a weapon which the AI don't know how to use?

Thanks for the pointers Sneakeye! I am aware of how the ai_economy with its modifiers works, but no changes to these could convince them to produce the unit.

I wasn't aware though that it puts so much emphasis on health! that could be a major factor here, since two of the three entities in the team weapon have a health of 1, set to invincible.

The main issue is really the unwillingness of the AI to use the units offensively, instead looping it back and forth between HQ and the first line of sectors. I have only ever encountered this when the AI lacks funds and has a half dead infantry unit that it can't reinforce, so it will constantly give it attack orders, they march out, then the AI realizes it needs to reinforce the unit and pulls it back, and the cycle continues.

With the Panzer III team weapon, the AI also looooves the reverse mode, reversing all over the battlefield sometimes. Thanks for the hints @Sie_Sayoka, I am already testing the different extensions from regular team weapons and will see if something sticks.

Sidenote: The Katyusha hardpoint is very interesting, I will investigate that. I currently use a much more complicated method of teaching the AI to work with artillery.

Some more combinations, this time two versions of the Panzer III, with some visual liberties of course.

I was using a bulldozer attach function and syncing to the gunner_sync marker of an M2 .50cal that's added to the turret's abp. That way the unit plays like a regular vehicle, but animating the treads is tricky. I used a filter action that requires the turret (Pz IV) to be moving, then a velocity variable will be applied to the hull (StuG) to move the treads.




Now, unfortunately, there is a big issue with AI. The AI can't spawn attached entities it seems, so this method will not work for AI-controlled vehicles. The vehicle has to have the "abandoned" critical removed from its health_ext, as on death or takeover by AI, the vehicle will lose any attached entities.

If anyone has found a way to make the AI spawn attached entities, let me know.

To circumvent this, I created team weapon-style copies of the Panzer III for the AI - these work exactly like the SdKfz 234 I made, see the guide above. This leads to two more issues:

1. The AI will never build team-weapon-attached vehicles. Maybe because it identifies the dummy weapon as useless, I don't really know. This can be fixed by having the AI build a regular Panzer IV as a dummy, that despawns and in its stead spawns a team weapon attached vehicle

2. Once the AI has built a team-weapon-attached vehicle, it will not use it properly. The moment it takes control, it will reverse the vehicle into its own base, drive up to the HQ and drive out again, about one sector, then reverse back and so on in an endless loop. I observed this behavior in several tests.

@Sie_Sayoka: You have experimented with these methods more than anyone, do you maybe have a solution or a pointer how to fix this, especially No.2?

It's open so many frankenstein options, amazing!
Back in 2016, i dreamed about some old models to be updated with WFA ones by Relic, but it never happened, like:
1. Ostwind on Panzer IV J hull
2. Tiger I with Sturmtiger hull/chassis elements
3. ZSU M17/M16 on M3 Halftrack
4. Brummbar with chassis from Panzer IV J
5. T-34 and SU-85 with T-34-85 hull (it has proper exhaust system)
6. SdKfz 251/1 or 251/16 based on Wurfrahmen 40 model

Also i have some ideas for new possible combinations:
1. KV-85 (KV-1 hull + IS-2 turret and rexeturred gun)
2. SdKfz 250/9 (250 + 222 turret)
3. M36B1 (M36 Turret + M4A3 hull)
4. M4A3(105) HVSS (M4A3 Turret + 105mm + M4A3E8 hull)
5. Jagdpanzer IV with KwK 40/L48
6. British Sherman (Firefly hull + M4A3 turret)
7. Vampire SdKfz 250 (250 + radio from 223)
8. SdKfz 250/10 (250 + M42 AT Gun)
9. Achilles with 17 pounder (M10 + Firefly cannon)
10. StuG IV (StuG III G top part of hull + Panzer IV J Chassy)
11. ISU-122S (ISU-152 + IS-2 cannon)

Some of these definitely doable, some others are gonna be very hard. Aligning turrets to sync the barrel movement would be a particular challenge.

Regarding the AI trouble, I adjusted pretty much every extension in squad, entity and weapon to those of a PaK Gun, with mixed results. I don't know what did it, but the retreat loops around the HQ are no longer an issue.

Two things became new issues now.

1. Sometimes, for minutes even, the vehicle will drive 10 meters back and forth on the spot until it eventually heads to a new target of opportunity. This happens in combat as well, and looks rather ridiculous. Never encountered anything like this before

2. The AI uses the vehicle much like a team weapon, despite it's armor, mobility and firepower. That means it won't do a frontal assault with it, but rather drive around the edges of the map looking for an open flank, sometimes parking the tank there to wait for you. Not terrible, but not what I had in mind. The tank will also try to remove itself from any engagement with other armor and sometimes infantry by reversing away, even if it could put up a fight.

My guess is that the dummy weapon and hardpoint 02 interaction is the major factor in all of this, but I'm at a loss as to how to fix this. The AI seems to roll out a particular movement and engagement plan for a unit as soon as it spots the team_weapon_ext, and this plan does not work well with the nature of a tank.

Some more combinations, this time two versions of the Panzer III, with some visual liberties of course.

I was using a bulldozer attach function and syncing to the gunner_sync marker of an M2 .50cal that's added to the turret's abp. That way the unit plays like a regular vehicle, but animating the treads is tricky. I used a filter action that requires the turret (Pz IV) to be moving, then a velocity variable will be applied to the hull (StuG) to move the treads.




Now, unfortunately, there is a big issue with AI. The AI can't spawn attached entities it seems, so this method will not work for AI-controlled vehicles. The vehicle has to have the "abandoned" critical removed from its health_ext, as on death or takeover by AI, the vehicle will lose any attached entities.

If anyone has found a way to make the AI spawn attached entities, let me know.

To circumvent this, I created team weapon-style copies of the Panzer III for the AI - these work exactly like the SdKfz 234 I made, see the guide above. This leads to two more issues:

1. The AI will never build team-weapon-attached vehicles. Maybe because it identifies the dummy weapon as useless, I don't really know. This can be fixed by having the AI build a regular Panzer IV as a dummy, that despawns and in its stead spawns a team weapon attached vehicle

2. Once the AI has built a team-weapon-attached vehicle, it will not use it properly. The moment it takes control, it will reverse the vehicle into its own base, drive up to the HQ and drive out again, about one sector, then reverse back and so on in an endless loop. I observed this behavior in several tests.

@Sie_Sayoka: You have experimented with these methods more than anyone, do you maybe have a solution or a pointer how to fix this, especially No.2?

amazing work, keep it up please.

1. Sometimes, for minutes even, the vehicle will drive 10 meters back and forth on the spot until it eventually heads to a new target of opportunity. This happens in combat as well, and looks rather ridiculous. Never encountered anything like this before

2. The AI uses the vehicle much like a team weapon, despite it's armor, mobility and firepower. That means it won't do a frontal assault with it, but rather drive around the edges of the map looking for an open flank, sometimes parking the tank there to wait for you. Not terrible, but not what I had in mind. The tank will also try to remove itself from any engagement with other armor and sometimes infantry by reversing away, even if it could put up a fight.

These are just guesses.

For the first problem this may be an issue with the simbox where the pathing becomes confused. For example if the entity is either has something in its abp that has conflicting pathing or something attached else is blocking it, it will try to move around something that is attached to itself. You can try and use a vanilla blueprint for the alternative_sua within entity_blueprint_ext and see if this works.

For the second problem this sounds like an issue with tactics. Check out the ai_squad category and ai_settings>tactics to possibly change the behavior. Ensure the all entities within the squad are of the correct types.

Thanks for the continued help. Only the parent entity has an actual simbox through an alternative_sua, so I am pretty certain that's not the issue. Assigning a custom ai_squad tactic seems to have improved the situation somewhat, but further testing is needed.

In the meantime, another issue arose, related to the tracking behaviour of the main gun. The weapon has a short setup and teardown to operate properly, and the behaviour_ext key"reset rotation on teardown" set to true.

So on teardown, the rotation will indeed reset, but only for a split second. For some reason, immediately after the teardown, the turret will again swing towards spotted enemies, which is an undesired behavior, as it messes with the visuals (turret pointing to the side gets instantly replaced with the static "moving" entity that only points to the front).

Further, even after losing sight of the enemy, the real turret, not set up, will keep it's rotation set, pointing towards the last enemy it has engaged.

Is there a way to tune this tracking behaviour, like force it to stop tracking after teardown, or tinker with the units "memory" (so it doesn't stay focused on the last unit it engaged even after losing sight)?

I'm not sure if I've encountered the issue where it will turn after teardown although I haven't used that specific behavior in the weapon.

There are 3 possible solutions I can think of.

1. Target action. You can add an action to this to have it target something else, maybe itself, and it might change the direction of the turret. I'm not really sure how this works it may require an action that will affect the turret.

2. Enable hardpoint modifier. Normally if you disable a hardpoint with -1 it will revert back to its default direction.

3. Override_weapon_target_prereq_action. If your filter removes all possible targets maybe it will revert to its default direction.

Additional Attachment Examples

The following units use all types of attaching systems previously discussed in the guide.

Show Spoiler

Truly amazing what you achieved! Is it possible to attach that flamethrower (from the universal carrier I assume) to the hull mg of the Sherman and T34 with a working killcounter and veterancy? And have you experienced any impact on the performance with some many attached entities?