3.79 is another compatibility fix for beta users - the previous fix uncovered another subtle change in the underlying WME code (the livemap link now needs to be referenced by the element classname rather than the id...) which annoying I hadn't noticed until after 3.78 had already been published.


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

Completely unrelated to URO+, but apologies for the below par nature of my spelling today - "seeming" and "worrying"??? My keyboard definitely is still capable of stringing together the letters l and y to form a -ly suffix, so how I managed to completely miss adding it in both of the previous posts is a mystery

Olestas wrote:Keyword filter does not seem to work.. or I don't understand how to use it..

The only thing you ought to be aware of is that it uses case-sensitive matching, and the "Invert feed filter behaviour" setting also applies. Other than that, there really shouldn't be anything to it.

Do the other feed filters still work OK for you?

CBenson wrote:Sorry for the delay I was unable to reproduce the issue until today. Today it is back (only when I use the INTL server).

Ah... I think I know what the problem is now, and I think it's your visiting one of the "foreign" servers rather than using a malformed PL that's causing the issue. The debug console screengrab you provided was a big clue BTW, I really should start ignoring any bug reports that don't come with them

To confirm my suspicions, please can you disable all scripts and go onto the INTL server again, then click on the Areas tab and tell me if you've got anything listed there. I suspect the answer will be no...

That's the answer I was after. Thanks, I'll try fixing this tonight.

Developers anecdote #47: the reason I can't replicate this bug here is due to an unexpected bit of WME behaviour (which I've now posted about in the beta forum). Although I have a combination of driven and AM areas on both the World and US/Canada servers, I *shouldn't* have either on the Israeli server. However, when I switch WME over to that server and check the Areas tab, it lists two driven areas, both of which are actually located in the UK... So despite having switched back and forth between the three servers countless times since the URO+ update that introduced this bug, these "ghost" areas on the Israeli server have prevented the bug from ever being triggered for me.

3.80 fixes the startup loop that occurs if WME is running on a server where the user has no driven areas...


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

Grrrr, I'd completely forgotten about that particular WME foible... will hopefully find some time to work around its effects on cloning before the end of the week.

m4rc072 wrote:It would be possible to have the possibility to select the Place to see by tipe (Area or point)?

Inviato dal mio OPO con tapatalk

That should be possible, yes.

Double meh with a side of bah humbug... A fix for this in in progress, though since URO was never designed to be restarted except via a "cold boot" session reload, making sure that it now restarts cleanly after the "warm boot" of exiting MTE mode is turning into a bit of a slog.

It also seems to have ballsed-up WMEOD a little, so I'll get that sorted out too.

3.81 now correctly handles switching in and out of MTE mode. RPP cloning now copies over the city/county/country attributes. And places can now be filtered by area/point geometry types...


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