[bob schmidt]

When you start a bot with the client logged out, upon logging in it will trigger the onItemAdded event for each item you have currently in your inventory. If the client is logged in already when the bot is started, this does not happen, nor does it happen if you later log the client out and back in again (as in with a break handler).

To me, this behavior seems a bit inconsistent. I feel like it should either:
A. Trigger onItemAdded every time you log the client in.
or
B. Never trigger onItemAdded when you log the client in.

My preference, and the most logical given the name of the event, would be option B. Currently, I've circumvented the behavior by delaying adding the listener until a second after the client has logged in, but I worry that on some laggy connections or slower computers, a second may be too short. On the other hand, raising this delay to cover this will make the bot seem to take an eternity to load for people with faster connections/better computers.

My current code looks (something) like this:

public ExecutorService executorService = Executors.newCachedThreadPool();

public LootWatcher loot;

@Override
public void onStart(String... arguments) {
    loot = new LootWatcher(this);
  
    executorService.execute(() -> {
        while (!RuneScape.isLoggedIn()) {
            Execution.delay(100);
        }
        Execution.delay(1000);
        getEventDispatcher().addListener(loot);
    });
}

This doesn't feel optimal. It does work. Is there another method that I've missed along the way to prevent the firing of the onItemAdded event when the client first logs on, or does basically everyone do something like this? I assume this behaves in this manner because the RuneMate API loads the inventory prior to executing the onStart if the client is already logged in, but has to load it after the onStart if the client is not logged in, since it executes the login handler after the onStart method returns.

One potential "fix" for this, then, assuming my above assumptions are correct, would be to log the client in prior to executing the onStart method of the bot. While I don't have a great deal of botting experience, what little I do have suggests that most bots assume or desire that the client be logged in right at the start, then may log the client off for breaks later. A possible exception may be complex bots that take time to configure in a UI prior to starting execution, but even then they could disable the login handler and let the client time out if necessary (or allow them to disable the login handler, but handle the side effects of that behavior on their own).

Comments? Suggestions?

 

[semajian]

The problem here is separation of concerns - your suggestion B would require the InventoryListener to be aware of the current state (first login here as an example) for it to exclude these events. What’s happening is:
1. Bot is loaded and initialised
2. InventoryListener thinks you have an empty inventory as you’re logged out
3. The bot logs you in
4. The event listener notices new items in the inventory and triggers as it would expect to

Sounds more like a homegrown solution would fit than an API change

 

[bob schmidt]

That's basically exactly what I just said, and why I suggested that it might be feasible to simply re-order the start-up operations to log the client in prior to loading and initializing the bot.

What I'm actually more interested in, I suppose, is if there's a more creative/intuitive way to handle the scenario than I'm currently implementing. Changing the order of operations would just make this a non-issue for other people down the road, and something that wouldn't have to be worked around.

 

[semajian]

Changing the order of operations would just make this a non-issue for other people down the road, and something that wouldn't have to be worked around.

You said I just repeated what you said, but this specifically is what I was saying can’t happen. The bot has to initialise before it logs in, otherwise there is no bot to login.

There are other ways around this than a delay, I’ve not toyed around much yet so I’m far from the best person to suggest them but as an example a loot “reset” could happen when your bot identifies it’s just started, or only loot added after a certain amount of time could be recorded. I’m not saying these are nice solutions, I’m just explaining why it’s not a big that’s all.

 

[bob schmidt]

You said I just repeated what you said, but this specifically is what I was saying can’t happen.

I was specifically referring to the order of operations currently in place, and the lack of necessity to change anything at the API level which you reiterated from my original post.

It seems that there is some confusion about what an API is, based on this comment. An API ("Application Programming Interface") is defined by the endpoints that my application is allowed to interface with within your application.

Changing the order of operations during bot startup by adding a call to the login handler prior to executing the bot's onStart method does not constitute a change to the API, by any definition. This is because the code that handles starting the bot is not part of the API. If it were, you would be able to start other bots from your bot, simply by referencing that interface. My point A in my original post, "Trigger onItemAdded every time you log the client in." would be a change to the API, because it would make a difference in the manner in which your bot "interfaces" with the client (this would require clearing the cached inventory items upon logging out, and then refilling them when logging back in, which is, in effect, modifying accessible portions of the bot->client interface). Modifying the InventoryListener to ignore inventory changes when logging in would also be a change to the API, although not one that I think anyone would notice (however, from a design perspective, I suspect this would be somewhat more difficult to implement).

Therefore, you did repeat what I had said by reiterating the order of operations during startup which I had already laid out, and stating that no change was necessary to the API, which I had also already stated, preferring instead to change the order of operations prior to the bot's onStart method being called.

The bot has to initialise before it logs in, otherwise there is no bot to login.

Just thinking about this statement logically - if this were the case, then the client process should not be required to be started prior to the bot's onStart method being called, as there's no bot at that point to execute any operations on that client.