(Solved!)Multiple Subsymbols using the same tracking image

Hi there! I’m new to Zapworks Studio (and zapworks in general) but I’m working on a project that is essentially a giant iSpy mural. Think of something that’s like this image:
image

My issue is that I want to have multiple lists for the SAME image. I managed to get the code to open each subsymbol when the correct button is tapped (I have 3 subsymbols made) but the image tracking only appears to work on the first subsymbol. Is this due to limitations of ZWS? Or could there be a bit fo code I’m missing? I’m trying to avoid having to put it all into one large subsymbol and then hide each set via states because I feel like that will make the file very complicated very quickly. The project I’m currently working on is just a small section of a larger mural.

I’m not afraid of scripting as I have a wee bit of coding knowledge and can wrap my head around it pretty quickly, so if the only solution is more scripting, I’m open to learn.

(Note: I wanted to add that I’m familiar with the “Multiple Tracking Images” thread and have used that in a different test, but I believe this is still slightly different than what I’m trying to achieve.)
https://forum.zap.works/t/support-for-multiple-targets/318/35

EDIT: I guess while I’m still at it, I can’t seem to get the “Look for Graphic” subsymbol to work. I have it as a child of each subsymbol that contains a tracking image, have placed the “seen/notseen” code according to the import notes, but I can’t seem to get it to show.

@biroatlas,
I guess I’m trying to see what your looking to do. Any subsymbols set relative to the tracking image will use it.
How are you using the list and image? Is your image here what your are using? Are the items to find what show up in the zap?

Steve

ACH Mural Demo.zpp (11.6 MB)

Here’s the project I’m working on at the moment. The tracking image is not in the parent, but is present in each subsymbol. The list of each items to find is shown in a help menu that you can click on within the subsymbol.

In a way, each subsymbol could be its own experience and deeplinked (note: this will be WebAR), but I was trying to avoid that because I was worried that opening the second browser might disrupt user flow. This is a prototype that will hopefully be installed into a children’s hospital waiting room, we’re just trying to get a polished prototype before we show it/propose it to the client.

EDIT: The letters subsymbol isn’t set up beyond the normal UI. I made the Animals_TEST first and got that working, but ran into hiccups when I started working on the Hobbies subsymbol. The Hobbies subsymbol has a few of the “find-ables” and their corressponding actions, so I’ve just been trying to get those two subsymbols (animals and hobbies) to play nice

I’m not at my main machine right now and can’t look at your file so I may have got the wrong end of the stick here.

But it sounds like you have a single image you want to use as a target, but you want three separate sets of content, only one of which will be shown at any one point, depending on a button press, or a parameter in the deep link or similar. Keeping the content organised in subsymbols sounds good.

I can’t see why you’d need the target image in each subsymbol, though. It may be helpful to have the image there just for your authoring purposes so you can line everything up right, but for the actual publishable project, is there a reason you don’t just have one single target image in the main project, and then your subsymbols are parented to it? All the subsymbols will inherit the transforms/tracking info, but you can leave all but one of them set to invisible.

You ought to be able to use subsymbols and groups to keep everything tidy, and as long as they’re all child nodes of the target image they’ll all follow along - rather than having multiple “image-tracker” nodes, which sounds like a recipe for confusion. As soon as you have more than one of those nodes in your hierarchy, you’re going to have to actively script / actively tell Zap which one you want it to be looking for (even tho you and I know they’re the same picture).

Will try and have a look later on, though :slight_smile:

1 Like

I hadn’t considered just dropping the tracking image into the main project, honestly. But you are correct in what I am trying to do!

As I’ve been trying to build my own projects I try to find a similar tutorial (or multiple) in the documentation and modify it. I knew that the tutorial for the math.random character photo feature had 3 separate experiences within one project that had a welcome screen, so I was tryign to mimick that function, albeit with a different kind of experience. I’m not at work right now to give it a try, but I should be in the office in about an hour or two so I can give it a try. I’ll post back here with updates :slight_smile:

So I’m trying to set it up so the tracking image is just in one image, but I’m not quite sure what the best way to go about that would be. Should I create groups that contain each set of content or is there a way to reuse my subsymbols? Those two options are visualized in the image below
image

However, when I tried to take the tracking image out of the subsymbol, but left the content as is, it didn’t seem to want to track correctly? The content just appears on screen and does not track to the image. Not quite sure what’s going on there.

Either groups or subsymbols will work, they’re just different to work with (in that you have to dive into a subsymbol to edit it, rather than it being out in the “main project” like groups are).

All nodes have a “Relative To” property you can set. You normally want to leave it at “—”, which means: just position this thing relative to its parent in the hierarchy. Subsymbols (well, any node) can override this - if you dive into one of your subsymbols and select the “root” node, check that the Relative To property is left at “—”. I’d bet it’s set to something else, like Z.screen instead, which is overriding what you want it to do.

The whole “Relative To” thing is very powerful precisely because any node, even if it’s grouped or parented to other things, can be told to position themselves relative to something completely unrelated if you like. But it does mean you have to kinda step down through the hierarchy (and into subsymbols - from the root inside them and down) to find if something’s overriden.

1 Like

Splendid! That’s exactly what was going on. Thank you so so so much!! the root of each subsymbol was “Relative To” Z.Screen. Once I swapped it to “—” it worked correctly.

1 Like