Forum › Forums › Discussion › Gathertouch not working since patch
This topic contains 14 replies, has 3 voices, and was last updated by Lyfox 6 years, 2 months ago.
-
AuthorPosts
-
October 17, 2018 at 12:11 am #9072
So since the patch yesterday, gathertouch is no longer working for me. Gives me the error “there is no gathering node to touch” and then terminates with execution error. Seems like if a node is not within visual range(showing up green text in the game world) the bot isnt using the compass+navmesh to move to it
Anyone else having this issue? very bad because all my ephemeral gatherers are semi broken now 🙁
October 17, 2018 at 3:46 am #9074October 17, 2018 at 4:03 am #9076October 17, 2018 at 7:54 am #9084That’s weird, did something else change? Most of my ephemeral scripts are sort of like your public ones Lyfox. Eg in an area with 3 node clusters 1,2,3 it would execute waypoint(3), gathertouch, randomWaypoint(1,2), gathertouch then continue. Prior to this patch I never had issues with it with a combined over a thousand hours of use. Since patch, if it went to waypoint 3, but only waypoints 1,2 had node spawns it would throw a execution error and stop the entire script
October 17, 2018 at 12:02 pm #9085October 17, 2018 at 7:33 pm #9092I have no idea why it despawned. I know on a few accounts all they do is gathertouch, no gather but still had issues. Do you think adding a waypoint(1), gather(1) before the gatherTouch() could help it? So makes miqo navigate to a cluster using the compass then do its thing
I’ll double check when I can later, but basically I would want to go to the area and see the locations of clusters manually then put those numbers into the waypoints right? Eg if I see theres nodes at waypoints 1,3 then I can be sure they will stay there and not be randomised on a relog/rezone?
October 17, 2018 at 8:06 pm #9093Umm not really, if you gather(1) it will despawn it. And nodes are always randomized within each cluster.
There are usually three clusters with 4 nodes in each. Only 2 of 4 are spawned and those 2 will be different after relog. So if you put waypoints 1,2,3 above three clusters you have to make sure that all 12 nodes are linked to them. Like 4,5,6,7 for the first cluster then 8,9,10,11 for second and so on. Use 3d radar to link both spawned (green) and non-spawned (white).
Sorry if its the same as you asked i wasnt sure.
October 17, 2018 at 11:50 pm #9098Yea I know it will despawn the node. My idea was to basically have :
gather(1)
gatherTouch()
… continue hereso it will navigate to a node beyond visual range, gather(despawn) it. then it will guaranteed be near another node since those spawn in clusters of 2. Does that make any sense?
I understand how the navmesh works, but the problem is eg if we have the following code(think this was from your ephemeral scenario actually):
teleport(Porta Praetoria) job(BTN) gatherPreset(e-Duskglow) grid(e-Torreya-Branch) rotationIfGP(Ephemeral-i) rotationIfGP(Ephemeral-8/8) //afkUntil(04:00ET) waypoint(20) gather(1) randomWaypoint(0,22) gather(1) gatherTouch() waypoint(4) gather(1) gatherTouch()
Given a mesh for example first cluster is 0,1,2,3; 2nd is 4,5,6,7 and 3rd is 22,23,24,25
When bot gets to the line randomWaypoint(0,22) and selects waypoint 0 to travel to. if no nodes are active in the 1st (0,1,2,3) cluster AND other clusters are out of visual range the entire bot hangs. I just don’t see any way around this unless im missing something major
October 18, 2018 at 5:53 am #9101Sorry i still dont understand why youre looking for a workaround for something that should never happen instead of trying to figure out what caused it. Theres probably a mistake in timing that made your bot to gather from a normal node when ephemeral wasnt active at all. The most logical thing to do is copy the message log into a text file and read it. Find the abnormal gather sequence which navigated to incorrect waypoint not connected to an ephemeral. If you dont figure out the real problem your workaround might break anyway.
You can show your scenario and log if you want and ill help you look for that problem.
October 18, 2018 at 8:39 am #9102I really don’t see how this ‘should never happen’. Unless you modify the scenario code each time an account relogs, how exactly does the bot avoid the problem I described above? I can go paste the the scenario/log next time it happens, but it feels to me that I’m not getting the problem across properly
Are you understanding why the bot may get stuck given the code and environment described in the previous post?
- This reply was modified 6 years, 2 months ago by he_le.
October 18, 2018 at 12:10 pm #9105I really don’t see how this ‘should never happen’.
Bot gathers ephemeral nodes only and touches normal ones only. Normal nodes never despawn.
Just try my ephemeral scenario it works exactly like this.Are you understanding why the bot may get stuck given the code and environment described in the previous post?
Yep.
– On first cycle scenario will gather(1) and despawn one node in the cluster. Then gatherTouch() second node.
– On second cycle scenario will gather(1) and despawn second node in the cluster. Then gatherTouch() has nothing left to touch.October 18, 2018 at 10:51 pm #9145So you realise why the gather(1), gatherTouch() system gets stuck due to node being not visible to the bot. How is that problem any different from the one in both of our original ephemeral scripts? We both use this type of code to respawn ephemerals:
waypoint(17) gatherTouch() randomWaypoint(21,2) gatherTouch()
which assumes that there are nodes within visual range of waypoint 17. If there are not, the scenario simply hangs
October 19, 2018 at 6:09 am #9147October 19, 2018 at 6:50 am #9148October 19, 2018 at 7:38 am #9164 -
AuthorPosts
You must be logged in to reply to this topic.