[Suggestion] Adjust z-order so it is always set from Head to Tail

[Shuggaloaf]

As we discussed on Reddit.

Summary: Set a z-order so tokens always overlaps from Head (highest z-order) to Tail (lowest z-order). This should remain even when controlling from the tail.

[oOve]

Had a talk with the Foundry Devs. Every token have a zIndex, but for some reason it isn't synced between clients.
The latest release does update the zIndex, but as it is now, that will not affect the worms on your players views.
There is a module called Token-Z, which has a solution for syncing this, via a flag.
So we have three options:

1. Do nothing
2. Implement cooperation between token-Z and this module, and adding a dependency to it.
3. Use the Token-Z methodology, but this might create some discrepancies/incompatibilities between these two modules.

Care to weigh in?

[Shuggaloaf]

OK I see. Too bad I was hoping it would be easier to implement.

I appreciate you asking for my opinions. Hmmm...

1. This one is obviously up to you and is a perfectly acceptable choice considering the alternatives. No hard feelings if you just want to call it done.
2. Personally I wouldn't want to add a dependency on another mod. Not sure how you feel about it but if that mod's development stopped then you'd potentially be in a tough spot.
3. When you say use the Token-Z methodology, I'm assuming you mean to add their flag method to your mod? If so, I would again have to defer back to you as I don't know how difficult a job that would be for you. I know adding flags themselves aren't hard, but not sure about adding/removing them from all the segment tokens, tracking across scenes, worrying about conflicts, etc.

Also, I made a purple worm model! I was actually going to give it to you to distribute with your mod if you'd like ( I know there was some prior talk of a compendium). It can be additional to yours, replace yours, whatever you want to do with it.
There's 2 things it needs though:

• Variable spacing, which I see you introduced (haven't updated yet). I was just editing your js file and changed the spacing to 3 or 4, as the segments are denser. (It looks like you may have reversed the spacing methodology so I would guess it would now be like 0.25)
• Head-to-Tail z-order. OK so this one is not absolutely necessary, but as you can see below, with the design of the worm, part of the design would be cutoff if we go tail-to-head. IOW, z-order is going to make this thing always look the way it should. That is if you even want to include it because again, if too much work, then just shelf it for the future.

Here's a sneak preview for you....

I wanted to go for the overlapping plates with spikes/horns like in this image:

(side note: not sure if the head jumping ahead of the body like that is known behavior or if I'm having an issue on my end. Any insight?)

By the way I love the interaction between Caterpillar and Pushable Tokens. Crates go flying to the sides and so do any PCs/NPCs marked as pushables. Not seen in my gif, I noticed if you run over pushables they get kind of drug along with the worm. Guessing that wasn't intentional but it's a cool effect that adds realism.

[oOve]

Thank you for input. I love your design. It's always nice to see videos of it in action. The pushing was not intentional no, but I understand why it happens. On my list of things to implement are a rigid body physics methodology, so they will be more accurately been shoved to the sides instead :)
The head jumping ahead is the fact that the heads movement is done "first" as it reacts to the user input, and its that movement that triggers the rest of the body. Not sure if there is much I can do about that.

[Shuggaloaf]

Hey just to clarify, I was saying I like the way the caterpillar pushes the boxes. Even without rigid body physics it seems to preform well as is. :)

I kind of figured the head movement jump was probably due to that. No worries at all, just wondering.

Glad you like the worm by the way!

[devinnasar]

Regarding the point on adding Token-Z as a dependency: it may be valuable to still include detection of a Token-Z install for the sake of preventing a conflict. If you implement similar logic, then there would need to be some mitigation to ensure which module's handling of Z-index applies in a given situation. That may suggest a path of least resistance: if you decide it's valuable to detect Token-Z in the first place, it might be simpler to rely on it now, and cannibalize it's relevant code if it ever goes defunct. Perhaps simply fork Token-Z and any module dependencies you develop in the future so you always have a copy of a dependency's code base to work with. It might be possible to do this with Github actions at regular intervals as well.