Skip to content

Update DS1R talk docs - #13

Draft
treacherousfiend wants to merge 1 commit into
thefifthmatt:masterfrom
treacherousfiend:DS1R_talk_docs
Draft

Update DS1R talk docs#13
treacherousfiend wants to merge 1 commit into
thefifthmatt:masterfrom
treacherousfiend:DS1R_talk_docs

Conversation

@treacherousfiend

Copy link
Copy Markdown

Update talk documentation based on reverse engineering of DS1R, uploading as is mostly for posterity and feedback since there's still several to-dos and extremely technical documentation that probably will help no one.

Notes:

  • In some cases if a command or function was not present in DS1R I removed it as being present in DS1 and DES as well since they were either in the range of IDs used the QLOC in DS1R or beyond that range, and it seems unlikely to me that they would jump around with IDs like that since they seem to go in order (not accounting for skipped IDs from seemingly removed functions)
  • Additionally, I've added games definitions for some of the later functions that did not have any defined, because I know that they are not present in DS1R so they shouldn't be considered valid for DS1R and prior.
  • I've renamed several functions so that they make a bit more sense and/or are consistently named with other similar functions (most notable with functions that open menus)
  • The MenuType enum is nightmarishly long because the IsMenuOpen doesn't seem to have any limitations, and can read from any of the (~500 allocated in DS1R) values that they use to store basically anything menu related in MenuMan. The ones I've added/changed in the enum are just ones that i'm about 99% certain of, there's so many more that I either don't know or am not super sure of.
    • This isn't extremely helpful because IsMenuOpen doesn't just return the value, it just returns true if the value is non-zero, which I don't think even means the menu is necessarily open for some of the later ones. They store all sorts of data in those values. Honestly the function is probably another way to arbitrarily read memory, but being limited to checking if a 4 byte value is or is not 0 is pretty limiting
    • DidYouDoSomethingInTheMenu is basically IsMenuOpen-lite, it can only read very specific menus from its own list (the InteractMenuType enum is complete, it is that small), but ends up essentially just checking if one of the values in MenuMan is non-zero or not.
  • I'm not fully sure how ShuffleRNGSeed actually works despite looking at it quite a bit, but it does seem to allow values of 0-255 rather than 0-100.
  • the TalkInterruptReason enum value names are taken from debug strings for the feature.
  • I'm not the biggest fan of splitting AddTalkListData into a version for DS1R and a version for every other game, but I see no reason to mention the functionality of setting the input to 69696969 outside of DS1R because its something that Q-LOC added for their terrible hardcoded functionality of the covenant menu.
  • Not super sure how GetRelativeAngleBetweenSelfAndPlayerWithAxis works either, but I do know that it uses the exact same code path as GetRelativeAngleBetweenSelfAndPlayer, so its not about getting the able between 2 players like the previous name suggested. I assume the function just takes into account another axis, since its used to show the talk prompt for Quelaag's Sister, I haven't checked but I wouldn't be surprised if the point it uses to determine the angle check is off the ground or something.

Based on reverse engineering of DS1R, uploading mostly for posterity and feedback
@gracenotes

Copy link
Copy Markdown
Collaborator

Thanks for these changes, I do want to get to them in more depth. I'll note some of the function names come from translating fromsoft's own names for them, which are always preferred for consistency even if they don't make as much sense in English. It's been a while since I've looked at those so I'll want to compare it against the list here before making any hasty conclusions!

@treacherousfiend

Copy link
Copy Markdown
Author

yeah i sort of figured that the function names must've been derived from official names, but wasn't sure if they were preferred simply for being semi-official or if no one had bothered to name them differently.
In theory I guess there could be a possibility of translations being inaccurate or just worded oddly, but in general I'm just a bit skeptical of translations of from soft's names in general, but thats partially because i'm used to the ancient machine translated DS1 param names.
I can update this to fit however you prefer it to be like

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

Successfully merging this pull request may close these issues.

2 participants