Hi, this'll be a bit technical so I'll just do an introduction for this so you guys can understand how items in CSGO work.
Basically you've got the code part which is compiled (and isn't public) etc... the usual stuff for a game, then they rely on a file called items_game.txt which is the implementation of the items in-game and on their item server. The part which needs cleaning now is how weapons are implemented. I'll add comments to the parts of the code so you can better understand what is what.
here's an example of an item existing in the game in the items_game.txt config file:
"7" // unique ID of the item { "name" "weapon_ak47" // name of the item "prefab" "weapon_ak47_prefab" // prefab used as a base "item_quality" "normal" "baseitem" "1" // if the item is owned by default "default_slot_item" "1" // if the item is the default item in the buy menu for this slot "item_sub_position" "rifle1" // position in the buymenu }
here's its "prefab" (what the item uses as its base; I've removed the non important parts so it doesn't fill the post with code) :
"weapon_ak47_prefab" { "prefab" "rifle" // prefab based on "item_class" "weapon_ak47" // In short the C++ class, but not really because Source uses entities etc... "item_name" "#SFUI_WPNHUD_AK47" // readable name of the item for players "item_description" "#CSGO_Item_Desc_AK47" // description for players "model_player" "models/weapons/v_rif_ak47.mdl" // Firstperson model "model_world" "models/weapons/w_rif_ak47.mdl" // Thirdperson model "model_dropped" "models/weapons/w_rif_ak47_dropped.mdl" // Model when the item is on the floor, fun fact: no collisions -> broken HL1-like physics "used_by_classes" // Who can buy it / equip it { "counter-terrorists" "0" "terrorists" "1" } "attributes" // Ajusts on the C++ class, usually gameplay related { "magazine model" "models/weapons/w_rif_ak47_mag.mdl" // Example of an attribute, this is the dropped magazine when reloading "primary reserve ammo max" "90" // Maximum ammo that can be carried "spread" "0.600000" "damage" "36" // Damage dealt, later multiplied by the hitbox's multipliers "cycletime" "0.100000" // "60/RoundsPerMinute" to get the cycletime [ . . . ] } "visuals" // Visual effects of the weapon, some are wrong and should be attributes { "muzzle_flash_effect_1st_person" "weapon_muzzle_flash_assaultrifle" // Muzzle particle "muzzle_flash_effect_3rd_person" "weapon_muzzle_flash_assaultrifle" "heat_effect" "weapon_muzzle_smoke" // Smoke particle "addon_location" "primary_rifle" "eject_brass_effect" "weapon_shell_casing_rifle" // Shells particle "tracer_effect" "weapon_tracers_assrifle" // Bullet Tracers particle "weapon_type" "Rifle" // Type of weapon, defines what animations to use in thirdperson, also what kind of weapon it is (scoped, grenade, melee etc..) "primary_ammo" "BULLET_PLAYER_762MM" // Ammo used by the gun, obsolete? "sound_single_shot" "Weapon_AK47.Single" // Sound script used when firing "sound_nearlyempty" "Default.nearlyempty" // The Low ammo CLICK sound script } }
Now that being said, a lot of work that was supposed to be done by the items_game were made on the Programming side, leading to weird results when editing the items_game. I can understand that it's underwhelming to work on existing spaghetti code and you have to deal with it by doing an other layer of spaghetti but they can't continue like that, at some point the bugs will become insane. Cleaning those issues will be a god sent for both their team and us. They have to let the items_game do what it's supposed to do.
So here's a list I did to point out what's wrong and I'm probably missing a lot of them:
-
weapon_aug, weapon_sg556
-
Scopes aren't implemented correctly since a year, worked fine before, their "name" is used instead of their class name resulting in weird issues if you decide to implement a new weapon based on it, this should be implemented inside the class itself and not rely on weird hacks inside the code. - [PREVIEW] (first is the custom weapon using the AUG's class, second is the real AUG)
-
the "aimsight *" "attributes" are obsolete and don't do anything except "aimsight lens mask" which sets the scoping mask of the item (blurs everything except the mask, used inside the scope to delimit the blur). They should either remove their implementation in the items_game or implement them in their C++ classes.
-
-
weapon_molotov, weapon_firebomb
-
Fire particles are spawned only if the ID of the item matches the one inside the C++ code (id: 46, 81), this is a misconception and a taped solution. This issue popped on reddit when Danger Zone was released, the particles were missing on the weapon_firebomb and I guess a simple C++ edit was done in order to not fix the molotov works because it was probably easier.
-
Here's an other issue not related to the items_game but generally: Thirdperson particles used on the worldmodel are getting rendered in firstperson
-
-
weapon_shield
-
If the item is equiped as a primary weapon, secondary or anything, you'll be FORCED to pick it up and will drop your current weapon equiped in the slot it wants to be in - [PREVIEW] (I'm just pressing movement keys, not pressing G or E on the shield)
-
-
If the "name" doesn't match "weapon_shield" the animations will be set to the knife's, again a very big misconception, this is either the C++ class' job or an items_game "visuals" parameter which already exists and is used by pretty much EVERY WEAPON. - [PREVIEW] (Exact same code as the weapon_shield except renamed to weapon_shield2)
-
Hitboxes are on the viewmodel, they don't do anything, no point in having them on it.
Now to something else
This icon mess (3 versions corresponding to wears?):
"alternate_icons2" { "weapon_icons" { "65604" { "icon_path" "econ/default_generated/weapon_deagle_hy_ddpat_urb_light" } "65605" { "icon_path" "econ/default_generated/weapon_deagle_hy_ddpat_urb_medium" } "65606" { "icon_path" "econ/default_generated/weapon_deagle_hy_ddpat_urb_heavy" } "65684" { "icon_path" "econ/default_generated/weapon_deagle_aa_flames_light" } [ . . . ] "330014002" { "icon_path" "econ/default_generated/studded_hydra_gloves_bloodhound_hydra_case_hardened_heavy" } } }
There is 14401 lines of those things which I believe have no reason being here anymore. they should have been inside their respective items or in a separate items_game file for readability reasons, I also doubt that they're still used in Panorama. Anyway here's what a skin looks like inside the items_game so you can better understand why it should be in there instead:
"17" { "name" "hy_ddpat_urb" "description_string" "#PaintKit_hy_ddpat" "description_tag" "#PaintKit_hy_ddpat_urb_Tag" "pattern" "ddpat" "style" "2" "color0" "40 40 40" "color1" "80 80 80" "color2" "140 140 140" "color3" "180 180 180" "phongintensity" "10" "pattern_scale" "2" "pattern_offset_x_start" "0" "pattern_offset_x_end" "1" "pattern_offset_y_start" "0" "pattern_offset_y_end" "1" }
I'm thinking that at times they just don't have the choice on how to handle things due to the mess Hidden Path Entertainment did when they were working on the game and all the mess Valve had to do over the years to fix that just accumulated causing unreadable code leading the programmers to work dirty to get shit done (that's just how I see it). If possible those issues should be addressed so they don't have to fix code that breaks over the updates due to poor implementations or worse.
A bit of bright side now because I kinda made them look bad ;)
-
Icons for weapons are now fully based on their "name", this makes implementing new weapons without bothering adding new parts in the code to load the icon for said weapon.
-
They just have to add a new entry in a file to set the positions and rotations for the inventory and buymenu when they create a new weapon ("itemmodelpanelcharweaponinspect.res")
-
How flexible the items_game is when they don't hard code weapons (the issues I'm pointing in this post), you can basically set whatever you want on the fly.
-
Panorama is actually amazing, the amount of customization you can do when modding the game is crazy and no doubt that with them using JS... they can do anything they want easily, the guys who worked on panorama did a very very good job... it's reliable and works as expected... Though it's sad we can't mod the JS part ( ͡° ͜ʖ ͡°)
The team have really outdone themselves so far in the recent years, they need to keep it up! Fixing those issues I believe will help everyone, Server owners will be happy and so will modders and ultimately players.
TL:DR: Valve plz fix. Their implementation of items is a mess, they really need to fix it and implement items in a cleaner way with the items_game's behaviors being the priority on how they implement them. They probably don't do it due to deadlines.
EDIT: Wow... that's a lot of upvotes hahaha
EDIT 2: CS:GO's code isn't available, this here is the config part which they rely on for easier development and tweaking, the issue isn't really about the config files, it's about the actual game's code behind the scenes that nobody knows about, this is a guessing game using the tools they basically gave us and is all about testing to find out what they did wrong.
EDIT 3: I don't want to be mean to the csgo team, and I'm sorry if I offended... the way I write makes people feel like I have a massive ego and hate Valve but I don't mean it. I just wish those issues would be fixed, so I'm pointing the spots where the issues are in hope that they'd get fixed...
