Overlays.

[Full Bleed]

The sweep ring is off playing hard-to-get with the fairies.

Yikes. That's strange.

MT's facing method is strange, too (Wiki: getTokenFacing()). Is that the method being used here?

[Azhrei]

I cannot upload the screencap of the animation, [...]

You didn't say why the screen capture couldn't be uploaded (filename extension?).

I've added .svg as a valid extension.

[bubblobill]

I cannot upload the screencap of the animation, [...]

You didn't say why the screen capture couldn't be uploaded (filename extension?).

I used CamStudio which produces *.mp4
Not that important, allowing them could lead to blowing out the size of attachments stored.

[Full Bleed]

There does seem to be 3 different "centers" at the moment that is a little disconcerting. There may be some technical reasons for it, but I was wondering if there would be a way to combine them (or at least a couple of them.)


MD_Centers.jpg

Current Centers:

1) X/Y coordinate of the targeting semi-circle.
2) Center of the animated detection wave.
3) Center of the token that is doing the detecting.

I think the X/Y coordinate of the targeting semi-circle would be the most accurate center (meaning the animation would have to be shifted down and the token blips shifted up.)

A small change to the CSS moves the center of the animated detection wave from position 2 to position 1. That looks a lot better than where it's currently emanating, imo. But it doesn't scale with a larger width motion detector, so a modifier based on a custom size of the detector would need to be added. It seems that most of the CSS was written with an "ideal" width of 275 in mind...

In .sweep replace:

Code: Select all

bottom: var(--controls-height);

with

Code: Select all

top: calc(var(--container-height) - 2 * (var(--controls-height)));

And with regard to moving all of the blips up (to move the center of the detecting token up to the center of the targeting crosshair) you can make this change in updateTracker:

Code: Select all

[posH		= y*resolution+blipAreaRadius]

to

Code: Select all

[posH		= y*resolution+blipAreaRadius-(controlsHeight-blipAreaBuffer)]

I think that's more accurate, too... but there does seems to be some slight offset inaccuracy with the X position (not caused by this change.)

[bubblobill]

Because I thought the CSS was too hard I decided to animate the ping in SVG instead.
The current latest work-in-progress version uses this

tracker_back.svg.txt

(4.21 KiB) Downloaded 13 times

instead (remove .txt extension).

I was wrong of course. Whilst this pic is much better for us, the learning curve caused me to crash into the mountainside many times.

[Full Bleed]

Because I thought the CSS was too hard

It is rather annoying... I felt like I was playing around with legos using 3 different metric systems.

I decided to animate the ping in SVG instead.

Looks good. I see you've got a 360 degree field image done as well.

The current latest work-in-progress version uses this tracker_back.svg.txt instead (remove .txt extension).

Az said he allowed SVG attachments now... let me test... nope... not working...

I was wrong of course. Whilst this pic is much better for us, the learning curve caused me to crash into the mountainside many times.

The scaling upside and flexibility after the fact is huge though. Glad you powered through. Will be looking forward to more SVG works-of-art from you in the future.

[wolph42]

in case your interested, here another WIP version.

[Full Bleed]

in case your interested, here another WIP version.

Thanks for the update.

The new tool-tip names and different graphics for things on the perimeter ( "in range" but not "on screen") is nice.

Can you hide the names of things that aren't visible in the tool-tip?

Couple other things I noted:

-It seems like the blips need to be adjusted half a blip to the left most of the time... just a technical limitation?

-And the range finder seems inaccurate against large+ tokens when approaching from all quadrants except (-x,y). Example below.

Blip distance.jpg (65.77 KiB) Viewed 709 times

[Azhrei]

Az said he allowed SVG attachments now... let me test... nope... not working...

Apparently, it can't be defined as an "image", even though that's what the browser will consider it to be.

I've set it as a "plain text" file. For me, when I click on such an attachment, my browser downloads it automatically. I'd prefer to see it in another tab, but "oh well."

[Full Bleed]

I've set it as a "plain text" file. For me, when I click on such an attachment, my browser downloads it automatically. I'd prefer to see it in another tab, but "oh well."

I can middle mouse click and open it into a browser window with my current Firefox settings so that's cool. Too bad we can't put svgs inline... seems like that might be a phpBB limitation.

[Azhrei]

I can middle mouse click and open it into a browser window with my current Firefox settings so that's cool. Too bad we can't put svgs inline... seems like that might be a phpBB limitation.

I don't want to derail the overlay discussion, but... SVGs can contain script elements, so allowing users to upload SVGs and then inlining them so the user sees the image automatically is a security issue (per some web searching). It may be possible to filter such things from the SVG during the upload process, but I don't see a phpBB extension/plugin that does that — it may be more complicated than it appears.

[bubblobill]

Getting prettier.

unknown.png (36.63 KiB) Viewed 687 times

[Full Bleed]

Getting prettier.

It sure is. Moving the field up to clear the area around the origin blip was a good idea. I see what might be a 360 button now, too.

[bubblobill]

Nah, 360 view is in settings, but it does exist.
Updated
The buttons left to right are;

• Minimise(removes scanner leaving control bar and range display)
• Move (switches the scanner around the four corners of the map)
• Display all tooltips
• Zoom (one day - harder than it looked)
• Toggle sound (the day after)
• On screen menu (probably never)

  • 

    Capture.JPG (25.04 KiB) Viewed 661 times

[wolph42]

-And the range finder seems inaccurate against large+ tokens when approaching from all quadrants except (-x,y). Example below.

the issue with that is that we look at the centre of the token NOT the edge. so with large(r) tokens you can have an offset. We *could* try to do an edge to edge calculation but I'd much more prefer a centre to centre, this also omits the issue with assymmetrical tokens that are rotated. Next to that it would require yet another layer of calculations...