Well that was odd... the package I uploaded to the CWS contained the 3.11.1 code in the main user.js file, yet the filename was still set to 3.11. Meanwhile both manifest.json and bootstrap.user.js were referencing the main file with the expected 3.11.1 filename, which is something I normally only change once I've changed the filename of the main file. So I'm really not sure how the main filename ended up being wrong in the uploaded package.

Anyway, I've uploaded another package which should now work as planned - note that to get around the "you can't upload a new package with the same version number, you muppet" problem (nice of the CWS to sanity check the version number for you, be even nicer if it'd also check that the files referenced in your manifest are present in the package...) it'll show up as 3.11.1.1 in CWS, but the script itself still calls itself 3.11.1 as that hasn't changed. The .crx packed version checks out OK in Canary, so it looks like all the filename references tie up correctly this time.

Fingers crossed

SuperDave1426 wrote:Ok, I'd like to modify my recommendation regarding the "disclaimer" to be that you should indicate that it only really works if you've got the AM layer turned on in the map editor display.

It should work either way - if the AM layer is already turned on then it uses the AM area data already loaded by WME itself, otherwise it requests that data itself as you pan/zoom the map view. One niggly bit of behaviour I've noticed (and will try to address in a future release) is that this self-request mechanism doesn't work when you first open up a location via the search box, it's only once you then nudge the map view even by a single pixel that it's able to pull in the data itself.

jasonroseweir wrote:Guess I'll just need to find another challenge to tackle, perhaps the auto commenting / smart canned responses for UR conversations (unless of course you already have plans in this area too )...

I may have been giving that some thought, yes...

ply8808 wrote:An issue with false turn restrictions on multiple nodes running either top/horizontal and east/verticle or bottom/horizontal and west/vertical, nodes show blue dot when highlighted.
Ran an isolation check through all scripts and it is the URO+ on chrome.

Any chance of posting a screengrab to illustrate this problem, because I'm struggling to picture it from your description here

ply8808 wrote:Forgive my attempt on a screen shot, but here it is.
I was unable to recreate the horizontal/vertical lines but they are the same as these only they come in the NE or SW corner of screen. I can keep trying to find that situation if it will help.

Thanks for these, but unfortunately I'm still not seeing what the problem is - everything looks normal in both those screengrabs. Please can you do a step by step description of what you're doing when you see the problem, and what you believe you should be seeing instead?

SuperDave1426 wrote:Maybe that's the way that it's supposed to work, but that hasn't been the case for me so far. I move, then move the mouse, and nothing. It wasn't until I turned on the AM layer that it started showing information. And when I turned the layer back off, it stopped updating the information. Whatever was there at the time remains there. When I move off and on areas where the information had been changing with the AM layer turned on, nothing was happening with it turned off.

Let me get this clear, are you saying that if you turn off the AM layer and leave the map view exactly as it was - no panning or zooming - the AM list then stops changing when you move the mouse pointer across the same part of the screen where, when the AM layer was still shown, the list was changing? Or does it still change the list OK until you then pan/zoom the map with the AM layer turned off, at which point it then stops updating until you turn the layer back on?

Which browser, WME version (public/beta), and language and server location settings (as shown in the top-right corner of WME) are you using?

ply8808 wrote:Lots of useful stuff...

Ah, gotcha! Thanks, I'll see if I can recreate this at home. One final Q, is this on the production or beta version of WME?

3.12 addresses the issues noted by ply8808, SuperDave1426 and jasonroseweir. Thanks to all of you for your feedback, makes my life a hell of a lot easier when bugs are so neatly described and dissected


The issues noted by ply8808 and SuperDave1426 are related, and were being caused by the way the script initiated its own request for the AM data when the AM layer was turned off. In some circumstances, this request could clash with a data request placed by WME itself, and depending on which of the requests got nuked determined whether it caused ply or SuperDave's issue...

Since I don't think there's any way for a userscript to determine with any level of accuracy when a WME-initiated request has concluded, URO+ now only displays the AM list when the AM layer is turned on, putting the responsibility for requesting the AM data back into the hands of WME... A new checkbox "Hide Area Manager polygons" has then been added to the Misc tab - when this is ticked and the AM layer is turned on, the explosion of technicolour polygons that usually accompanies turning on of this layer will no longer occur, and the end result is visually identical to how 3.11.1 looked when the AM layer was turned off.



Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi

That was one of the few feature requests I never implemented, as it wasn't quite as easy to implement properly as it had first seemed.

Thanks for the filter suggestions, I'll work on those when I get back home at the weekend.