Open Shuggaloaf opened 2 years ago
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:
Care to weigh in?
OK I see. Too bad I was hoping it would be easier to implement.
I appreciate you asking for my opinions. Hmmm...
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:
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.
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.
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!
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.
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.