Overlays.

[bubblobill]

Capture.JPG (20.51 KiB) Viewed 1237 times

New version without the copyright issues.

lib_motion_tracker_20200814.rptok

(141.38 KiB) Downloaded 34 times

The only button that does anything is the leftmost button.

[wolph42]

nice if things go parallel without communication. Here's the first official release (with apparently the wrong graphics). It turned out quite a hefty update but I got everything working. Players can now have their individual tracker and can set their own settings, next to that its distance per cell compliant (and lots of other stuff).

MotionTracker_Rev_W42_V2.cmpgn

(567.26 KiB) Downloaded 34 times

[Full Bleed]

nice if things go parallel without communication. Here's the first official release (with apparently the wrong graphics). It turned out quite a hefty update but I got everything working. Players can now have their individual tracker and can set their own settings, next to that its distance per cell compliant (and lots of other stuff). MotionTracker_Rev_W42_V2.cmpgn

You guys are killing this.

Some things I'd like to see:

1) Dots be a different color when objects are things the token can see on screen (not blocked by VBL/Light/Sight) and things they can't (blocked by VBL, lack of normal visual range, no light, etc.) This would help with orientation and immediate recognition of data that the motion detector is showing that the token isn't "seeing."

2) 270 and 360 degree viewport options. The assumption being that people are swinging a handheld device around to read an area larger than just 180 in normal practice and/or that the technology/ability can go through the originator (i.e. Daredevil doesn't just sense things at 180 degrees.)

3) A way to set the orientation to another corner as the current default is where MT defaults the statsheet. Probably would be best if we could relocate the default location of the Statsheet, but that's a MT feature request that has probably been made before with little traction and would take a long time to get into a new version even if someone jumped on it right now. :/


Question:

a) Can the dot objects in the overlay have tooltips or, even better, some way to "click" on them and bring up additional information about the object?

[wolph42]

well some collaboration with reverend would be nice so we don't work on two parallel version and then have to integrate the lot (which appears to be A LOT of work).

As for your questions...

1. if there are MT macros allowing to discern the difference between the two, then yes, thats possible
2. thats already possible, just rotate the token itself and the viewport changes accordingly
3. yes... but given that reverend hardcoded all the coords, again not an easy feat.

[bubblobill]

Blips are displayed using CSS. It would be possible to differentiate anything by manipulating the CSS, e.g. visible tokens could be crisp instead of blurred. It's an extra level of processing the token list to separate things. An example is the current way blip size reflects token size.

At present the background relies on an image so everything is fine tuned by pixel to fit over the image. Ideally the image(s) would be SVG so everything could be scaled and manipulated relatively. Unfortunately I have yet to come across an SVG drawing package I like.

I originally built the bones to be dynamic but ended up being specific to overcome my inability to make CSS behave. I should probably shanghai Melek into the visual design, apparently he speaks fluent CSS.

Will also be nice to have some competent JS assistance to put controls on the tracker that do something.

[wolph42]

ok not that much work. Here a proper release with graphics that Reverend created himself. I had to remove the option to change visuals for now.

MotionTracker_Rev_W42_V3.cmpgn

(576.72 KiB) Downloaded 33 times

[bubblobill]

a) Can the dot objects in the overlay have tooltips or, even better, some way to "click" on them and bring up additional information about the object?

You can already see how big it is and how far away.
Clicks and tooltips are doable, bearing in mind that the information would be loaded for every token in sight and not checked at the time of clicking/hovering, what info would be beneficial to add? Range and size values could be done pretty easily.

[Full Bleed]

1. if there are MT macros allowing to discern the difference between the two, then yes, thats possible

Wiki: isVisible() doesn't do that?

2. thats already possible, just rotate the token itself and the viewport changes accordingly

With round tokens when you rotate the facing you have to actually move the token before the detector updates (it doesn't do it on facing changes.) And while it's quite clever the way it currently works and can appreciate the technical feat, it's not particularly intuitive since once the orientation of the detector diverges from the actual screen you have to constantly be reorienting yourself and trying to associate what you can seeing with what you can't (which is harder at a different heading.) It's why most games with mini-maps give you the option to lock them and/or show facing in them.

On top of that, seeing a full 360 degree sweep in one shot is quite different than looking at 180 at a time and then mentally stitching them together in real time.

If you had graphics for a 360 display would that be useful?

[Full Bleed]

a) Can the dot objects in the overlay have tooltips or, even better, some way to "click" on them and bring up additional information about the object?

You can already see how big it is and how far away.
Clicks and tooltips are doable, bearing in mind that the information would be loaded for every token in sight and not checked at the time of clicking/hovering, what info would be beneficial to add? Range and size values could be done pretty easily.

This is, like some of what I mentioned above, more about more easily getting oriented and understanding what the motion detector is showing you. If you can click on a dot and the name of the token it's associated with were to pop-up you can then more easily sync up what you see on the screen. For example, in front of you are 3 xenomorphs and 4 marines. But your detector is reading 9 objects. So you know there are 2 hidden things. It's crowded, the detector's facing doesn't match the screen, you can't update the motion detector without moving, you have to align what you can see against what you can't to try and figure out what you're missing and where it is on the map... it's not easy. If a click could just produce the name of the token it would be helpful for orientation... but I suppose if you could enter in properties that the click could pull up that could be used too (maybe this could be used to sense creature types, like undead, or see invisible, or astral, etc. Knowing why you can sense something but not see it could be useful information when clicking on something.)

If tokens we can't see were a different color, if the map matched the orientation of the screen I'm looking at, if clicking on the dots produced a name that I could match to what I can actually see, then all the sudden what I'm seeing on the motion detector starts to make a lot more sense.

[digiacom]

I gave the code a pass to make the size relative to the width. Could be fine-tuned, and the background image definitely could be replaced with a more flexible image, but it works.

I used a combination of Macro script and CSS variables/calculations.

I also added a quick javascript function to hide/show names for dots and attached it to the second button. I found that :hover effects failed on blips near the center of the map when the 'sweep' animation scale contained the blip, so that functionality might need some work to make hover/click info available for the blips.

[Full Bleed]

I gave the code a pass to make the size relative to the width. Could be fine-tuned, and the background image definitely could be replaced with a more flexible image, but it works.

I used a combination of Macro script and CSS variables/calculations.

Great feature!

I also added a quick javascript function to hide/show names for dots and attached it to the second button.

Cool. I think that will help address some of the orientation issues I had above. But, the re-orienting of the dots based on facing doesn't work in this version (so it's only working when facing "north".)

Also, if a token can't be seen then the name probably shouldn't be shown either (since they may know something is there but not what it is... yet. That helps maintain that sense of suspense about what might be coming.)

I found that :hover effects failed on blips near the center of the map when the 'sweep' animation scale contained the blip, so that functionality might need some work to make hover/click info available for the blips.

Thought of another tidbit of optional info that might be nice on hover/click: actual distance.

[bubblobill]

I have plans to be able to click on the scanner and rotate the image with blips which will be similar to waving it around.
I have created a full circle SVG image to facilitate this which could also be shown in full to give a proper 360 degree view, even though that is nothing like Aliens™

One of the buttons could be used to update the view if JS can call the relevant macro.

The sweep problem with :hover should go away once I get the expanding rings animating correctly in the SVG. They currently do very weird things.

[wolph42]

sigh... again two versions in parallel. I hope I got everything right in merging the two codes. Pls check (in Dropbox!!). Here the latest update.

MotionTracker_Rev_W42_Melek_V4beta.cmpgn

(707.73 KiB) Downloaded 31 times

this one blurs non visible tokens. (and has Meleks changes merged and some new stuff by Reverend)

note that rotating the token really F things U. So that part is now broken.

[Full Bleed]

this one blurs non visible tokens. (and has Meleks changes merged and some new stuff by Reverend)

Sweet. I think it's much better to have that visibility differentiation.


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 (68.25 KiB) Viewed 1151 times

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.)

[bubblobill]

Getting all the centres aligned is a CSS issue, which is why I recruited Melek. It hurts his head less than mine to make CSS work.

I have created some original art to use. I used SVG because it is scalable and awesome and animatable on top of being a pig to create.
But the animation behaves weirdly in MT.

I cannot upload the screencap of the animation, but try this;

• Rename attachment file extension to .svg (can't upload SVG files either)
• Open it in your browser
• Now edit the file and surround the text with

• Code: Select all

  [r, dialog5("test"):{['<html>  all the svg stuff  </html>']}]

• Paste in MT chat

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