I understand, and I do appreciate all you do for the rest of us.
I agree with RichardPyne’s observation that the controls really do seem much coarser now in WME2.
Thanks, we really appreciate your work on this and will gladly wait until you get a chance to look at this, remaining grateful for what we have.
Great! Thank you Very Much
Enviado desde mi iPhone utilizando Tapatalk
I’ve found some extra time this evening, which I used to improve the script greatly. I first wasted another hour trying to add handles to the image, but failed to progress there. Then I decided to just fix the issue with the resizes being too big (turned out I had my calculations wrong), added a slider that allows you to set the sensitivity of all controls (save for the 45° rotate buttons, those are absolute) and added buttons to stretch and contract the images.
I’m currently still thinking of an alternative way of adding images, but I’d need to work out the maths for it and it doesn’t seem easy to me.
The new tools for image handling are excellent, thank you so much for this amazing and super useful script!
A quick suggestion: disable the “Add image overlay” button in the LH panel whilst you’re already adding an image. Otherwise, you might spend a few minutes rotating & resizing your image until you have it perfectly lined up - then hit the wrong button by mistake and be back to the start! :oops:
I’d ask you why you posted this, but I already know! ARGH!! lol
I’ve created a GitHub issue for that request and already added that behaviour to the version in development yesterday. I’m first going to include some other fixes/changes as well though.
For some reason, I find that there is no-longer a way to name and save an overlay.
I still have those I have made earlier, but can’t add to the list.
I thought there might be a hidden limit on how many I could have named, but even when I delete several, I can’t add a new one.
Strange. Are you not seeing the little edit icon to the right of the name? It seems to be working for me.
My bottom line contains the name of an image I already stored. I don’t see a new bottom line.
I didn’t put any limit on the amount of images you can rename. Could it be you’re getting some sort of error when you click on the edit button? (you can check for errors in the developer console with Ctrl+Shift+I)
Not sure what the problem was (perhaps a loose nut on the keyboard at this end!), seems to be working ok now.
Hi,
I’m having issues running this script. Seems like getting faulty at the OpenLayers class.
Browser: Firefox Quantum 57.0.3
Greasemonkey: 4.1
I do have to admit that I feel that Firefox quantum is a bit too fast 
(Some sites have possibly related issues as well)
Script error: ReferenceError
columnNumber: 1
fileName: "resource://gre/modules/ExtensionContent.jsm"
lineNumber: 373
message: "OpenLayers is not defined"
stack: "userScript@user-script:http%3A//www.tomputtemans.com//WME%20Image%20Overlays:373:1\nscopeWrapper@user-script:http%3A//www.tomputtemans.com//WME%20Image%20Overlays:1177:9\n@user-script:http%3A//www.tomputtemans.com//WME%20Image%20Overlays:361:17\n"
__proto__: Object { stack: "", … } WME%20Image%20Overlays:1179:23Huh. It seems like TamperMonkey is executing the script sooner than expected (before page load) on your computer. I’ll tackle that issue in the next version. For now, you can try to go into the settings of TamperMonkey, open the script, go to its settings and set the “Run At:” setting to “document-end”. If I’m not mistaken, that should make TamperMonkey wait long enough for the OpenLayers class to be loaded.
I really think Firefox Quantum is to blame. While it is lightning fast, its fastness seems like an extra hurdle. I have a lot of issues with firefox only because of this. It seems like it has still some child diseases.
Also, this particular issue seems to me to occur because of the multi-process structure of ff quantum. As javascript is single threaded but you use multiple processes, you can run multiple js’es simultaniously, so OpenLayers can loaded after the overlays script.
Personally, I think you can tackle this but this is in my opinion a case for mozilla or greasemonkey. Firefox broke this, they should fix this.
And I’m pretty sure your script is not the only script experiencing this kind of issues.
I was able to fix the issue.
As I used Greasemonkey is the past (2010 something) I installed this add-on again for this script. However, as you were refering to Tampermonkey (I was thinking this was like a chrome-addon for the same purpose) I eventually looked it up and it worked out-of-the box. (I never used userscripts except if I really had to)
So for the people having the same issue: It does not work with greasemonkey.
Oh, I hadn’t noticed you mentioned GreaseMonkey. They recently changed quite a few things making it a lot more difficult to create userscripts for it. While I won’t try to sabotage GreaseMonkey, I’m only going to be testing stuff on TamperMonkey from now on. Their version on Firefox works very well, so I’d advice everybody to use that.
Version 1.0.1 of the script has just been released. This is a technical release that replaces the internal Waze object with W, as the Waze object will be removed in about two months.
There currently seems to be an issue where the rotation of an image gets lost when you move the image afterwards. This seems to be caused by the new version of OpenLayers. I’ll try to look into it soon, but I’m a bit too busy at the moment to fix that right away.