-
Notifications
You must be signed in to change notification settings - Fork 6
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
corrected and clarified some stuff related to action functions #2
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! This is very helpful, I had been meaning to document this system but never found the time to. There are some things I would prefer be re-phrased but it would also be fine if they stayed with explanation.
parameter and may pass in `invoker` and `stateinfo` parameters as well. `stateinfo` | ||
refers to the `State` which this action was called from. | ||
|
||
Action scopes are a flag field and as such an action function can have multiple scopes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a little too specific, preferably this would be written as user-facing documentation rather than from an implementation perspective. I would suggest the phrasing "Action functions may have one scope or multiple scopes."
Action scopes are a flag field and as such an action function can have multiple scopes. | ||
The only scopes that actually set the internal action function flag are `item`, `overlay` and `weapon`, | ||
so action functions without one of these do not act much like action functions, and they do not get an | ||
`invoker` or `stateinfo` pointer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Preferably this would also be rephrased as something like "Actor scope and un-scoped action functions do not have invoker
or stateinfo
parameters and as such are not often useful." Followed by an explanation of what these two do and in what circumstances they may be useful.
| None | The actor this function operates on, ambiguous in some contexts | N/A | | ||
| `actor` | The actor | N/A | | ||
| `item` | Context-dependent. The item itself when it exists in-world, but the owner when used as part of a CustomInventory state chain | Item itself | | ||
| `overlay` | Context-dependent. The actor itself when it exists in-world, but the owner of the PSprite when it is being used as one | Context-dependent. The actor itself when it exists in-world, but the PSprite's `caller` field when it is being used as one. In most cases this field should be set to be the actor defining the action function, but it can be changed by user code so this is not technically guaranteed | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PSprite is a technical term, which while correct, is not very intuitive. Preferably "the weapon" would be used here because it is an equivalent term in abstract.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PSprite is a technical term, which while correct, is not very intuitive. Preferably "the weapon" would be used here because it is an equivalent term in abstract.
That's not actually correct. PSprites don't have to be weapons, and don't have to be contained in them.
I was looking through the GZDoom source to work out some stuff about the internals of the action function system and after checking these docs I noticed that they don't get certain things right (or aren't specific enough). So I've tried to create a more technically complete definition here based on the results of an hour or so of playing around with ZScript and reading the source code. I may not have gotten everything completely perfect but I think it's a more complete description of the messy parts of the system.