still getting reports for misclicking spells in .77

 

a user even posted a small gif http://gyazo.com/0481b8bd5505e6c19915dd4b2ae284bb

 

they claim .75 has been working better

 

i dont know what else to post, i'm just relaying the message

 

code:

 

if (getMagic().castSpell(stunAlchSpell.getSpell())) {
return random(50, 70);
}

 

i thought it was a rare occurrence, but it seems to have happened 2 minutes into the script (as shown in gif)

Spell casting was reported three times, each time I asked for a test against .77 with no response from each topic. I did a controlled test for 5 minutes and I was unable to reproduce the bug; using that information I released 2.3.77 as a stable version.

 

Please test against 2.3.77 and the official API (not your custom spells). The client is a bit ripped apart right now, it's going to take some time until even a development build will be available.

 

I'll make some changes, but all I'm using is magic.castSpell, either the sleep timer is too low (probably not even relevant at all) or the fact that I'm casting 2 spells, 1 after the other each time (stun-alch), either way, the reports on my thread are piling up

I'll make some changes, but all I'm using is magic.castSpell, either the sleep timer is too low (probably not even relevant at all) or the fact that I'm casting 2 spells, 1 after the other each time (stun-alch), either way, the reports on my thread are piling up

 

21 June 15 - Bug reported

22 June 15 - I asked to test against 2.3.77

28 June 15 - No response, performed internal test without failure

 

There was a five-day window to follow up; as it stands my next release will be around 08 July 15. Please conduct a thorough test using only the official API (preferred if contained within onLoop) and post your results. If any issues are found, they will be addressed.

Spells are fine IMO, I guess it's just misclicks in general, ever since ~.60, I've had to add failsafes to report interface, GE collect interface and a few others due to the misclicking. I guess spells are included in this, but it's very difficult to prove a misclick, so I guess you can close this thread

 

also, suggestion:

 

can we have like an accuracy value for osbot's mouse, so that we can increase accuracy? It would instantly increase the quality of scripts. Not increase accuracy too much tho, just accurate enough to not cause problems, and not too accurate like a typical robot would do

 

i guess ill just have to hardcode the mousedestinations if I want click accuracy

Edited July 1, 201510 yr by Czar

If you can isolate the issue, it would help me a lot in figuring out what the problem is. Running my controlled tests, the destinations and events are executing perfectly. Generally speaking, destinations are created based on the shape with an average click toward the center of an object (widget, NPC, etc). The destinations are later translated into PointDestination (in InteractionEvent) which makes an evaluation based on the distance to the mouse versus whether or not the shape contains the mouse (preventing a premature click before reaching the final destination).

 

You mentioned having a problem with GrandExchange and Spells, both of which use Widgets. If this is the case, I would expect everything else which is using widgets (eg bank, inventory) to also be giving you problems. The purpose of using official API (in a report) is so I can reproduce a bug and debug the issue. You can create your own destinations, but I feel like that would just sink you deeper into problems when they arise.

 

I'll leave this open for now in case you are able to reproduce the issue somehow, or if you decide to create your own work-around.

 

Just wondering, is this because the bounding boxes between two spells/widgets appear to overlap at the borders:

 

Code used to get this info:

Area one, two, three;
	
	
	@Override
	public int onLoop() throws InterruptedException {
		// TODO Auto-generated method stub
		if (getWidgets().isVisible(218, 35)) {
			RS2Widget hla = getWidgets().get(218, 35); //High Level Alch
			int w, h, x, y, endX, endY;
			if (hla != null) {
				w = hla.getWidth();
				h = hla.getHeight();
				x = hla.getAbsX();
				y = hla.getAbsY();
				endX = (x + w);
				endY = (y + h);
				one = new Area(x, y, endX, endY);
			}
			
			RS2Widget ss = getWidgets().get(218, 42); //Saradomin Strike
			if (ss != null) {
				w = ss.getWidth();
				h = ss.getHeight();
				x = ss.getAbsX();
				y = ss.getAbsY();
				endX = (x + w);
				endY = (y + h);
				two = new Area(x, y, endX, endY);
			}
			
			RS2Widget eb = getWidgets().get(218, 34); //Earth blast
			if (eb != null) {
				w = eb.getWidth();
				h = eb.getHeight();
				x = eb.getAbsX();
				y = eb.getAbsY();
				endX = (x + w);
				endY = (y + h);
				three = new Area(x, y, endX, endY);
			}
			
			if (areaOverlaps(one, two)) { //HLA & SS
				log("High level alch overlaps Saradomin Strike");
				log("HLA: " + one);
				log("SS: " + two);
			}
			if (areaOverlaps(two, three)) {
				log("Saradomin Strike overlaps Earth Blast");
				log("SS: " + two);
				log("EB: " + three);
			}
		}
		return 2500;
	}
	
	public boolean areaOverlaps(Area a, Area b) {
		for (Position p : a.getPositions(0)) {
			if (b.contains(p)) {
				return true;
			}
		}
		return false;
	}

When stunalching, check if, when going to alch, it goes to Y position 340. The only thing I can think of regarding this is that you go to y=340 and RS sees that as being on Saradomin Strike because it has a higher index than HLA (42 opposed to 35).

I updated the calculation for grabbing the point. Here are the results for High Level Alchemy:

 

java.awt.Point[x=721,y=325]
java.awt.Point[x=723,y=325]
java.awt.Point[x=713,y=319]
java.awt.Point[x=715,y=329]
java.awt.Point[x=721,y=323]
java.awt.Point[x=722,y=336]
java.awt.Point[x=715,y=335]
java.awt.Point[x=719,y=324]
java.awt.Point[x=715,y=335]
java.awt.Point[x=724,y=318]
java.awt.Point[x=711,y=326]
java.awt.Point[x=720,y=329]
java.awt.Point[x=717,y=329]
java.awt.Point[x=710,y=326]
java.awt.Point[x=715,y=329]
java.awt.Point[x=712,y=335]
java.awt.Point[x=713,y=331]
java.awt.Point[x=719,y=328]

 

 

I updated the calculation for grabbing the point. Here are the results for High Level Alchemy:

 

Is this just for spells? It has been happening for just about everything you can click on, for example when right clicking or accidentally clicking search instead of bank all within a bank.

You mentioned having a problem with GrandExchange and Spells, both of which use Widgets. If this is the case, I would expect everything else which is using widgets (eg bank, inventory) to also be giving you problems. The purpose of using official API (in a report) is so I can reproduce a bug and debug the issue.

All i use is osbot api and i still get mis clicks from time to time. IDK how you expect for us to prove to you how/why interactions keep miss clicking.

 

edit:

i have come to notice that i usually get miss-clicks more often with widgets interactions.