Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!
Discussion for the unofficial, community-developed addons, extensions and scripts built for the Waze Map Editor.

The official index of these tools is the Community Plugins, Extensions and Tools wiki page.
Post by Twister-UK
khaytsus wrote:I always hide UR's with "Last comment less than 4 days ago", but that always hides the UR marker when the user gets back to me so if their marker is relevant to the report (ahem) I have to un-hide it. Is it possible to un-hide the current UR being viewed?
You mean, if you open up WME via a link containing an "&mapUpdateRequest=" property? Yeah, I could include an option to ignore the filtering options for any UR referenced in the link URL. And even if that wasn't what you meant, it sounds like far too good an idea to ignore :)
khaytsus wrote:I've always thought that if you set options like "If last comment made by UR reporter" to No, it would un-hide but perhaps I don't understand how all of those work.. It seems to be all Hide, none that'll not hide.
Correct, the filtering is always doing its best to hide the URs, so as soon as any one filter meets the requirements to hide a UR it'll be hidden no matter how many of the other filtering options would leave it visible. I'd love to allow the creation of more complex filtering rules (e.g. hide a UR if conditions A and either B or C are met, but only if conditions D and E are not also being met), but I can't think of a way that would allow such a rule to be defined easily within the limitations of the UI elements available to us.
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
qwaletee wrote:I'm thinking you could have this done somweher around 2018-2019.
Optimist!
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
Morais69spbr wrote: When I open config/extensions to reactivate it... an alert shows that this occurred because it requires a new PERMISSION to view and change ALL data on EVERY visited sites... ?
Is it ok and is it true ? :-O
It's true, but only for this release, and only because I used the wrong manifest file when creating the package for the Chrome store. It'll be fixed again in the next release, but other than this annoying start-up request it doesn't affect how the script behaves.
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
PHIL-IP63 wrote:Humm it seems that URO+ stop working under Firefox 44.0a2 (2015-11-03) Developper Edition
Its tab no longer appears. I disabled all other scripts, I reinstalled, I reinstalled the previous version and the tab still not reappeared. :(
This appears to be a developer edition issue with the bootstrap code used in URO. As this is the same bootstrap code defined in the wiki, and which is used by several other scripts, it'd be interesting to know which other WME scripts you've got installed and whether they are still working OK.
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
iainhouse wrote:Additional information. In the above example, the closed MP was first in the stack. I've now found another pair where the open MP is first in the stack - and that one always gets connected.

I've also noticed that, if I have already got the un-shifted MP open, then hovering over the unstacked MP changes the pop-up with the information, but clicking on it has no effect.

Just guessing, but this might be something to do with the new behaviour of MPs where selecting one automatically centres it on the screen.
This appears to be a fundamental change in how the marker click handlers behave in the native WME code when two markers exist at the same location as in your example, and which can be even better illustrated by the two perfectly stacked URs here.

In the UR case, the UR with an internal ID of 5469302 (aka A) is rendered on top of the UR with an ID of 5469303 (aka B). Without unstacking, clicking on this stack of URs would then, as expected, open up the editing UI for UR A and the only way to access the editing UI for UR B would either be to use the "next update request" button in UR A's UI, or to mark A as solved/not identified and then use the native "show/hide closed" functionality to bring UR B to the top of the new stack where it could then be clicked on.

In this case, UR B has some descriptive text associated with it, whereas UR B does not. This means we can use the "Hide URs with no description" filter to hide the marker for UR A. In previous versions of WME this alone would then allow UR B to be selected even if unstacking wasn't being used, however in this version of WME it's still UR A's UI that gets opened when clicking on UR B's marker...

Even dropping into the JS console and manually forcing a click event on the UR marker of interest doesn't work, WME will stubbornly continue to redirect that click event to the UR marker that would have been at the top of the stack when rendered natively.


So, in short, there appears to be eff all I can do about it, and you can all now go and thank the WME devs for breaking this functionality. Thanks guys, much appreciated. :roll: :evil:
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
Hmm, there may be a workaround for this, having spent some more time observing the crazy new behaviour of WME here... I haven't even attempted to trace the real behaviour through the labyrinthine depths of the WME code, but my observations lead me to conclude that:

1. each time you click a marker, WME makes a note of the co-ords defined for it, and then (for absolutely no reason I can think of that makes the slightest sense) looks through its internal cache of marker objects to see if there are any others at the exact same co-ords.

This is where the native behaviour of WME differs from previous releases - in those, if you managed to submit a click event to a marker that was directly underneath another one (i.e. one that ordinarily you wouldn't be able to click on whilst the overlaid marker was still visible), WME didn't then go off and do this weird "oh let me just double-check to see if the user actually meant to click on a completely different marker at the same location here" thing, it'd simply treat it as a valid click event and open up the editing UI with the details of the actual marker associated with the event.


2. the editing UI which is then shown following the marker click, contains the data from the first object found within the cache for a marker at those co-ords.


3. once a marker is hidden by the native WME functionality (i.e. by marking it as solved/not-identified and then hiding closed markers), the next marker found at those co-ords becomes the "active" one for clicks.


4. since WME natively doesn't offer any means of identifying where two or more markers are stacked exactly on top of one another in this way, non-URO+ users won't notice any change in WME behaviour here - you click what looks like a single marker and you get an editing UI populated with information that looks reasonable for the marker you just clicked. You then close off that UR and, oh look, there's another UR underneath. Click on that, rinse and repeat, etc. etc. until the stack is cleared.


Now, having spent a while realising that this weird behaviour had nothing to do with the rendering order of the markers (which is usually what catches us out when trying to push click events down through a stack of overlaid elements), and really did seem to be related purely to the co-ords of the marker, I tried something absurdly simple and changed the cached co-ords for one of the stacked markers. Visually this does nothing - the marker has already been rendered onto the marker layer - but it does appear to prevent this "check for duplicate co-ords when clicked" behaviour which is currently preventing the unstacked markers from being clicked on properly.

I need to spend more time checking for any unwanted side-effects of adjusting the co-ords like this, and also seeing if it acts as a reliable workaround the WME change under a variety of conditions. But it's a start at least...
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
3.58 works around the bizarre new marker click handling behaviour for markers that share identical co-ords, allowing such markers to be clicked on successfully after having been unstacked. It also adds a new Misc tab option - Replace "Next update request" button - which forces the UR editing dialog to always show the "Done" button at the bottom...

...or, at least, something that looks and behaves just like a Done button ;)


Chrome users should also now be able to relax, as the brief attempt by URO to take over the world has been put to an end with the inclusion of the correct manifest file once more...


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
Oh FFS, another behind the scenes tweak in how URs are handled has broken backfilling - clicking on any UR that was added via backfillling means the edit dialog doesn't open, but WME is left looking as if it should be open (i.e. GPS/user drive traces are shown for the clicked-on UR, and all other URs are faded out) until you click on a non-backfilled UR which resets everything.

Problem seems to be that when URO adds in the new UR objects, WME isn't updating W.model.mapUpdateRequests.additionalInfo, so when you click on them WME goes off to find their additional info, fails to find it and bombs out. Not sure if WME ever did update this by itself, but as it now seems to require it to be updated I'll have to see what's involved in doing the update myself.

Not at all happy with this WME release...
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
Turns out I was barking up the wrong tree earlier with my initial thoughts on why backfilled URs couldn't be clicked on, but after a traditional bughunting combination of late night + earthquake-inducingly loud European heavy metal, the real culprit was found. Once I'd got that out the way I was on a bit of a roll, and 3.59 therefore fixes the following bugs...
  • Clicking on backfilled URs works again
  • Loading WME via a URL containing selected segment IDs no longer misplaces the URO+ tab
...and introduces the following new features
  • UR filtering can be disabled for the UR contained in the URL
  • The auto-centering when a UR is clicked on can now also be disabled
You can only begin to imagine how wide the smile on my face was when I got that second feature working :D


Firefox+Greasemonkey version: https://greasyfork.org/scripts/1952-uroverview-plus-uro
Chrome Web Store version: https://chrome.google.com/webstore/deta ... mjcdghdphi
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png

Post by Twister-UK
iainhouse wrote:The prevent auto-centring is also affecting Map problems, which saves me asking for that. :)

However, could we have 'Replace "Next update request" button' working for MPs as well as URs please?
Interesting, I take it you're using Chrome here when you say MPs are "fixed", because they currently still auto-centre in Firefox which is how I'd expect them to behave given that I've only applied the fix to UR markers...

In any event, now I know how to stop the native behaviour (both auto-centre and the replacement of the Done button) for URs, applying the same fixes to the MP and PUR UIs shouldn't be too much work. He says, hoping that he hasn't just invoked the famous last words variation of Sods Law.
Twister-UK
Waze Local Champs
Waze Local Champs
Posts: 4670
Answers: 2
Has thanked: 736 times
Been thanked: 4677 times
Send a message
Chris (not to be confused with Chris or Chris, or even Tim, Stu, or any of the other champs team...)
AM SE England & Shetland Islands, UK Local Champ, WME Beta Tester & ScriptMangler
WME/Livemap enhancement scripts @ GreasyFork


https://chizzum.com/greasemonkey/images/beta.pnghttps://chizzum.com/greasemonkey/images/s0400.pnghttps://chizzum.com/greasemonkey/images/c5s.png