first of all .. thanks for the bot
i did not read all the 75 sites of this thread.
i am new to this and still testing.
it looks like the bot still having problems.
1. if the mob is too far away, the bot do not chip the mob. and thats suicide at low lvl maybe you add the feature, if mob is like 40% hp, then chip one more time. because sometimes i cant kill the mob with one chip.
2. i was testing at laksy north (orcs / yetis). sometimes it says: possible bot trap. but it was targeting small hairy yeti. so this is buggy too. plus, he dosent loot anymore.
3. if i change the attack from 8000 to 1000 for expample, it says ... possible bot trap, when he was targeting an orc or yeti.
maybe you can fix those problems.
regards
And that's what happens when you don't read any of the rest of the thread, and expect someone to actually answer your questions, which have already been addressed a 1000 times over...
Quote:
Originally Posted by django23
I'm sorry.
Jt is great, but i was scaried that the .exe contain a keylogger.
Good work
And if you're so concerned about a keylogger, why didn't you bother checking even 2 pages back to see that someone had already done this check not even a day ago lol (not to mention several times before...).
hi everyone, I've been following this thread for some time now. though I haven't said anything, I just wanted to make sure I knew all the details.
I'm one of those who in the v11.3 was getting the error -1: specifically the 'subscript used with non-array variable' one.
and not the 'variable used not defined' that I saw some having. (or something similar)
I believe the problem is due to vista, as I am using vista 32-bit home basic.
and I have also been noting jt's attempts to getting rid of the -1 error.
However, I do not believe adding that pause to the script will fix the issue.
your new verson 11.4, does in fact get rid of the error, but only to send the script into an infinite loop.
my reasons for this are as follows:
I must apologize to jt before hand as I have been debugging his code (sorry, sorry) (and yes this means I do have the source *please don't kill me*, but due to jt's desire to keep cheap spin-offs floating around; I have respected his wish. and will continue to do so, as I am only trying to help)
jt there is a certain part of your 11.4a code that's causing the issue.
true the -1 error is gone, but look:
= PixelSearch(480, 5, 1200, 5, 11119531, 0)
While IsArray() = 0
ToolTip("Working - If this does not go away in after 10 seconds, Press
CTRL+ALT+X to exit")
WEnd
ToolTip("Target window POS set")
ftarget is remaining 0, the assumption that we need to wait for vista to update via the pixelsearch is incorrect!
(also, this is will cause a memory leak effectively maxing out one's CPU resources due to the excessive tooltip, the fix for this is simple just add a Sleep(200) line right below the tooltip)
however, the leak isn't the real problem here. the problem still remains that ftarget isn't getting updated (and thusly not being turned into an array, which means that if your code hits one of the ...target[x] lines, we will indeed see the -1 error return)
what I haven't done is try and fix the code myself, as I see this as useless because jt is the one coming out with the updates (and again, I do not intend to even attempt to do so)
however, my advice (should you decide to follow it) is this:
= PixelSearch(480, 5, 1200, 5, 11119531, 0)
While (@error = 1) ; because if pixelsearch fails @error becomes 1
Sleep (100) ; to stop the memory leak
@error = 0 ; you'll need to reset this because I do not believe that a success will change it back to a 0, (or you can use a temp variable via: temp_err = @error ... and so on and so forth.)
= PixelSearch(480, 5, 1200, 5, 11119531, 0) ; a retry, hoping it works this time around
ToolTip("-something else in here telling the user that it's retrying or whatever-") ; it doesn't matter much
Sleep (100) ; personal preference really, but it will also lessen the memory usage
WEnd
ToolTip("Target window POS set")
now, if even this doesn't work then I can only assume that vista isn't letting pixelsearch grab the correct information (but if it's working in other areas, then the problem may be something totally different all together, still)
....umm .... I think that's all I had to say.
oh yes, good work jt. I was really impressed by the amount of effort you put into this. (as I am very lazy when I actually have to write my own code from scratch, Kudos to you man )
and if you so desire, I don't mind stopping in from time to time or helping you debug in general, or whatever else is needed (but seeing as though you're doing well on your own, I'm not expecting anything )
alright, I'll check back tomorrow (after I sleep a bit -no pun intended- )
later all.
your recommendation was stage two of my attempt to repair the error Line-1 code. The infinite loop was put in place on purpose to isolate the problem. In theory I was experimenting and trying to get feedback from everyone with the problem. You are the first I have seen to provide such. I appreciate the recommendation and it will actually be in the next release of the script that I might be posting later tonight.
your recommendation was stage two of my attempt to repair the error Line-1 code. The infinite loop was put in place on purpose to isolate the problem. In theory I was experimenting and trying to get feedback from everyone with the problem. You are the first I have seen to provide such. I appreciate the recommendation and it will actually be in the next release of the script that I might be posting later tonight.
hmm, well I've been experimenting with the bot (and other scripts) and found some rather disturbing information.
1st off - I found that the bot will pass the winpos issue (this is the same/current one from before) if an enemy or some character that uses the central slot in the HUD has previously been selected. but I assume that this only gives the bot incorrect information as it simply loops itself in the main body but it never re-enters any of those conditionals.
(so yes, a totally useless find)
2nd - I've attempted to run only the camera turning. and it is also unsuccessful.
am I correct to assume that the bot cannot move the mouse when rappelz is the selected window? nor can it click the mouse? and thus the reason why the bot switches between the 'bot-window' and rappelz client when during a camera turn?
my reason for asking this is thus: when it attempts to perform this (at least on my system and others similar) the camera actually doesn't get moved.
and when I built a script from scratch (that didn't re-focus a different window) it couldn't move the mouse at all. let alone turn the camera in-game.
also, jt, am I correct to assume that this bot works in xp, and, at least, on the vista systems you've tried it on?
I am currently at work (I'm off the clock but my ride is here for another hour or so).
so once I get back to my laptop, I can put out some screenies if I need.
I'll also make some other (albeit feeble) attempts to give you a heads-up about the vista related bugs.
so, currently. the only things I see that are preventing usage on my system are 1 - the failing pixelsearch function (because if the first instance usage of the function doesn't work, I can't see why the entire chain of them afterwards will work) and 2 - the screwy mouse movement and clicking within the rappelz client.
(though that window re-focus bit may work in xp *I'll try testing it on xp tonight if I can*, it doesn't seem to work in vista home ... or the ones I've tried ... I suppose I can try a different computer and see if I get the same results)
so, in the meantime, I'll be attempting to see if I can find alternative ways to fix either of those issues. (because if I can find a way around the mouse thing, heaven forbid letting the bot work in full-screen mode)
The bot work good, but it don't simulate the pressure of the right button in game, and the arrow of mouse stay ever in the same point, so the camera don't move.
How can I resolve this problem? I'm using Windows XP 32 bit and your bot version is JT's Beta V11.4a.
Thanks for the help.
)
)
(or I might have to kill you)
