https://steamproxy.com/sharedfiles/filedetails/?id=2131057232
https://steamproxy.com/sharedfiles/filedetails/?id=2131058270
https://steamproxy.com/sharedfiles/filedetails/?id=2257255110

Arctic's Customizable Weapons is a new weapon base with focus on strong customization and high performance. It is new and actively being supported by a team of talented content creators (such as me!), and if you're looking to start your own modding journey this is the best choice.

https://steamproxy.com/sharedfiles/filedetails/?id=2131161276
I am the creator of the ArcCW Extras pack, and through developing for this base learned a whole suite of new skills. Now, I wish to share it to you so that you can do the same.

If you want further help, join the official discord server![discord.gg]

You are likely intimately familiar with TFA, CW 2.0, or both. While ArcCW is a very recent creation, it boasts many customization features that neither can offer - this means less work for the modder, and more options and more fun for the player.

Instead of manually defining the position of every single attachment on every gun, you define one (two for sliding) spot on a gun, and every attachment simply goes onto that spot.

For optics, you do not need to adjust the aim - the base will auto-calculate the sight position from ironsight. You can add alternative aiming positions (like backup optics), variable zoom or even thermal vision to your sight with just a few variables.

Underbarrel attachments, like foregrips and underbarrel weapons, are also easy to make and use. The LHIK system rigs the left hand to animations on the attachment, so any gun can have any foregrip and UBGL, and it will all blend in perfectly with reload animations.

The AttachmentElements system allows for easily changing the name, bodygroup, skin and position definitions of a weapon with ease. If that's not enough, you can write hooks to dynamically change every variable and aspect of the weapon.

Attachments have gameplay consequences too, which makes this choice meaningful. A short-barrel weapon with no stock will handle fast but have lots of recoil, while foregrips and stock options allows for stable shooting. The possibilities are much more varied than the single-digit amount of attachment options you see on most TFA and CW2 weapons.

The attachment system is also the best of all worlds. In TFA, all attachments are always free, in CW2 you pick up one attachment to unlock it. With ArcCW, you have an inventory system where one attachment goes on one gun, but you also can switch to the other two modes on the fly. It is incredibly easy to code external systems to unlock or otherwise grant attachments, too.

These seemingly trivial but innovative systems allow every gun to support hundreds of attachments with minimal effort. With this many attachments, players are given an unprecedented amount of freedom to adjust their gun to their liking.

Lastly and most importantly, ArcCW is alive and being actively developed and maintained by Arctic and other contributors. Bugs are being fixed and new features are being pushed on a daily basis. We encourage you to join the discord server to keep in touch with development and other modders creating content.

A worker is nothing without their tools. Depending on what you want to do, you need some, or all of the following software.

For the sake of this guide, I will not cover stuff related to Lua scripting and the process of creating a Workshop addon. Please refer to the GMod wiki for these commonly dealt witih topics.

https://steamproxy.com/sharedfiles/filedetails/?id=109724869
SCK is very useful for positioning attachments and ironsights.

Lua is plaintext, which means technically you can write it with as little as Notepad. However, a good text editor can drastically improve your coding efficiency, catch syntax errors, and help you develop good coding practices with linting.


For these reasons, there is no other choice but Visual Studio Code[code.visualstudio.com]. It has plugins for syntax highlighting and automatic linting, two of the most important features that speed up coding several times.

To install VSCode, head to the website to download and run the installer. Once done, you will want to install the plugins. Do this by clicking the Extensions tab (it looks like 4 boxes) on the left, and search for "glua". You want two addons, glua and vscode-glualint.
The other plugins are untested, so use at your own discretion.

glua should work out of the box, but you will have to manually download the linter exe file, place it somewhere, and set a PATH variable to the folder containing the exe. In my case, I put it in D:/_GMod (It is a good idea to dedicate a folder to your custom stuff!).

Find the latest glualint download here.[github.com]

If you're still confused, look up "Setting up PATH variable" on google.

You can configure glualint further, but for the sake of brevity the default settings should suffice. At this point, you can open a .lua file, and the editor should recognize it as a GLua file and show the appropriate highlighting.


Crowbar is a multiuse tool for dealing with Source engine content. You can unpack .gma and .vpk files, decompile and compile models, and even publish addons with it, like a Swiss army knife! There is no reason not to get it.


Get Crowbar here!

Crowbar is a single executable file (recommended to place in a dedicated gmod folder, same with the linter). It should automatically configure itself; if not, go to the "Set Up Games" tab and set the directories.


Blender is a free modelling and animation tool. If you are looking to modify models and animations, this is your best bet.

Download Blender here.[www.blender.org] After that, download Blender Source Tools here and follow the instructions on that page.

The GMod Rig I use is found here.[gamebanana.com]

I will assume you have at least a tiny bit of familiarity with Blender. If you can't catch up, try watching a few tutorials for it.

Let us start with the easy part. Let us assume you already found an ideal viewmodel and worldmodel, textured and animated, and only want to set it up for ArcCW - likely the case when you are porting an SWEP from some other base.

The base has lots of documentation for each and every variable, and the CS+ pack is a great template to kickstart your weapon. Unpack these with Crowbar and put it somewhere in your working folder.

You can either use {LENKE FJERNET}https://steamworkshopdownloader.io/, or find the addon at Steam\steamapps\workshop\content\4000\2131058270\temp.gma. Replace the number with 2131057232 for the base.

The two most useful files in the base is lua/weapons/arccw_base/shared.lua and lua/arccw/shared/attachments/default.lua. They contain all the variables used by the base and are well documented.

Start by copying a weapon lua file that is most similar to the gun you have. I am using the M1911 as an example, so I went with the USP. Put it in GarrysMod\garrysmod\addons\[Addon Name]\lua\weapons.

Please don't name the addon or file something stupid! By convention, you should use the [ArcCW] or ArcCW prefix on addons, and arccw_ on weapons. In my case, since the weapon is part of a pack, I will name it "arccw_dod_m1911".

Let us start from the top. I will not include every line - this below is only important information that you should absolutely change.

I repeat, do not simply copy all the snippets below! Copy an existing weapon file and edit that! I am omitting variables here!


So far so good, but what's coming up is the meat of the file.


It is possible to set DamageMin larger than Damage, recommended for long range rifles and snipers. When this happens, attachments that increase range will decrease it and vice versa.

One meter is approximately 39.3 Hammer Units.


If your gun can't hold an extra round in its chamber (revolvers, open bolt weapons), set ChamberSize to 0.

ExtendedClipSize and ReducedClipSize is used by ammo type attachments. Attachments that reduce clip size are usually stronger, so balance accordingly.


Firemodes is fairly interesting. For simple setup, 0 is safety, 1 is semi, 2 is automatic, and a negative number is burst count (-3 means a 3-burst). You can even include stat multipliers in here (more on that later).


10 MOA is approximately 0.00925 degrees.

It is most likely at this point that you still have no animations on the weapon. This is because ArcCW needs an animation list defined for each action.

The SWEP.Animations table holds all animations. Each entry in this table is an "animation" the base recognizes, but the actual data containing the animation is in a model sequence. Multiple animations can use the same sequence with different settings.

To get a list of viewmodel sequences you can use, type arccw_listvmanims into console. This will give you a list of strings, each being the name for a sequence. Generally you can tell what each one does.



Scroll to the very bottom and find SWEP.Animations. This is the table all animations go in. An animation definition would look like this (this one is for the ak47):


The string key should be one of the names provided to you by the base. The only necessary ones are Source, the string you see in the console, and Time, the duration of the animation.

The animations you should absolutely have are "draw", "fire" and "reload". There is, however, a long list you can use, the most important ones listed below:

• idle and idle_empty
  
• ready - First-time deploy
  
• draw
  
• holster
  
• reload and reload_empty
  
• fire, fire_iron, and fire_empty
  
• cycle - Manual action guns play this to pump/bolt
  
• bash - Replaces procedural bash
  
• sgreload_start, sgreload_insert, and sgreload_finish - Shotgun reloading

Each animation can append "_empty" to denote an animation played when empty/on last shot.
You can leave idle out, and the animation will simply stop at the last frame. This is useful if you have a fire_last animation but not an idle_empty one.
Shotguns use 3 (or more) animations to start, insert and finish reloading - see the next part for details.

There are also additional variables you can use (the full list is in arccw_base/shared.lua):

• TPAnim - plays a thirdperson animation
  
• TPAnimStartTime - start the thirdperson animation midway
  
• Checkpoints - time checkpoints, in frames. Segment a reload with this and it will continue where left off if switched away.
  
• Framerate - set this alongside Checkpoints. If you don't know the framerate, check the qc file after decompiling the model.
  
• ShellEjectAt - eject a shell at this time, in seconds
  
• LHIK - If set to true, foregrip animations will be temporarily disabled (useful for reloads).
  
• LHIKIn/LHIKOut - The time to ease in/out of non-LHIK animation in seconds.

A special note for converting from TFA
When converting a model from TFA to ArcCW, take note to include the Time variable for reload animations. The corresponding value is usually in SWEP.SequenceLengthOverride.

If you're working on a pistol, make sure to use _empty animations to make the slide lock back properly. For manual action guns, remember to add "cycle", and for single-shell loading guns, "sgreload_start", "sgreload_insert", and "sgreload_finish".

At this point, you should be able to use the gun normally, but the ironsights may be off. Let us fix that right now.


Spawn SCK, right click, and set the model.



Go to the Ironsights tab, then drag the viewmodel and adjust angles until it points at the center of the screen. Finally, click "Print ironsights code to console".



Be careful! SCK gives both in Vector, but IronSightStruct takes a Vector and a Angle! The values are the same however, so just put the values in.



What if you want to do a gun that has its own sight, you ask? The best solution is to make an attachment out of that sight! This will be covered in a later scenario. If you don't want to do that for whatever reason, check the base shared file for variables you can use.

As for holdtypes, the GMod Wiki has a list of holdtypes you can use.

You can also set SWEP.CustomizePos and SWEP.CustomizeAng if they are not positioned well, in the same format as above.

Time to add attachments to your gun - the fun part! Unlike CW2.0 and TFA, you will only need to define one position (2 for sliding attachments) instead of one position per weapon. This allows you to dramatically improve customizability with very little effort.

The process is similar with those weapon bases though. Take out SCK, go to View Models, create an element, and set its model to any attachment in the category.



Set its bone, position and angle, Print to Console, then use the relevant values in the table (the other aren't necessary). Remember to rename pos and ang to vpos and vang in Offset!



Repeat the same process for worldmodels. You can use "Import Viewmodels" to quickly get the model you've set up earlier, but the position won't be correct.



Et volia - attachments!



Let's take a look at more advanced functionality. Below are 3 attachment slots for the AK47. One of them uses a custom element, and one of them is sliding.

Some weapons like the AK47 needs an extra mount for optics and things. You can accomplish this with AttachmentElements. This is also where you define bodygroups for attachments like extended magazines. The syntax in each VMElement/WMElement is identical to attachments.


Slidable attachments are even easier. Just define SlideAmount, which takes two vectors for viewmodel and two for worldmodel. Note that it overwrites Offset's position but uses its angles.

There's a few extras things you can do with attachment slots.



If your weapon has special behavior regarding attachment dependencies, you can use the flag system. Use GivesFlags to make a slot grant a flag, RequiresFlags to make a slot invalid unless the flags exist, and vice versa with ExcludeFlags. These are all tables, and any attachment is their own flag.

You can create hidden slots to merge into another slot. This is usually necessary if you have an attachment type that needs its own Offset, Flags or AttachmentElements. This example is used by my USP Match, which has a compensator that blocks underbarrel except pistol styles (cowboy style).

You can add most attachment stat multipliers and overrides in AttachmentElements. The CS+ pack uses it to rename weapons with specific attachments; while my Extras pack use it to apply stat changes when removing an integrated foregrip.
Note that an attachment will automatically apply an element with its name as the key.

At this point, your weapon should be fully functional - congratulations! But there are some additional things you can do to spice your weapon up even further, depending on what kind of gun it is.

Despite its name, shotgun reloading simply means "per-round insertion". To make your weapon reload one round at a time, set the following:

Make full advantage of TPAnimStartTime to make it look like your character is actually inserting shells to others! _empty suffixes also work - sgreload_start_empty has special behavior where it loads one round in, useful for semi-automatic shotguns (the AS-1217/M1014 uses this).

If your weapon has visible single bullets during reloading (such as revolvers), you can make the bullets act according to the magazine condition - if you only load one bullet in, one will be visible; if you eject 3 shells and 3 bullets, that will be visible too! Do the following code:

Note that this requires each bullet and case to have its own bone. If there is none, you can probably hack it in (as will be explained in a later scenario).

Presentation is everything when it comes to good addons. Having entity icons makes it easy to tell your weapon apart at a glance, while killicons enhance the experience of seeing people get killed by your gun.

Going by the CS+ pack conventions, spawn icons is just the weapon in the customize menu. Walk into the whiteroom in gm_construct, color it a distinct color (like green), take out the gun and press F5 to screenshot. If any of the HUD elements is blocking your gun, set cl_drawhud 0 and arccw_atts_inspectonly 1.


Here is my Galil 7.62. You don't have to remove the HUD unless it is obstructing the gun.

Next, open your image editor of choice and remove the white (and UI elements). I use Photoshop, and Magic Eraser is probably the easiest option here.


Lastly, create a new file with size 256x256 (or 512x512), copy your weapon over, and adjust its position. Remember that the bottom bit is blocked by the weapon name, and there is a frame to the sides! Don't place the gun too low or too close to the edges.


Save that file as addons/[Your Addon]/materials/entities/weapon_name.png. Reload your game and it should be there! Adjust as needed - materials hotload and refreshing is not necessary.

This one is slightly more complicated, but the process is similar. Take a screenshot of the side of your weapon pointing right. Put that screenshot in an image editor and remove the background.


Put it in a 256x128 canvas. Going by ArcCW conventions, you should give it a White Color Overlay and Black Outer Glow.

Save it as a .png or .tga file in materials\arccw\weaponicons, but that's not the end of it. Select and kill icons only accept .vtf files!

Open VTFEdit and import your file with default settings (Normal format DXT1, Alpha format DXT5). Save it in the same directory, but name it the class name of your weapon.


Create a .vmt file of the same name. In it should be the following:

And now we're done. ArcCW will handle the rest, and your weapon icon will show up whenever you kill something, as well as in your weapon selection HUD.

Sometimes the model isn't going to work out of the box. This might be because it is a CSS replacer and has the same model as another weapon, or that there's a scope on the gun you want gone.

"Hexing" is the practice of recompiling a model to use a different model and texture path, usually so that a model can exist alongside the model that it's supposed to replace. You can of course make further changes to the model in the process by changing the .smd files.

First, find the model you want to decompile. Each model comes with several files, but the relevant one is the .mdl (you still need the rest though).


If you have setup Crowbar as a file format like me, simply double click the .mdl file; otherwise path to it in Crowbar. Default settings should work fine, but I recommend ticking "Folder for each model", as it is easier to organize.



After decompiling, go to the decompiled folder. You should see a .qc file, a folder for animations, and one or more .smd files.


Open the .qc file with a text editor. You should see the following:

The only lines you need to change right now are the $modelname and $cdmaterials lines. The former tells Crowbar where to put the compiled model files, and the latter tells the model where to look for its materials. Note that it is only a path - which material in particular is defined by the .smd files.

For convention's sake, we recommend the path weapons\arccw\c_weapon_name.mdl (v_ for models with no c-hand support), and material directory weapons\arccw\weapon_name\.

Now, we should actually move the materials to the place we promised it will be - otherwise you will get missing textures!


This alone isn't enough, however. The .vmt files are what the model actually looks for, and they are text files that point to one or more .vtf files (the actual textures). Right now, the .vmt files still are looking for the old path, and it will give you missing textures.

Open up all the .vmt files. An editor like Notepad++ or VSCode is great here because they have multiple tabs. Replace the old directory with your new directory - Use "Replace All in All Open Documents" or do it one by one.


Save the .vmt files and close them. The texture part is done. You can go ahead and compile the file now, and it should show up in your game after a restart.

Unfortunately, CSS hands do not abide by the c-hand system, and you will not be able to use LHIK attachments (foregrips, ubgls) with this weapon. Converting is difficult, but will be covered in a later scenario.

Run the console command r_flushlod to refresh a model after compiling. This works if the model is already loaded by the game; otherwise use console command reload to load it.

Physics meshes do not like to be refreshed this way. To avoid excessive restarting, use the "View" tab in Crowbar to open HLMV, then Physics -> Highlight to see your physics mesh.

If the weapon has custom sounds for reloading and drawing, you will have to hex those as well. The $sequences in a .qc file can embed "soundscripts", a string that is a predefined sound. It would look something like this - note event 5004.
This example already has unique soundscripts, but CSS weapons might not. By convention, you should change the part of the string before the period to something like "ArcCW_Vector", and the second half to the sound name.

After that, you need to actually define the soundscripts. You can do so in Lua like this:
You can change stuff like pitch and sound level here. https://wiki.facepunch.com/gmod/sound.Add has more details.

Sometimes a model needs a bit of touch-up to work. If you have Blender, this is within the realm of possibility!

Open Blender, and go to File -> Import -> Source Engine. (If you don't have this, install Blender Source Tools.)


Here's our Vector, but it's not ready yet.

Blender has different "modes" that determines what it does currently. The default is Object mode, where you can drag objects around and stuff, but we want to edit vertices.
Click on the imported object to select it (make sure it has a white box surrounding the triangle icon), and switch to Edit Mode on the top left.

You should be seeing all the vertices and edges on the weapon now. If not, double check your mode and selected object.


Let's say we want to remove that embedded EOTech on the top (we will be attaching our own, after all!). Click on any one vertex on that part, then Select -> Select Linked -> Linked or Ctrl+L.


You will select everything connected to that vertex. In this case the part is made up of several disconnected vertices, so hold Shift and keep doing the same to select everything, then Right Click -> Delete Vertices. Clean shaven!


Now let's take a look at the ironsights. We want the ironsights to stay on by default, but removed when an optic is attached - this is what bodygroups are for.

Do the same step and select all parts of the ironsights, and Right Click -> Separate -> Selection.


You should see a new object with a .001 suffix. Rename it and create a new collection for it.


Blender Source Tools will treat each collection (or each object without a collection) as its own .smd file to export. Speaking of exporting, you should go to Scene Properties (lower left) and setup export options. Point the two paths to your qc file directory, and the engine bin folder. If you have something you don't want to export, untick it below.


Now you can export it and have them each as their own .smd file. Do the following in your .qc file to setup a bodygroup, using "blank" to indicate you want a choice to be nothing.

Sometimes the bones come out with no parenting, and sometimes you want to remove the CSS hand bones. It's quite simple! Go back to Object mode, select the skeleton and go into Edit mode again.


To edit a bone, click on it in the right tab and go to Bone Properties in the lower right. You can change the position (There's a head and tail, but you should just move them around together as BST treats them as one point), as well as adding a parent to it. Here we choose to parent the trigger to the body.


Let's also remove the CSS bones to prepare for reanimating the whole thing. Select the parent bone, press Shift+G -> Children to select all children, then Right Click -> Delete Selected Bone(s). Do it for each hand.


Some weapons are missing bones for things that should be moving. You can add a new bone and assign the relevant vertices to them. For the sake of example, let's add a bone for the firemode selector.

To do so, stay in Edit mode and Add -> Single Bone. Set its name and parent, then move it into position.


We're not done yet however, as the model hasn't specified which vertices should move alongside this bone. This is done using Vertex Groups.

Go back to Edit mode on the object, and select the relevant vertices. Go to Object Data Properties, and create a new Vertex Group with name identical to the bone. Click Assign, making sure weight is at one.


But also remember to remove the assignment of body, or the model will tear! Select "body" and click Remove. Now the bone should work - to verify, select the skeleton, go into Pose mode and rotate the bone around.


Note! If you make changes to a bone, you have to remove all $definebone lines generated by Crowbar in the .qc file. If none exist, Crowbar will automatically generate them when it compiles; but if there are any definebone lines it will not do so.

Also note that bones without assigned vertices, as well as bones that don't move at all, may be collapsed by Crowbar during compilation. To prevent this, add a $bonemerge line for that bone, or add a sequence where the bone moves.

You may have noticed at this point that the model is flipped. That is because CSS flips its viewmodels by default (whyyyyy), so we will have to flip it manually.

Select the skeleton and set its X Scale to -1. Press Ctrl+A -> Apply All Transforms. Select all objects and do the same. Note that if you had any animations before, they are likely ♥♥♥♥♥♥ by this process.

There are some special considerations you need to make for worldmodels, but the principles are similar. The best practice is to have one Hand bone to bonemerge to. Use an existing CSS worldmodel for the hand position, then import your weapon onto it.

Remember to delete extra bones, set vertex groups of your weapon to the hand bone, and re-origin the object to zero.

You may need to assign attachments for muzzle flash and shell ejection. Follow the CSS examples and reposition them to match - remember to use r_flushlod for quick refreshing

Sometimes the model will be rotated wrong. Simply rotate it (usually 90 degrees on Z axis) and compile again. Note that you can't refresh physics meshes this way - to avoid restarting a lot, use HLMV to see the physics mesh before starting the game (refer to the part above).


Ensure that the idle pose is the first sequence of your file. ArcCW needs this to auto-solve sight positions, and if you don't do so your sights will be ♥♥♥♥♥♥. If the issue persists, try removing $bbox and $cbox definitions, as they aren't useful.

If you've added new faces or stretched existing ones, you may realize that they are missing textures or have stretched textures. To fix this, we will have to get into UV mapping.

UV mapping is the process of assigning faces to a 2D texture. This obviously means that you need the texture itself to work with. Simply grab whatever textures the weapon uses, export it to .png or .tga, and put it somewhere you know. If you have multiple textures, you likely need them all.

Open your file in Blender, and go to the UV Editing tab on the top. If you don't have one, you can add it as a preset. Click the top bar's folder button and look for the png file.


You should see the UV on the left, but not have any textures on the right still. To fix that, you need to assign the same image to the material. Find the material, click Use Nodes, then click on the little dot to the right of Base Color and select Image Texture. Click the image icon and look for the texture you just imported.


If it's applied and you don't see the textures, select Viewport Shading on the top right (it's the third sphere-like button).

Next, go into Edit mode on the object which has the faces you want to edit. Select Face Select next to the Edit mode button, and select the faces you want to edit. You should see the UV file on the left showing the faces.


Drag the points around, scale them, and rotate until desired. If you need to regenerate a new UV, Right Click -> Unwrap or use one of the projection options. For the Tommy Gun, I had to be creative with the UVs to create a stick mag, even when there is no dedicated texture for it.

Because of ArcCW's universal approach to attachments, making one attachment will make it available to every weapon. This makes new attachments much more exciting in terms of opportunity, which is also why you should learn to make one!

Each attachment is a .lua file located in addons/[addon_name]/lua/arccw/shared/attachments/. The file name determines the internal class name.

We will start with a model-less attachment, like a grip.


The icon should ideally be a transparent .png file in the format of entities/acwatt_attachmentname.png. ArcCW will automatically read that as the entity icon for droppable entities.


You can write your own pro/con text here, but AutoStats can generate most stat-based changes. They should be a table of strings, each entry taking up one line.


The slot determines which slot this attachment belongs to. This can either be a string, or a table of strings (if it can go in multiple slots).

Most variables you want to change can be found listed at ArcCW_Base/lua/arccw/shared/attachments/default.lua. Generally they are in the format of Override_Variable or Mult_Variable. There are also hooks, which are lua functions used for advanced functionality.

att.ActivateElements can be used to activate AttachmentElements in a weapon. If there is none, it will do nothing. This is used by ammo types that extend or reduce magazine size, remove integrated foregrips etc.

Simple, right? Here are some more example behaviors to get your creative spark going.

Most FCG attachments override the firemode to do their own thing. Here is Hyper-Burst - note here that you can also add firemode-specific multipliers and overrides!

These two hooks are commonly used to do things when you shoot a bullet or when you hit someone. Note that all hooks provide two variables, wep (the weapon itself) and data (a variable or a table, depending on hook).

Charms are decorative attachments that is made up of a charm base model and any arbitrary model. You simply have to set the position, scale and angle of said model.
Note the attachment model is the charm base, and the CharmModel is the model itself.

Once you've gotten comfortable with compiling and decompiling models, you can get into making new modelled attachments for guns.

These are the simplest type of attachments, model-wise. All it needs is one model, no bones or advanced configuration needed.

Start by decompiling an existing muzzle attachment from the CS+ pack. Open Blender and import the .smd file.


Next, paste your own model (remember to remove any extra skeletons if you pasted it from somewhere else). Align it to be the same place as the original attachment.


Apply the transform by pressing Ctrl+A -> All Transforms. Then, in Object Mode, Object -> Set Origin -> Origin to 3D Cursor. If you accidently moved the 3D cursor elsewhere, bring up the little tab on the right, go to View -> 3D Cursor and reset it.


That's it - export and rejoice! Note that the model will automatically be used as attachment entities, and as such you need a collision model for it. Crowbar will automatically generate a collision mesh as long as you provide a non-collisionmesh .smd file in the $collisionmodel argument.

Foregrips utilize LHIK (Left Hand Inverse Kinematics), a fancy way of saying the attachment has its own bones used to bonemerge the left hand with. This is to say, the model has baked in bones for the hands.

Import a Foregrip as well as its animations. You should also import a hand model to see the animations clearly (but don't include it in the model!).


You can place your own foregrip where the existing one is, or change the animations to hold it better. That's pretty much it!

In the attachment file, you will need to set the following to enable LHIK:

While seemingly very complex, they use the same LHIK system as foregrips, just with some extra animations and code behavior. If you want to create one, follow the existing examples.

They have an extra bone (usually "laser") to determine where the laser comes out from. You will need to specify a few lines in your attachment for them:

These are a bit trickier. Each optic consists of two models, the scope itself and the holosight picture. The HSP should be a cut-out piece of surface to see through with, and be present in both models.


There are some extra variables associated with optics as well, which should be self-explanatory:

You should keep the origins of all objects at the global origin (0, 0, 0) at all times.

For attachment icons, you can go into Isometric mode in Blender, set Shading to Flat (click dropdown next to the spheres in top right of view), then take a screenshot. Remove the background, color it white and add black outer glow.

Yes yes, there's no way around it. If you want c-hands for CSS weapons, you will have to reanimate it by hand. On the bright side, a lot of these animations are not that pretty and also made by hobbyists like us, so there's no real loss.

B-but 8Z, I've seen people port guns from games like COD to c-hands!
In order for animations in another game to be transferred to GMod, a .qci file is required. This file contains information that reassigns the rigs on the model to the GMod rig. These .qci files differ from game to game, and making one is beyond the scope of this tutorial (and my abilities).

If you wish to port content from a different game, look around to see if such a thing exists. Select communities may be incredibly guarding of their secrets, but our discord still has a small selection that you may be able to make use of.

Before putting the rig in, you should make sure to delete the CSS hands and bones, flip the viewmodel, and scale it accordingly. Remember to Ctrl+A -> Apply All Transformations.

Import the rig by going to File -> Append, browsing to the .blend file of the rig, and finding the arms in the Objects folder. Generally you should use the citizen arms and hands (they are two objects).

Once you import them, move all relevant objects except the new skeleton to a separate collection (usually the one housing the Camera). Select the two skeletons (the gmod rig first and the original rig second), then Object -> Join. If you have done so correctly, the rig skeleton should disappear, its bones merged into the gun skeleton.

Select the two arm objects, go to the Modifier tab, and set the Armature object to the new skeleton. This rigs the vertices back up.

Set up the camera. Reset its position and rotation (Alt+R and Alt+G), set its rotation to (90, 0, 180) in Euler XYZ mode - this makes it point forward. Finally, go into Object Data Properties and set Lens Unit to FOV and its value to 70.

At this point, you should be able to start animating. Go to the Animation tab, turn on Auto Keying (it is the "record" button at the bottom), and switch to Action Editor (button on the left).

While an idle animation is technically not necessary for the weapon base, it is the default pose every weapon needs. Create a new action and name it 'idle'. Move into Pose Mode, select all bones (press A), and add a LocRot keyframe to all of them (Press i -> LocRot).

For the rig, you generally only need to move the clavicle, hand, and fingers. The poles determine the rotation of the forearm and can sometimes come in handy.

First pose the right hand - drag it onto the weapon handle, and pose the fingers. Do the same for the left hand.

You should probably drag the clavicles back, the right clavicle being further back than the left. Make sure they are not visible in-game, they are quite immersion breaking.

For fingers, do not change their position - only rotate. If you accidently drag them, Alt+G to reset position. Rotate the first finger joint freely, but only move the other two on the z axis. Additionally, make sure you are in Local orientation.

If you are completely satsified with the idle position, there is one last step that will help you animate the weapon - Bone Constraints. They allow you to "weld" the hands onto the guns and disable it at will during reloads and such.

Go into Pose Mode and select a hand bone. Go to Bone Constraints, and add a "Child Of" constraint. Set its object to the skeleton and the bone to the weapon bone. Click "Set Inverse".

You ideally need a keyframe for every bone constraint on every action, so that BST does not get confused over where the hand should be. Hover over the "Influence" bar and press i. This sets a keyframe for it. Generally, you need a constraint for each hand on the gun, the left hand on the mag (for reloading), and the mag on the gun if it is not parented.

Once you have a decent looking idle position in, you should compile it, create a weapon file for it, go in-game and see if it looks good.

Shooting is the simplest of animations to do, but there are a few things to take note of.

Generally, shooting animations should be snapped to (set snap in $sequence), and its first frame is the gun after recoil. Set the gun's angle upwards a bit, move it down and to the back, and add a tiny bit of side angles.

The last frame should be the idle frame, and one frame in the middle is the recovery frame, where the angle should mostly be neutral but the position is only partially recovered. The whole process should take about 0.5 - 1 second (15-30 frames if doing 30fps) depending on the weapon.

If your gun has a particularly strong recoil (like the Raging Bull), spend the first frame in a lower angle and jolt it upwards on the second frame.

Remember to move the trigger and trigger finger, as well as the bolt, dust cover or cylinder if necessary. If you're not sure whether it should move or not, look for a video of the gun on Youtube or refer to the original animation. These should revert to neutral about 1/3 of the way in.

You likely need a ironsight shooting animation. Duplicate the shooting animation but remove (or minimize) movement on the gun itself.

If your gun has a locking slide or bolt (like most pistols), you need an empty fire animation. Duplicate the shooting animation but remove the recovery on the locking slide/bolt.

Reloading is usually the most complicated part of the animation. For most weapons it should be 2-3 seconds for a tactical (partial) reload and 3-4 seconds for a dry reload. You want to balance the time spent during each portion of the animation (mag out, mag in, bolt/slide) so that none of them look too fast.

Before you begin however, it is a good idea to understand the physical mechanics behind your weapon, and the steps that need to happen to reload it in real life. There are some easily missed stuff like pressing the mag release, releasing the slide lock, or pulling the handle instead of the forward assist(!). If you don't understand it, there's usually plenty of videos with white middle-aged men shooting these guns.

Once you know what to do, start by plotting out the vague movement of the weapon, ignoring any fine details. You want to maximize the screen presence of the weapon and magazine (some CS:S weapons really exaggerate this) but also for it to not look too sudden - raising and tilting the weapon towards the center is a good method.

During this process, you will also need to plan out how to keyframe your Child Of Bone Constraints. Because your left hand will likely leave the weapon, keeping the constraint will make its movement look unnatural and "glued" to the weapon. You can either fade the strength out over time, or use an instant snap, good for sudden movements. Depending on the weapon, you may also need to adjust the constraint for the magazine or even the right hand.

Next, you should add anticipation and reaction frames (fairly sure these are not the technical term, but whatever). What this means is for each movement (like inserting the magazine), you need keyframe(s) anticipating the movement (moving the weapon closer downwards) and frame(s) reaction to the movement (jolting the inserted magazine alongside the weapon upwards). What kind of movement is appropriate depends on the action itself - a good way of figuring this out is making exaggerated motions with your very own hands. This is also a good time to position your fingers.

When the animation is about 50-80% of the way done, you should start compiling it and viewing them in-game. This is important so you catch mistakes like mag not lowering outside of the view, or arms blocking the view. At the same time, you should setup soundscripts. Depending on where you sourced the weapon, it might already have them; otherwise set them up like the following:
In the .qc file, the second number is the frame where the sound starts.

Continue refining your animation. If you created the full dry reload, you should duplicate it and cut it short for the tactical reload and vice versa. It might also be necessary to have different reload animations for extended or reduced magazines, which can accomplished with the following code:

Here's a lighting round of tips for other animations you may need for your weapons.

Cycling
Because cycle animations are immediately played after firing, it cannot be snapped to. Make sure snap is off, then set fadein to a large number like 200. Make sure to also have a slower windup to allow the fade to work well.

Bashing
Bash animations should be extremely short (0.5s), and so you have very little time to windup. The hit should connect about 0.2 seconds in, the rest of the time spent winding down.

Shotgun reloads
Same principle as regular reloads, but you need a startup, insert and finish animation. The ending frame of the start animation should be the starting and ending frame of the insert animation, as well as the starting frame of the finish animation. Take advantage of sgreload_start_empty and sgreload_finish_empty to make sure your gun cycles the bullet in - don't become a tragedy like the MW2 M1014.

Readying
You can definitely cheap out on this by not doing it at all, but it's quite simple to just copy and paste over the bolting/cycling animation and blend it in a bit.

If you are a Lua developer looking to integrate ArcCW into your addons, here is some information that may be of help.


Returns a table of attachment names for the given slot. Slot is a table of indices on the weapon Attachment table.
Inputs: Table/String slot, Entity wep
Outputs: Table ret, containing a list of attachment names
Returns true if the given slot on the weapon can accept the attachment of that name.
Inputs: Table/String slot, Entity wep, String att
Outputs: True if acceptable, False if not

Adds an attachment to the player's inventory. Needs to be called both serverside and clientside.
Inputs: Player ply, String att, Integer amt = 1

Similar, but removes attachments instead.

Networks a player's inventory to their client. If you called PlayerGiveAtt serverside, call this afterwards.
Inputs: Player ply