How often are you seeing that appear? I put this in as part of the ongoing battle to resolve (or at least minimise) the problem of the wrong UR details being shown, but since this is one of those glitches that seems to be damn near impossible to trigger on demand I wasn't able to properly test the behaviour of this code.

So if you are seeing it regularly enough to have felt it necessary to comment on, given that 3.90 has only been available for around 6 hours, this suggests there's something about your system or the way you perform UR maintenance that's causing it to trip more often. And I'd *love* to know what that is...

Ahh, scratch that, I've just realised what you're probably doing... I'll put in a fix later today, the problem is that if you've ever moused-over or clicked on a UR marker within the map view during the current editing session, and then click on a UR entry in the feed list, it'll incorrectly trip the "other UR opened" detection code due to the UR having been opened via the feed "backdoor" rather than via a direct "click on the marker" which is where the problem actually occurs that I'm trying to address.

In the meantime, either try and avoid highlighting or clicking on any UR markers within the map window if you want to select them from the feed list, or only select them via direct clicks. A quick session reload will also clear the underlying tracking data that triggers the message, allowing URs to be selected from the feed again without any issue.

Sorry for any inconvenience this might cause

russblau wrote:The "Clone" RPP feature in 3.90 still has a bug relating to city/state/country names. The city name always appears as "undefined" for the cloned place.

Based on what I know has changed in WME, this is going to be a new bug rather than anything that's been present for a while. Might not seem like there's much of a difference from an end user perspective, but from my perspective as the person who knows the previous bug here was fixed and now gets to do it all over again thanks to the devteam, it's quite a big difference

I would have fixed this last night, as well as releasing the fix for the "wrong UR opened" popup, but my car had other ideas about how I should be spending the evening - a gearbox failure plus a 3 hour wait for a recovery truck meant I didn't get home until 2am

3.91 changes...

• The UR click monitoring popup is now only enabled when URO+ is running in debug mode
• RPP cloning works again
• Places can be filtered by their creator/last editor
• 7KM/H is now accepted as a valid segment speed limit in Germany
• PLIAP MPs now get their own filter setting

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

Don't tempt me Iain, I was already considering a different custom marker for SLURs before they disappeared...


As a note to self, I've just noticed that RPP cloning sets the house number on the clone to NaN if the house number field in the original RPP contains non-numerical data...

Also, TfL MPs now have an empty [] tag, preventing their custom marker from being applied - need to work in matching of the provider details as well as/instead of description text matching...

3.92 includes the following changes:

• Segment popup now includes MTE name in closure information
• Fix for closure event selection bug in Firefox
• Removes the "Choose Event" non-event from the closure event dropdown
• Closure cloning now includes the MTE setting
• RPP cloning now works with non-numerical house number values
• Custom marker and filtering support restored to TfL map problems
• Feed filtering now includes MP feed entries

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

iainhouse wrote:is that a special just for me, or does everyone get that?

Just thee and me, it's triggered by editor ID... I'd finished off all the real updates and was in a slightly happy mood at fixing the various MTE dropdown issues (that whole closure UI is one giant furball of weirdness in how it behaves ) so decided to have a bit of fun

3.93 enables filtering of the two new types of "Missing Parking Lot Place" MP (aka Type 70 and Type 71) that've recently started cluttering up the map like a very cluttery thing indeed, and the mere existence of which on your editor screen starts to get annoying after about 25 femtoseconds give or take a smidge...


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

Before anyone asks, no, the type 70/71 filters haven't been broken by another sneaky WME update, Waze now appears to have nuked all of these MPs just as they did with SLURs recently - yet another knee-jerk reaction required to fix a problem they really should have been able to predict and avoid creating in the first place...

PesachZ wrote:3.93 doesn't update (at least for me) the version number in the browser storage, so I get the changelog pop-up everytime I load WME.

Odd... Please try the following:

* Reload your WME session
* Change the state of the URO+ "Enabled" checkbox next to the version number
* Reload the WME session again

After this second reload, does the "Enabled" checkbox get set to whichever state it was in after you changed it, or does it revert to whichever state it was in immediately after the first reload?