[X] My Assistant

concerning the matter of stop on buff expiration:

Go easy sickentide.. (IMG:[invalid] style_emoticons/default/smile.gif)
Your frustration is fully understandable, especially by how hard you've worked on Monsterbation for the rest of us.
Just speaking for myself, it's the best script I've seen on this site.

However comma... (IMG:[invalid] style_emoticons/default/smile.gif)
Psychological reciprocity could cause an immediate ban on buff expiration.
And we don't want that. (IMG:[invalid] style_emoticons/default/smile.gif)

(Your script rocks! )

This post has been edited by RoadShoe: Jul 1 2017, 03:26

Go easy sickentide.. (IMG:[invalid] style_emoticons/default/smile.gif)
Your frustration is fully understandable, especially by how hard you've worked on Monsterbation for the rest of us.
Just speaking for myself, it's the best script I've seen on this site.

However comma... (IMG:[invalid] style_emoticons/default/smile.gif)
Psychological reciprocity could cause an immediate ban on buff expiration.
And we don't want that. (IMG:[invalid] style_emoticons/default/smile.gif)

(Your script rocks! )

thank you. i'd just like some clarity as to whether i should pursue the matter of automatic expiration stop further or take a different route and make expiration of certain buffs more visually obvious to the player without causing an automatic stop

concerning the matter of stop on buff expiration:

i don't like the ruling that "it's fine as long as the counting is done internally." either you want players to pay attention to effect durations at all times or you want to allow them to use a script to help with that. it should be decided by how you want people to play the game, not by what can be done technically

so please either ban the function outright or make it fully legal, none of this half-way nonsense

This is very true. Why would internal timers be allowed, after the hard work has been done once all user will be using it. Then, the play experience will be exactly the same as when the expiration data from screen would be used. Why force coders to write difficult internal timers for buff tracking? The effect for all other users is the same!

Mmm......these recent comments seem to reflect my sentiments on the pony chat.

Anyway, I though of something:

Position and resize non-autocast buffs like this:



Note that the soonest expiring spell covers the entire right of the monster box.
The entire buff bar is aligned right.

Make it so that on load, attack listeners on monster box are removed.
Only on hover of the big buff bar are attack listeners on monster box added and the buff bar disappears, enabling the user to attack.

When a buff expires, due to being aligned right, the buff bar will no longer cover the monster boxes, the user's mouse, which should be positioned on the monster boxes, would not touch the buff bar. As a result, attack listeners are not added and they can't attack.

This way, we do not need the script to make a decision, yet can autostop.

The only downside is that we would need the user the configure how many buffs they normally use so we can position it just right. Also it can be ugly, unless we can also make it invisible (IMG:[invalid] style_emoticons/default/heh.gif)

Mmm......these recent comments seem to reflect my sentiments on the pony chat.

Anyway, I though of something:

Position and resize non-autocast buffs like this:



Note that the soonest expiring spell covers the entire right of the monster box.
The entire buff bar is aligned right.

Make it so that on load, attack listeners on monster box are removed.
Only on hover of the big buff bar are attack listeners on monster box added and the buff bar disappears, enabling the user to attack.

When a buff expires, due to being aligned right, the buff bar will no longer cover the monster boxes, the user's mouse, which should be positioned on the monster boxes, would not touch the buff bar. As a result, attack listeners are not added and they can't attack.

This way, we do not need the script to make a decision, yet can autostop.

The only downside is that we would need the user the configure how many buffs they normally use so we can position it just right. Also it can be ugly, unless we can also make it invisible (IMG:[invalid] style_emoticons/default/heh.gif)

Interesting solution! This might work!

For my part, I don't understand what's the deal with detecting buff expirations.
I mean, seriously, we have a vanilla blinking on the buff's icon when it's about to exprie, so why in the hell all this fuss about detecting when a buff is about to expire ?

Could someone explain me?

For my part, I don't understand what's the deal with detecting buff expirations.
I mean, seriously, we have a vanilla blinking on the buff's icon when it's about to exprie, so why in the hell all this fuss about detecting when a buff is about to expire ?

Could someone explain me?

I'm still new to the discussing, but my understanding is the problem is on stopping the user from attacking due to buffs expiring.

The script cannot use information available on the page to make that decision, else "it would be against the rules".

For my part, I don't understand what's the deal with detecting buff expirations.
I mean, seriously, we have a vanilla blinking on the buff's icon when it's about to exprie, so why in the hell all this fuss about detecting when a buff is about to expire ?

Could someone explain me?

I'm still new to the discussing, but my understanding is the problem is on stopping the user from attacking due to buffs expiring.

The script cannot use information available on the page to make that decision, else "it would be against the rules".

It's easier to keep up all scrolls + infusion + regen + arcane focus if the hoverplay stops at the moment that one expires. It's just ease of play. For me, my conclusion is that I could live without this after playing without for a while. Visible warning would be somewhat helpful, but if forbiddent then it's okay for me.

Only one addition would be ESSENTIAL for playing Ffudorfest: I died again on round 550 of PFFUDOR fest - @Scremaz, can we please, please have 'Disable Imperil Keybind In Case OF Emergency"?

After that, the bounty can be released for my part.

This post has been edited by DJNoni: Jul 1 2017, 11:44

I can live with no stop on buff expiration because I have Spark on at all times, but frankly if we could chose what buff expiration stops the hovering and what buff shouldn't, that'd be great. Or at the very very least a background that warns us without stopping the hovering.

For my part I'm lacking only one thing right now before being OK: the round counter. Like the "63/80" we used to have.

Side note : I'm averaging 2.2 turns per second. It's not bad, but it could be better aswell. Frankly, I do feel like it's the server that is a bit slow at answering, not the script being poorly optimized.

This post has been edited by decondelite: Jul 1 2017, 12:28

For my part I'm lacking only one thing right now before being OK: the round counter. Like the "63/80" we used to have.

CODE

  
// ==UserScript==
// @name           round counter
// @version        1.0
// @author         OMP
// @grant          none
// @match          *://*.hentaiverse.org/*
// @run-at         document-start
// ==/UserScript==

(function() {
  window.addEventListener('DOMContentLoaded', function() {
    var battle = document.querySelector('#textlog > tbody');
    if (battle) {
      var round,
          logs = document.querySelector('#textlog tr:nth-last-child(1)').textContent,
          log = logs.match(/Round (\d+) \/ (\d+)/);
      round = log? log[1] + ' / ' + log[2]: localStorage.HVRoundCounter;

      if (round) {
        var final = round.split('/'),
            x = document.body.appendChild(document.createElement('div'));
        x.textContent = round;
        x.style.cssText = 'position:absolute;top:13px;left:203px;width:362px;text-align:right;font-size:20px;font-weight:bold;';
        switch (final[1] - final[0]) {
          case 0 : x.style.color = '#FF0000'; break;
          case 1 : x.style.color = '#FF8C00'; break;
        }
        localStorage.setItem('HVRoundCounter', round);
      }
    } else {
      localStorage.removeItem('HVRoundCounter');
    }
  }, false);
})();

This post has been edited by DJNoni: Jul 1 2017, 12:24

Round counter is supposed to be in the script's release. It's written in the first post. (IMG:[invalid] style_emoticons/default/wink.gif)
But I guess that this bit of code will do in the meanwhile.

For my part, I don't understand what's the deal with detecting buff expirations.
I mean, seriously, we have a vanilla blinking on the buff's icon when it's about to exprie, so why in the hell all this fuss about detecting when a buff is about to expire ?

Could someone explain me?

the matter is not what can be done and whatnot. the matter is what can be done while complying tenb's guidelines. having a couple features less is way better than having hovering banned, afaik.

Round counter is supposed to be in the script's release. It's written in the first post. (IMG:[invalid] style_emoticons/default/wink.gif)
But I guess that this bit of code will do in the meanwhile.

sending, saying, 1M to OMP is another option.

Only one addition would be ESSENTIAL for playing Ffudorfest: I died again on round 550 of PFFUDOR fest - @Scremaz, can we please, please have 'Disable Imperil Keybind In Case OF Emergency"?

erm... i'm pretty sure admin would say that when you do something you should pay attention to what you do... (IMG:[invalid] style_emoticons/default/heh.gif)


@ topic: anything else, apart for the internal timers thing and the hook on-site scripts thing?

erm... i'm pretty sure admin would say that when you do something you should pay attention to what you do... (IMG:[invalid] style_emoticons/default/heh.gif)

So that means you're not even gonna ask? This f*cks PFfest. Might as well delete the whole option.

So that means you're not even gonna ask? This f*cks PFfest. Might as well delete the whole option.

provide me another useful use of such a feature and i'll ask (IMG:[invalid] style_emoticons/default/smile.gif)

you know, for how you presented it, it seems to me that's a feature useful only for mages on deep PFfest who rely too much on the scheme "Imperil, Imperil, Imperil, Shoot". i'm pretty sure that admin didn't go under all these troubles for such a thing...

i was uncertain whether the round counter should only appear in the end-of-battle statistics or any time during battle. it does the latter now

The quibar extend+spell cooldown+bind is really awesome.
I'm using Alt+S to cast Sleep, and it's basically the same way than using the default Alt+1-0 of the default bar.

(IMG:[i.imgur.com] http://i.imgur.com/NTYeTAz.jpg)

This post has been edited by decondelite: Jul 1 2017, 20:47

you know, for how you presented it, it seems to me that's a feature useful only for mages on deep PFfest who rely too much on the scheme "Imperil, Imperil, Imperil, Shoot".

to be fair there's not really any other efficient options other than to imperil imperil imperil shoot, and when you do hundreds of rounds where that's the best path it's very easy to misclick. Personally I've died to this myself. it's actually much safer (but conversely much slower) for me to go non imperil style even at high difficulties (IWBTH for me) because there's too much risk otherwise to try to notice SoL procing and stop myself from pressing a number key in less than the span of a second.

This post has been edited by abc12345678901: Jul 1 2017, 20:54

to be fair there's not really any other efficient options other than to imperil imperil imperil shoot, and when you do hundreds of rounds where that's the best path it's very easy to misclick.

you know it. i know it. but i cannot go to admin blatantly telling him "hey, people would like this feature so they can blindlessly play as mages". maybe i'm only counting the chickens before they hatch, but still... (IMG:[invalid] style_emoticons/default/heh.gif)
as i said, a better reason is all what i need.


@ topic: so, now spells are returned on the left? so nostalgic... (IMG:[invalid] style_emoticons/default/wub.gif)

This post has been edited by Scremaz: Jul 1 2017, 22:22

Quick question: how do we bind skills? I tried Cast('Shield Bash') but it doesn't work.

you know it. i know it. but i cannot go to admin blatantly telling him "hey, people would like this feature so they can blindlessly play as mages". maybe i'm only counting the chickens before they hatch, but still... (IMG:[invalid] style_emoticons/default/heh.gif)
as i said, a better reason is all what i need.

here's a workaround that should leave everyone happy: in the latest version you can hold shift to hover-imperil, with the usual hover safeguards

Quick question: how do we bind skills? I tried Cast('Shield Bash') but it doesn't work.

skills should work the exact same as spells

This post has been edited by sickentide: Jul 1 2017, 23:34