-
#Steam AliasWL%Streak
- 1.279110.717+17
- 2.422.955+12
- 3.29647.863+2
- 4.17999.644+3
- 5.399200.666+8
- 6.20387.700-1
- 7.212115.648+17
- 8.971570.630-4
- 9.459212.684+2
- 10.13589.603-1
Posts: 99 | Subs: 1
Thread: Sov units stuck on map. by halftrack13 Nov 2021, 13:27 PM
That's strange, it works for me. By the way it's the left quote (`) not tilde (~) so you don't need to hold shift for it. |
Thread: Sov units stuck on map. by halftrack13 Nov 2021, 12:35 PM
If you are on Windows you can use the on-screen keyboard although I'm not sure if it's available to you if you're using a Finnish version. |
Thread: Sov units stuck on map. by halftrack13 Nov 2021, 01:36 AM
Why does ~ not work? |
Thread: [Guide] Attaching to Moving Entities7 Nov 2021, 19:40 PM
Additional Team Weapon Crew Info Because team weapon crew is so complex there's bound to be many issues that arise from us doing what the game isn't meant to do. Although it may not be possible to get everything perfect, we can mitigate and fix some of the problems that team weapon crew presents. Hit Points Normally how team weapon tp_mobile works is that the team weapon itself does not have its HP displayed within the squad. Instead the squad HP bar is split evenly between all its members. We can trick the game into making the HP bar behave as a normal entity though. Add a blank team_weapon_ext to all child entities with tp_mobile. You can then just delete health_ext and that will make the child entities invincible. Weapon targeting should be off in type_ext. Squad Count Unfortunately I don't think it's possible to fix this one. Terrain Kick Up If you're dealing with multiple child entities you may have noticed that there's a lot of material that the wheels kick up because of the many stacked entities. To fix this use the above state on child entities. Clean Up Your Extensions Since child entities are purely for visuals you should probably remove everything that isn't necessary. An example would be shot blocking or some similar unintended consequence. Smoother Movement Because there's a movement delay between parent and child you'll have much better results by just making all the visuals as child entities. This comes at the cost of not having any turrets move but we can somewhat get around that which will be explained later. Set the damage_state of the parent to crush or some similar state that hides it. Ensure that the movement_ext as well as the simvis attributes of all entities are the same. If your entities have a hold remove the garrison state action as I believe this interferes with movement somehow. There will still be some desyncs, especially if the unit travels over long distances, but it will be much better than before. Moving Turrets There are 3 ways to have turrets with team weapons, each with certain advantages and disadvantages.
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. |
Thread: UI Categories Discussion3 Nov 2021, 12:23 PM
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. |
Thread: [Guide] Parachuting Animations for More Models29 Oct 2021, 04:16 AM
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. |
Thread: [Guide] Parachuting Animations for More Models27 Oct 2021, 14:44 PM
This guide requires knowledge of abp file editing. It also uses some unused infantry models. 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.
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. para6.abp Code
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. |
Thread: [Guide] Attaching to Moving Entities25 Oct 2021, 16:10 PM
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.
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.
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
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 Panzer III We can make a Panzer III by using the chassis of the Stug and the turret of the Panzer IV f1. environment\objects\vehicles\wrecked_vehicles\stug_iii_frozen armies\west_german\vehicles\panzer_iv_sdkfz_ausf_i In world builder place the stug wreck and a panzer iv.
You can make them in a summer or winter skin.
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. |
Thread: [Guide] Using Sound_Action22 Oct 2021, 10:05 AM
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. speech\mp\soviet\eng\orderconfirmations\ability\sb_eng_abt_203gen_lt_s 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_action can of course be used for many other things other than speech. Hopefully you can find good uses for them. |
Thread: [Guide] Attaching to Moving Entities22 Oct 2021, 09:17 AM
I've done some testing and attached entities are, in fact, able to attack. Both passenger and bulldozer attach types are able to attack. The issue is that their position is not updated. This means that the entity will only be able to attack around where it has been spawned. A workaround would be to have two always_on abilities, one with the attacking entity, the other with a dummy. When the parent entity moves the dummy entity will be used and when it has stopped the attacking entity will be spawned. However, because rotation is also not updated it may lead to the attached entity aiming at a wrong direction. Using garrisoned squads is still the best method of using attacking attached entities. Although you'll be limited to the combat slots it works flawlessly since its a mechanic within the game. You can use the damage_state to hide the parent entity as instructed earlier in the guide and have a child entity attached to 0, 0 for visuals. Because garrisoned squads are a form of attached entity this means that it may be possible to trick other types of attached entities into thinking they are garrisoned, allowing their position to update. I'll have to take a look into this later. Apparently some info about disabling unloading and decorators is wrong so I'll update that information at a later date. |