I noticed when playing around with model stacking that the long coat will have its texture stolen by another model. In the picture I have both winter volksgrenadiers and sappers in the abp but the sapper texture overrides the volksgren's for the coat. This could lead to some interesting combinations. I also believe that this works for some things other than the coats as well.
Code
model = { "..\\..\\..\\common\\NewMotionTree.abp", "..\\..\\..\\west_german\\soldiers\\volksgrenadier\\volksgrenadier", "..\\..\\..\\british\\soldiers\\engineer\\engineer", }
Note that the abp only contains relevant blueprints so you'll have to add weapons and other stuff. I'm also unsure what causes the priority of textures as putting the sapper blueprint above the volkgren's still results in the sapper texture override.
Unfortunately there's not many applications for this until we learn what the exact circumstances are required to swap textures. Maybe someone else has more insight into this.
Code
model = { "..\\..\\..\\common\\NewMotionTree.abp", "..\\..\\..\\aef\\soldiers\\assault_engineer\\assault_engineer", "..\\..\\..\\aef\\soldiers\\mortar_crew\\mortar_crew", }
You can open mua files with notepad or any similar program. The marker that you should use will be within the quotation marks after name =. If you open up the rifle_m1_carbine.mua file it will look like this:
In order for tracers to work properly the weapon needs 3 things:
anim_table>visibility_name
fx_action_target_name
fx_tracer_name
However, as the fx_tracer_name says in the description, tracers are only useful for bullet (i.e. non-projectile) weapons.
The reason why the projectile comes from the ground is because the projectile_ext>launcher_marker is incorrect. When the game has an invalid marker it will always default to the 0,0,0 coordinates on the entity.
The default launcher_marker for the canister shot is fx_muzzle_maingun which an infantry unit lacks. Since you're using the svt40 try replacing it with "marker_svt40_muzzle". For future reference you can look up the mua files in the archive viewer.
Thanks for the reply. I've done some tests and whilst they do look promising the AI doesn't seem to want to use the ability if its not within the range of the ability itself regardless of what tactic_max_override I set. I'm probably doing something wrong though.
For future reference this is what I've been using so far as an always_on ability. The scar function orders the units towards whatever enemy is within the radius. The main issue is that the AI will order stop in most situations which ends up making the zombies inch towards whatever their target is.
The summer skin is unfinished but the winter skin works just fine. To override the skin to show winter on any map go to ebps>ui.
skin_pack_override: True
skin_summer: winter
skin_winter: winter
soviet\soldiers\isakovich
You will need to create an abp file to add the completemotiontree.abp which will allow animations for this blueprint.
I could not get any of the Pozarsky blueprints to work. Anyone have any luck with it?
Yes, it's possible. The method Dar mentioned would work although the offset issue is present. If you're interested in making a tank using the Stug or Panzer IV chassis there's environment wrecks for them. You can remove the turrets by changing the tank type state. Two issues would be that they are of lower detail than actual tanks and that the treads will not move but if your mod is played at lower zoom this shouldn't be much of a problem.
My friend has mentioned that attached entities can't attack although I haven't gotten around to testing that just yet. In theory it should be possible, at least on the combat slots since natively that's what infantry do when they garrison a vehicle. I'll investigate this as well as finish up the guide at a later date.
Under attribute editor>ebps>ui_ext there will be skin_summer/skin_winter. If left blank the map type will dictate the skin, if you put "summer" or "winter" and set skin_pack_override to true this will force the different skin type.
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.
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.
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.
The searchlight model is unique in that it allows for 360 degree rotation on both the x and y axes which lets us rotate an entity in every angle possible. It's also possible rotate using other models although these are usually restricted in degrees, notably the x axis.
A horse viewed in the world builder. The goal of this example would be to make the horse upright.
The first thing to do is open up world builder and place down the searchlight. The rotate and hinge variables above are what we are interested in. Although this step isn't strictly necessary, using world builder is useful for finding rotation values.
The rotate variable rotates along the y axis. Values are -180 to 180.
The hinge variable rotates along the x axis. Values are -1 to 1. Divide 1 by 180 to get degrees.
Next we create dummy blueprints, one for the searchlight (parent) and another for the horse (child). Since we want to rotate on both axes we will use attach_bulldozer and thus the barricade blueprint. Passenger_attach will only allow rotation of the y axis and not the x axis.
(parent) cin_ostruppen.abp
model =
{
"..\\..\\..\\..\\environment\\objects\\defenses\\metal\\searchlight_l_01\\searchlight_l_01",
}
(child) ostruppen_winter.abp
model =
{
"..\\..\\..\\..\\environment\\nature\\animals\\dead_horse_01\\dead_horse_01",
"..\\..\\..\\..\\environment\\objects\\barricades\\barricade_dirt\\barricade_dirt",
}
In the searchlight_l_01.mua the relevant marker we want is "marker_light_flare_00" as this is directly on the light. Some other markers would work as well but damage markers usually have non-centered positions, weird rotations, and are only on the 'main body' of the model.
These are the relevant actions for the parent entity. The variables are all set to the default values with the exception of hinge which is normally 0.138. The spawn_entity action is through an ability which will be explained later in the post.
This is what it looks like in-game. The entity is facing towards us. Apparently this marker (along with most markers) rotates the z axis by 180 degrees. Aside from needing to change the rotation of the searchlight there are a few other problems we need to solve. The visibility of the searchlight itself, the decorator position, and the offset that occurs because the horse isn't centered on 0, 0.
Because the horse is upside down I'll make the hinge rotate by 180 degrees or a variable value of 1. Then it will rotate 90 degrees clockwise with the rotate variable.
Initially I thought that the health variable would work well to hide the model. And although it serves this purpose, it also removes the rotate axis presumably because the marker is considered destroyed or something.
To offset the decorator go to ui_ext>decorator_offset. Decorator positions are markers which are labeled marker_fx_ui in the mua files. Since many environmental objects lack these markers we will have to change it manually. I set the offset to 4 for this example. Although we don't actually need a decorator for this example this is useful to learn.
I offset the blueprint using the vehicle render offsets mentioned in the first post. Render offsets are a bit of trial and error. Since the values are measured in meters it's easy to gauge the general distance that something would need to be offset but you'll probably end up having to do a few trials to fine-tune things.
And here is what it looks like in-game it's facing towards the bottom right. The decorator, offset centering, and rotation all look good. Unfortunately the searchlight itself isn't ideal as it can't be hidden.
The next logical step would be to attach an entity to an attached entity which, in theory, will let us get full rotation. Unfortunately whilst this does "work" it's buggy visually and is not practical. If the attached entity flickers between its spawn location and has a position delay this is why.
When the parent entity dies the child entity will preserve its rotation, presumably because it still thinks it's attached because we didn't add a detach action. This means that whilst it isn't practical for moving entities, it will be good for static ones like buildings. For this example ensure that the make_dead action has destroy set to true to prevent the health variable from reaching 0.
Rotating Moving Entities
This system may not be consistent as the event will sometimes reset the variables to the default values. I'll investigate the bug later.
Because the searchlight blueprint is still visible the number of practical applications for it are slim. However, I was able to get around this with a few additional steps although it still comes with some caveats which will be explained upon later.
So the question is how do we hide the searchlight if it doesn't have any invisible states? Well the answer is we don't. Instead we are going to detach the searchlight model from the entity itself. The death_upperbody event is unique in that it will detach the model but also not interfere with any of the markers. Because the searchlight doesn't have this event we will have to edit the abp and add basemotion.
cin_grenadier.abp
model =
{
"..\\..\\..\\..\\environment\\objects\\vehicles\\civilian\\civilian_coupe\\civilian_coupe",
"..\\..\\..\\Common\\base\\basemotion\\basemotion",
}
Next we will add actions on top of what we already have from earlier in the post.
Delay
In order for the detachment to work correctly it needs a delay. I don't know why, maybe something to do with fx_lamp_warm_up_00.
Animator_set_event: death_upperbody
If you use this event in world builder on an infantry unit you'll notice it ragdoll. The same applies to the searchlight but without a skeleton, it will just remain stationary. In both cases it will detach from its entity which is what we want.
Animator_set_state: timeofday
This is important for night maps as there will be a beam of light. Setting the state to day will turn off the light.
Animator_set_state: _using_female
This is to hide the head and hands of basemotion.
This is what it looks like in-game after the actions are applied. The searchlight is detached near the HQ and the horse can freely move around without it. These will despawn around 4 minutes after detachment. I'm not sure if there's a way to make this shorter. As you can see the decorator is too high. This is because basemotion has its own marker_fx_ui of 4 which on top of the 4 we put on earlier becomes 8.
An optional step would be to add a variable to health and set it to 0. This will make the searchlight into debris and also trigger the death explosion of the searchlight so it doesn't happen when the entity dies. Why this doesn't reset the rotate axis I have no idea.
Alternative Method of Removing Attached Entities
The method in the previous post isn't consistent and I'm not sure why. This new method will remove entities with a 100% success rate. It utilizes an ability to spawn the entity and since abilities are removed on death the same will apply to the child entity.
Clone the blank_ability_slot
Set the activation to always_on
Under start_self_actions make a spawn_entity action
Follow the template image above
Note that the duration cannot be 0 and permanent must be false.
Relic Entertainment
cblanco ★ 
보드카 중대 
VonManteuffel 
Heartless Jäger 
