-
Notifications
You must be signed in to change notification settings - Fork 433
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
Conversation
Co-authored-by: engineer124 <engineer124engineer124@gmail.com>
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.
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
// Allows Tatl to fly over the actor and Z-target it | ||
#define ACTOR_FLAG_TARGETABLE (1 << 0) |
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.
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
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.
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
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.
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
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.
I rewrote this comment a bit, tell me if it is clear now
src/code/z_actor.c
Outdated
f32 sTargetableNearestActorDistanceSq; | ||
f32 sBgmEnemyDistSq; | ||
f32 D_801ED8D0; | ||
s32 sTargetableHighestPriorityPriority; |
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.
Is the double Priority intended?
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.
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
?
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.
Would something like:
sTargetablePrioritizedActor
sTargetablePrioritizedPriority
Sound less awkward? idk
src/code/z_actor.c
Outdated
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; |
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 sets more than colors, it also sets position. Could there be a simpler name than Target_SetFairyPosAndColors
?
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.
What about Target_SetFairyState
?
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.
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
* `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. |
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.
* 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?
Co-authored-by: engineer124 <47598039+engineer124@users.noreply.github.com>
Co-authored-by: engineer124 <47598039+engineer124@users.noreply.github.com>
src/code/z_actor.c
Outdated
if (actor == params->player->lockOnActor) { | ||
actor->isTargeted = true; |
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.
if (actor == params->player->lockOnActor) { | |
actor->isTargeted = true; | |
if (actor == params->player->lockOnActor) { | |
actor->isLockedOn = true; |
I think?
@@ -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; |
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.
fairyActor = play->actorCtx.targetCtx.fairyActor; | |
targetFairyActor = play->actorCtx.targetCtx.fairyActor; |
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.
Great work!
Documentation pass for the Target system and general cleanups
ACTOR_FLAG_TARGETABLE
,ACTOR_FLAG_FRIENDLY
andACTOR_FLAG_UNFRIENDLY
TargetMode
enumz_actor
bssSomething to note is every time either
ACTOR_FLAG_FRIENDLY
orACTOR_FLAG_UNFRIENDLY
is used, it is used in conjunction withACTOR_FLAG_TARGETABLE
. We may want to define compound flags for those two, maybe something like this:(Not convinced by
FLGSET
tho)