Document Save.cutsceneIndex and adjacent data / code
#2286
Conversation
so that it doesn't clutter previous commit. still, allowing `clangd LSP` to run format-on-save yields inconsistent results for me with the project's tooling, especially for header files
Co-authored-by: mzxrules <mzxrules@gmail.com>
and some additional observations reverified with > `check_format.py ...` > `make ...` additionally: - current clang-format lacks a rule for trailing commas - compiler says about them `cfe: Warning 624`
zeldaret#2286 (comment) reverified with > `check_format.py ...` > `make ...`
https://jenkins.deco.mp/job/OOT/job/PR-2286/4/console hmm, i do need this automation locally to
and add a comment chunk from zeldaret#2286 (comment)
it gets assigned to the `nextCutsceneIndex`, so `CS_INDEX_NONE` name was misleading
the purpose of `CS_INDEX_BARRIER` is not quite clear still
`ntsc-1.2` refused to comply though
probably size of enum entries doesn't match well? originally these were just numbers. besides, not like it's a real enumeration from zero to a value or some bit flags
|
(unresolved as needed) |
Feacur
force-pushed
the
doc/cutscene_index
branch
from
c91e8c0 to
6efea0a
Compare
zeldaret#2286 (comment) essentially reverts 106cb10, except for 2 generic `z_scene.c` lines
There was a problem hiding this comment.
There has been extensive discussion on the macro names and I think they're mostly fine (wrt how poorly this system is designed), just going to comment on the documentation comments
The only name I have an issue with is CS_INDEX_EMPTY, as mzx said it seems to be very much tied to gSaveContext.cutsceneTrigger, I'm guessing it was just taken as an arbitrary value that verifies >= 0xFFF0 (see Cutscene_UpdateScripted) so that cutsceneTrigger can trigger a scripted cutscene at all
It being reset to default on play state init makes sense in that case, because it would have no meaning on play state init (cutsceneTrigger is meant for interrupting gameplay with a cutscene rather than loading into a cutscene)
Maybe a name could be CS_INDEX_SCRIPT_TRIGGERED, unsure
| // sentinel value used for `cutsceneIndex` to indicate that it should be reset to default | ||
| #define CS_INDEX_EMPTY 0xFFFD |
There was a problem hiding this comment.
I still don't think the name makes much sense, but I also don't have a strong idea for what to call this.
There was a problem hiding this comment.
I will once again advocate for CS_INDEX_D (and CS_INDEX_F instead for 0xFFFF), since these also indicate a scripted cutscene despite not corresponding to any scene layer
There was a problem hiding this comment.
Fair, although now that I think about it I kind of just wish the whole value was written out in full, like...
CS_INDEX_0->CS_INDEX_FFF0
There was a problem hiding this comment.
At this point I won't mind. Either way, you should know better than me, and I already expressed my standpoint. I mean, no subtext, I just trust your decision
Co-authored-by: Dragorn421 <Dragorn421@users.noreply.github.com> Co-authored-by: mzxrules <mzxrules@gmail.com>
while studying the game logic flow, i saw there's a pattern between
Save.entranceIndexSave.cutsceneIndexSaveContext.sceneLayerbut values weren't yet described. so, it's time to cleanup my notes and shape them in a proper PR.
(UPD: not anymore) it's a WIP, but i'll start with a draft for visibilityP.S.:
the closest thing i see here is #1300, but
SaveContext.sceneLayer