Connect function seems to misspell account/password

@Wobbuffet

connect(login:lower()...

If your password has any CAPITALIZED member it'll obviously type it wrong.

while not $connected do

        connect(login:lower(), password, character) wait(1000, 1200)

    end

This is also a part of a really bad code, the function 'connect' already tries to connect several times before exiting, inserting it into a while loop won't do any difference except for fucking up the code.

You should use ready to use scripts found on forum and stop doing this shitty persistents if you really want to bot, I use my own reconnecter and I have no problems.

Quote:

---

Originally Posted by Leonardo

@Wobbuffet

connect(login:lower()...

If your password has any CAPITALIZED member it'll obviously type it wrong.

while not $connected do

        connect(login:lower(), password, character) wait(1000, 1200)

    end

This is also a part of a really bad code, the function 'connect' already tries to connect several times before exiting, inserting it into a while loop won't do any difference except for fucking up the code.

You should use ready to use scripts found on forum and stop doing this shitty persistents if you really want to bot, I use my own reconnecter and I have no problems.

---

Grr, it's c0de by @walukasz, I kn0w 0nly h0w t0 l0ad script and d0n't say smth is fucked up if y0u d0n't kn0w what wa1ukasz wanted t0 d0
I msg t0 him right n0w,

edit:
thx f0r answer, I h0pe it wi11 w0rk,

Quote:

---

Originally Posted by Leonardo

@Wobbuffet

connect(login:lower()...

If your password has any CAPITALIZED member it'll obviously type it wrong.

while not $connected do

        connect(login:lower(), password, character) wait(1000, 1200)

    end

This is also a part of a really bad code, the function 'connect' already tries to connect several times before exiting, inserting it into a while loop won't do any difference except for fucking up the code.

You should use ready to use scripts found on forum and stop doing this shitty persistents if you really want to bot, I use my own reconnecter and I have no problems.

---

For the first thing password is not being lowered, so it's obviously typed correct. Account is lowered as it is case insensitive, as you can easly check, it was added as a desperate try to reduce use of shift key by the bot.

Besides, it was clearly said, function usually eventually connects, being in the loop called with the same arguments, so if the lower() was the problem, how could for the same data give errors and then succeed?

Don't search problems where there are none, the problem was explained and it seems it's bot internal problem, and it was reported as a bug, not as 'my function doesn't work ;( someone fix plox'

It's not a shitty persistent, it's not even a persistent, it is a function that relogs to (as name says, doesn't it?) to a specified character from specified account, and it's called when needed in other functions, that are called in specified waypoints. Connect function, even if it maybe tries more than once, does it try untill connected? I doubt it.

You know what is bad programming practice?
This is (callback[2] ~= nil and stopattack() and callback[2]()) or false

Quote:

---

Originally Posted by walukasz

For the first thing password is not being lowered, so it's obviously typed correct. Account is lowered as it is case insensitive, as you can easly check, it was added as a desperate try to reduce use of shift key by the bot.

It's not a shitty persistent, it's not even a persistent, it is a function that relogs to (as name says, doesn't it?) to a specified character from specified account, and it's called when needed in other functions, that are called in specified waypoints. Connect function, even if it maybe tries more than once, does it try untill connected? I doubt it.

---

My bad, it's not the password but the account, indeed, I have no idea if this Deepling guy is just a troll or this is for real, anyway he copied part of the code, which means I can't guess if it's an action or persistent. Maybe in his case (not all of your scripts) he should do in a different way, changing type press/focus/button stuck policies to fill the password correctly.

If you really want to go via the while loop, I recommend this in a future use:

while not $connected do

    setlifetime(60000)

    connect(a,b,c)

end

Quote:

---

Originally Posted by Leonardo

My bad, it's not the password but the account, indeed, I have no idea if this Deepling guy is just a troll or this is for real, anyway he copied part of the code, which means I can't guess if it's an action or persistent. Maybe in his case (not all of your scripts) he should do in a different way, changing type press/focus/button stuck policies to fill the password correctly.

If you really want to go via the while loop, I recommend this in a future use:

while not $connected do

    setlifetime(60000)

    connect(a,b,c)

end

---

i'm not trolling when i speak about my profit.
I didn't copied anything, walukasz gave me this title/description, screenshot was my.

Quote:

---

Originally Posted by Leonardo

My bad, it's not the password but the account, indeed, I have no idea if this Deepling guy is just a troll or this is for real, anyway he copied part of the code, which means I can't guess if it's an action or persistent. Maybe in his case (not all of your scripts) he should do in a different way, changing type press/focus/button stuck policies to fill the password correctly.

If you really want to go via the while loop, I recommend this in a future use:

while not $connected do

    setlifetime(60000)

    connect(a,b,c)

end

---

No, he wasn't trolling, even had pictures to prove it. The way function is used could been guessed from it's name, or as you said if you couldn't guess, don't :d. You could be right, policies can help, it is kind of roulette though, but probably worth trying. Actual solution is to make or improve connect function checking what it typed before confirming.

I don't want to do it through while loop, I have to, I want to relog to another character and I want it to happen for sure, there is no point to proceed before relogging.
About the lifetime thing, how exacly would it help? I mean that for sure wouldn't resolve the current problem, but could resolve a problem I am not even aware of, but afaik there is no problem such aborts connect function execution before it did what it had to.

Quote:

---

Originally Posted by walukasz

No, he wasn't trolling, even had pictures to prove it. The way function is used could been guessed from it's name, or as you said if you couldn't guess, don't :d. You could be right, policies can help, it is kind of roulette though, but probably worth trying. Actual solution is to make or improve connect function checking what it typed before confirming.

I don't want to do it through while loop, I have to, I want to relog to another character and I want it to happen for sure, there is no point to proceed before relogging.
About the lifetime thing, how exacly would it help? I mean that for sure wouldn't resolve the current problem, but could resolve a problem I am not even aware of, but afaik there is no problem such aborts connect function execution before it did what it had to.

---

Quote:

---

Originally Posted by walukasz

You know what is bad programming practice?
This is (callback[2] ~= nil and stopattack() and callback[2]()) or false

---

This is called "noob proof". In other words this script will do what it must even with wrong user input without raising errors the user can't manage to fix. You should learn this to improve your scripting skills.

Another thing to learn is how the environment of windbot events works before placing them in structures they don't belong to.

I agree it could be a problem with the function itself but first I wanna try all possibilities I can create to help the affected user. So, if you don't have anything that could help then step aside.

Quote:

---

Originally Posted by Leonardo

This is called "noob proof". In other words this script will do what it must even with wrong user input without raising errors the user can't manage to fix. You should learn this to improve your scripting skills.

Another thing to learn is how the environment of windbot events works before placing them in structures they don't belong to.

I agree it could be a problem with the function itself but first I wanna try all possibilities I can create to help the affected user. So, if you don't have anything that could help then step aside.

---

Maybe you are not getting something here. I am the author of the script, this is why I talk in here.

If you are still in there about this loop, well, bot doesn't always succeed, and it's not always scripter fault, like why people put opening backpacks in loops? Because it sometimes fails. Same goes for connect function, it fails. If it fails with timeout, I don't care, try again, same for internet connection not working, try again till internet is back, till servers are back up or whatever, this is how user expects it to work, this is the expected behaviour. If he had 10 min net kick, he doesn't want to have houndreds of bots stopped, he wants them to login, when possible. Besides this function does not return errors, how do you expect me to detect it's type?

This function is internal, it's not for the user to call, and it does what it's supposed to. User does not provide the login data, its provided by another application, and before trying to log in to the next account, account is also checked by another program whether data is valid (account exists (not deleted)). Besides script is raising error, that is the error connect function raises, which says password are incorrect, and provides enough log messages to track the problem, what else you expect? The error appears shouldn't happen, it is a bug of bot as said before. Maybe you would check every function for errors to be sure? assert(2+2==4)

It could be problem with function? It obviously is problem with function, but there might be workarounds that might help which would be good, but still connect function should work always, not with specific settings.

Really it does not occur to you it's obviously a bug? Only reason I shown the code is that it clearly shows that.
When you call the function like this relogTo("1234", "asd12", "Leonardo")

then the function calls connect("1234", "asd12", "Leonardo") multiple times with the very same arguments, how come it can twice say the password is incorrect, and then using the very same data succeed to login on the third try?

I never deeply looked in to events tho, but afaik setlifetime would just let the connect function to do what it wanted for longer than default, but it doesn't seem to be the case, calling it repetedly shouldn't be a problem either as waitforevents is true by default, or no?

Quote:

---

Originally Posted by Leonardo

Another thing to learn is how the environment of windbot events works before placing them in structures they don't belong to.

---

Some resources for 'environment of windbot events' thing?


Why is setlifetime needed here.

Code:

---

while not $connected do
    setlifetime(60000)
    connect(a,b,c)
end

---

Shit is getting quite hot in here, so let me clear the air:

1. The code in question is totally valid. There is nothing wrong with it and, apart from styling and naming conventions, that's pretty much how I'd write such function.
2. setlifetime doesn't add much. Even though it could be helpful and should probably be included, it doesn't factor much into the problem being faced. What it does is give connect more (or less) time to execute. Also worth to note that it shouldn't (or rather doesn't need to) be placed inside the while loop because, as I already explained on other occasions, it is script scoped, which means that all events inside the script that called the function will have that lifetime from that point. It's also a good reason why you should probably call setlifetime again outside the loop to reset the default lifetime for the other events, which I believe to be 30000ms.
3. This thread is valid and helpful. It did report a real bug and did propose a decent fix. The issue will be looked at and solved when we deem appropriate.
4. Gaxeo is a troll.

Now, if we could stop with the ad hominem and focus on the issue here, I'd appreciate.