Wrong thread I think, PM links are added by WMETB, not URO+

Yeah, I've noticed that today as well - strongly suspect a change to WME which is causing this, as I can't believe this behaviour has been present all this time without it ever being noticed till just now...

With Chrimblemass just a few days away, here's an early present from me in the shape of URO+ 3.32...

• Places can now be filtered by lock level, age of last edit and presence/absence of photos
• Option allowing place polygons/points to remain visible when their associated PUR markers are filtered
• Filtered cameras no longer generate popups
• JS console output can be toggled on/off by clicking the URO+ version number
• Compatibility fix for latest WME beta

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

Fredo-p wrote:I don't know if this URO did this, but, with the recent update, WME is now a lot lighter than before. Personally, I preferred the darker color of the editor.

Yes, that's an undocumented fix in URO - when you deselect the white background option it sets the colour back to the default WME colour, but until this release it was using the darker grey that WME originally used when the grey background was first introduced. It now uses the lighter grey to match the present WME colour scheme...

It'd be trivial to include an option to use the darker grey as well, or even to make the background colour user definable - I'll add it to the to do list for the next release.

Can't reproduce this behaviour here - are you able to stop it if instead of completely disabling one or the other script, you instead leave them both running but alter the settings within each script?

If not, do you have any other WME scripts/add-ons enabled as well, and if so, does this behaviour still occur if you have *only* URO+ and WMETB enabled?

I was assuming jemay is using a mouse button remapping option in their OS/mouse driver to assign the primary button to the right rather than the left.

In what I suspect will be the final release of 2014, 3.33 lands with a thud to bring you:

• URLs in segment restriction popups are now clickable
• Petrol Station Checker UR filter has now been removed
• "Update watchlist entry" option in camera popup now actually does what it says it does...
• Map background colour is now user-definable
• New filter options to hide URs except those commented on or closed by a specific editor
• Custom comment markers (aka the Mickey Mouse ears) are now shown on custom-tagged URs
• Performance optimisations

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

Hmm, I can't replicate this in either FF or Chrome

qazxcvbnmm wrote:1) I'm getting this quite regularly in the LA MapRaid area. Perhaps it is related to having many many URs in the map.

2) I also found that the filter by reporter often doesn't stay set to the selected user when you pan around.

3) When hiding by "Without comments by user", it seems the other hide options stop working. In particular, the "Last comment less/more than X days ago" stops working when "Without comments by user" is selected.

1. Possibly, although there are more than enough URs in London (my home turf and where I do pretty much all my script testing) to give any UR-based code a damn good workout.

2. The reporter lists are generated in realtime from the names which are present in the map data at that point in time, so if you scroll out of an area where the selected editor has been active, their name will no longer be present in the list and so the script deselects it. I'll look into making it a persistent selection so that if the user is no longer present in the area it still remembers them unless you deliberately change the selection.

3. Confirmed (bah humbug...) I'll fix this next year

In that case I wonder if it's related to the UR loading problems - if the UR data isn't all loading as expected, the script may end up generating a new list using the incomplete data. If this is the cause, it would also be "solved" by making the selection persistent.