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

Currently status doesn't make sense #15

Open
CLOEI opened this issue Nov 29, 2024 · 3 comments
Open

Currently status doesn't make sense #15

CLOEI opened this issue Nov 29, 2024 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@CLOEI
Copy link
Owner

CLOEI commented Nov 29, 2024

The current implementation pretty much does not fully update the status.
Let us say I'm currently on EXIT caused by failure on warping to a world. the status would still be "Connected"

We want the status for that case to be "Failed to enter the world" or another message that sounds fit.

Here's a hint: for that issue, you can use OnFailedToEnterWorld function.

Note: this issue is completed when every status message that seems necessary is fully added.

Please comment if you like to work on it.

@CLOEI CLOEI added enhancement New feature or request good first issue Good for newcomers labels Nov 29, 2024
@bbangg
Copy link
Contributor

bbangg commented Nov 29, 2024

I encountered an issue while writing a Lua script for the bot. I was using a basic loop to check if the bot was in the game and in world X, then sending a call to warp(xyz). However, I noticed that using warp in a loop resulted in multiple warp requests being sent to the servers, which could potentially cause shadow bans.

To address this, I initially introduced is_not_allowed_to_warp (though it was not actively used) but later changed it to is_allowed_to_warp. Storing the positive state directly is more intuitive and avoids unnecessary logical complexity.

I'll create a pull request about this.

@bbangg
Copy link
Contributor

bbangg commented Nov 29, 2024

If we are referring to state messages like these:

(copied from my old bot project)

enum EBotState : std::uint8_t {
  BOT_STATE_DISCONNECTED = 0,
  BOT_STATE_CONNECTED,
  BOT_STATE_BANNED,
  BOT_STATE_SUSPENDED,
  BOT_STATE_WRONG_PASSWORD,
  BOT_STATE_UPDATE_REQUIRED,
  BOT_STATE_MAINTENANCE,
  BOT_STATE_AAP,
  BOT_STATE_LOGON_ATTEMPTS,
  BOT_STATE_ON_SEND_TO_SERVER,
  BOT_STATE_CAPTCHA,
  BOT_STATE_SUCCESS,
  BOT_STATE_SERVER_OVERLOAD,
  BOT_STATE_BYPASS_TUTORIAL,
  BOT_STATE_UNABLE_TO_CREATE_ACCOUNT,
  BOT_STATE_INVALID_EMAIL,
  BOT_STATE_GUEST_CAPTCHA
  // ... we can add an endless number of states
};

I think these state messages are primarily useful for the GUI. For example, imagine we want to warp to another world. Should we check if the state equals Connected? If so, when would we update the state to Connected? After OnSuperMainStart.. or after enet::EventNoRef::Connect?

I believe that these states don’t align well with the functionality we’ll need. For instance, warp requests should be controlled using is_allowed_to_warp. Would we then update the status to "Failed to warp" after OnFailedToEnterWorld? It seems states like these aren’t appropriate for function-level control and might introduce unnecessary complexity.

If it's required for the bot's functionality rather than being displayed in the interface, it seems overly complex for now. We can discuss the states after identifying similar points across them, such as is_ingame and is_allowed_to_warp, once all the necessary checks have been added.

@CLOEI
Copy link
Owner Author

CLOEI commented Nov 29, 2024

Hello @bbangg after reading your comment, yea i agree that it will surely add a complexity. we will come back to this after every necessary things has been added.

I'll keep this issue open, anyone is free to comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants