-
Member
8OLF4fpjWF8.jpg Hi guys, how to fix it?
-
Contributor
Originally Posted by
MaDEvgen
disable HealthBars plugin and enable it again
-
Member
Hi,after install the new update (today at 18:47 in brazil),my map (the central map) don't show anymore enemies in area of map,tried restart program and deactivate/activate all options.
Screenshot by Lightshot
Thanks!!!! (PS:Sorry about my english hahaha)
Last edited by rcmartone; 02-03-2021 at 11:09 PM.
-
Contributor
Originally Posted by
Sikaka
The terrain data in the client is super useful for pathfinding obviously and I'm aware I'll need to handle spawnable objects like doors and stuff. As for movement skills though like flame dash am I correct I can combine the melee and ranged layers and any un-walkable tiles that have valid ranged layers are ones that can be crossed with movement skills? Or do I need to dig into the heightmap/tile data itself?
In theory, yes
In reality, it's super sketchy due to skill use mechanics and general terrain oddities
Ultimately, the server decides if an action should happen or not. This means the client can think it's able to perform an action, but then the server rejects it, and then the client desyncs or the expected outcome doesn't happen. This was a huge problem with the game back before they "fixed" desync with the lockstep model. However, they didn't quite fix as much as just making it less of an issue, to which they then made it worse later on by "fixing" the skill casting system when it comes to unwalkable terrain and skills not firing because the terrain under the cursor was unusable.
I think you'll be able to get something that works, but from my testing on this, there's a lot of "false positives" when trying to do it in an automated manner, and there's other things to consider, such as the skill casting mechanics themselves. For example, lightning warp can traverse a longer distance than flame dash, so when you try to operate on that ranged terrain layer, it's more than just having walkable ranged pathfinding data because the distance itself matters, but if you don't perform the calcs exactly like the client does, you're bound to end up with issues (although it's hard to say if such issues will matter or not without trying)
The best way to study this and play with it, would be in The Riverways. I don't think I have an image saved atm, but I recently looked into this idea and decided ultimately, it'd make for a killer feature if you could get it to work nicely, but the problem is such a system is so counterintuitive for pathfinding, because you're then spending more (real)time trying to figure out a faster way to traverse the terrain (which you only spend a few minutes in and then throw away forever since the game is proc genned) as opposed to just speedily moving along an easy to generate melee based path that will almost always work (as long as you handle terrain changes from dynamic objects ofc)
Basically, if it takes 1 minute to fully traverse an area to get to the next area, then having to spend any amount of time doing processing on the terrain before you start moving renders the feature useless (for bots at least) if the net result is you taking longer than 1 minute to traverse the area. That's the biggest challenge I think you'll have, how to balance the overhead vs any possible speed boosts gained from using it. Extensive pathfinding logic is generally CPU heavy, but you can also look into offloading it by having server sided pathfinding (which would be useful for multiple characters in the same area anyways for coordination)
You do need the heightmap for correct melee based movement, but only for cursor/world mapping. It won't ever be perfect though, because the client has some nasty bugs still that once you trigger them, you'll shake your head and have to adjust your code for. Fellshrine still has tiles near the Church entrance that will trap bots because of the cursor/terrain mapping for example. There's no real way to avoid those issues other than by having a better "player mover" system when it comes to moving the mouse in a more human-like way to not trigger the client issue but those issues are all human triggerable as well so you can't prevent it entirely
It's certainly worth looking into and is an interesting problem to solve, especially if you're familiar with pathfinding stuff, but it also seems like one of those "you just have to throw enough time at it and it'll either be good enough or no longer worth the time" types of issues.
Last edited by pushedx; 02-03-2021 at 07:33 PM.
Reason: fixed a wrong word
-
Active Member
Originally Posted by
pushedx
In theory, yes
In reality, it's super sketchy due to skill use mechanics and general terrain oddities
Ultimately, the server decides if an action should happen or not. This means the client can think it's able to perform an action, but then the server rejects it, and then the client desyncs or the expected outcome doesn't happen. This was a huge problem with the game back before they "fixed" desync with the lockstep model. However, they didn't quite fix as much as just making it less of an issue, to which they then made it worse later on by "fixing" the skill casting system when it comes to unwalkable terrain and skills not firing because the terrain under the cursor was unusable.
I think you'll be able to get something that works, but from my testing on this, there's a lot of "false positives" when trying to do it in an automated manner, and there's other things to consider, such as the skill casting mechanics themselves. For example, lightning warp can traverse a longer distance than flame dash, so when you try to operate on that ranged terrain layer, it's more than just having walkable ranged pathfinding data because the distance itself matters, but if you don't perform the calcs exactly like the client does, you're bound to end up with issues (although it's hard to say if such issues will matter or not without trying)
The best way to study this and play with it, would be in The Riverways. I don't think I have an image saved atm, but I recently looked into this idea and decided ultimately, it'd make for a killer feature if you could get it to work nicely, but the problem is such a system is so counterintuitive for pathfinding, because you're then spending more (real)time trying to figure out a faster way to traverse the terrain (which you only spend a few minutes in and then throw away forever since the game is proc genned) as opposed to just speedily moving along an easy to generate melee based path that will almost always work (as long as you handle terrain changes from dynamic objects ofc)
Basically, if it takes 1 minute to fully traverse an area to get to the next area, then having to spend any amount of time doing processing on the terrain before you start moving renders the feature useless (for bots at least) if the net result is you taking longer than 1 minute to traverse the area. That's the biggest challenge I think you'll have, how to balance the overhead vs any possible speed boosts gained from using it. Extensive pathfinding logic is generally CPU heavy, but you can also look into offloading it by having server sided pathfinding (which would be useful for multiple characters in the same area anyways for coordination)
You do need the heightmap for correct melee based movement, but only for cursor/world mapping. It won't ever be perfect though, because the client has some nasty bugs still that once you trigger them, you'll shake your head and have to adjust your code for. Fellshrine still has tiles near the Church entrance that will trap bots because of the cursor/terrain mapping for example. There's no real way to avoid those issues other than by having a better "player mover" system when it comes to moving the mouse in a more human-like way to not trigger the client issue but those issues are all human triggerable as well so you can't prevent it entirely
It's certainly worth looking into and is an interesting problem to solve, especially if you're familiar with pathfinding stuff, but it also seems like one of those "you just have to throw enough time at it and it'll either be good enough or no longer worth the time" types of issues.
Thanks that makes sense.
Here’s sort of what I was planning on testing.
Take the total travel distance remaining on current melee path. If ledge/gap nearby then calculate a valid position on other side of ledge, calculate total path distance from that jump point to nav target and compare the total distance of both paths. You would only run these calculations if near a wall, minimum current pathing distance is long enough and only allow the calculation to be attempted periodically (say once a second in background).
The edge case I’m worried about is when you’ve got maps with different layers such as act 1 where you have to backtrack to find a ramp vs just jumping the ledge. Far less worried with more advanced stuff where path finding wouldn’t already have you following that ledge wall anyways, would be super difficult to do that type of path finding for me where it’s a totally alternate route.
I’ve got plenty more important things to work on before I start making things more fancy but wanted to make sure that I was headed the right direction before I dive into hours of math lol.
Currently my only goal is a super simplified follower script. Existing one has plenty of great logic but is complicated for end users and half the features are broken.
Last edited by Sikaka; 02-03-2021 at 09:18 PM.
-
Member
Originally Posted by
rcmartone
Hi,after install the new update (today at 18:47 in brazil),my map (the central map) don't show anymore enemies in area of map,tried restart program and deactivate/activate all options.
Screenshot by Lightshot
Thanks!!!! (PS:Sorry about my english hahaha)
Any fix help,please???
Last edited by rcmartone; 02-03-2021 at 11:09 PM.
-
Elite User
Originally Posted by
Silent_Warrior
Seems Delve plugin not working after last patch

Also tried to compile it from
IlliumIv
btw, works good on previous release (3.13.12)
I highly doubt it works on 3.13.12, the only changes were a few offset fixes and catching a exception with the chatbox. Most likely the last game update broke it. (The one which changed the map offsets)
My current stance on plugins is, I am personally looking into the plugins listed in the default section. Others will in most cases not get maintained by me. If a plugin developer has a specific problem with the Api, e.g. a missing offset or another Api bug, feel free to reach out to me in here or in a private message.
You can as user obviously still post here about working / broken plugins, just dont wonder if I skip those posts.
Originally Posted by
rcmartone
Any fix help,please???
From first post:
If you run into any problems please read the Troubleshooting section in this post, the last point (Nothing worked) tells you what to do if the section did not solve your problem.
Questions which ignore this message will be ignored by me.
-
Contributor
Originally Posted by
Sikaka
Currently my only goal is a super simplified follower script. Existing one has plenty of great logic but is complicated for end users and half the features are broken.
If all you're doing is a follower script, then I feel your task is a lot simpler than you think.
A human moving around the map efficiently (across unwalkable areas using skills) provides you all the information that I was talking about is hard to figure out in an automated way.
In other words, the follow bot doesn't technically have to do any pathfinding of its own as long as it has the same movement skills as the character it's following and doesn't leave spawn range of the player it's following. Ideally though, you can still support melee based pathfinding to fix stuck issues or desyncs automatically.
All you have to do is collect the information of where movement is taking place, and when a movement skill is being used, as in "at this position, a movement skill was used with this destination", and that should be all you need, because you'll know exactly where on the map a move skill can be used to cross unwalkable terrain without using any ranged pathfinding data because the player is solving that problem for you.
-
Member
@Queuete
Is there working MapsExchange for your repo?
The one from Illiumlv's github fails to compile I'm guessing that it's been changed for TC's repo or something?
Code:
2021-02-04 13:30:18.243 +01:00 [ERR] MapsExchange -> CompilePlugin failed2021-02-04 13:30:18.247 +01:00 [ERR] MapsExchange -> PoeHelper 3.13\Plugins\Source\MapsExchange\src\MapsExchange\MapsExchange.cs(426,74) : error CS1061: 'Element' does not contain a definition for 'InventorySlots' and no accessible extension method 'InventorySlots' accepting a first argument of type 'Element' could be found (are you missing a using directive or an assembly reference?)
2021-02-04 13:30:18.247 +01:00 [ERR] MapsExchange -> PoeHelper 3.13\Plugins\Source\MapsExchange\src\MapsExchange\MapsExchange.cs(588,47) : error CS1061: 'AtlasNode' does not contain a definition for 'GetLayerByTier' and no accessible extension method 'GetLayerByTier' accepting a first argument of type 'AtlasNode' could be found (are you missing a using directive or an assembly reference?)
-
Active Member
Originally Posted by
pushedx
If all you're doing is a follower script, then I feel your task is a lot simpler than you think.
A human moving around the map efficiently (across unwalkable areas using skills) provides you all the information that I was talking about is hard to figure out in an automated way.
In other words, the follow bot doesn't technically have to do any pathfinding of its own as long as it has the same movement skills as the character it's following and doesn't leave spawn range of the player it's following. Ideally though, you can still support melee based pathfinding to fix stuck issues or desyncs automatically.
All you have to do is collect the information of where movement is taking place, and when a movement skill is being used, as in "at this position, a movement skill was used with this destination", and that should be all you need, because you'll know exactly where on the map a move skill can be used to cross unwalkable terrain without using any ranged pathfinding data because the player is solving that problem for you.
Yes for sure but I prefer generalized solutions that can be applied to many problems.
I found that the existing follower with no path finding gets stuck very easily (but yes mimicking path of leader would solve that) and ofc has broken functionality for using area transitions, looting, etc,
Goal is follower, then advanced follower that can run through the acts (so talk to npc, loot quest items, pull levers etc). Once it goes past basic aura bot following then the other logic becomes necessary. Once all those steps are done then it would really just need a basic scripting engine and combat/explore logic to let it complete the acts on its own. Obviously that’s a BIG over simplification
-
Elite User
@Sikaka @pushedx I am always happily reading the extensive posts from pushedx. Nevertheless the stance on bots based on ExileApi is still unchanged. A public bot based on ExileApi is most likely the death of the whole project. While I also dislike private bots based on ExileApi because depending on GGGs detection methods those could be a danger aswell, I am not able to do anything against those.
Please dont discuss bot developement in this thread, thanks!
Originally Posted by
Tonkan
@
Queuete
Is there working MapsExchange for your repo?
The one from
Illiumlv's github fails to compile I'm guessing that it's been changed for TC's repo or something?
Code:
2021-02-04 13:30:18.243 +01:00 [ERR] MapsExchange -> CompilePlugin failed2021-02-04 13:30:18.247 +01:00 [ERR] MapsExchange -> PoeHelper 3.13\Plugins\Source\MapsExchange\src\MapsExchange\MapsExchange.cs(426,74) : error CS1061: 'Element' does not contain a definition for 'InventorySlots' and no accessible extension method 'InventorySlots' accepting a first argument of type 'Element' could be found (are you missing a using directive or an assembly reference?)
2021-02-04 13:30:18.247 +01:00 [ERR] MapsExchange -> PoeHelper 3.13\Plugins\Source\MapsExchange\src\MapsExchange\MapsExchange.cs(588,47) : error CS1061: 'AtlasNode' does not contain a definition for 'GetLayerByTier' and no accessible extension method 'GetLayerByTier' accepting a first argument of type 'AtlasNode' could be found (are you missing a using directive or an assembly reference?)
Short answer is I dont know. For the longer answer I will quote myself from a few posts ago:
"My current stance on plugins is, I am personally looking into the plugins listed in the default section. Others will in most cases not get maintained by me. If a plugin developer has a specific problem with the Api, e.g. a missing offset or another Api bug, feel free to reach out to me in here or in a private message.
You can as user obviously still post here about working / broken plugins, just dont wonder if I skip those posts."
-
Member
Originally Posted by
Queuete
@
Sikaka @
pushedx I am always happily reading the extensive posts from pushedx. Nevertheless the stance on bots based on ExileApi is still unchanged. A public bot based on ExileApi is most likely the death of the whole project. While I also dislike private bots based on ExileApi because depending on GGGs detection methods those could be a danger aswell, I am not able to do anything against those.
Please dont discuss bot developement in this thread, thanks!
Short answer is I dont know. For the longer answer I will quote myself from a few posts ago:
"My current stance on plugins is, I am personally looking into the plugins listed in the default section. Others will in most cases not get maintained by me. If a plugin developer has a specific problem with the Api, e.g. a missing offset or another Api bug, feel free to reach out to me in here or in a private message.
You can as user obviously still post here about working / broken plugins, just dont wonder if I skip those posts."
I understand, thank you for your answer.
-
Active Member
Originally Posted by
Queuete
@
Sikaka @
pushedx I am always happily reading the extensive posts from pushedx. Nevertheless the stance on bots based on ExileApi is still unchanged. A public bot based on ExileApi is most likely the death of the whole project. While I also dislike private bots based on ExileApi because depending on GGGs detection methods those could be a danger aswell, I am not able to do anything against those.
Please dont discuss bot developement in this thread, thanks!."
Understood, will keep it out of here. Thanks!
-
Active Member
Originally Posted by
hudman
Attempting to use this fork of Stashie:
GitHub - IlliumIv/Stashie: og. Author: Nymann
It has worked until recently when it now fails to compile. I believe it is this commit:
Big Refactor . IlliumIv/Stashie@25c4487 . GitHub
This introduced a new method "WaitFunctionTimed" which is not supported by this version of exile api. I am assuming this is a new feature in the other fork of exile api. Is there any chance of adding this method (and potentially other new functions) to allow support for Stashie and similar plugins going forward?
I have pushed the necessary Update to ExileApi Community Fork to support the newest Stashie Version which btw is being developed here: GitHub - nymann/Stashie: A stashmanaging plugin for PoeHud
Preaches aka nymann doesnt seem to be active right now so all development is done by me.
I recently did a first iteration of refactoring Stashie, especially with the focus of making the Plugins Source Code more modular readable and hopefully encourage people to pick up development and send some PR's if they have done work on it. Even though the mentioned Github Repo does not belong to me i have rights on it and can accept PR's.
For anyone interested the next thing i want to work on is updating the itemData process. Instead of copying relevant itemdata in an essential redundant object id like to take information directly from ExileApi's Inventory Data at time of execution with minimal caching involved and hopefully open up more filtering possibilites.
One thing i am currently struggeling with is MetamorphSamples Mods. So if any hobby dev wants to help out that would be a good place to start.
Besides that the affinity keyword is active and works well so far.
I have also started to work on a wikipage on the repo with all available keywords, a description and a possible Use Case example to make your own filters easier (but thats a WIP)
Regarding the drifting of the two ExileApi Forks: I have access to the private one and you guys are overexaggerating quite alot. The differences are fairly slim and its just a matter of reminding myself that when i change API stuff on the private fork and use those in one of my plugins to just shoot a quick PR to the community fork.
so TLDR: i will try my best to have the community fork in mind when changing stuff. If i forget, just remind me.
my github: https://github.com/Arecurius0/
Contributor of https://github.com/nymann/Stashie
-
Post Thanks / Like - 4 Thanks
-
Member
hi, any chance to pickit work properly on high juicy delirium maps? it stops after pick some items the reason i thikn coz there is so much loot