LP.Input / PHM

[Meta4]

Meta4's question thread

Posting my questions here instead of making 1 thread/subject, whenever they might arise.
Not expecting answers to everything but it's nice when it happens, and I get to not spam the forum. :>
__________________________________________________________________________________________
Ok, sooo..
a) LP.I.PressKey / ReleaseKey do the exact same thing (press and release) Edit: This isn't true, nor useful
b) PHM.SetState() does nothing noticeable
c) PHM.ClearAllKeyStates() .. considering a) and/or b) what does this even do?

Scenario:
1. I want to send press and only a press of a specified key or mousebtn.
2. I want to send release and only a release a specified key or mousebtn.
3. I want to check and only check the state of a specified key or mousebtn.


I feel like I'm missing something cause.. a) and b) !?!

Thanks

Edit: That de-escalated quickly.. let the above scenario and implied questions be null. Would still be curious to find out the reason for which it is how it is. (Cause intent or cause not useful/worth it?)
Edit2: So it's by design. Should've checked phm's lock behavior before.. -.-

So far LokiPoe.InGameState.SkillBarPanel.BeginUseAt() seems to be the only way to go

 

[pushedx]

Why don't you tell me what you're trying to accomplish, and I'll get you pointed in the right direction.

If it's just trying to make skills cast even when the bot isn't hooked between frames, then yes, BeginUseAt is the only way to achieve that (although it's built from the input/phm functions you also have access to).

Basically, with the way this game works, you can't tell the client to just start casting something, and then it continues to cast on its own; you have to emulate that behavior, which is what the systems we have in place do, but in such a way we don't have to take control of your PC, just input for the game itself.

 

[Meta4]

Thanks, but I didn't have anything specific in mind with that.

Been reading that input is the big issue when running at low fps, and low fps is really cheap on resources so I wanted to give tweaking that a shot (in the future), but have since moved on from that ideea.
Maybe the input delay could, in the future, optionally be an "iTickable" with bool IsReady() and void Tick(). The int field obstructs control, can't implement various logics regarding frameCount, frameTime, simple randomization, etc.

On a different subject, could you help me with understanding the ExternalReadCache as gotten through TemporaryCacheState and SaveCacheState?
My 'theory' so far is that TemporaryCacheState is a wrapper over DisableCache() and EnableCache() that works like the FrameLock/Release objects. How about SaveCacheState?
And what is "hardlock"? I kind of get what happens when hardlock=true, but what about when it's "false"? If you don't feel like explaining, maybe tell me what to look for to figure it out?

Not trying to achieve anything specific with the greymagic stuff either, but it seems like potentially very useful knowledge.

 

[darkbluefirefly]

Thanks, but I didn't have anything specific in mind with that.

Been reading that input is the big issue when running at low fps, and low fps is really cheap on resources so I wanted to give tweaking that a shot (in the future), but have since moved on from that ideea.
Maybe the input delay could, in the future, optionally be an "iTickable" with bool IsReady() and void Tick(). The int field obstructs control, can't implement various logics regarding frameCount, frameTime, simple randomization, etc.

On a different subject, could you help me with understanding the ExternalReadCache as gotten through TemporaryCacheState and SaveCacheState?
My 'theory' so far is that TemporaryCacheState is a wrapper over DisableCache() and EnableCache() that works like the FrameLock/Release objects. How about SaveCacheState?
And what is "hardlock"? I kind of get what happens when hardlock=true, but what about when it's "false"? If you don't feel like explaining, maybe tell me what to look for to figure it out?

Not trying to achieve anything specific with the greymagic stuff either, but it seems like potentially very useful knowledge.

Hardlock;

its so current frame is left, so you can run stuff without freezing client, then its acquired again.

and rare quote from sensai.

and you can play with that if you want, but you'll see the exceptions as a result, if you set LokiPoe.UseHardlock = false, you'll notice there's hardly any frame overhead since the bot is no longer synced with the client (other than a few forced places)
basically, the design of the API as a whole needs to be re-done for how the client currently works and what we know about the game after years of messing with it. When we first wrote the API, the client behaved a lot different, and we didn't even have a hardlock until I bugged someone to code it for us to solve the memory problems
as a result, the current design, is more or less Frankenstein code, especially object manager, but it's just good enough to work compared to how it used to.

 

[Meta4]

Thanks dbf, in that case..
I don't think I could/should have a use of framelocks without hardlock.

The lock/release system is awesome!
Please never remove the public LokiPoe.Memory

I was testing my npc-stuff wrapper the other day and realized that calls to Npc.Converse, Purchase, etc.. have a pretty random/long delayed effect. (which I find good, props for not making it wait around in the call)
I could already envision the logics code getting littered with 'wait-around and check' code. And then magic: i just added a 6 line long bool SpinUntil(msTimeout, delegateCheck, msThrottle=50) method to my memory wrapper, mind=blown, so simple. There was no point to iterate the bot.tick for npc stuff, not like I'm gonna open PurchaseTab and instead of waiting I'm gonna decide I got something better to do elsewhere in those x00 ms, so why leave the tick or sprinkle waits in the logic code.
Ugh, I've missed these. Ramble done

            Timer Timeout = new Timer();

            using (Unlock) using (NoCache)
                while (!Timeout.Done(msTimeout))
                {
                    if (Check()) return true;
                    Thread.Sleep(msThrottle);
                }

            return false;

 

[darkbluefirefly]

Thanks dbf, in that case..
I don't think I could/should have a use of framelocks without hardlock.

The lock/release system is awesome!
Please never remove the public LokiPoe.Memory

I was testing my npc-stuff wrapper the other day and realized that calls to Npc.Converse, Purchase, etc.. have a pretty random/long delayed effect. (which I find good, props for not making it wait around in the call)
I could already envision the logics code getting littered with 'wait-around and check' code. And then magic: i just added a 6 line long bool SpinUntil(msTimeout, delegateCheck, msThrottle=50) method to my memory wrapper, mind=blown, so simple. There was no point to iterate the bot.tick for npc stuff, not like I'm gonna open PurchaseTab and instead of waiting I'm gonna decide I got something better to do elsewhere in those x00 ms, so why leave the tick or sprinkle waits in the logic code.
Ugh, I've missed these. Ramble done

            Timer Timeout = new Timer();

            using (Unlock) using (NoCache)
                while (!Timeout.Done(msTimeout))
                {
                    if (Check()) return true;
                    Thread.Sleep(msThrottle);
                }

            return false;

Awesome, Keep in mind.
There are delays for a reason, you will get flagged for doing things too fast. This advice you should heed.
And Gl on coding =). The Api is wonderful to use and pushedx has 99% of the bases covered. Also allows 'hacky' customizations too =).

 

[Meta4]

#Pathfinding #RD #ExilePather

I know i can test these for myself, and I will if no answers by the time I get to it, not lazy, but at this point info is much appreciated.

A) ExilePather:
PathDistance(Vector2i start, Vector2i end, bool ignoreWallHugging = true, bool dontLeaveFrame = false);
PathExistsBetween(Vector2i start, Vector2i end, bool dontLeaveFrame = false);

Do these actually do a complete path retrieval? (Same performance)

B) Also:
WalkablePositionFor(Vector2i position, int maxDistance, bool noCache = false, bool dontLeaveFrame = false);

Seeing the "dontLeaveFrame", does it try a lot of times? Does it actually try to path to it or just onMesh && isWalkable?

C) RDPathfinder:
TileCache.AddTempObstacle(Tripper.Tools.Math.Vector3 pos, float radius, out uint obstacleRef)

Is this functionality implemented? Is it handled by Loki? (I didn't see it getting stuck in mobs but I might've just been lucky xD)
Is UpdateObstacle for calling after add/remove?

D) Raycasting, or CanObjectSee
Raycast(Loki.Common.Vector2i start, Loki.Common.Vector2i end, out bool result, out Loki.Common.Vector2i hit)

What can this raycast hit? (Seeing it has no height, I'm a bit confused..)

 

[darkbluefirefly]

I know i can test these for myself, and I will if no answers by the time I get to it, not lazy, but at this point info is much appreciated.

A) ExilePather:
PathDistance(Vector2i start, Vector2i end, bool ignoreWallHugging = true, bool dontLeaveFrame = false);
PathExistsBetween(Vector2i start, Vector2i end, bool dontLeaveFrame = false);

Do these actually do a complete path retrieval? (Same performance)

B) Also:
WalkablePositionFor(Vector2i position, int maxDistance, bool noCache = false, bool dontLeaveFrame = false);

Seeing the "dontLeaveFrame", does it try a lot of times? Does it actually try to path to it or just onMesh && isWalkable?

C) RDPathfinder:
TileCache.AddTempObstacle(Tripper.Tools.Math.Vector3 pos, float radius, out uint obstacleRef)

Is this functionality implemented? Is it handled by Loki? (I didn't see it getting stuck in mobs but I might've just been lucky xD)
Is UpdateObstacle for calling after add/remove?

D) Raycasting, or CanObjectSee
Raycast(Loki.Common.Vector2i start, Loki.Common.Vector2i end, out bool result, out Loki.Common.Vector2i hit)

What can this raycast hit? (Seeing it has no height, I'm a bit confused..)

a) You use obect.Distance(otherobject.position) to get a rough idea of where something is, once you are within 100~ units, use Exilepather.
Exilepather is more CPU intensive then the first because it actually gets "walkable" positions.
If you were to lets say use the first to get an object. The object is below you, you will get a larger(or smaller depending) value on where the object is, because it just does a distance check. Exilepather takes into account all the positions and will give you a correct return value.

Path exists between, I believe, checks all the points from A-B to make sure it's traversable. Leave frame is recommended, due to CPU required work.

b) Walkable position finds a position on a walkable TGT(I think), again this requires CPU work.
Pushedx, will have to elaborate on this more.

c) I've never used it, or needed a use for it.

d) raycast is a crude raycast, I think it accounts for obstacles. Cansee, is raycasting as well but does not account for obstacles.

Gotta wait for pushedx to confirm.

 

[pushedx]

Do these actually do a complete path retrieval? (Same performance)

Yes.

Seeing the "dontLeaveFrame", does it try a lot of times? Does it actually try to path to it or just onMesh && isWalkable?

Don't leave frame is for a different concept. To put simply:
(Executing Frame 1) Game Frame #1: Player's life component address is at 0x1000.
WalkablePositionFor is called and leaves the frame
(Executing Frame 2) Game Frame #5: Player's life component changed, and is now at address 0x2000. Any objects that were cached and accessed from when the execution started are now invalid.

Is this functionality implemented? Is it handled by Loki? (I didn't see it getting stuck in mobs but I might've just been lucky xD)

It's not supported, but it should be functional, but I don't think it will work correctly because meshes aren't updated after generation (which was removed for performance reasons a while ago).

Is UpdateObstacle for calling after add/remove?

That function isn't for users. Basically, our RDPathfinder wrapper is really old now, but it was the best pathfinding possible at the time (current system was put into place early 2014, 6 months after we launched with a different system), and it's not been touched since. I do want to revamp it in the near future, since we have new updated stuff from other bots, but it's something that affects so much, there's just not been a good enough time to try.

What can this raycast hit? (Seeing it has no height, I'm a bit confused..)

Pathfinding data is all 2D in PoE (and there's a lot of it). The game does have height, but height affects how coordinates are mapped between the world and your screen coords.


Basically, the pathfinding and terrain stuff in EB is really basic, and rough, but it's because of how the game works, and we've yet to find a better way to handle it. As a result, we're still stuck with what's there, and the random side-effects that occur we just have to code around as best as possible.