Override_weapon_target_prereq_action will only attack the target unit types within the requirement_table. The name is misleading as there are no priorities involved and any unit types that are not in the requirements will be ignored. This action is bugged and will not work when in garrisons.
Possible reasons why it's not working for you is that the squad_caster or target is incorrect, the requirements are not met for the ability, or the ability is applied in an incorrect way. Can you share how you modified the ability and what you put it on?
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.
Reticules (reticles) are normally used to display range of weapons or building placement. However, this can be expanded to show the radius of auras and other things. Vanilla examples would be viewing a sniper's range or a grenade's radius.
You may view the different types of reticules in the ui_reticule category in attribute editor. From these, there are several different types of reticules located within the data extension. There are a limited amount of textures being used and unfortunately most of them are either green or red. However, we can recolor some of them as well as pull textures from other ui categories probably. You can also try to recolor the green/red types of textures but you wont be able to get the full color palette as they are already pre-colored. You may also use the textures from the other ui categories as these are usually meant to be recolored.
Reticules can be used through the reticule action, the ui_reticule in abilities, or ui_range in weapon.
The greatest potential of reticules would be to add custom textures which will effectively allow us to paint directly on terrain. Unfortunately I haven't been able to find where these are located or the dimensions needed for the texture file. Maybe someone else knows.
The other types of UI categories are much simpler and self-explanatory in what they do.
You may check to see if a blueprint can use this system by placing it in world builder and setting the gibs state to on. If the base model's mesh disappears complete then it is incompatible. As mentioned before the most likely candidates for this method would be single player and unused blueprints as these would have been overlooked by Relic when setting up the gibs state.
It's possible to add the parachuting animations to more models than just the Fallschirmjager and Paratroopers. These are, however, limited to certain special models from the campaign. Here is a short (but not exhaustive) list of some of the models that can be used. If you find other blueprints that can use this system feel free to post it in the replies.
armies\common\base\cinematichead\cinematichead (use with some blueprints i.e. isakovich_writer)
Animation & Rigging
The reason why fallschirms and paratroopers only have the parachuting animation is because these are the only models to have rigging for it. If you've tried to get other types of parachuting troops before you know that simply adding a parachute to the abp wont actually result in the infantry having the animation.
The way animations work in general is that there are bone riggings that tell the model what part of the body goes where i.e. left foot here, right foot there. The rigging will apply to the entire blueprint and anything within the abp. For the purpose of parachuting this is dictated by the paradrop state.
Now its actually possible to have other infantry use the parachuting animation by adding them into a paratrooper's abp file but this will result in ugly clipping as both models will be visible at once. The next part will bypass that.
The Gibs State
armies\common\soldiers\giblets\giblets
armies\common\base\basemotion\basemotion
Normally the gibs state hides an infantry's model and replaces it with giblets. Normally this is reserved for deaths such as being blown up by artillery or burned. The file that actually causes the model to be hidden is basemotion. The giblets model is handled by the giblets blueprint. Both of these are normally within motion trees so they are shared by every infantry. You can see how gibs replaces infantry in the world builder, or better yet, have a paratrooper with a paradrop state on as well as a gibs state on.
However, if you don't want the giblets model we will need to use models that aren't affected by it. A good example of this is the isakovich_writer blueprint. If you place him in world builder and set gibs state to on notice how nothing is affected. Presumably Relic didn't bother to hide the model for the gibs state as these types of models were either for cinematics or other special single player things which is good for us.
Walkthrough
1. Make a copy of armies\common\newmotiontree.abp and rename it to something, I renamed mine gibhead.abp. In the new abp delete the basehead and giblets lines. Place this new abp in the appropriate path within the burn folder.
2. Make a copy of armies\aef\soldiers\paratrooper\paratrooper.abp and rename it. Replace the newmotiontree.abp line with that of your custom motion tree abp. Add a line for whatever blueprint you want to use and add cinematichead when applicable. In this example I will use conscript_sergeant.
The order within the abp is somewhat important. It's best to replace the newmotiontree.abp line and add the infantry model next to the paratrooper.
3. In ebps create a clone of the paratrooper_mp unit and rename it. In entity_blueprint_ext change the animator so it links to your newly created abp.
4. In sbps create a clone of paratrooper_squad_mp and rename it. In squad_loadout_ext change the type to your new ebps.
5. In action_apply_ext create an animator_set_state. This will hide the paratrooper model so only your new model is visible.
6. You can figure out how to make a paradrop dispatch on your own, you're a smart person.
Isakovich_writer requires special attention as its blueprint is somewhat different than the others. If you look at the files in archive viewer it uses several different textures. Presumably this somehow conflicts with basematerial so we will need to create a separate motion tree file to remove it.
Some of the blueprints have the head/hands built into the model but others do not. If you find they are missing heads add the cinematichead blueprint in the abp, this blueprint is not affected by the gibs state.
Some models have seen the horrors of war. This is probably because they are using rigging not meant for the model. Just don't zoom in. You may also be able to just cover up the heads with cinematichead as I believe these heads aren't affected by the rigging.
You can see how these units look in-game by playing this test mod as Soviets. Each of the parachuting units has two toggles which change the states of paradrop and gibs.
Applications, Limitations, and Advanced Techniques
The final part of the guide will discuss the practical applications of attaching entities as well as its potentials and shortcomings. There will be some examples of tanks but I wont go too into detail about individual steps as the basics for them were covered in previous posts. Examples wont be perfect as they are just for showing the potentials of attaching. I'll also share some tips and some of my own units from my mod.
Limitations
Attached entities do not update their positions for combat. Meaning they will only be able to fire at units around the location where they have been attached. It's best to just not have weapons on attached entities at all to prevent any visual bugs. The exception to this would be garrisoned squads.
Attaching to an attached entity will result in flickering. Don't attach to child entities. The exception would be team weapon crew as these child entities can have things attached to them because they use a different method of attachment.
Attached entities sometimes do not appear depending on the camera angle. This might be caused from environment blueprints having lower priority than army units when rendering or something.
AI owned units will sometimes not show child entities. I don't know why.
Blueprints within the ABP may conflict. There can only be one vehicle rendered with priority given to the topmost line. I believe this may also extend to some types of weapons as well.
Because of vehicle physics within the abp, child entities may not have movement reactions like the parent. An example would be the child entities attached to 0, 0. You can either remove vehicle physics altogether for the parent abp or lower them for more consistent visuals.
Changing the name of an abp of a unit with hold_ext may cause them to not show garrisoned squads for some reason.
There may be some issues with displaying vehicle crew on the parent of a team weapon. This is probably because crew actions conflict somehow.
Team weapon crew parent entities have some of their behaviors changed. Namely they will not be able to attack when moving and require a complicated setup to prevent child entities from rotating if the parent entity has a rotating weapon. See the section on team weapon crew for more details.
There may be some issues with team weapon crew behaving oddly or rotating along with the parent's weapon. This is mainly because of the complicated relationships between the different entities and that we are doing something that shouldn't be done to them.
Tips
Debugging actions. It may be necessary to differentiate between different entities. These actions should help as they change the color of the entity. They should be used in an interval action as mousing over them will remove the color.
ui\camouflage or ui\build_structure: transparency
ui\animator_highlight_invalid: pink
ui\animator_highlight_valid: green
ui\entity_flash_on or ui\entity_selection_highlight_flash: white
ui\entity_selction_highlight_flash_ally: yellow
ui\entity_selction_highlight_flash_enemy: red
If you need more than these you can use something like small arms weapon hit actions.
Using appropriate attachments. Here is a list of the many different methods, their complexity and stability, and what they are best used for.
ABP editing. Useful for adding blueprints that can be used directly by the parent model. i.e. guns, capes, pintles. Stable but susceptible to typos and animator state conflicts.
Garrisoned Squads. Useful for enabling entities to attack and move. Can be used to attach to combat slots. Very stable and simple.
Passenger/Bulldozer Attaching. Useful for attaching to specific markers on a blueprint or to the 0, 0 (center position) of the parent. Required for attaching to moving parts such as turrets or barrel tips. Bulldozer uses full rotation, passenger ignores x axis rotation. Simple and stable.
Vehicle Crew. Useful for adding more infantry visuals and enabling multiple team weapons within a squad. Somewhat simple and stable.
Team Weapon Crew. Useful for making offsets and having child entities with movement animations. Perhaps the most powerful but most unstable. I would only recommend this if you need offsetting that markers do not provide.
MUA Files and Markers
Although I haven't figured out exactly what the first 9 values for the markers in mua files mean, we can get a general idea of what they don't do. If the values are of a integer then the rotation will be on any 90 degree angle (0, 90, 180, 270, 360). You can control this further by using passenger or bulldozer attach. Since passenger attach locks out the Y axis you can control this axis by using, or not using, this type of attachment.
I've had partial success unlocking the mysteries of the first 9 values. Each of them represent x, y, and z axes in that order. For example ending in 0 will be x, 1 y, 2 z. These values are multiplied by 180 and added up. It also seems that the marker has some initial rotation on the model or attachment point so finding the final rotation is largely inconsistent. I'd recommend just not trying to calculate the rotation of the marker and just test the markers in-game.
Markers can attach to either the object or model of an entity. An example would be the 0, 0 position which is the position on the object itself. This is why entities attached to this marker do not follow the vehicle simvis attributes. A model marker would be something like a marker on a turret which can move and rotate along with the turret. If the model becomes invisible due to something like a state it will convert the marker to an object marker.
Most marker names are self explanatory and you can get a general idea of where they are by the position labeled in the last 3 values in the mua file. You may add additional markers by adding more things into the abp but its usually better to keep the abp of the parent entity as clean as possible to prevent conflicts of animator states.
Offsetting
Offsetting was talked about briefly in the first post. This uses the simvis attributes in the abp file to offset the visuals of the entity. However, any attachments would also be offset which made this function rather limited in use. With team weapon crew attaching this enables us to have as many offset entities as we want because the child entities are not affected by the simvis of the parent.
ABP stacking
ABP stacking can be used to show multiple models that share the same animation. This is most useful for infantry, as vehicles conflict for some reason.
One of the units from my mod using abp stacking. The stacking is used both for the infantry model as well as the weapon.
Code
model = { "..\\..\\..\\common\\NewMotionTree.abp",
-- Common Soviet Gear "..\\..\\sovietcommongear.abp", "..\\..\\..\\common\\engineer.abp", "..\\..\\..\\soviet\\weapons\\mine_tm35\\mine_tm35", "..\\..\\..\\west_german\\weapons\\rifle_fg42\\rifle_fg42", "..\\..\\..\\british\\weapons\\boys_at_rifle\\boys_at_rifle", "..\\..\\..\\german\\weapons\\panzerfaust_100\\panzerfaust_100", -- Main Mesh
As you can tell from the abp it uses 3 different infantry blueprints with the winter skin. Volksgren are used for their long coat, infantry section for their helmet, and at gun crew for the black scarves. There is minor clipping seen because both the volksgren and at gun crew have larger models than the infantry section and their colors are mostly the same.
The weapons visible are the fg42, pzb39, and the British AT rifle. These are all weapons in the rifle category so they do not conflict with each other. You will need to set the visibility states to on for the guns.
Skins
You can view skins (that aren't custom) within the world builder by clicking on a unit in NIS. To know if something has a skin or not, open the corresponding archive in archive viewer and there will be a folder with the name of the skin in the blueprint folder.
To apply them in-game go to ui_ext in ebps. Under skin_pack_override set to true if it's a vehicle (you won't need to do it for environment or infantry). Skin_summer/skin_winter is where you will put the skin name. You shouldn't change these if they are the default, for example don't put summer in skin_summer since it already uses that skin.
Custom skins are an incredibly powerful tool as you will be able to hide certain parts of vehicles. This means you can have the turrets or chassis of vehicles and attach things to them leading as opposed to just mixing and matching. I've never made a custom skin before but there are plenty of resources about it if you choose to use it in your mod.
Other Attachment Types
There are two other types of attaching that I haven't gone over because I don't think they are of much practical use. The first is fx attaching which is used for things like projectile tracers or damage markers. The second would be projectile attaching which is used for homing projectiles and sticky grenades.
Useful Blueprints
This is a short list of blueprints that should be of use to your creations. As always view them in the world builder.
armies\aef\weapons\bazooka_m9
• Used to get -90/90 z rotation with 180 x rotation which is not available from searchlights.
• In the abp combine with basemotion.
• m9_bazooka_visible state on
• bazooka_state state offhand
• marker_bazooka_barrel_exhaust marker_bazooka_barrel_end
armies\various projectiles
• They provide nice fx and sfx
• Some exhaust markers with passenger_attach will make entities face backwards
armies\common\base\basemotion
armies\common\vehicles\crew\gunner_turret
• Used to get -90/90 z rotation which is not available from searchlights.
• turret_mg42_state state aim
• turret_mg42_horiz variable -90/90
armies\soviet\props\cape
• summer and winter skins
armies\soviet\props\patriotic_flag
armies\west_german\structures\west_german_hull_down_l
armies\west_german\structures\west_german_hull_down_m
armies\west_german\structures\west_german_hull_down_xl
environment\buildings\ardenes_urban\accessories\misc_searchlight_01
• summer and winter skins
environment\buildings\eastern_industrial\accessories\misc_searchlight_01
environment\objects\barricades\barricade_dirt
environment\objects\barricades\barricade_snow
environment\objects\defenses\metal\searchlight_l_01
environment\objects\vehicles\parked_vehicles\panzer_iv_parts\panzer_iv_barrel
environment\objects\vehicles\parked_vehicles\panzer_iv_parts\panzer_iv_hull
environment\objects\vehicles\parked_vehicles\panzer_iv_parts\panzer_iv_turret
environment\objects\vehicles\wrecked_vehicles\panzer_iv_frozen
• remove turret with stug_iii_type state
• summer and winter skins
environment\objects\vehicles\wrecked_vehicles\stug_iii_frozen
• remove gun with stug_iii_type state
• summer and winter skins
gameplay\props\various weapons
• Because they are props they can be attached unlike many of the armies folder weapons
Panzer III
We can make a Panzer III by using the chassis of the Stug and the turret of the Panzer IV f1.
In world builder place the stug wreck and a panzer iv.
Pz4 state vehicle_variant: f1
Stug state stug_iii_type: g_long_barrel
You can make them in a summer or winter skin.
Pz4: german_default_summer, german_0014_winter
Stug: summer, winter
If we use a passenger or bulldozer attachment the stug chassis will be offset a bit more forward than in world builder because we can't have nice things. I would recommend against doing this as it partially blocks the turret.
Instead we use the team weapon crew method and have the chassis as a team_weapon_user. Then in the simvis attributes section of the Panzer IV abp offset the z axis by 0.5 which will fix the offset problem.
Stug III MG Turret Mount
We have an m8 greyhound parent with a stug iii child. The greyhound's hardpoint 1 weapon is that of the stug's which matches up for the most part. This is the only way I found to get a 360 degree mg turret on the stug.
Maus
By using team weapon crew and changing the rotation of some tanks using the mrkr_exhaust marker from west_german_rifle_grenade I made a maus. It's fairly complex and uses 17 different entities. This is possible because of offsets.
The turret doesn't rotate since it uses a jagdtiger parent. To get a functional turret a different method would need to be used alongside custom skins. Maybe by using garrisoned squads but it's difficult as the turret is so large.
Here's what it looks like in-game.
Towing
We can use the same offset method to create at gun trailers, however because the towing state doesn't lift the legs up we wont use the mrkr_exhaust method. Instead we will make the team weapon crew use a searchlight and attach the at gun to the searchlight. This will enable us to give the at gun a bit of rotation using the hinge variable on the searchlight and have its legs line up with the trailer coupling.
In game. Note the searchlight offset into the ground.
Showcase
These are units I made with entity attaching for my mod. You can play the zombie mod to see how they look like in-game. I wont go into much detail about how each of them are made as it is fairly complicated.
Conclusions
There's many different applications that I haven't covered within this guide. Part of the fun is discovering them for yourself. The above examples as well as some of the units from the crew post are available in this example mod where you can see how they interact in-game. Play as OST.
By combining team weapon crew and rotation using searchlights its possible to get both offsets and rotation on your units. Visually, this will allow you have place anything in any configuration. The only limiting factor would be having attacking entities with movement as you'll have to use either hardpoints on the parent unit or garrisoned squads on the child entity with team weapon crew or parent.
Although complex, once you get the hang of it you will be able to make some cool shit. Hopefully this guide explains the concepts enough for you to learn the basics of entity attaching. If you need clarification on something you can always ask.
Sound_action will allow you to play sounds directly from the sound archive. This means we can finally have speech from different races among other things. It's not a perfect solution as there's some caveats.
You can see how sound_action is natively used on some DLC units. For example attributes\abilities\aef\modal_ability\sp\sp_240mm_off_map_barrage. This ability will use sound_action to play the offmap artillery firing. To understand the paths and codes we need to open two archives:
Data.sga
data\game\speechtuning.lua
Open with notepad. This will tell you what the 3 letter codes are for.
Sound.sga
These are the paths that sound_action uses. They are .bsc files which I believe is a Visual Studio file although we can open and view them partially with notepad. The files referenced are located in soundhigh.sga/soundlow.sga? but we don't really have to dig that deep. I think they are just variations of sound types.
So as an example we will make any unit produce the Soviet engineer 203 ability sound. Let's break down what the file path means.
sb: The speechtuning.lua file refers to it as "Soviet Building" but I think this may be for a race indicator. For example US, Brit, and Sov all have "eng" units but this code is different for each race. OST/OKW share xb for some reason. eng: Combat Engineers. 3 letter code for the unit. Refer to speechtuning.lua abt: Ability. Type of action. 203: Name of the ability or action. gen: General. There are specific variations for some speech codes. Take a look at speech\mp\german\gre\orderconfirmations\ability\ to see the Panzerfaust codes for different vehicle types. lt: Loud/normal talking? Don't know what the abbreviation is but lt is yelling, nt is talking. s: Size? l/m/s are in this field.
As mentioned before there are some issues and limitations with using this. You will not be able to get a perfect system for imitating speech.
Sound origin is centered in the middle of the map. But maybe it's because I put the action on a unit. Offmap artillery will sound the same no matter where the screen is on the map, speech will have radio sounds if off screen.
Sounds will only play for the executing player.
Some sounds don't work. I tried to get thunder sounds but nothing happened.
Because these are played through actions and not through native systems it may be difficult to detect when to play sounds for certain actions.
Sound_action can of course be used for many other things other than speech. Hopefully you can find good uses for them.
Relic Entertainment
cblanco ★ 
보드카 중대 
VonManteuffel 
Heartless Jäger 
