-
Notifications
You must be signed in to change notification settings - Fork 8
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
d_t_mole_prohibit OK #31
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.
This applies to most pre/do functions. This is due to being passed into commonPack:
/* 802e1500 */
int fBase_c::commonPack(int (fBase_c::*doFunc)(), int (fBase_c::*preFunc)(), void (fBase_c::*postFunc)(MAIN_STATE_e)) {
MAIN_STATE_e state;
// Pre Function to setup
int result = (this->*preFunc)();
if (result) {
// Do function to handle current
result = (this->*doFunc)();
if (result == NOT_READY) {
state = WAITING;
} else if (result == SUCCEEDED) {
state = SUCCESS;
} else {
state = ERROR;
}
} else {
state = CANCELED;
}
// Post Function to handle after effects (Allows for retry after waiting)
(this->*postFunc)(state);
return result;
}
Similarly actorCreate()
, actorPostCreate()
, actorExecute()
and actorExecuteInEvent()
all return the same kind of status
} | ||
|
||
int dTgMoleProhibit_c::doDelete() { | ||
return 1; |
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.
return 1; | |
return SUCCEEDED; |
|
||
int dTgMoleProhibit_c::actorExecute() { | ||
mStateMgr.executeState(); | ||
return 1; |
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.
return 1; | |
return SUCCEEDED; |
} | ||
|
||
int dTgMoleProhibit_c::draw() { | ||
return 1; |
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.
return 1; | |
return SUCCEEDED; |
🚫
Yes, for some reason this matches if I include the weak
__dt__5dTg_cFv
and__vt__5dTg_c
symbols. I don't know why these would be included here (since they're unreferenced), and this might break if a similar pattern is observed in other RELs (though easily fixable by giving up on the commondTg_c
ancestor. Who knows...)