Problem with code executing differently in TaskNode vs AbstractScript

[zeepzoop 3]

I have a tutorial island script that I want to incorporate in my TaskScript as a TaskNode.  

 

The onLoop() looks like this

    public int onLoop() {
        if (getDialogues().canContinue()) {
            getDialogues().continueDialogue();
            sleepUntil(() -> getDialogues().canContinue(), 2000);
            return Calculations.random(200, 700);
        }else if(getWidgets().getWidgetChild(162, 33).isVisible()){
            getWidgets().getWidgetChild(162, 33).interact();
            return Calculations.random(200, 700);
        }

        switch (getPlayerSettings().getConfig(281)) {
            case 0:
                return case0();
            case 3:
                return case3();
            case 7:
                return case7();
            case 10:
                return case10();
            case 20:
                return case20();
            case 30:
                return case30();
[a shit ton of case ##: return case##();]
            case 1000:
                return case1000();
            default:
                return 10000;
        }
    }

When I put this code in the execute() of my TaskNode, it sometimes skips the dialogue check and clicks on the NPC while it is already in dialogue. It runs fine in a standalone AbstractScript.  Bug? or am I missing something?

[Hopewelljnj 46]

First off you are continuing if you can continue and then sleeping until you can continue(typo?)

[zeepzoop 3]

After continue is called, canContinue returns false until the next dialogue is loaded.  If I don't sleep then on the next loop canContinue is false and it executes the switch.  

[Mad 86]

Why do you need this as a node, just keep it how it is

[Hopewelljnj 46]

After continue is called, canContinue returns false until the next dialogue is loaded. If I don't sleep then on the next loop canContinue is false and it executes the switch.

But... The switch will run every loop no matter what

[zeepzoop 3]

it runs after return?

Alright so i just added another sleep 

            sleepUntil(() -> !getDialogues().canContinue(), 2000); <--added
            sleepUntil(() -> getDialogues().canContinue(), 2000);

and it works again.  Weird how this only happens in TaskNode, not AbstractScript.  

[raptor 10]

I think you're approaching this from the wrong perspective. I agree with Mad:

 

Why do you need this as a node, just keep it how it is

 

If you want to make this into a TaskScript, you might want to split out each case into a separate task node. Then, you can split your switching logic up from this monolithic switch/case and break it up in an intelligent way into the accept() method of each node.

 

As it is currently, I think it makes more sense to keep it as an AbstractScript.

[IWasDiagnosed 0]

deleted

[zeepzoop 3]

Hmm I don't think I was clear. I want this script to be a TaskNode of a taskscript that also handles leveling, gold farming, muling, etc.

 

I know the giant switch looks pretty bad, but I think it's just the nature of tutorial island since I have to account for like 100+ playersettings. I guess I could split it up based on the area/NPC, but I don't see the benefit of doing so.

[Hopewelljnj 46]

Hmm I don't think I was clear. I want this script to be a TaskNode of a taskscript that also handles leveling, gold farming, muling, etc.

 

I know the giant switch looks pretty bad, but I think it's just the nature of tutorial island since I have to account for like 100+ playersettings. I guess I could split it up based on the area/NPC, but I don't see the benefit of doing so.

It could possibly be that 

 

it runs after return?

Alright so i just added another sleep 

            sleepUntil(() -> !getDialogues().canContinue(), 2000); <--added
            sleepUntil(() -> getDialogues().canContinue(), 2000);

and it works again.  Weird how this only happens in TaskNode, not AbstractScript.  

It's possible that it is moving past continuing the dialog too quickly. So the continue isn't being changed fast enough allowing your code to go faster than it should be which can cause some issues. Whether this is or is not the case I am not sure.