Skip to content

Conversation

@JFerrix
Copy link
Contributor

@JFerrix JFerrix commented Jan 20, 2026

About the PR

Originally just an attempt to make the hristov into less of a joke, this changes the hristov to not slow you to a crawl but dramatically reduces firerate, making its first strike potential and downtime in fights higher for more mobility options.
Also added .60 cal as emagged lathe recipe because... for some reason that isnt a thing already?

Reworked the cobra.
For some reason the cobra is insanely loud, very very bright when firing with the same muzzleflash as everything else.
This contradicts the entire stealth promise of the weapon which is why its muzzleflash was changed to be less visible, its slightly quieter and it now comes default with subsonic ammunition which is tracerless, allowing it to finally fit its role as stealth weapon
Also added .25 caseless subsonic as emagged lathe item

Media

(video cant be uploaded due to 10MB limit)

Requirements

  • I have tested all added content and changes.
  • I have added media to this PR or it does not require an ingame showcase.

Licensing:

Breaking changes

Changelog
🆑

  • add: Added new sprites and muzzleflash effect for the cobra pistol
  • add: Added .25 caseless subsonic as ammo packet, pistol magazine and uplink purchase option
  • add: Added .60 cal and .25 caseless subsonic to emagged lathe recipes
  • tweak: Changed Hristov sound
  • rework: Reduced movespeed penalty on hristov, decreased firerate substantially

Added the .60cal ammo packet to emagged lathes, changed hristov to have less slowdown.
Reworked the cobra:
- Added caseless subsonic ammo, same stats as regular ammo but doesnt have a tracer and a custom less visible muzzleflash
- Patched store, cobra and emag lathe recipes to include caseless subsonic from the start
@github-actions
Copy link
Contributor

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@github-actions
Copy link
Contributor

github-actions bot commented Jan 20, 2026

RSI Diff Bot; head commit 9d4b02c merging into a6ae995
This PR makes changes to 1 or more RSIs. Here is a summary of all changes:

Resources/Textures/_Floof/Objects/Weapons/Guns/Projectiles/muzzleflashes.rsi

State Old New Status
kineticSuppressed Added

Resources/Textures/_Floof/Objects/Weapons/Guns/Projectiles/projectileSubsonic.rsi

State Old New Status
bullet Added

Edit: diff updated after 9d4b02c

JFerrix and others added 5 commits January 21, 2026 00:10
Signed-off-by: Johnny Ferrix <103964800+JFerrix@users.noreply.github.com>
I used mine because good god, two steel for antimaterial ammo. Really? Are we that unserious now? Do we wanna throw antags fucking twoshot ammo around every corner?
@SyaoranFox SyaoranFox added enhancement New feature or request DO NOT MERGE Mrrow mrrp labels Jan 21, 2026
Copy link
Collaborator

@Mnemotechnician Mnemotechnician left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks mostly good so far, but changes to upstream need to be properly commented

// Muzzle flash stored on ammo because if we swap a gun to whatever we may want to override it.

[DataField]
[DataField("muzzleFlash")]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simple, the field could not be addressed before. Every bullet weapon used the same muzzleflash because it was hardcoded in the line below. This defeats the purpose of "we may want to override it" if there is no way to override it to begin with

Copy link
Collaborator

@Mnemotechnician Mnemotechnician Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it's not, this datafield has the name muzzleFlash by default (see docs), specifying it explicitly is redundant.

Copy link
Contributor Author

@JFerrix JFerrix Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But where is it then? Furthermore if it had then why did addressing the field not work? If it is named muzzleFlash by default then why did adding muzzleFlash in the yml component part not work?
Forgot to mention, you said see docs, where? Where is the documentation for this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why it didn't work for you, you likely made some kinda typo and it slipped through. When the name of data field is not explicitly specified, it defaults to the name of the backing field with the first letter converted to lower case.

Image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That explains a lot. Is a shitty dolution but it explains a lot. Ill try to get that to work. I tried to reverse emgineer it according to other datafiel entries which specifically specified the names of the fields. I have to admit, I hate that this doublestandard exists but I suppose the entire codebase is just held together by permanent duct tape solutions the more I look around it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no idea how or why but now it works. I swear, it didnt work before with the same approach

Comment on lines -129 to +130
walkModifier: 0.25
sprintModifier: 0.25
walkModifier: 0.8
sprintModifier: 0.8
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The entire point of this is to force you to stand still while aiming. This isn't cs:go or tf2 where you can snipe people on the fly, is it?

Copy link
Contributor Author

@JFerrix JFerrix Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Multiple reasons, a) Current one has 0 movespeed slow and that already hasnt exactly done it any good. b) fairness. I actually considered removing the slowdown entirely to begin with but the sight advantage requires a tradeoff. Mainly because: No other weapon has this. If we port our loadout weapons sec will be armed as hell with weapons that have no slowdown, literally higher dps (the hristov has a 16.666 dps rating btw, one shot every ~3s) and same range. To kill a hristov user you can literally blindfire into the general direction and because they effectively cant move they WILL die from this. There are no long range engagements where the hristov will have an advantage, not in this game, the hristov already has no niche and needs to compete with weapons that are made to excel at this. The only way the hristov will work is if you employ hit and run tactics. It will literally be the only way to not have a joke of a weapon again. Adding an 80% movespeed slow is killing this entire strategy and the only other way to make the hristov viable would be to increase its damage. That wouldnt work either however as due to the low firerate and armorpen all we could do would be to make it a 100 damage per shot weapon which would move it into the op, unfun to play category because it could literally oneshot anything.
You see how the movespeed is the only variable we can tweak to give both the player a fair chance without making the weapon op?
Also quickdrawing it will never be viable because you have an equip delay with the value of the fire speed, aka between equipping it and firing you will have over 3s of 80% slow without any form of pressure other than looking menacing.
Trust me this is already a statistically speaking bad weapon without the slowdown at all, we dont want to move it from shit weapon on EE to also shit weapon on DV, the entire purpose is to add a high risk, high skill, high reward weapon into the pool of available weapons.

Ill be happy to discuss this but trust me, the hristov has ironically enough already received most of the changes I would have wanted on EE here on DV and it still isnt a weapon you see often because a buff thats two steps forward but three steps back is not a buff

Copy link
Collaborator

@Mnemotechnician Mnemotechnician Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point. I don't fully agree with what's being said here, but I suppose we can give it a try given the unpopularity of this weapon.

Comment on lines 258 to 266
- type: Tag
id: CartridgeCHIMP

- type: Tag
id: CartridgeCaselessRifle # Specialty ammo for WeaponPistolCobra.

- type: Tag
id: CartridgeCaselessRifleSubsonic

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New prototypes need to be put in the _Floof namespace

@github-actions
Copy link
Contributor

github-actions bot commented Feb 9, 2026

This pull request has conflicts, please resolve those before we can evaluate the pull request.

Signed-off-by: Johnny Ferrix <103964800+JFerrix@users.noreply.github.com>
@github-actions
Copy link
Contributor

This pull request has conflicts, please resolve those before we can evaluate the pull request.

Co-authored-by: Mnemotechnican <69920617+Mnemotechnician@users.noreply.github.com>
Signed-off-by: Johnny Ferrix <103964800+JFerrix@users.noreply.github.com>
@JFerrix
Copy link
Contributor Author

JFerrix commented Feb 10, 2026

I cant resolve the merge conflicts, git doesnt even want to show me what they are, this shit is starting to severely annoy me because none of this is my shit but I need to fix it everytime. Can we either just greenlight this or do SOMETHING so that this merge conflict shit stops?

JFerrix and others added 3 commits February 10, 2026 11:59
hope that works, thank you github for being really fucking not helpful
Discording changes for redoing it.
THANK YOU COUNTLESS MERGE CONFLICTS FOR THAT SHIT

Signed-off-by: Johnny Ferrix <103964800+JFerrix@users.noreply.github.com>
@github-actions
Copy link
Contributor

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@JFerrix
Copy link
Contributor Author

JFerrix commented Feb 10, 2026

Quick the merge conflicts arent home

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants