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

Documentation pass for the Target system #1281

Merged
merged 62 commits into from
Sep 2, 2023

Conversation

AngheloAlf
Copy link
Collaborator

Documentation pass for the Target system and general cleanups

  • Name the actor flags ACTOR_FLAG_TARGETABLE, ACTOR_FLAG_FRIENDLY and ACTOR_FLAG_UNFRIENDLY
  • Introduce a TargetMode enum
  • Migrate z_actor bss

Something to note is every time either ACTOR_FLAG_FRIENDLY or ACTOR_FLAG_UNFRIENDLY is used, it is used in conjunction with ACTOR_FLAG_TARGETABLE. We may want to define compound flags for those two, maybe something like this:

#define ACTOR_FLGSET_FRIENDLY (ACTOR_FLAG_TARGETABLE | ACTOR_FLAG_FRIENDLY)
#define ACTOR_FLGSET_UNFRIENDLY (ACTOR_FLAG_TARGETABLE | ACTOR_FLAG_UNFRIENDLY)

(Not convinced by FLGSET tho)

Copy link
Collaborator

@engineer124 engineer124 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay, I really wanted to try and understand targeting from both Player and Navi/Tatl's perspective as well. I have some more thoughts on these names

include/z64actor.h Outdated Show resolved Hide resolved
include/z64actor.h Outdated Show resolved Hide resolved
include/z64actor.h Outdated Show resolved Hide resolved
include/z64actor.h Outdated Show resolved Hide resolved
src/code/z_actor.c Outdated Show resolved Hide resolved
src/code/z_actor.c Outdated Show resolved Hide resolved
src/code/z_actor.c Outdated Show resolved Hide resolved
include/z64actor.h Outdated Show resolved Hide resolved
include/z64actor.h Outdated Show resolved Hide resolved
include/z64actor.h Outdated Show resolved Hide resolved
Comment on lines 471 to 472
// Allows Tatl to fly over the actor and Z-target it
#define ACTOR_FLAG_TARGETABLE (1 << 0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is Z-target in this context the same as lockOn, or is it the more general case of targeting? It's possible for tatl to fly to an actor because of this flag, but not be able to lockOn which is controlled/blocked by a different actor flag: ACTOR_FLAG_8000000 or ACTOR_FLAG_CANT_LOCK_ON

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly. As you said having this flag enables Tatl to fly to an actor and lock-on it. To only allow flying over the actor but not lock-on then both flags must be set

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was referring more to the comment in that ACTOR_FLAG_TARGETABLE alone isn't enough to lockOn. ACTOR_FLAG_8000000 must also be unset for you to be able to lock on

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rewrote this comment a bit, tell me if it is clear now

src/code/z_actor.c Outdated Show resolved Hide resolved
f32 sTargetableNearestActorDistanceSq;
f32 sBgmEnemyDistSq;
f32 D_801ED8D0;
s32 sTargetableHighestPriorityPriority;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the double Priority intended?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly yes, because of this block in Target_FindTargetableActorForCategory

                if (isNearestTargetableActor && (actor->targetPriority < sTargetableHighestPriorityPriority)) {
                    sTargetableHighestPriorityActor = actor;
                    sTargetableHighestPriorityPriority = actor->targetPriority;
                }

The first variable stores the address of the actor with the highest priority, while the second one tracks the priority of the actor with the highest priority. Would be fine to drop the second Priority?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would something like:
sTargetablePrioritizedActor
sTargetablePrioritizedPriority
Sound less awkward? idk

src/code/z_actor.c Outdated Show resolved Hide resolved
src/code/z_actor.c Outdated Show resolved Hide resolved
include/z64actor.h Outdated Show resolved Hide resolved
Comment on lines 472 to 475
void Target_SetColors(TargetContext* targetCtx, Actor* actor, ActorType type, PlayState* play) {
targetCtx->fairyPos.x = actor->focus.pos.x;
targetCtx->fairyPos.y = actor->focus.pos.y + (actor->targetArrowOffset * actor->scale.y);
targetCtx->fairyPos.z = actor->focus.pos.z;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sets more than colors, it also sets position. Could there be a simpler name than Target_SetFairyPosAndColors?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about Target_SetFairyState?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think that's fine? I've been starting to look at fairy docs and there is something called fairyState (name might change eventually tho), plus this has Target_ to give it context. So it's probably fine

src/code/z_actor.c Outdated Show resolved Hide resolved
* `sTargetableNearestActor`. The higher priority / smaller distance of those actors are stored in
* `sTargetableHighestPriorityPriority` and `sTargetableNearestActorDistanceSq`.
*
* Something something, ACTOR_FLAG_40000000, D_801ED8C4/D_801ED8C0, D_801ED8D8/D_801ED8D0.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Something something, ACTOR_FLAG_40000000, D_801ED8C4/D_801ED8C0, D_801ED8D8/D_801ED8D0.
* There is not much info to infer anything about ACTOR_FLAG_40000000, D_801ED8C4/D_801ED8C0, D_801ED8D8/D_801ED8D0. All appear unused in any meaningful way

Maybe something like this?

AngheloAlf and others added 3 commits July 27, 2023 20:21
Co-authored-by: engineer124 <47598039+engineer124@users.noreply.github.com>
Co-authored-by: engineer124 <47598039+engineer124@users.noreply.github.com>
Comment on lines 2487 to 2488
if (actor == params->player->lockOnActor) {
actor->isTargeted = true;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (actor == params->player->lockOnActor) {
actor->isTargeted = true;
if (actor == params->player->lockOnActor) {
actor->isLockedOn = true;

I think?

src/overlays/actors/ovl_En_Elf/z_en_elf.c Outdated Show resolved Hide resolved
@@ -1134,12 +1134,12 @@ void func_8088F214(EnElf* this, PlayState* play) {
sp34 = 1;
Actor_PlaySfx_Flagged(&this->actor, NA_SE_EV_BELL_ANGER - SFX_FLAG);
} else {
arrowPointedActor = play->actorCtx.targetContext.arrowPointedActor;
fairyActor = play->actorCtx.targetCtx.fairyActor;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fairyActor = play->actorCtx.targetCtx.fairyActor;
targetFairyActor = play->actorCtx.targetCtx.fairyActor;

Copy link
Collaborator

@engineer124 engineer124 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work!

@engineer124 engineer124 removed the Needs-second-approval Second approval label Jul 30, 2023
@AngheloAlf AngheloAlf added Merge-ready All reviewers satisfied, just waiting for CI and removed Needs-first-approval First approval labels Sep 2, 2023
@AngheloAlf AngheloAlf merged commit 9cceea4 into zeldaret:master Sep 2, 2023
1 check passed
@AngheloAlf AngheloAlf deleted the actorcleanup branch September 2, 2023 19:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation Merge-ready All reviewers satisfied, just waiting for CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants