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. In order for an entity or blueprint to attach, it must meet these requirements:
This points to the parent entity and dictates the type of target. Entity attaching (garrison and dozer) is always "target". Vehicle crew uses vehicle_target. Weapon teams depend on what kind of weapon they use.
This points to a marker on the parent entity. Garrisons will always attach to combat slots. Crew will attach depending on their attach action.
This is the marker of the child entity. Entity attaching will always point to 0, 0. Crew will always use skeletons i.e. metarig_pelvis.
This is the action that tells the child to attach to the parent. This must have a compatible visual_target.
So what does skeleton_attach do exactly? It attaches the entity or blueprint at 0, 0 on the parent entity then attaches the skeleton of the infantry to a specific point. 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 team weapon crews have all other models in the abp other than the infantry set to invisible while they are part of a crew.
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.
Desants and Gunners Additional_crew_option Vehicle Crew Applications Team Weapon Crew Applications
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.
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
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.
Next we will add actions on top of what we already have from earlier in the post.
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.
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.
This is important for night maps as there will be a beam of light. Setting the state to day will turn off the light.
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.
You will be able to attach vehicles to vehicles with a new system I'm working on. What you're describing is possible. The stug can already support an MG mount. But you will be able to add MG mounts to other things if you can find a way to make everything but the MG mount invisible for the blueprint.
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.
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:
But if you wanted to reference the sergeant for a grenadier's abp file it would be:
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.
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.
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.
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.
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.
To hide the decorator for the garrisoned unit go to squad_ui_ext in sbps and set the decoratable to false. 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_m12 = z axis
transform_m21 = z axis
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.
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:
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:
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.
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:
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
action_apply_ext - animator_set_state to hide the head and hands made by completemotiontree.abp
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.
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
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.