[X] My Assistant

You might want to check when you bind the num handler (IMG:[invalid] style_emoticons/default/wink.gif) (now that i think about it, same should go for the right click handler)

I'm not sure what you mean, could you explain better?
Thanks.

And this is just me being nitpicky, but there seem to be different formattings going on, [jsbeautifier.org] this might help (IMG:[invalid] style_emoticons/default/happy.gif)

This i will do, after all why not.

I'm not sure what you mean, could you explain better?

You should not add event listerners on OnPageReload since they run each time the page gets reloaded.
That code should go in initialPageLoad.

You should not add event listerners on OnPageReload since they run each time the page gets reloaded.
That code should go in initialPageLoad.

Oh, right, damn.
I overlooked that.
I'll try to fix that up.
Thanks.

This post has been edited by gianfrix94: Jan 25 2017, 20:31

You should not add event listerners on OnPageReload since they run each time the page gets reloaded.
That code should go in initialPageLoad.

Yeah, this. Though my next hint would have been how often (IMG:[invalid] style_emoticons/default/laugh.gif)
I suppose something else prevents multiple xhr firings in any case, otherwise you would probably have noticed earlier. It just generates lots of garbage in this case, esp with 1h build and long rounds.

// Edit
Just to be clear, not trying to be mean, just wanting more people to understand more about the frameworks they move in, to prevent the situation we're in with EQCompare where only 2-3 people still understand how it works and of those 2-3 people 1-2 people don't post here or are on hiatus.

This post has been edited by simrock87: Jan 25 2017, 17:04

...

No problem, if you see some problems with what i write feel free to tell me always, this was more of an oversight than anything else.
I'm not too experienced in JS anyway (IMG:[invalid] style_emoticons/default/heh.gif)
Thanks.

PS: I took a look at EQCompare once, and i can understand why some feel it's daunting (IMG:[invalid] style_emoticons/default/heh.gif)

@Sapo84
@simrock87
Question for you two, since i'm sure you know CC well:
When Reloader and CC work together, the Keybinds that are in CC set up only once right, at the start when it loads up, and then all the rest gets refreshed by Reloader with setupCc and updateCc, right?
Sorry if the question is stupid (IMG:[invalid] style_emoticons/default/heh.gif)

"This version also seems to be quite slower, due to numerous lag spikes. I also noticed that my laptop's fan runs at a faster speed, so I guess that my CPU is having it rougher with this 1.3.4."
Not on my pc, that's pretty subjective.

I didn't know that a computer could be subjective...
And I've got an i5, I'm not planning on investing into a high-end computer to play a browser game.

It takes me twice more time to register a single action with that version, me wanting it or not. It's only a fact and I'm not putting any judgement in it.

Oh, right, damn.
I overlooked that.
I'll try to fix that up.
Thanks.

See? I'm still waiting for the apologizes. (IMG:[invalid] style_emoticons/default/happy.gif)

I'm looking for the next version eagerly with both this improvement and the keybinding for Imperil. I'm with sapo when it comes to being practical. Even if the entire left area of the mob is used for the right click, we still need to first identify the SG, then hover there, then right click, then hover to the damage area. While with a key, you simply press the key while you haven't even identified the SG yet, and you cna use the entire monster area to deal damage.

This post has been edited by decondelite: Jan 25 2017, 21:10

I didn't know that a computer could be subjective...
And I've got an i5, I'm not planning on investing into a high-end computer to play a browser game.

It takes me twice more time to register a single action with that version, me wanting it or not. It's only a fact and I'm not putting any judgement in it.
See? I'm still waiting for the apologizes. (IMG:[invalid] style_emoticons/default/happy.gif)

I'm looking for the next version eagerly with both this improvement and the keybinding for Imperil. I'm with sapo when it comes to being practical. Even if the entire left area of the mob is used for the right click, we still need to first identify the SG, then hover there, then right click, then hover to the damage area. While with a key, you simply press the key while you haven't even identified the SG yet, and you cna use the entire monster area to deal damage.

I mostly use a Core Duo, and it isn't really slower... but it's probably fault of my connection, i guess.
The Keybinding was added already, for the fix of not setting the Listeners at every page reload instead it will take some time, as i'm not really sure how to go about it decently to not make a mess of the code (IMG:[invalid] style_emoticons/default/heh.gif)
Btw, if you aren't going to Imperil all the enemies, you have to identify the SGs anyway before shooting imperil at them, even with the numbers.

This post has been edited by gianfrix94: Jan 25 2017, 21:13

@Sapo84
@simrock87
Question for you two, since i'm sure you know CC well:
When Reloader and CC work together, the Keybinds that are in CC set up only once right, at the start when it loads up, and then all the rest gets refreshed by Reloader with setupCc and updateCc, right?
Sorry if the question is stupid (IMG:[invalid] style_emoticons/default/heh.gif)

Now that i'm done writing, this seems a bit too detailed, but wth, could be useful if someone wants to get into CC and Reloader (IMG:[invalid] style_emoticons/default/heh.gif)
TLDR;
You have parts that require the DOM to be loaded, Reloader to be present or nothing at all.
---

Hmm, not sure how far you've gone into CS in general, but generally think of it this way.

I'm assuming Vanilla Reloader for now as it's a little simpler than the full bore.

You have two lines, one for Reloader and one for CC.

As JS in Browsers only has one Thread it only executes one script or function at a time. So the basic setup of both has to stand on its own. Both scripts are injected at document-start, so theoretically before the page is fully loaded.

Let's assume Reloader goes first (almost random in reality but doesn't make a difference as it stands), Reloader need a DOM and access to it to work properly, so has to wait until everything is loaded to inject itself (otherwise it wouldn't work in chromium based browsers), so Reloader now waits until the DOM is loaded and the Thread/Line gets suspended until the DOM is built (signified that document emits a 'DOMContentLoaded' event).

Now, the browser has nothing to do so switches to CC, in the way CC is written, it first just hangs function reference points, does the basic setup of Settings and binds eventHandlers. In case no reloader is present, it just runs setupCC and updateCC in succession and then you get a new page where all starts again. As we usually have CC with Reloader it just binds setupCC to the 'Reloader_page_reloaded' that gets triggered when Reloader has successfully entrenched itself and updateCC for when the xhr has gone through successfully and the page has been updated with new data. That's for the first run

Then we get back to Reloader again, 'DOMContentLoaded' might have been emitted or not by now, if not it just sits and waits so that's uninteresting for now, when it gets emitted Reloader does the whole injection thing as in it puts itself as a new <script> tag in the head and executes itself. This part so far is pretty boilerplate for now for pre-Reloader scripts that work natively in chromium. Then Reloader just does the same as CC and just defines stuff first off and then runs into OnPageLoad(). This fn replaces the submit action of the form (and does some nifty stuff to circumvent sandboxing without GM or TM *cough*, then emits 'Reloader_page_reloaded' and does the basic stuff to do on new turns, which basically is just resetting the on site Battle script and emit 'Reloader_reloaded'. That's Reloader done again for now.

So, now Reloader has emitted it's two events and their respective handlers sort of get queued inside the browser. CC now has setupCC() for 'Reloader_page_reloaded' which came first and does it's basic setup now, which just resets some vars to a clean state and places elements that stay for the whole duration of the round. Then CC runs updateCC() as we also received a 'Reloader_reloaded' event and updates some fluctuating stuff like consumables, removes old elements from the previous turn, unlocks run time protections and starts the general logic inside prepare(). prepare() itself just checks for buffs and then binds hover handlers to the monster elements or, if you're still hovering over a monster, just fires its hover.

That's the setup so far and both scripts essentially do nothing for a while (in relative terms) until something happens. Usually this is some sort of 'mouseover' event on the monsters, or key handler, in any case at some point the battle form gets submitted (or for Reloader you click on the hidden submit button (*hint hint* sandbox work around)).

Now Reloader comes back into play as it has replaced the usual submit action on the form with its own submit action. This submit action now fires a xhr request, instead of the standard http post through the browser. When you get a reply from the server, Reloader catches it, parses for the useful bits and replaces the previous elements with the new elements. This is actually the part that makes Reloader faster than the standard, as the browser does not have to re-render as much as when you do a whole page refresh.
After that's done you get a new 'Reloader_reloaded' event and CC does it's thing again as before.

This repeats until the page changes through a normal http request or gets reloaded and the cycle begins anew.

...

Woah, this answer was far more than what i was expecting.
Thanks (IMG:[invalid] style_emoticons/default/smile.gif)

i hope this is the right place to ask..

im using reloader version 1.3.3b and you can use t1 spell as default action.

is there any way to put weaken or any deprecating spell as default?
which part should i add or edit?

thanks.

nver mind, got it figured out. thanks.

This post has been edited by diegodiego13: Jan 25 2017, 21:42

Ok, fixed that bug, now the event Listeners are in initialPageLoad.
You can find the new version here: Reloader 1.3.5b

Tell me if you find anything else out of place, thanks (IMG:[invalid] style_emoticons/default/smile.gif)

PS: Thanks for jsbeautifier simrock, it was useful.

PPS: By the way, my way to move Listeners without modifying half the code was maybe a bit unconventional, i guess. So, question to the programmers.
I made a pair of functions anonymous and put them in global scope variables, to make them able to be called from the initialPageLoad scope.
Was it a bad approach, in the sense that it could be slower than others, or it's ok like i think?

This post has been edited by gianfrix94: Jan 26 2017, 03:38

Gonna try it tomorrow and tell you if it works better. Thanks.

Gonna try it tomorrow and tell you if it works better. Thanks.

Good, let me know. Thanks to you too (IMG:[invalid] style_emoticons/default/smile.gif)

An update towards the new url redirection

Project_automation 1.0.2

[attachmentid=98238]

Ok, fixed that bug, now the event Listeners are in initialPageLoad.
You can find the new version here: Reloader 1.3.5b

Tell me if you find anything else out of place, thanks (IMG:[invalid] style_emoticons/default/smile.gif)

PS: Thanks for jsbeautifier simrock, it was useful.

PPS: By the way, my way to move Listeners without modifying half the code was maybe a bit unconventional, i guess. So, question to the programmers.
I made a pair of functions anonymous and put them in global scope variables, to make them able to be called from the initialPageLoad scope.
Was it a bad approach, in the sense that it could be slower than others, or it's ok like i think?

I find the 1.3.5b a bit slower but it doesn't lag on pots or other actions. I would rather go back to the 1.3.5 and put up with the occational lag, if not for the speed on onmouseover for the script.

Is there a sort of general comprehensive script for the basic changes that most people want for HV? I've been looking around but all I can find is piecemeal stuff.

I used to use something called the HV statistics, tracking, and analysis tool but it seems to have broken since I last played (about 2 years).

Is there a sort of general comprehensive script for the basic changes that most people want for HV? I've been looking around but all I can find is piecemeal stuff.

I used to use something called the HV statistics, tracking, and analysis tool but it seems to have broken since I last played (about 2 years).

Check out fatal's script compendium

[blog.chromium.org] https://blog.chromium.org/2017/01/reload-re...er-page_26.html

(IMG:[invalid] style_emoticons/default/rolleyes.gif)

I wonder if this will make performance boost from our hand optimized reloader scripts negligible or even worse

rip firefox

---

Looks like it has been around since chromium 54
Anyone noticed any improvements?

This post has been edited by FabulousCupcake: Jan 26 2017, 19:00

[blog.chromium.org] https://blog.chromium.org/2017/01/reload-re...er-page_26.html

(IMG:[invalid] style_emoticons/default/rolleyes.gif)

I wonder if this will make performance boost from our hand optimized reloader scripts negligible or even worse

rip firefox

Don't worry, Firefox is killing itself, no need for help by Chromium (IMG:[invalid] style_emoticons/default/laugh.gif)