Simple Flask Manager for PoeHUD

[WorkingPour]

I run an MoM build. I'm 86 right now. Every level, every node, every item upgrade can change my maximum mana by enough to have noticable affects on my flasking for flasks that trigger on mana.Sometimes its higher sometimes its lower, but every time I it changes I then have to go in and modify every single flask linked to mana, where if i could just use a percentage the only time I'd have to adjust them is if I want to change when I want them triggered.

tl;dr any time I level up/get a new piece of gear/take a new node my maximum mana changes and I have to manually adjust every flask because the flat number changes where with a % I wouldn't have to do that every single time.

Perfect example. If I have to choose between #mana and %mana then no contest, %mana all the way.

% or absolute doesn’t matter to me, choose any you want I will implement it.
But what I am against is both of them in the flask manager at the same time.

So choose one and I will implement it.
But other one have to go away then.

I vote %mana. Maybe create a poll and message everyone that's bought in and have a vote?

[upsala]

skills take #mana, so it's ok how it works now.

[GameHelper]

Perfect example. If I have to choose between #mana and %mana then no contest, %mana all the way.



I vote %mana. Maybe create a poll and message everyone that's bought in and have a vote?

I will do that voting poll

[poetesttt]

Does the flaskChargeReductionMod work now?

It's seems not due to sometimes the flasks still available with few charges, but the plugin will not use it.

[GameHelper]

Usecase 1: the way flask manager works is it search the flask array ( 0 to 4 ) and drinks whichever is ready to drink ( decision based on triggers )
But you can’t say it will always drink left one first or one with higher chargers first as you never know where in the array is your flaskmanager when the trigger happened. But there is no priority given to any flask for any reason. ( see first post number 1 rule )

Usecase 2: you mark a flask insta based on its usage. So for a 50% insta flask ( meaning it’s insta on low life only ~ low life is <35% life ) and you want to trigger this flask only on low life only then you should mark it as insta flask. If you want to trigger this 50% insta flask on high life don’t mark it as insta. So it totally depend on the usage of insta on low life flask. That being said currently multiple triggers on a single flask isn’t allowed ( ailment is an exception to this rule ) meaning 1 single flask ( let’s say 50/50 insta flask ~ insta on low life ) can only be used as insta or as normal flask but not both. I am working on implementing multiple triggers but you want to wait for that feature. Let me know if that answers your question.

Usecase 3:utility flasks are never insta, that doesn’t make sense....why would be a utility flask be insta that’s stupid!

[GameHelper]

Does the flaskChargeReductionMod work now?

It's seems not due to sometimes the flasks still available with few charges, but the plugin will not use it.

That might be broken due to offset changes....I will double check it once I come back.

[upsala]

Usecase 2: you mark a flask insta based on its usage. So for a 50% insta flask ( meaning it’s insta on low life only ~ low life is <35% life ) and you want to trigger this flask only on low life only then you should mark it as insta flask. If you want to trigger this 50% insta flask on high life don’t mark it as insta. So it totally depend on the usage of insta on low life flask. That being said currently multiple triggers on a single flask isn’t allowed ( ailment is an exception to this rule ) meaning 1 single flask ( let’s say 50/50 insta flask ~ insta on low life ) can only be used as insta or as normal flask but not both. I am working on implementing multiple triggers but you want to wait for that feature. Let me know if that answers your question.

Bubbling "50% of Recovery applied Instantly" is not low life btw ) so its 50% insta 50% regain on any level of life.

How differs work of insta flask on or off? What it affects in plugin logic exactly? Non-insta just prevents to reuse it until regain finished? To make decision I have to understand how this flag changes algo.

"2: Triggers should define when to drink the flask ( the new architecture have the ability to incorporate any trigger you guys can think of )."
According to your post, trigger CANT define when to drink, first its full random on equal flasks, next u not described logic of condition check in terms of sequence. Just for stupid example, 2 insta flasks same. 75% condition is true, both flask have to trigger. But there is delay between flask use and nothing simultaneously can happen in computer world ) Do u recheck condition after delay? So in our example some flask activated and can heal over 75% to avoid activation of second flask? Or u use tick system to flag what to drink and do not recheck after delay? Next step in theory crafting. Lets assume u do recheck conditions between flask use, and 75% not overhealed. Do u proceed to second flask check-use? Or every time after delay u check ALL flasks again? If second, first flask will reapply until 75% or empty, never activate second.

Usecase 3:utility flasks are never insta, that doesn’t make sense....why would be a utility flask be insta that’s stupid!

Technically utility flasks is always insta. Effect applies immediately. So u have to note, that insta flag is only for mana/life? If u really do not check type of flasks inside, interesting how insta flag will affect utility? Because u removed type of flasks from terms(im not sure that inside plugin u dont check type of flask), we have to understand how its applied and reapplied. Back to our examples. We have 3 utility flasks, all triggered 50% hp. Condition is true. One applied. 100ms. Second applied. Total 200ms. If we recheck conditions, now hp can be 50 or over, remember we have insta heals from first example. Third utility flask will not apply? Condition is not true for moment. And if u remember I want all 3 be activated on same condition. ALL have to triger, not just random few.

All this questions is about your internal plugin logic. Do you have queue of flasks use? Do u recheck conditions between moving from one action in queue to another? or u just check conditions every <delay> and running first flask fits condition of every type <hp, mana, utility>? Or u dont group flasks by types and running just first one met conditions....thats gonna be terrible. Im sure some queue exists.

Edit: plus there is no such thing like no priority. If u dont rule priority(thru hidden order in queue or other way) it work in priority of index in array, that means u just skipped this part of logic programming and virtually said "let the god and intel decide what flasks will apply".

[Sychotix]

Bubbling "50% of Recovery applied Instantly" is not low life btw ) so its 50% insta 50% regain on any level of life.

How differs work of insta flask on or off? What it affects in plugin logic exactly? Non-insta just prevents to reuse it until regain finished? To make decision I have to understand how this flag changes algo.

"2: Triggers should define when to drink the flask ( the new architecture have the ability to incorporate any trigger you guys can think of )."
According to your post, trigger CANT define when to drink, first its full random on equal flasks, next u not described logic of condition check in terms of sequence. Just for stupid example, 2 insta flasks same. 75% condition is true, both flask have to trigger. But there is delay between flask use and nothing simultaneously can happen in computer world ) Do u recheck condition after delay? So in our example some flask activated and can heal over 75% to avoid activation of second flask? Or u use tick system to flag what to drink and do not recheck after delay? Next step in theory crafting. Lets assume u do recheck conditions between flask use, and 75% not overhealed. Do u proceed to second flask check-use? Or every time after delay u check ALL flasks again? If second, first flask will reapply until 75% or empty, never activate second.



Technically utility flasks is always insta. Effect applies immediately. So u have to note, that insta flag is only for mana/life? If u really do not check type of flasks inside, interesting how insta flag will affect utility? Because u removed type of flasks from terms(im not sure that inside plugin u dont check type of flask), we have to understand how its applied and reapplied. Back to our examples. We have 3 utility flasks, all triggered 50% hp. Condition is true. One applied. 100ms. Second applied. Total 200ms. If we recheck conditions, now hp can be 50 or over, remember we have insta heals from first example. Third utility flask will not apply? Condition is not true for moment. And if u remember I want all 3 be activated on same condition. ALL have to triger, not just random few.

All this questions is about your internal plugin logic. Do you have queue of flasks use? Do u recheck conditions between moving from one action in queue to another? or u just check conditions every <delay> and running first flask fits condition of every type <hp, mana, utility>? Or u dont group flasks by types and running just first one met conditions....thats gonna be terrible. Im sure some queue exists.

Edit: plus there is no such thing like no priority. If u dont rule priority(thru hidden order in queue or other way) it work in priority of index in array, that means u just skipped this part of logic programming and virtually said "let the god and intel decide what flasks will apply".

Just gonna say... this entire post sounds like its from /r/iamverysmart/.

[upsala]

Just gonna say... this entire post sounds like its from /r/iamverysmart/.

Yeah, after re-reading feels like that. But I wrote it because started to do test and found that its unclear how plugin work internally. Next I found that we dont have this information. Asked few questions. From answers found it can work in the way that is really, really strange from programming point of view, otherwise I dont get zaafar concepts. This questions, its more about idea, not implementation. "No priority" thing absolutely non-existent in programming, either u ignore existing priority, not building your own( u do normalized "pseudo-random" or worse case "god know how it works"), nor u hide it. Same thing about "simultaneously", it's not exist. Everything in computer works step by step, never ever same time. Nothing can happen same time, always something goes first, its nature of processors.

[Sychotix]

"No priority" thing absolutely non-existent in programming, either u ignore existing priority, not building your own( u do normalized "pseudo-random" or worse case "god know how it works"), nor u hide it. Same thing about "simultaneously", it's not exist. Everything in computer works step by step, never ever same time. Nothing can happen same time, always something goes first, its nature of processors.

You should really look into multi-threading and multi-core processors. This entire statement is false.

[upsala]

You should really look into multi-threading and multi-core processors. This entire statement is false.

1. MT is emulation, on single core its just manage time quotas between threads. Thats why MT not used wide, fucking semaphores and mutexes killing whole benefit.
2. I do work with multiprocessor MT years and years. Ask yourself why this technology known for at least 25 years and still almost not used? Answer is simple. Amount of real world tasks that can be programmed in MT way is very strict. Video pre-processing is good example. But most real-time tasks with human being operator is not working with MT. So statement is true, with very few exceptions that hard to code. (i dont wanna go deep inside theory and discuss that multicore still share single stack and actually can run simultaneously just sub atomic routines, that blocking each other in logic flow, only different for completly separate processes with no I/O interaction)
My statement about processor (single core) is true. 1 tick do single math operation.
Anyway I dont think zaafar running own thread for every flask slot, even in this case there is priority, some flasks commands go into tcp stack before others.

[GameHelper]

I will reply to those questions when I find some free time ( maybe tonight ), I really liked that you are asking such questions.

[Sychotix]

1. MT is emulation, on single core its just manage time quotas between threads. Thats why MT not used wide, fucking semaphores and mutexes killing whole benefit.
2. I do work with multiprocessor MT years and years. Ask yourself why this technology known for at least 25 years and still almost not used? Answer is simple. Amount of real world tasks that can be programmed in MT way is very strict. Video pre-processing is good example. But most real-time tasks with human being operator is not working with MT. So statement is true, with very few exceptions that hard to code. (i dont wanna go deep inside theory and discuss that multicore still share single stack and actually can run simultaneously just sub atomic routines, that blocking each other in logic flow, only different for completly separate processes with no I/O interaction)
My statement about processor (single core) is true. 1 tick do single math operation.
Anyway I dont think zaafar running own thread for every flask slot, even in this case there is priority, some flasks commands go into tcp stack before others.

Multi-threading is a tool, not an "emulation" with time quotas between threads. If your task can be split up into multiple semi-atomic tasks and takes any significant amount of time to run... you will probably see a performance increase from multi-threading. I've had a multi-core processor since the mid 90s iirc... if you are still running a single core in 2018, you may want to upgrade. Multi-threading IS widely used... in fact Zaafar's Flask Manager is running on its own thread... just like many of the PoEHUD plugins. Multi-threaded applications are not difficult to write, and if your threads are waiting on a resource lock for extended periods of time, you need to re-evaluate your design choices to decouple the threads from this resource or maybe forego multi-threading.

some flasks commands go into tcp stack before others.

LUL. What are you even talking about here? TCP is a networking protocol.

Anyways... I'll let Zaafar handle it from here. Clearly you know what you are talking about. /s

[upsala]

....MT part....

We are talking on different levels of depth. All that MT that ordinary software developer see, using standard libs, most of it just illusion of "concurrent execution". Deep inside its step-by-step or close to it. MT widely used, because frameworks implement it, that doesnt mean threads really effectively running concurrent. Starting thread dont make u running in parallel yet. If u take a look to your windows machine, u will see that each core mostly running threads from one process, not threads from one process among few cores(sure there is exceptions, generally well coded system stuff). Guess what? All that threads inside single process running in frames of time quotas on same core, nothing "multi" happens. Hmm, i guess its not place to discuss such things.

LUL. What are you even talking about here? TCP is a networking protocol.

o'rly? *sigh* do I have to explain how chain of key presses finally builds up in order of commands going thru tcp protocol? i used tcp as final bottleneck example, that clearly shows , there is order and priority. no matter how many pseudo "multi" threads, cores, or even processors u gonna use.

P.S. dont take my words personaly, im in bad mood now, god-damned cat attacking me few hours, that beast want to play, me not.

[GameHelper]

Bubbling "50% of Recovery applied Instantly" is not low life btw ) so its 50% insta 50% regain on any level of life.

How differs work of insta flask on or off? What it affects in plugin logic exactly? Non-insta just prevents to reuse it until regain finished? To make decision I have to understand how this flag changes algo.

I cannot answer that question, only you know the answer to that question. I will give you a scenario that will let you decide should you enable/disable the instant flask.

(assuming your trigger is at 20% life)
Let's say you are fighting a hard monster and your life become 20%. You pop a bubbling (50-50) instant flask. Now your life instantly becomes 30% and flask other 50% is on. Now the hard fucking monster hit you again, and your life again becomes 20% while your flask "other 50%" is still active. Should you or should you not pop another bubbling flask? If your answer is you should, enable the instant flask. If your answer is you shouldn't then disable the instant flask.

So basically instant flask ignores your flask buff before drinking the flask. It is like a panic flask..... fking drink the flask again I don't fking care if my flask buff is up or not.

"2: Triggers should define when to drink the flask ( the new architecture have the ability to incorporate any trigger you guys can think of )."
According to your post, trigger CANT define when to drink, first its full random on equal flasks, next u not described logic of condition check in terms of sequence.

Your logic is good but your knowledge on how flasks work in POE is not enough. Triggers do decide when to drink the flask but there is a catch here. In Path Of Exile, it's useless to drink a flask if it's already being drunk before. So if you have two flasks and you have drunk 1 of them, it's useless to drink or even look at the other flask and other flask trigger (when both flasks is 100% same). That being said, only place where this logic doesn't apply is instant flask (or ailment remover flask i.e. they remove different ailment) and over there we don't look at the fact that if the flask buff is up or not we just drink them.

Now to answer the example you gave me. In your example you said 2 instant flask, which means I don't have to read any further as they would both be used at the same time if the trigger = true. If in any case before drinking the flask their trigger become false, we wouldn't drink those flask. So in short, if trigger is true => instant flask is going to pop. If trigger is false instant flask ins't going to pop. end of story. If that doesn't happen it's a bug.

Now that being said, it sounds all good in an ideal world with there is no lag, no latency, no processing delay and pressing a button on any flask did pop that flask with 0ms delay but in a real world scenario there is minor delay when we pop the flask and when that effect take place. That delay is dependent on 3 things. Processor speed to process the key, latency to the poe server and server response to the client after processing our request. Let's say all of those delay combined together to be equal to 100ms then you should set "delay after drink" to 100ms. If that is 200ms, then set "delay after drink" to 200. That change from person to person, computer to computer, location to location etc etc.

Technically utility flasks is always insta. Effect applies immediately. So u have to note, that insta flag is only for mana/life?

I will just ask you one thing, if utility flasks are instant flask in path of exile why isn't there a word instant anywhere near the utility flask name, mod name, mod defination. Until/Unless you show me a utility flask with a word instant in it ( anywhere near 100 feet from the utility flask ), I am going to say 1 thing.... Utility flasks are not considered as instant flask in path of exile and in simple flask manager. That being said, I have a logical reason to belive that utility flask are not instant flask but logical reasons can be defeated with different point of views but facts are facts.


It's round robin scheduling and as far as I remember round robin scheduling isn't a pirority based scheduling.