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

Extend functions.yml format #453

Open
burner1024 opened this issue Jan 24, 2023 · 5 comments
Open

Extend functions.yml format #453

burner1024 opened this issue Jan 24, 2023 · 5 comments

Comments

@burner1024
Copy link
Contributor

I have a suggestion to further detalize function data by splitting detail into separate fields.
That would allow to provide signature help:

Peek 2023-01-24 12-18

The format would change like this:

old

- name: disable_aimed_shots
  detail: void disable_aimed_shots(int pid)
  opcode: 0x823f
  doc: Allows overriding the normal rules regarding which weapons are allowed to make aimed attacks. (e.g. weapons that cause explosive damage normally cannot normally make aimed shots.) stops a weapon from making aimed shots even if it normally coulld. Affects player and NPCs alike. The list of edited weapons is not saved over game loads, so you need to call the function once at each reload. Use a pid of 0 to represent unarmed.

new

- name: disable_aimed_shots
  type: void
  opcode: 0x823f
  args:
    - type: int
      name: pid
      doc: Weapon PID. 0 means unharmed.
#      default: 123 # this arg has no default, omitted.
  doc: Allows overriding the normal rules regarding which weapons are allowed to make aimed attacks. (e.g. weapons that cause explosive damage normally cannot normally make aimed shots.) stops a weapon from making aimed shots even if it normally coulld. Affects player and NPCs alike. The list of edited weapons is not saved over game loads, so you need to call the function once at each reload.

The proposal is only to allow this format, not to convert everything at once, hopefully that can happen naturally over time.

Another thing I'd like to suggest is to allow an optional deprecated string field, which could be used to do, well, deprecations.
Captura desde 2023-01-24 12-24-29

@NovaRain
Copy link
Collaborator

Since the current website document stuff is from your previous "better docs" pull request, feel free to make another one.

@phobos2077
Copy link
Collaborator

Sounds like a good idea.

@phobos2077
Copy link
Collaborator

I gotta say I don't like deprecating vanilla opcodes. For compatibility I try to use as much vanilla stuff as possible, so 99% of the time, floor works perfectly for me, so does critter_inven_obj (there's only one case where it bugs out which I never used in any of my scripts yet, and it should've been just fixed instead of adding new opcode anyway).

@NovaRain
Copy link
Collaborator

NovaRain commented Jul 12, 2023

I gotta say I don't like deprecating vanilla opcodes. For compatibility I try to use as much vanilla stuff as possible, so 99% of the time, floor works perfectly for me, so does critter_inven_obj (there's only one case where it bugs out which I never used in any of my scripts yet, and it should've been just fixed instead of adding new opcode anyway).

For critter_inven_obj2 (added by you about 7 years ago): #38

If the opcode gets "fixed" (i.e. returning valid object pointer for inactive hand slot), you will break the vanilla game as at least critter_is_armed vanilla macro relies on the original behavior. The player will suddenly find that he is attacked by NCR police for no obvious reason as he cannot simply holster his weapon (switching active slots) like before.

For floor2: #109

Not sure about this one, I think it should be fine to fix the vanilla opcode (thus make floor2 metarule more or less an alias) as most of cases in game are about dealing with positive values.
EDIT: I already made a fix for op_floor locally.

@burner1024
Copy link
Contributor Author

Well, the field can be called somehow else, it doesn't matter.
The whole deprecation thing is just visual, no one suggests for them to be actually removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants