Profile of Sie_Sayoka

Crew and YOU

This post will detail the mechanics of crews and how to use them. Crews have many interesting properties and although they are mainly visual there are some practical applications to them as well. First let's start with defining what crews are within the game. There's two types of crew, vehicle crews which are only visual and team weapon crews which are entities within a squad. Both of them use the skeleton_attach command as opposed to the animator_attach that we have been using previously.





Examples of vehicle crew, weapon team crew, and entity attach respectively. The system for attaching a blueprint or entity to a parent entity is as follows:

• Target Visual
  This points to the parent entity and dictates the type of target.
  
  • Garrisons: target
    
  • Spawn_attached_option: target
    
  • Vehicle Crew: vehicle_target
    
  • Team Weapon Crew: antitank_target artillery_target heavymachinegun_target mortar_target
    
  
  
• Target Marker
  This points to a marker on the parent entity. Garrisons will always attach to combat slots. Crew will attach skeletons depending on their attach action. The only way a target marker can be specifically set is through the spawn_attached_option.
  
  • Garrisons: "combat slot" type markers see .mua file
    
  • Spawn_attached_option: see .mua file
    
  • Vehicle Crew: determined by crew attach action
    
  • Team Weapon Crew: determined by crew attach action
    
  
  
• Self_Marker
  This is the marker on the child entity. Despite the names being different all types of attaching will use 0, 0 as the self_marker.
  
  • Garrisons: marker_base
    
  • Spawn_attached_option: bone_barricade
    
  • Vehicle Crew: metarig_pelvis
    
  • Team Weapon Crew: metarig_pelvis
    
  
  
• Attach Action
  This is the action that tells the child to attach to the parent. This must have a compatible visual_target e.g. attach_gunner_antitank must use antitank_target.
  
  • Garrisons: passenger_attach
    
  • Spawn_attached_option: attach_bulldozer
    
  • Vehicle Crew: refer to world builder or AE
    
  • Team Weapon Crew: refer to world builder or AE
    
  
  

The first three items on the list are the requirements for a successful attach action. If they are not met the entity or blueprint will not attach or not attach properly. Improper attachment will result in the child attaching to 0, 0 on the parent.

So what does skeleton_attach do exactly? It attaches the entity or blueprint at 0, 0 on the parent entity then gives the skeleton of the infantry to the parent entity. Because it uses the skeleton to attach it will only affect the infantry model and no other models associated with its blueprint. For example guns, capes, and other models that aren't natively part of the infantry model will not be affected by skeleton_attach and will remain at 0, 0.



Grenadiers as crew. Because the cape is added through the grenadier's abp it separates from its model. The only infantry that can have a cape and be crew would be guards rifle because the cape is part of its model.




The first picture has grenadiers as crew again. Capes are nowhere to be found. In the second picture we have a pioneer with an mp40 in world builder. Note how the mp40 is floating at the 0, 0 of the AT gun. Presumably this happens because of the antitankgun_state which hides the other blueprints within the abp. If the blueprints in the abp do not have this state they will still be visible.

As mentioned before, vehicle crew are only visual. The blueprint is loaded directly and as such it has no actual interaction within the game. You can determine if an entity uses vehicle crew if it has the crew_ext in ebps.

Team weapon crews are much more complicated as they deal with 3 or more entities interacting with each other. Because they are entities, each of them can be attacked which can lead to some new mechanics that will be covered later. You can determine if an entity uses team weapon crew by team_weapon_ext in ebps.

Usually it's easy to determine what kind of crew a unit has. However, sometimes it's misleading. For example the OKW flak emplacement uses team weapon crew whilst the British emplacements use vehicle crews.



Vehicle Crew

Because vehicle crew load the blueprints directly they aren't regarded as entities. This might be better for performance as you wont have additional entities and their associated calculations to worry about. I'd recommend using vehicle crew when applicable if your mod has several times more the normal amount of units. We are not able to apply states or actions on vehicle crew at all other than what is listed under the role tree. Basically whatever the blueprint has on by default is what you get.



In the above example I have a clone of the ZIS AT gun with vehicle crew from an SU76. The only difference between the attach actions for these two blueprints are the target type which ultimately doesn't matter as their roles are the same. However, since the crew animations are directed by the antitankgun_state we have to change a few other things in order for it to behave like a normal AT gun.

• Delete team_weapon_ext
  
• Copy crew_ext from the SU76
  
• Under type_ext change the weapon_targeting to automatic
  
• Create the above action to make the crew have move animations
  
• In sbps delete the requirement_action and the crew loadout
  

Functionally it'd be the same as an AT gun but with an invincible crew although some animations may be a bit off. You could also achieve the same effect by making the team weapon crew invincible but this is just an example.




We can also use vehicle crew to have multiple team weapons within a squad. To address the weird moving during take down you can play with the duration of a speed modifier in the requirement action.



Vehicle crew can also be used to attach blueprints directly to 0, 0 of the parent entity. In this example I used the attach_bulldozer action on an M10. Note that there can only be one type of target within the crew_ext. This is why the M10 crew is not visible as they use vehicle_target whilst I used just "target" for the attach_bulldozer. Using passenger_attach or incompatible crew attaching will not work.

churkin.abp

model =
{
"..\\..\\structures\\occupied_object\\occupied_object",
"..\\..\\flag\\flag",
"..\\..\\..\\..\\environment\\objects\\barricades\\barricade_dirt\\barricade_dirt",
}

For some reason the occupied_object will not load the flag in its abp which is why I needed to add the flag as another line. The role name cannot be blank and is used for crew related actions. Abandon, death, and desync aren't really needed for non-infantry models as these are related to animations on death.


Additional_crew_option

The bren carrier is unique in that it's the only entity that natively uses additional_crew_option. This crew function reads the blueprint of a garrisoned model and creates a blueprint of that infantry in a crew slot. These are not entities and the same rules that apply to vehicle crew of course apply to additional crew.




To illustrate a possible issue I have the German vehicle crew with the hat_01 hats state. This state is not the default so when they enter the bren the hats wont appear.

This function is best used to provide a dynamic visual indicator that the building or vehicle has garrisoned units above the default limit of the combat slot markers. So if you wanted a halftrack to have more than 4 garrisoned infantry visible within it you could use this provided that you have crew slots that match it visually to your standards.

It can also be used to have vehicles or buildings that will display crew and function when garrisoned. Examples would be a halftrack or bunker that only enables its MG turrets when garrisoned.






In this example I have an M10 with the crew_ext changed to have only additional_crew_option. I also enabled hold_ext. When an infantry squad garrisons the M10 they will occupy the gunner and loader crew slots. If you wanted to make it functional i.e. turret not being able to rotate or fire you would have to disable it through modifiers or weapons.





Gunners
Data\art\armies\common\vehicles\crew\

Some of these blueprints have "attachment" points that are compatible only with certain vehicles. In the above picture for example we have different vehicles. All of these blueprints use the gunner_pintle yet the offsets on all the axes are different. In the second example we have a gunner_turret which for some reason by default is 90 degrees off. Yet these function perfectly well on compatible tanks. If you try to add one of these crew blueprints in your abp and it doesn't work this may be one of the reasons why.

Pintle_ type blueprints are all of the same family and can be switched freely between vehicles. Because of these "attachment" points they will automatically snap to wherever the pintle is supposed to go. Some vehicles such as the IS-2 and the M8 will allow for 360 degree horizontal rotation despite most pintle guns natively having a 90 degree arc. This is because of a special variable within these vehicle blueprint types that uses the turret_gunner_horiz variable instead of the normal pintle_(weapon)_horiz.

Likewise the gunner_ type blueprints are for specific types of vehicles which are in their name. The exception would be gunner_pintle which is regarded as a pintle type blueprint and gunner_turret which is meant to be shared by German tanks.

The most useful application for these is to swap pintle_ blueprints to have different types of machine guns. I've tried many different methods to get a 360 degree MG turret on the Stug but because it already has a pintle attachment point everything just snaps there. There are, however, always workarounds although they may not be the cleanest more on that in a future post.




Image courtesy of Starbuck.

Desants
Data\art\armies\common\vehicles\crew\crew_desant_a-f

Desants and can be added through the abp to give more slots for vehicle crews. These are an unused feature and are meant for the Sherman (not the 76mm version) but some desants can be put on other vehicles with minimal clipping.



For some reason desant D and F have carbines and these are persistent whether there are crew attached to them or not. The other desants look like they are supposed to be holding weapons as well but the blueprint provides none. Desant E is on the turret and moves with it accordingly, the rest are on the hull of the tank.

Show Spoiler



In this example I'll have an additional_crew_option to load the infantry. Have the ebps>hold_ext>on_loaded_squad_actions do an additional_crew_action like the bren.


I would recommend against having both additional crew and garrisoned squads active on a vehicle at once as it will result in each infantry making 2 visible units, one of vehicle crew and one of the actual entity. It might be possible to set requirements so that you can have both but since the on_loaded_squad_actions is the garrisoned squad itself it becomes rather difficult.



Team Weapon Crew

Team weapon crews are proper entities and as such we can apply actions and other properties to them without the limitations that vehicle crews had. In order to function visually a team weapon requires 4 criteria:

• Team_weapon_ext in ebps. This designates that an entity is a team weapon as well as determines the roles to man the team weapon.
  
• Team_weapon_user_ext in ebps. This designates entities that they can man a team weapon.
  
• Requires a weapon on the parent entity. The weapon on hardpoint 1 cannot be null.
  
• Squad_loadout_ext in sbps. The squad requires enough crew to perform the roles.
  
• Squad_team_weapon_ext in sbps. This tells the squad to search for team weapon users to man the team weapon.
  

The system for attaching is different than the previous methods used because they are handled entirely by states, as opposed to actions however the states themselves provide attachment actions. This will make applications somewhat difficult if you want to do something outside the range of normal behavior like what we will do later.



As mentioned before, because team weapon crew are entities we can do things like add those hats to the German crew which we weren't able to do earlier with vehicle crew. Also note in the screenshot that if a role within team_weapon_user_ext is invalid the entity will just attach to 0, 0. The reason why they are different colors is for debugging purposes.



This can lead to some interesting mechanics such as having crew that can actually be hurt. However, because their simbox is attached to 0, 0 this means that usually only splash would be able to hurt them. Note the box in worldbuilder is actually larger than the simbox used in game because it uses alternative_sua of commonhuman.

So let's get started with a simple example of adding a driver and gunner with hats using team weapon crew to the Bren Carrier.

ebps

• Clone universal_carrier_mp in ebps and rename it.
  
• Delete crew_ext as we wont be using vehicle crew.
  
• Copy team_weapon_ext from something like the pak40. The main things that matter here are the ext itself, tp_mobile, and the sync_target_name which should be changed to vehicle_target. The other stuff doesn't matter since we wont be using the team weapon crew system of attaching. If you would like to add more roles just copy/paste more in.
  
• Clone any infantry (I used pioneers) and rename it.
  
• In entity_blueprint_ext change the animator to armies\german\soldiers\vehicle_crew\vehicle_crew.
  
• In action_apply_ext create an animator_set_state. Do_action_state_name: hat_01, state_machine_name: hats. This will make the crew have the commander hats.
  
• They need team_weapon_user_ext.
  

slot_item

• Clone 2 new slots items.
  
• Use the settings of the first screenshot for both of them.
  
• For the on_add_actions follow the second screenshot. The interval_action is for debugging purposes so you don't need to add it.
  
• For the second slot item do the same except for action_name use attach_driver_bren.
  

sbps

• Clone universal_carrier_squad_mp and rename it.
  
• In squad_loudout_ext add your cloned bren and at least 2 of the cloned crew. The bren must be first.
  
• Add squad_team_weapon_ext. You don't have to change anything for it.
  
• In squad_action_apply_ext add the 2 slot items we made. Permanent: true.
  

If everything went smoothly you should end up with something that looks like this. When either the driver or gunner die, another member of the squad will take over their role. This is because we used slot items that are owned by the squad. If the bren dies then all of the crew will retreat because their team weapon died as dictated in on_abandon_action in team_weapon_ext.

We need the delay because we have to wait until the team weapon system attaches the child entity to the bren usually this means the infantry running over to the 0, 0 point. You may also want to change this to an interval action to make sure it's foolproof. The weapon for the item slot is the same as the hardpoint 1 of the bren. This is because a slot item will not be given to an entity with the same weapon. Honestly I'm not sure what the logic is behind the item slot giving order.

If you simply need to attach to 0, 0 without infantry animations, such as the example below, using team weapon crew is much simpler.

• Copy the team_weapon_ext from an AT gun and paste it in the parent entity's ebps. Set the number of roles you need. You don't have to change anything in this extension, roles can be copy/pasted.
  
• Create team_weapon_user_ext for the child entity.
  
• Create Squad_team_weapon_ext in the sbps. Can_auto_face_target to true.
  
• Set the Squad_loadout_ext. Make the team weapon the first loadout_data and the child entities after it.
  

Because team weapon crew can attach at the 0, 0 point and also because they have movement animations this can make a better visual than other types of attachments as there's both movement animations and vehicle physics. This is not a perfect attachment as there is some movement inconsistencies between the parent and child presumably because the children and parents lack the correct sync markers.

The child's movement will lag a little bit behind the parent's which will make it look weird when moving. To remedy this you can make the parent entity invisible, either through damage_state: crush, or some other means. All the children entities will handle the visuals.





On turreted or other types of rotating weapons like pintles you may encounter a situation where the child entities rotate with the turret. This could be either be useful or an issue. Ideally we would want to be able to choose and let both the hull and the turret have attached entities. Unfortunately I haven't figured out how to do this.

I believe I've narrowed down the factors of this issue to hardpoint 1 as well as hardpoint 1's tracking. But because this is a rather complex system that isn't fully understood there may be other factors. It may require further knowledge about hardpoints and weapons to get around the interactions inherent of team weapon crew.



In the example I have an ostwind parent with scout car child. I made hardpoint 1 have a dummy weapon and changed the parent_hardpoint of it to something unused. I also moved the flak to hardpoint 2. Receives_attack_commands is set to true to enable you to right click on things and attack ground.



The dummy weapon in hardpoint 1 is a clone of the dummy_weapon_mp with the fire_cone_angle 360 and speed_horizontal to 0. This will trick the dummy weapon into thinking it has 360 degrees of rotation despite not being able to rotate. If the dummy weapon has different range than the actual weapon you will have to change these values to make it behave normally.



Changing the hardpoint of the main gun may present some issues so you may have to change some things as hardpoint 1 is used for overall behavior like attack moving. Another issue are buffs or changes to weapons. The ostwind gets a veteran version of the flak on hardpoint 1 so you'll need to change that.

Another important note is that because we changed the parent entity to a team weapon this means that they will no longer be able to fire when moving. I believe this is caused by it being a team weapon, rather than a weapon's behavior. For example the child entity may be required to attach to the parent before the parent can fire. This might be why you see a small loading bar before the parent can attack, just like a normal team weapon setup.



With some blueprints getting the child entities to not rotate becomes more complicated. An example would be the m15. Because all of the weapons within combat_ext have a parent_hardpoint of 1 any child entity will rotate along with its turret.

For hardpoint 2 I made a clone of the 37mm and added the tracking variables in anim_table as the dummy weapon is no longer responsible for tracking animation.

For hardpoints 3 and 4 the parent_hardpoint is set to 2 because the turret is dictated by hardpoint 2 now.

All very complicated things but I think this is an exception to the norm as the m15's behavior is different from most units. Just know that these issues can occur but there's usually a fix for them although it may require a lot of time. You can see the m15 in this example mod by playing Soviets. Use cheat commands to teleport it out of the HQ after the child has attached. This is a bug in general where team weapons do not have collision with buildings when spawned in.

Updated the guide with a better system for attachments and more information regarding how it works.

I'm not sure if that's possible as the turning joints can't be done with this system. For realism I think making foliage camouflage for tanks using bushes would work well.

In ebps under your projectile go to explosion_ext. On_detonate_actions spawn several dummy entities with offsets that match the radius you want. Then for the dummy entities you can set_animator_action for whatever effects and then kill them.

So I've spent the past few days messing around and found out a few ways on how to attach things to moving entities. All methods require apb file editing so refer to this video if you don't already know how to do that. Knowing how to preview entities and interact with them without having to boot up the game for every small change is also useful. For this we use world builder. You can learn how to use it with the NIS world builder guide.


How It Works

Normally within the game there's the model and anything that isn't part of that model is added through the apb file. An example of this would be weapons on infantry or the hull down ability. These are invisible by default until an animator state reveals them. As far as I know whatever the abp points to will get merged into a blueprint. Imagine an infantry unit with all of its available weapons and accessories on it at the same time.

Keep this hierarchy in mind:

• Model Files - Files such as mua, sua, rgt, etc. Includes states, actions, variables, and other necessary data.
  
• ABP File - Contains pointers to blueprints and additional information such as vehicle physics and other ABPs.
  
• Blueprint - Collection of all the model files and the abp file (if any) within the folder that share the same name.
  
• Entity - Collection of everything above that has a physical manifestation within the game. For example crew and fx are not considered entities as they are only visual.
  

Editing the ABP File

In this example I gave capes to Grenadiers. Animations and everything work the same as if they were Guards Rifles. Blueprints that normally don't attach to infantry work as well but of course they don't have animations for infantry.

By simply adding this line in the Grenadier's abp file it gives them a cape.

"..\\..\\..\\soviet\\props\\cape\\cape",

In addition to pointing to other ABP files and models you can also edit vehicle physics and offsets. In the above example I changed the vehicle_render_offsetY to 3, which makes it 3 meters above the ground. This is only a visual change as the hitbox will stay at ground level. This can also be used on non-vehicle models such as infantry. I believe the only requirement to enable offsets is to set vehicle_physics to 1. Blueprints added within the abp will still center its location on the parent model but keep the offset of the parent. Attaching blueprints will override any offsets.

All blueprints added to the ABP will merge their events, states, variables, and actions. This can be both beneficial and detrimental. An example of how this within the base game is weapons. Infantry initially do not have weapon states such as rifle_mosin_nagant_visible, it's only because the abp references sovietcommongear.abp and that references rifle_mosin_nagant that this state will be available to the infantry.

It's important to understand the directory system of abp files. Incorrectly referencing a model will result in a blue box. The ".." is equivalent to "one level up". As such the lines may be different depending on where the abp file is located. For example if you want to add a conscript_sergeant to your conscript abp you would add:

"..\\conscript_sergeant\\conscript_sergeant",

But if you wanted to reference the sergeant for a grenadier's abp file it would be:

"..\\..\\..\\soviet\\soldiers\\conscript_sergeant\\conscript_sergeant",

Of course you could just use the second line for both of abp files since it will lead to the same result. I think most of the things in the armies folder shares the same folder system but if you were to reference, for example, in the environments folder you'll have to change the number of "..".




Take care on what you reference as some states may overlap. For an example, I wanted to add a pathfinder beacon on a 222. Both of these blueprints have damage_state but the values do not match.

sdkfz_222 damage_state

• healthy
  
• wreck
  
• crush
  

usf_pathfinder_beacon damage_state

• healthy
  
• damaged
  
• destroyed
  

What ended up happening is when 222's health reached the limit that the beacon would enter a damaged state it would disappear. This is because the 222 would also have a damaged state which it doesn't have. I was able to solve this issue with the settings in the picture but just keep in mind that overlaps can happen and it may not be solvable. This issue can also be bypassed through the use of entity attaching which will be covered later in the guide.

Note that editing abp files will not be included in the mod if you haven't made changes in the attribute editor. To get around this use the rebuild function. If you made changes in the AE then build will work normally.




Garrison Markers

This would be useful if you'd like to attach to a garrison marker on a vehicle or building. If the blueprint has the associated marker for garrisoned units you can attach things to that point. In this example I attached a flag to a medic and had it garrison the half track.

"..\\..\\..\\soviet\\props\\patriotic_flag\\patriotic_flag",

You can garrison non-infantry blueprints but it will have an issue of only updating its position every few frames. To get around this you'll have to add basemotion. Keep in mind that the line below may have to change depending on where the abp is located.

"..\\..\\..\\common\\base\\basemotion\\basemotion",

Most tanks are able garrison units. To do so, add marker_ext and hold_ext in ebps. In the example the Sherman can hold at most 6 units but a Tiger has no garrison markers. Because the infantry are no longer on the ground, the attached blueprints wont be either. Note that the abp used by the parent entity must use the same path as the original entity in order to get garrisoned squads to show up. I don't know why this is. For example if you edit the sherman_m4a3 abp it must be located within the same folder and named sherman_m4a3.abp. This rule is only applicable for showing garrisoned squads, you wont have to do it for other types of attaching.

To hide the decorator for the garrisoned unit go to squad_ui_ext in sbps and set the decoratable to false. In ebps set decorator_visibility to hidden. Note this only works when viewing other players' units. Your own units will still show the decorators next to the hold's decorator.

To prevent the unit from exiting the vehicle go to hold_ext and set disable_unload to true. You can also set percent_unload_on_death to 0 to make sure the unit dies with the vehicle.




The Spawn_Attached Function

The Bulldozer Sherman's ability to create barriers has the unique spawn_attached function. This creates an entity(not a blueprint) and attaches it to a specific marker. Vehicles normally have tons of markers all over for things such as damage, headlights, tracks, etc. All of these points can be attached to but the rotation of the marker cannot be changed. To view the markers use the archive viewer to extract mua files and open it up with the notepad.

name = marker you enter with spawn_attached function
subtype = if labeled 'infantry only' this is a garrison marker
transform_m00 = z axis
transform_m01 =
transform_m02 =
transform_m10 =
transform_m11 =
transform_m12 = z axis
transform_m20 =
transform_m21 = z axis
transform_m22 =
transform_m30 = position x
transform_m31 = position y
transform_m32 = position z

I think the first 9 values are for rotation. They match up for the most part but there's something other than just rotation going on. Note that rotation degrees are multiplied by 180?

Position is from the 0, 0 origin of the blueprint. To get a preview of where the marker is on a blueprint open up the world builder and add the entity you want in the NIS with a 0, 0 position. Then add the entity you're planning on attaching and the values for position and rotation from the mua file. You can use the animator action "ui\camouflage" to make the model transparent for easier viewing. The world builder makes y position 10 be the default for some reason but it will be 0 in game.




The barricade attachments are unique as they use the animator_attach command as opposed to the skeleton_attach for crew. This is the same type of attach command that garrison uses although it's used in a different way. The 4 barricades are the only types of blueprints that can use the attach_bulldozer action. The dirt and snow barricades are by default invisible but it seems the mud and rubble barricades are unfinished and have an ugly fence that can't be hidden well. We can inherit this action from the barricade if we reference it in the abp.




As mentioned before garrison, or more specifically, basemotion have the animator_attach command as well. The passenger_attach action has the lock_position_only value which, unlike the bulldozer_attach function, will ignore rotation on the x axis. This means that it will share the same rotation as the model it's attached to as opposed to the rotation determined by the marker. For whatever reason it isn't 100% as I've tried to attach to projectiles but their rotation changes but attaching to vehicles seems to work fine. Also note that while basemotion and the passenger_attach should prevent rotation, it doesn't but using completemotiontree.abp does.

I'll make two examples to demonstrate the possibilities of the power of attachments. One example will make a civilian car driveable the other will create a new fully functional tank with existing assets.




First I'll open up world builder to use it as a reference. I'll be making the data>art>environment>objects>vehicles>civilian>civilian_coupe. Unfortunately this model doesn't have a mua file and thus has no markers so we wont be able to attach things directly to it. In the picture both the coupe and the kubelwagen have a 0, 0 position. The "driver" is actually the gunner crew for the kubelwagen. Unfortunately the coupe model is offset to the back a bit so the models don't line up well. This will make turning look awkward but it can't be helped unless if I find a way to offset attachments.




If I set the kubelwagen's damage_state to crush it will make the model invisible but leave the crew member. However, the coupe also has this damage state so we will want to use the spawn_attached function for this to keep the states separate.

Next we will need to create an abp file for a dummy blueprint. Since there's only the 2 barricade choices (snow and dirt) and basemotion is shared by all infantry we would quickly run into problems if we wanted to use more than 2 different attach blueprints. By using dummy blueprints it will allow us to use as many unique attachments as we want without worrying about affecting existing blueprints. Dummy blueprints should be something that are not used by neither the map nor the tuning pack. Good dummy blueprints to use would be cinematic or unfinished models as they wont be used by maps and we can avoid using these models with some abp editing.

Here's a list of some useful dummy blueprints:

• armies\german\cin_grenadier\cin_grenadier
  
• armies\german\cin_ostruppen\cin_ostruppen
  
• armies\german\ostruppen_winter\ostruppen_winter
  
• armies\german\tank_hunter\tank_hunter
  
• armies\german\tank_hunter_winter\tank_hunter_winter
  
• armies\german\wehrmacht\wehrmacht
  
• armies\soviet\ania_cin\ania_cin
  
• armies\soviet\churkin\churkin
  
• armies\soviet\churkin_book\churkin_book
  
• armies\soviet\hospital_patient\hospital_patient
  
• armies\soviet\isakovich\isakovich
  
• armies\soviet\isakovich_captain\isakovich_captain
  
• armies\soviet\isakovich_captain_cin\isakovich_captain_cin
  
• armies\soviet\isakovich_photo\isakovich_photo
  
• armies\soviet\isakovich_prison_book_cin\isakovich_prison_book_cin
  
• armies\soviet\isakovich_writer_cin\isakovich_writer_cin
  
• armies\soviet\pozarsky_officer_cin\pozarsky_officer_cin
  
• armies\soviet\pozarsky_officer_pist_cin\pozarsky_officer_pist_cin
  
• armies\soviet\pozharsky\pozharsky
  
• armies\soviet\recon\recon
  
• armies\soviet\sniper_female_recon\sniper_female_recon
  
• armies\soviet\specialist\specialist
  

Most of these blueprints are actually usable if you add the completemotiontree.abp to their abp. However, some like churkin I couldn't get working at all.

You can also reference an abp directly instead of using the blueprint of the folder's name. This will allow you to have as many abp files within a folder as you want. Note that in the AE this will give a warning as the AE doesn't reference the burn folder. If you don't want the warning use the method above. As an example in the cin_ostruppen folder I'll make an abp filed named test_object.abp. Then in the entity_blueprint_ext the string should be:

armies\german\soldiers\cin_ostruppen\test_object

I'll start by making a dummy blueprint out of the cin_grenadier. I'll create an abp file in data>art>armies>german>soldiers>cin_grenadier and add this:

model =
{
"..\\..\\..\\..\\environment\\objects\\vehicles\\civilian\\civilian_coupe\\civilian_coupe",
"..\\..\\..\\Common\\CompleteMotionTree.abp",
}

As the abp file doesn't reference the grenadier in any way it wont be made for the blueprint. Next I'll change the kubelwagen's abp file.

Show Spoiler

I've added the basemotion line because I need a marker that is centered on 0, 0, 0 to ensure it looks like what I've made in the world builder. You don't have to use basemotion as there's a few other blueprints with 0, 0, 0 markers but since the kubelwagen doesn't have one you'll have to include it.

Instead of using basemotion you can just enter an invalid marker name to have it attach to 0, 0, 0. For example just type in "afaeswgwesg" to the marker.



In the AE I'll clone a blank entity and only add these 3 extensions:

• action_apply_ext
  
• entity_blueprint_ext
  
• sim_entity_ext

As this entity is only visual it doesn't need any more extensions than these.

• action_apply_ext - animator_set_variable to make the car only have the canopy down
  
  • variable_value: 0
  
  
• action_apply_ext - animator_set_state to hide the head and hands made by completemotiontree.abp
  
  • do_action_state_name: on
    
  • state_machine_name: _using_female
  
  
• action_apply_ext - picture above
  
  The last step will kill the attached entity when the kubelwagen dies so it doesn't persist forever in the world. If the entity still persists after the death of the parent entity it's probably because it still exists after that entity is "killed" this is most notable with infantry as their body will linger. Under health_ext set the death_seconds to 0 to remove this problem. The spawned_entity_actions are bugged or something and wont actually apply so we have to put the actions on the entity entry itself.
  
  Use the always_on ability method within a lower post. This method is not consistent.
  
  
  
  Then make these changes for a clone of the kubelwagen:
  
  • combat_ext - delete hardpoints to prevent MG attacks and make the gunner have the correct potision
    
  • crew_ext - delete the driver and change the gunner's bp to armies\civilian\soldiers\partisan_male_01\partisan_male_01
    
  • action_apply_ext - animator_set_state to make the kubelwagen's model invisible
    
    • do_action_state_name: crush
      
    • state_machine_name: damage_state
      
    
    
  • action_apply_ext - picture above
    
  
  
  
  
  
  After all these steps I have a functional car. An issue I've found is that the coupe model will disappear if it enters the screen from below. This might be from it being an environmental object or something that normally shouldn't move.
  
  
  
  
  Because we are able to attach to specific markers the entity can rotate along with the turret or even recoil with the barrel. If you're having trouble with there being a blue occlusion outline under ui_ext of the barrier entity set the occlusion_state to no_occlusion.
  
  If this seems confusing don't worry it's very confusing for me too. If you have any questions just let me know in a reply. A tank example will come later.
  
  I uploaded the test tuning pack to the workshop where you can see how they interact in game. I also made a convoy using repair_station_ext I can make a guide on that if anyone is interested.
  
  Workshop Link Play as Ostheer.