Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "Mod Weapon Vars" #691

Open
wants to merge 25 commits into
base: main
Choose a base branch
from
Open

Add "Mod Weapon Vars" #691

wants to merge 25 commits into from

Conversation

EladNLG
Copy link
Member

@EladNLG EladNLG commented Apr 24, 2024

What?

Creates an alternative to weapon mods by allowing overrides of any numeric eWeaponVar through script.

Example

ScriptWeaponVars_SetInt(weapon, eWeaponVar.ammo_clip_size, 50)

Why?

  1. Weapon files need to be downloaded client side to work, and MAD isn't finished yet.
  2. Weapon mods have a 200 "modifications" limit. This has been raised to ~240 through admirable work of others, but will not be enough for larger-scale mods/mods that want to apply a variety of modifiers on a variety of weapons.
  3. Allows setting a variable to a range of values instead of being limited to 32 options (e.g. if you'd want to recreate the nemesis with the current weapon system, you wouldn't be able to because the amount of possible values for its burst delay is effectively infinite, however, this allows such things.)

WIP. Relies on #692.

Required before merging

  • Manager for script weapon modifiers
  • System to reapply overrides when weapon vars are recalculated (e.g. after AddMod) (Script PR not existing yet)

Optional

- [ ] Auto-sync server changes to client through a remote function
- [ ] Add "predicted" versions of functions, that do not transmit to client
Decided against autotransmitting changes for a few reasons:

  1. MAD
  2. would be a pain and overcomplicate things imo

[Screenshots/Examples TBD]

@EM4Volts
Copy link

while im not able to "review" this because i dont know anything in c++ or such at all i just want to say that his would be an excelent addition, the mod limit is big but still something that can happen. and having the evars modifyable directly via script enables alot more then the current need of switching mods on stuff.

primedev/client/weaponx.cpp Outdated Show resolved Hide resolved
primedev/mods/modweaponvars.cpp Outdated Show resolved Hide resolved
primedev/mods/modweaponvars.h Outdated Show resolved Hide resolved
primedev/server/weaponx.h Outdated Show resolved Hide resolved
primedev/mods/modweaponvars.cpp Show resolved Hide resolved
primedev/mods/modweaponvars.cpp Show resolved Hide resolved
create an alternative to weapon mods by allowing overrides of any numeric eWeaponVar.
- reformat some error messages
- add support for boolean values
- expand WeaponVarType enum
- set weaponVars length to the correct length
- rename functions
- replace hook for random func with hooks to Cl_CalcWeaponMods and Sv_CalcWeaponMods
we will be doing a script PR instead, as it is easier
@EladNLG EladNLG requested a review from catornot April 25, 2024 18:26
@catornot catornot added needs testing Changes from the PR still need to be tested depends on another PR Blocked until the PR it depends on is merged needs code review Changes from PR still need to be reviewed in code labels Apr 25, 2024
@EladNLG
Copy link
Member Author

EladNLG commented Apr 26, 2024

PR finally works with prediction - gonna try cleaning up code tomorrow.

Unfortunately, i cannot figure out proper naming for the hooked functions - im just going off of frequency of calls :[

Please help if you can.

i think thats what it is? makes the most sense to me
also format fix
@EladNLG
Copy link
Member Author

EladNLG commented Apr 27, 2024

Also, do we want to support strings/assets/vectors?

@ASpoonPlaysGames
Copy link
Contributor

Also, do we want to support strings/assets/vectors?

If it's not that bad, yeah would be nice. Vectors probably the most useful

primedev/mods/modweaponvars.cpp Show resolved Hide resolved
primedev/mods/modweaponvars.cpp Outdated Show resolved Hide resolved
- the rare crash would happen when the given weaponVars pointer was not from a weapon, and the location before it was not meant to be read
isbadreadptr sucks actually
@EladNLG EladNLG requested a review from catornot May 6, 2024 13:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
depends on another PR Blocked until the PR it depends on is merged needs code review Changes from PR still need to be reviewed in code needs testing Changes from the PR still need to be tested
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

None yet

4 participants