[X] My Assistant

As a rule, compile time is better than run-time for HV, because we want our scripts to load fast enough to be able to smoothly override HV hotkeys,

then why not run the script at @document-start?

setup time seems a huge problem on Chrome, and mostly not on Firefox for me.

*You''have to wait to check the health then though (mousemelee) (on hover maybe)

That could speed the things up probably.

Razor320: There are not always only 3 cwbt elements - if you're on low health, the flashing of it is done by layering another HP with different color on top of it and changing the opacity.

Oh, in that case we can get parent elements (with 'cwbdv') and look at first 'cwbt' element.

Owyn, not all browsers support @run-at tag, and browsers which support it handle scripts differently. Generally, 'document-end' value means, that script is run exactly after html data is parsed and DOM is constructed for page (DOMContentLoaded event), when 'document-start' runs script before html loaded, so there isn't any node which can be used to set keyboard hooks other than 'window'.

Also, behavoir of Tampermonkey and Scriptish is different in this case - @run-at in Tampermonkey defines earliest moment at which script could be injected, while in Scriptish it is a hard directive for script injection. For example - if script takes too long to load, it could be executed after all content is loaded, even if it has '@run-at document-start'. Scriptish will delay loading of page, so until script finishes execution, page doesn't load further.

update
Modern JavaScript engines use JIT compilation. Tampermonkey and Scriptish cache scripts in browser's memory, so they will not recompile at each injection. Matter of setup time in case of great number of listeners or html modification is greatly overestimated. Insert a short shippet of code to look at loading times, and see yourself, that generally it takes less than few milliseconds to execute scripts. In my practice - 3-8 msec max for script ~40Kb size (code size, not data).

If anyone could describe, what you need from mousemelee, i can write it from scratch.

This post has been edited by Razor320: Jan 29 2014, 18:15

Mousemelee Light 1.1: Hover cursor over monster to attack.
 hvmml.user.zip ( 464bytes ) Number of downloads: 474

A very small Mousemelee Light update to make the script more resilient to changes to the environment (by other scripts or a HV update).


Mousemelee Light+: Hover cursor over monster to attack. Stops on specified conditions.
 hvmmlp.user.zip ( 685bytes ) Number of downloads: 825

Introducing Mousemelee Light+! Like Lement's Mousemelee, you can now prevent hover attacks when hp/mp/sp are too low.

Razor320:

Also generates 4 of that. And 4 of that's parent. There's a reason why I check the length of HPMPSP for MP and SP. Furthermore, the cycle may be more "code" thing, but only really applies when one checks for HP, MP and SP. If it is any 2 of them or just 1 it is better to have individual lines, because, well, cycle for 2 elements seems kind of silly. Actually, even with 3 you're not saving any space or using less variables here.

And as for textContent, I initially used innerText -but that didn't work on firefox....Hence the uglier DoM climbing, which is a far older, more accepted standard.

@Compile time:

All saved lines speed up, each and every one of them do - hence why I uploaded MouseMeleeGenerator instead of having options like HVStat does. If you don't want to be stopped from attacking at low HP and leave the value to 0, the compiler will not include the line about HP.

You could perhaps make it smidge faster by checking HP after an attack has been made, perhaps, but it is naturally lot more risky.

As for keeping the compiled code in memory, I've heard that. And at least before the 4t/s limit, I could also visibly see the slowdown of HVStat even with all options turned off. I've tested stuff like having a just a single HV hotkey overriding in the start - can hold down and HV hotkey won't get called - and then that same hotkey overriding followed by giant if(false) statement - Oh hai focus there why am I dead - and can only conclude that no matter how it is kept, each line matters.

And that's why I created a script compilator instead of having bunch of variables for options at the top.

Lement:
innerText is not in standard. textContent in. So far every major browser supports `textContent` (IE and Android browser also). Also, textContent should work faster or same as children[0].children[0], and you will be free from modifications in case developer adds or removes a layer of 'divs'.

Just checked and, no, additional text added in 'cwbdv' before normal node.

CODE

<div class="cwbdv">
    <img src="http://ehgt.org/v/s/barsilver.png" class="cwb2" style="width:41px" alt="health">
    <img src="http://ehgt.org/v/s/barfg.png" class="cwb3">
    <div class="cwbt" style="z-index: 10; opacity: 0.4;" id="healthflash">
        <div class="cwbt1">
            <div class="fd2" style="width:120px; height:16px">
                <div style="text-align:center; color:#CB000A; font-family:Trebuchet MS; font-size:10pt; font-weight:normal; font-style:normal; margin-top:-4px">
                    2335 / 6890
                </div>
            </div>
        </div>
    </div>
    <div class="cwbt">
        <div class="cwbt1">
            <div class="fd2" style="width:120px; height:16px">
                <div style="text-align:center; color:#FCFF00; font-family:Trebuchet MS; font-size:10pt; font-weight:normal; font-style:normal; margin-top:-4px">
                    2335 / 6890
                </div>
            </div>
         </div>
    </div>
</div>

Have you any measurements of actual execution speed of "parametrized" and "static" versions?

This post has been edited by Razor320: Jan 29 2014, 19:59

As a rule, compile time is better than run-time for HV, because we want our scripts to load fast enough to be able to smoothly override HV hotkeys, especially with things like addEventListener, and also because we don't stay very long on any single page as opposed to most javascript more complex javascript usages you might encounter. But for you, in this case specifically? Run tests. Browsers can vary a lot.

So I reckon, for HV, one signle window.addEventListener to handle all clicks/mousemove/etc... is more favorable than having like 10 eventListener for 10 elements

So I reckon, for HV, one signle window.addEventListener to handle all clicks/mousemove/etc... is more favorable than having like 10 eventListener for 10 elements

For this count of listeners it won't make any difference, try yourself. Shorter code will make slight difference if JIT doesn't work for userJS. Not using event capturing will save some time though.

Lags of userJS in chrome is a matter of chrome itself. Use "@run-at document-start" and place code within listener of `DOMContentLoaded` event.
Don't inject code in page with <script> tags. Use event listeners and create events to trigger them, that would be also faster (at least in not triggering DOM refresh, it is funny, when in some scripts i see injecting at <body> - this trigger refresh on almost entire page - and then look at statements about execution speed), because js in a one-time injected <script> tag very likely will be executed in interpretation mode only.

PS. Users of Tampermonkey and Scriptish can use `unsafeWindow` internal object to obtain access to page javascript. So you can read credits value just using `unsafeWindow.current_credits`.

This post has been edited by Razor320: Jan 29 2014, 22:47

@Razor320: Argh, you're right about cwbdv - I searched and found 4 of it, forgot about OC because it uses cwbt2 so it nearly never comes up.

As for textContent, if it is truly regular, might as well use it - tbh I used innerText because, well, chrome, and it'd seem obvious then that textContent would be for something not chrome. Making things easier to write is good. Speed, well that's what JSperf is for.

As for actual measurements of parametrized and static, I have not actually checked if having a number in three places is better than declaring a variable and using that instead of the number in those places. But for larger, parametrized version and static minimal, yes, I have tested it, and while my ping is a bit too small to properly run it by stopwatch/timer there is a reason why there is HVMA even if one can just turn the features in HVStat off - if(false){code} can still lag.

It's an interesting idea of using DOMContentLoaded in such way. Also, that is cool, useful tip about Tampermonkey/scriptish even if I won't be using it.

holy_demon: Well, if you're injecting the 10 elements, possibly in response to one another, one is indeed probably more favorable - DOM injection is not optimal.

I have this idea for some time. How you think, if shop bot would be illegal? I mean, it is an automation, but not a gameplay automation, private trading between players don't seem to me like gameplay element.

Something like userJS script, that checks mail (forum mail or mogglemail) perodically for appropriate requests and serves them without player intervention. It also should be capable of maintaining actual list of items in form of post in forum thread.

Theoretically quite possible, I've been thinking of running a free shop with a helper script - I certianly wouldn't do it without human oversight, only checking stuff periodically.

There are though some troubles like a) multi-accounting due multiple IPs, (IMG:[invalid] style_emoticons/default/cool.gif) most people won't be able to have a computer running and c) anybody who would care enough to configure it would go through the effort of just checking HV periodically and using in-built user interface instead and d) the latter also means no fear of sending off your collection gear, for example.

As for legality, once you have something concrete, PM 10b as it is does not perform simple things.

This post has been edited by Lement: Jan 30 2014, 21:48

version 1.0  fastest_mouse_melee.user.js.zip ( 1.06k ) Number of downloads: 59

version 1.1  fastest_mouse_melee.user.js.zip ( 1.02k ) Number of downloads: 59


latest version https://forums.e-hentai.org/index.php?s=&am...t&p=3034527

Introducing Mousemelee Lightning+! Like Lement's or Dan31's Mousemelee :3

- 'Shift' hotkey to disable the script till you turn it back on or restart the browser *or launch the game in another window\tab (you can see when it's turned off in the Title)

- Show colored borders arounds monsters if low on hp\mp\sp (like in original MouseMelee) (works even when disabled)

= Works only for Firefox (sorry, Chrome can't handle its awesomeness)

Just was testing stuff and made this. It sets onhover attributes of monsters in the moment they appear and not later, did some measurments and this seem to show a bit better results than original mousmelle (might be better on faster computers)

my timings in ms between monster hits:

CODE

this: 276,267,269,244,255,245,250,257,267,322,325,284,269,276,274,279,255,327,282,272,287,275,268,270

original: 285,270,266,286,239,281,261,266,265,271,295,258,260,282,265,250,280,272,268,250,272,287,267,282

This post has been edited by Owyn: Jan 31 2014, 21:59

Hm. About timings, if you can get 250ms between monster hits(what did you use, btw?) you're doing 4 turns/second and are capped.

you're doing 4 turns/second and are capped.

what cap are you talking about?

I used simple js ( now - lasttime )

what cap are you talking about?

I used simple js ( now - lasttime )

HV is throttled at 4 turns per second, server-side.

Where is the link to that Mousemelee Lightning+ of yours, btw?

This post has been edited by Dan31: Jan 31 2014, 16:12

HV is throttled at 4 turns per second, server-side.

sad =\ Well, now at least I won't blame the speed of my computer for not doing HV faster

Where is the link

attached it but forgot to embed xD thx for telling.

I checked your script, it's basically mine with a key to enable/disable the script. Plus the fact it runs at document-start.

Dan31, well, three lines to check hp mp and sp are exactly yours, hovering is a method you used, warning coloring is original of Lement, hotkey and installing of your hovering override is mine (haven't seen those anywhere here)

fact it runs at document-start.

that's the point of the new script.

Plus the fact it runs at document-start.

He also used MutationObserver to add the mouseover event as soon as a monster element is added. So he doesn't have to wait for the entire DOM tree to load. Pretty cool trick

Owyn, note about `sessionStorage` - it is different for any browser window. So, when you open new window with HV, its sessionStorage is empty. This is Firefox behavior. (I write 'window' - tabs also counts as windows)

Why you don't use `m[n].onmouseover = m[n].onclick`? Assigning reference is much faster than copying string.

I doubt that MutationObserver is faster than standard method. At first, it is not guaranteed that it fires before DOM is completely built, it only provides ability to run custom code when DOM is changed and faster than MutationEvent. At last, checking every node with javascript? Or allowing DOM to select objects with optimized algorithm? What should be faster?

And, finally, that doesn't matter (IMG:[invalid] style_emoticons/default/smile.gif) Either way, execution time probably less than 5ms.

This post has been edited by Razor320: Jan 31 2014, 17:46

So, when you open new window with HV, its sessionStorage is empty. This is Firefox behavior. (I write 'window' - tabs also counts as windows)

Forgot to write about that in the description, thx (IMG:[invalid] style_emoticons/default/happy.gif) I made the hotkey just to stop mousemeleeing when monsters get too strong, so user shouldn't change windows when he's fighting monsters

Why you don't use `m[n].onmouseover = m[n].onclick`? Assigning reference is much faster than copying string.

thought about that after I archived and uploaded the script, but was too lazy to test that it's working and update,
+reference changing doesn't change the html of the element, so it would stay the same there which would be pretty weird (at least to me)

anyway

Either way, execution time probably less than 5ms.

I doubt it gonna be more than 1ms, but I'll fix it after few tests.