itch.io

it looks awesome!! can't wait to give it a test drive!

Oh awesome, glad to hear you have some plans for that! I'm sharing info about your tool as best I can and I hope my friends like it!

Here's another question I have.  Related to the Character Select stuff. We're enjoying the data driven framework of JuicyNavOverlay, but this UI problem may be too much trouble for you, so my apologies. 

We're wondering if your addon currently supports creating an interface that is both on the Horizontal and Vertical.  For example, setting the X going by Character/Party Member, and then down through the Y is their Settings or Scene. This is in function, a grid concept with X and Y. In this example you want to be able to see all submenu in context of each other as you re-assign equipment or else it becomes tiring on the player.

Can JuicyNavOverlay support a structure where each NavItem(example here being Char[X]) generated (on the Horizontal) contains or is associated to a series of further objects (on the Vertical) like a trunk ?  Is this something possible with the SubMenu concept?

Unlike the examples given in the addon, this asks for visible children of the NavItems. 

Another example (with a table below to help). If I had Char1 selected I could move down to Char1_Scene1, and when doing so all other Char[x] NavItems moved their list items children down the Y direction accordingly? The theory being a scroll effect with all lists moving. So if the SelectedItem was Char1_Scene1, pressing Right would cycle Char2_Scene1 as SelectedItem. 

When I think about it, it's possible that the SelectedItem on the top level is always one of the Char1,Char2, etc. And pressing Left or Right cycles between those, but does a submenu navitem list understand how to signal its parent? As well can all main Char[X] NavItems in this theoretical, keep it's submenu visible. 

Was simply wondering if this style of presentation of nested recursive items was possible in your awesome addon and now it's the biggest post I've ever written on itch. Oops! As always thank you for your time and great work!

And thank you for the quick responses! 

Hey another query I have is about the OrbitalDemo scene. In the scene the selectable characters are put in an infinite loop which is great and what I'm looking for!

Something that comes to mind though, is the visible duplication when the item at one end of the array is moved to continue that infinite loop. This creates something akin to an infinite loop, but its visibly jumpy. 
Is there a way the system could perhaps use set positions in the spline or something akin to that? Creating a true loop (without navitem duplication visual pop) would make this very useful for these types of menus.  

Unrelated to the current usecase for this current project, but always good to look into the future; the fan mode I have some questions about. Does it support having the cards bunch closer together depending on distance from the active center item?

For example, in a game where you can have unlimited handsize of cards, eventually cards would have to be culled unless there are spacing modifiers that adjust how much the cards are spaced depending on position away from the active index item. This would make the most sense for games like Slay The Spire style where you can and often do draw big combo hands of 20+ cards.

Just a thought!

Really love this plugin and deeply appreciate how it's built and how responsive the developer is to questions!

Fan mode is also something I was thinking of when I noticed this issue, awesome!

you're literally the best! I appreciate  your swift response!!

EDIT: Issues fixed with new feature update

Hey I'm loving the package overall!

But one thing that's been hard to hunt out, is how somebody could set up their UI to be a 3D-like wrapped carousel WITHOUT rotating along the path. In the demo I see that each character in that character select is flipping up and down and around. I'd love to use this tool for my character select but until I can solve the rotation issues I'll have to run something else.