Discuss full rewrite

[Gaurav0]

@cdvv7788 has written a full rewrite in mithril.js here:

#223

First, do we want to consider a full rewrite in a js framework?

[Gaurav0]

My thoughts:

1. Getting rid of the data- stuff is awesome. I don't think a framework is necessary to do that though.
2. Instead of a full rewrite in one PR, we could incrementally introduce a framework as we solve particular problems.
3. Any particular framework will reduce the number of people who feel comfortable writing PRs.
4. Mithril.js doesn't have a templating language built in. We could use msx.

[jrconway3]

I don't mind frameworks, though I've personally never used Mythril its still JS. Wouldn't be too hard to learn. I don't have any inherent problem with rewriting the codebase as long as it works and we don't lose functionality.

I'll do a bit more research on it before commenting further, though.

[cdvv7788]

In the defense of mithriljs (first time using it too), it is just replacing jquery. It uses a vdom and enables reactivity which makes it easier to compose some patterns and keeps it relatively performant when compared against vanilla dom manipulation (and all of this without requiring an npm build). The rendering part still uses the actual dom.
About your points:

1. Correct
2. You could, that is true, but there is a lot of cognitive debt you need to pay off even before your first contribution. Plus there needs to be a concerted sustained effort over a longer period of time.
3. This is true, but if we want to go there, we could say the same about the current status and jquery. Maybe we could get some metrics about how many casual contributors come around? (Don't count consistent contributors because they will stay in any case). If the cognitive load of modifying/adding components is lower because the final structure is a bit more isolated than before, it could end up actually encouraging people. Instead of "let me trace how this click changes the hash which in turn changes a radio state which in turn triggers a render" we could untangle the technical debt that has accumulated over the years and just go back to simpler reactive patterns.
4. Why do we need a templating language? The tool's purpose is relatively straightforward, with my only complaint about it being the performance (which is improved to a good baseline with my other PR).

If this gets traction I would achieve parity before releasing it, and then would iterate with smaller updates (the canvas is still using the DOM, the mithriljs components can probably be further improved, the global state can be handled better, etc). These should be easier to play with once everything is more straightforward.
It looks huge, but most of the file changes are made to the json files (many, multiple lines).

As a closing note, I think the value this tool provides is not the how, but the what. If changing the how can improve the what (smoother UX to generate the sprites for my game), and more people find it useful in the end, that would be a nice win.

Thanks for opening the discussion :). I have had fun doing all of this, and it is in a state that it is usable for my needs, so I am ok with what you decide.

[jrconway3]

Yeah I see the path. I tried testing it but almost nothing works right now, so I can't really tell what its supposed to be doing atm. I think its a good WIP though. If I knew how the end result was supposed to look like then it'd be easier to approve the suggestion.

[cdvv7788]

Are you in the path? https://deploy-preview-223--liberatedpixelcup.netlify.app/mithril-generator.html#body-body=light&head-heads-heads_human_male=light

[cdvv7788]

https://deploy-preview-223--liberatedpixelcup.netlify.app/mithril-generator.html#body-body=light&head-heads-heads_human_male=light This one is a bit better, I was downloading images sequentially, restored the promise based downloads.

[cdvv7788]

@jrconway3 I can walk you through it if you are having issues. If the current version is not functional for you I would like to know what is going on haha

[jrconway3]

Look I already saw what the problem is, but this is something that needs to be fixed.

I clicked the link:
https://deploy-preview-223--liberatedpixelcup.netlify.app/

Which goes to this:

Which is broken. And I get that you said to open that file but there's no indication on this page that anything else is there.

That being said, the interface has completely changed:

So I need time to look it over. However, this part definitely doesn't work:

I'm fine having Body Type be more pronounced, but it needs to be adjacent to the other filters so it can easily be toggled. Having to scroll down and back up again to change Body Type is not good design.

[Gaurav0]

This is true, but if we want to go there, we could say the same about the current status and jquery. Maybe we could get some metrics about how many casual contributors come around? (Don't count consistent contributors because they will stay in any case). If the cognitive load of modifying/adding components is lower because the final structure is a bit more isolated than before, it could end up actually encouraging people. Instead of "let me trace how this click changes the hash which in turn changes a radio state which in turn triggers a render" we could untangle the technical debt that has accumulated over the years and just go back to simpler reactive patterns.

Oh yes. Definitely in favor of improved reactivity and getting rid of jquery slop. Again, this doesn't actually require a js framework.

Why do we need a templating language? The tool's purpose is relatively straightforward, with my only complaint about it being the performance (which is improved to a good baseline with my other PR).

We don't, technically, but I find it makes the code easier to read.

I'm fine having Body Type be more pronounced, but it needs to be adjacent to the other filters so it can easily be toggled. Having to scroll down and back up again to change Body Type is not good design.

I agree with this.

I think this is overall a technical improvement, so as next steps we should achieve parity and discuss any interface changes. @cdvv7788 Can you post some screenshots for discussion purposes?

Anyway, I think first the order should still be download, controls, filters, body type, selections, available items on the left. I also think the left and right sides should remain independently scrollable. I do generally like the shadow boxes and more prominent buttons though.

[cdvv7788]

What additional functionality do you need at the framework level? It is very lean, so it doesn't get in the way too much. For the canvas rendering I am still using raw js for example, if the idea is to programmatically enable variables (is that it?) I don't think it gets in the way.

[cdvv7788]

I modified the layout a bit. The body is not part of the tree (it could be moved back there tho) because it is used differently. It is used to decide a lot more things than the rest, including visibility in the filters.

[jrconway3]

What additional functionality do you need at the framework level? It is very lean, so it doesn't get in the way too much. For the canvas rendering I am still using raw js for example, if the idea is to programmatically enable variables (is that it?) I don't think it gets in the way.

That's fine, as long as it interfere with anything it shouldn't be a huge deal. I still would prefer to ask around a bit before jumping to a big change like this, though.

[Gaurav0]

I'd also be concerned if the framework supports additional functionality we want. I assume it probably doesn't affect anything like our ability to add support for post-process palette swaps (I assume that's more raw JS than anything), but additional functionality should be a consideration as well before going forward.

Overall, having looked at this, better reactivity primitives should probably make stuff like this easier to implement.

[jrconway3]

Sounds good. Thanks for looking into that. I need to sit down and take a better look at the code myself.

[cdvv7788]

Added previews in the list (still needs some work to handle edge cases) and a transparency background (doesn't export when downloading). Also added back the zoom to the canvas.

[Luke-Fernando]

We’ll probably need to rewrite the codebase at some point since it’s starting to show its age by today’s standards. The main question is which framework we should use. This is actually the first time I’ve heard of Mithril.js. I read through its documentation, and it seems like a decent option, especially since we only need a client-side framework.

However, I’m not sure how future-proof it is or how strong the community support will be in the long run. We might risk losing contributors if people aren’t familiar or comfortable with it.

It might be good to consider other factors, like how well-supported the framework is in terms of third-party libraries, that we might want later on, such as styling libraries or other tools.

I think it will be better to update/migrate each part one by one instead of rewriting everything. There are also popular lightweight options out there that we can consider.

[Gaurav0]

We’ll probably need to rewrite the codebase at some point since it’s starting to show its age by today’s standards.

I've thought about this many times. See the other discussion on the future. I've always put solving problems ahead of fixing the framework.

However, I’m not sure how future-proof it is or how strong the community support will be in the long run. We might risk losing contributors if people aren’t familiar or comfortable with it.

I think we'll likely lose contributors with any js framework other than React. That said, and my awful opinion of React aside, I think overall the more minimal the framework and the more easily replaceable the better. Based on those criteria, Mithril.js is actually a fairly good choice. I could definitely see replacing it with tomorrow's framework du jour.

I think it will be better to update/migrate each part one by one instead of rewriting everything. There are also popular lightweight options out there that we can consider.

I suggested this earlier. That said, I'm not eager to turn away a great contribution just because it doesn't align perfectly with what I'd like to see.

[cdvv7788]

Ok people, I think I am done with this for now https://deploy-preview-223--liberatedpixelcup.netlify.app/#bodyType=male&body-body=light&head-heads-heads_human_male=light

The main features should be in place, I just need you to decide if you are moving forward or not now (not rushing like now now, just waiting for next steps haha). If we do move forward, the next steps should be imo:

• Merge that branch to the main repo (maybe not master just yet).
• Test thoroughly.
• Iterate with smaller PRs (that can be actually code reviewed) to close the remaining gaps.
• If we are moving forward with the paint-in-place instead of the current pre-rendered approach, there is a POC in here. I think that as long as the UI remains responsive, the pros outweigh the cons, and we should move forward. We would need some discussions here because some metadata structure may need to change, but the code itself is relatively straightforward and we could make this feature part of the revamp itself (blocking the final release until it is done, I can do it quickly).
• Once the dust has settled, just announce it and move it to the master branch.

Waiting on you finishing the discussion for now. I may tweak it here and there, but I will stop adding features now (I think functionally I should have achieved at least 95% parity by now).

In the case where you decide not to move forward with it, that's ok too. Feel free to use the code if it helps you further down the line when you decide it is time for a revamp.

It has been a fun ride, you got a nice tool :)

cc @Gaurav0 @jrconway3

[Gaurav0]

I for one, am in favor of moving forward.

• This is a massive improvement
• I don't want to dismiss a PR just because it isn't an approach I would take myself
• We can discuss interface details as we go forward if necessary
• I'm well enough convinced we can replace Mithril.js with another framework in the future if needed.
• I'm really excited to see the poc of post process palette swaps

[jrconway3]

Yeah I think making it a separate branch on the main repo may be a viable option here. That let's us work on gradually improving it over time.

Its definitely not ready yet as there's still features missing, but its getting close and the post-process palette swap branch is an excellent POC. I am worried about making such a big change suddenly which is my only hold up. Ideally we'd hear from others and see if they think its a good idea.

[cdvv7788]

Its definitely not ready yet as there's still features missing

The only arguably critical feature missing is the pink mask thing. If I understand that correctly it will color an area with a custom color? If that is the case I think the runtime palette coloring will make it obsolete, and we probably can drop it.

Stuff I know needs attention:
-hiding the whole branch when the tree has no children (filtered out)
-search is a bit clunky
-possibly a ton of ui/ux improvements to come

What functional features apart from this are missing and you would like to see implemented?

[jrconway3]

Sorry, I'll take a look again when I have time.

As for the pink mask, don't worry about that.

The purpose of the pink mask is to simply mask out a piece of an existing sprite and remove it entirely. You can see how its supposed to work on the examples given; one of them is the "peg leg". All the area around the peg leg itself is masked with that pink color, only over the skin of the foot.

I don't know if it actually even works in the original editor either; I think that's supposed to be a "post-process" thing where after you export the spritesheet, you manually select the pink mask on the sheet and delete it using an image editor (or you program it into your project to remove it).

[Gaurav0]

To be honest, it's mostly there.

Some missing features I see:

• Responsive Mobile/Tablet view (single column) with:
  • collapsible animated preview
  • collapsible full preview
  • collapsible controls section
  • collapsible tree section
  • collapsible credits section
• Download Credits (Text)
• Compact Display
• Selecting None / Removing selection from within tree
• Credit the authors at the top should link to Credits section
• Link to Detailed Attribution Instructions in README from Credits section
• Link to full CREDITS.csv
• Advanced tools: Custom file with z position

[cdvv7788]

Buggy how? If you click once it zooms in, if you doubleclick it zooms out. It may detect 2 clicks as part of a double click and zoom in - zoom out in a single event pass (3 events fired in that case, 2 clicks and a double click). This is happening in the old version too.
Maybe we should just not use the clicks for this? We can add a slider to control the zoom and it can control both elements? I will add that to see how that looks.

[Gaurav0]

That does sound preferable if it doesn't take up space.

[cdvv7788]

I added a slider, plus drag support for the canvas. It should be easier to move around. The canvas is now correctly contained within the collapsible element.
You can also unselect things now by clicking on them again.

[Gaurav0]

This is really looking good now! @jrconway3 Can you find anything else?

[jrconway3]

Sorry, just been distracted lately. I'll check it out as soon as I can but I can't guarantee I can check it that quickly.

[cdvv7788]

I think the main focus if we merge it to a branch here would be discussing how we want the tree to look like. Ideally I would like to have what we can and cannot render based on the path. For example, if we already have a body, don't allow other bodies to render at all. At this moment this can happen with regular bodies and the zombie body for example. The exclusion key is body-body vs body-special. If we can make the structure of the tree dictate this exclusion, we can control the app just by placing assets in the right path.
The alternative is to keep a separate key (what the old app is doing with itemType) and then every time we add an asset (not sure if that is a common thing tho) the new element has to add this key.

Any ideas about this? Should we just make zombie a body type? Should we give the bodies a special treatment?

[cdvv7788]

@Gaurav0 can you please create a new branch so I can change my PR to point there, sort out the conflicts, and get an approval for this behemoth? Once that is merged we can start iterating in smaller steps in that branch. I want to avoid adding the paint-in-place in this branch, that will delete a HUGE amount of files, so I don't want to mix them.

[jrconway3]

Yeah I was going to suggest this for sure. We should simply create a new branch for this instead and then the rest of us can play around with it as well.

[Gaurav0]

@Gaurav0 can you please create a new branch so I can change my PR to point there, sort out the conflicts, and get an approval for this behemoth? Once that is merged we can start iterating in smaller steps in that branch. I want to avoid adding the paint-in-place in this branch, that will delete a HUGE amount of files, so I don't want to mix them.

As you are now a member, I think you could have done this yourself.

[cdvv7788]

@Gaurav0 can you please create a new branch so I can change my PR to point there, sort out the conflicts, and get an approval for this behemoth? Once that is merged we can start iterating in smaller steps in that branch. I want to avoid adding the paint-in-place in this branch, that will delete a HUGE amount of files, so I don't want to mix them.

As you are now a member, I think you could have done this yourself.

Maybe, I don't want to overstep tho ;)

[Gaurav0]

Maybe, I don't want to overstep tho ;)

I can always undo what you did lol.

Only thing you can't do is write to master without a pr with approval.

[Gaurav0]

Remaining things (not blocking, just for remembering and discussion)

• Compact Display
• Pink mask
• Pinch to zoom
• removing type_name
• subcategory name duplication

[cdvv7788]

We should think about adding spinners at some point for the slow bits (specially the initial render). Just a simple css based spinner until we render should be ok.

[jrconway3]

Now that we have a new branch, I think we can report issues related to said branch and slowly work on them.

I still have yet to review again, I've been busy with other things (and work). But I'll try reviewing later in the week.

[cdvv7788]

Until the release, should we try to merge changes to the new branch if they make sense? I see f3b1d18 in master, not sure if we need it here.
Maybe we should make a roadmap to warn users? I think the current state is not bad at all, just has some rough edges that need polishing, but it is certainly functional.

[Gaurav0]

I rebased full_rewrite against master after that commit was merged, so it's included in your branches.

[Gaurav0]

@cdvv7788

@sanderfranken did some testing. Here is what he found:

the eye color is not working.
you can select a tool and a weapon at the same time. Which conflicts in the walk animation. These should be mutually exclusive.
Match body color does not work on the faces. When I select an angry face in another color it doesn’t change the color of the body and the head.

[cdvv7788]

I mentioned this before. You can select a regular body and a special body too.
I am not sure about how to handle this. The only disambiguation I am using is forbidding using anything in the same subcategory (for example body-body or head-hair).
Open to discuss this, definitely something we need to tackle.

[Gaurav0]

Just use the type_name you previously deleted. That was the radio button group.

I opened a PR to restore the missing field.

[Gaurav0]

@cdvv7788 Are you registered on the OpenGameArt.org discord? If so, what's your username? I can add you to our chat.

[cdvv7788]

Sent you a dm

[Gaurav0]

Further issues:

Exported from existing generator, won't import in rewrite:

Details

{ "bodyTypeName": "female", "url": "https://liberatedpixelcup.github.io/Universal-LPC-Spritesheet-Character-Generator/#?body=Body_color_light&head=Human_female_light&sex=female&hair=Sara_blonde&earring_left=Simple_Earring_Left_blue&earring_right=Simple_Earring_Right_blue&earrings=none&eyes=Eyes_blue&nose=Straight_nose_light&clothes=Shortsleeve_sky&hat=Tiara_tiara_silver&apron=none&shoes=Sara_sara&legs=Straight_skirt_navy&sash=Waistband_rose&cape=none&facial_left=none&neck=none&buckles=Buckles_gold&weapon=none", "spritesheets": "https://liberatedpixelcup.github.io/Universal-LPC-Spritesheet-Character-Generator/spritesheets/", "version": 1, "datetime": "8/21/2025, 2:45:16 PM", "credits": [ { "fileName": "body/bodies/female/light.png", "licenses": "OGA-BY 3.0,CC-BY-SA 3.0,GPL 3.0", "authors": "Benjamin K. Smith (BenCreating),bluecarrot16,TheraHedwig,Evert,MuffinElZangano,Durrani,Pierre Vigier (pvigier),ElizaWy,Matthew Krohn (makrohn),Johannes Sjölund (wulax),Stephen Challener (Redshrike)", "urls": "https://opengameart.org/content/liberated-pixel-cup-lpc-base-assets-sprites-map-tiles,https://opengameart.org/content/lpc-medieval-fantasy-character-sprites,https://opengameart.org/content/lpc-ladies,https://opengameart.org/content/lpc-7-womens-shirts,https://opengameart.org/content/lpc-jump-expanded,https://opengameart.org/content/lpc-be-seated,https://opengameart.org/content/lpc-revised-character-basics,https://gitlab.com/vagabondgame/lpc-characters,https://opengameart.org/content/lpc-male-jumping-animation-by-durrani,https://opengameart.org/content/lpc-runcycle-and-diagonal-walkcycle", "notes": "see details at https://opengameart.org/content/lpc-character-bases" }, { "fileName": "head/heads/human/female/light.png", "licenses": "OGA-BY 3.0,CC-BY-SA 3.0,GPL 3.0", "authors": "bluecarrot16,Benjamin K. Smith (BenCreating),Stephen Challener (Redshrike)", "urls": "https://opengameart.org/content/,https://opengameart.org/content/lpc-character-bases", "notes": "original head by Redshrike, tweaks by BenCreating, modular version by bluecarrot16" }, { "fileName": "head/nose/straight/adult/light.png", "licenses": "GPL 3.0,CC-BY-SA 3.0", "authors": "Thane Brimhall (pennomi),laetissima,Matthew Krohn (makrohn)", "urls": "https://opengameart.org/content/lpc-base-character-expressions", "notes": "" }, { "fileName": "hair/sara/adult/fg/blonde.png", "licenses": "OGA-BY 3.0,CC-BY 3.0", "authors": "Stephen Challener (Redshrike),William.Thompsonj,Mandi Paugh,bluecarrot16", "urls": "https://opengameart.org/content/lpc-sara,https://opengameart.org/content/lpc-hair,https://opengameart.org/content/lpc-expanded-xlong-hair", "notes": "" }, { "fileName": "hair/sara/adult/bg/blonde.png", "licenses": "OGA-BY 3.0,CC-BY 3.0", "authors": "Stephen Challener (Redshrike),William.Thompsonj,Mandi Paugh,bluecarrot16", "urls": "https://opengameart.org/content/lpc-sara,https://opengameart.org/content/lpc-hair,https://opengameart.org/content/lpc-expanded-xlong-hair", "notes": "" }, { "fileName": "hat/formal/tiara/adult/tiara_silver.png", "licenses": "CC-BY-SA 3.0,GPL 3.0", "authors": "Luke Mehl", "urls": "https://opengameart.org/content/female-mage-clothing-set,https://opengameart.org/content/lpc-expanded-hats-facial-helmets", "notes": "" }, { "fileName": "facial/earrings/simple/left/adult/blue.png", "licenses": "CC0", "authors": "bluecarrot16", "urls": "https://opengameart.org/content/lpc-pirates", "notes": "" }, { "fileName": "facial/earrings/simple/right/adult/blue.png", "licenses": "CC0", "authors": "bluecarrot16", "urls": "https://opengameart.org/content/lpc-pirates", "notes": "" }, { "fileName": "torso/clothes/shortsleeve/shortsleeve/female/sky.png", "licenses": "OGA-BY 3.0,CC-BY-SA 3.0,GPL 3.0", "authors": "bluecarrot16,ElizaWy,JaidynReiman,Stephen Challener (Redshrike)", "urls": "https://opengameart.org/content/liberated-pixel-cup-lpc-base-assets-sprites-map-tiles,https://opengameart.org/content/lpc-7-womens-shirts,http://opengameart.org/content/lpc-revised-character-basics,http://opengameart.org/content/lpc-clothing-updates,https://github.com/ElizaWy/LPC/tree/main/Characters/Clothing,https://opengameart.org/content/lpc-expanded-sit-run-jump-more,https://opengameart.org/content/lpc-expanded-simple-shirts", "notes": "original by ElizaWy walkcycle only; extended to all animations by adapting from longsleeve, edited to v3 bases by bluecarrot16; cleanup and climb/jump/run/sit/emote/revised combat adapted from LPC Revised by JaidynReiman" }, { "fileName": "torso/waist/waistband/female/rose.png", "licenses": "OGA-BY 3.0", "authors": "Bluecarrot16,Mandi Paugh,Stephen Challener (Redshrike),William.Thompsonj", "urls": "http://opengameart.org/content/sara-wizard,https://opengameart.org/content/lpc-sara", "notes": "LPC Sara by Redshrike, contributed by William Thompsonj, Waistband Separated by Bluecarrot16" }, { "fileName": "torso/waist/buckles/female/gold.png", "licenses": "CC-BY-SA 3.0,GPL 3.0", "authors": "Luke Mehl", "urls": "https://opengameart.org/content/female-mage-clothing-set", "notes": "" }, { "fileName": "legs/skirts/straight/female/navy.png", "licenses": "OGA-BY 3.0,GPL 3.0", "authors": "bluecarrot16,ElizaWy", "urls": "http://opengameart.org/content/lpc-clothing-updates", "notes": "original skirt by ElizaWy, extended to all animation frames and edited for v3 bases by bluecarrot16" } ], "layers": [ { "fileName": "hair/sara/adult/bg/blonde.png", "zPos": 9, "parentName": "hair", "name": "Sara", "variant": "blonde", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" }, { "fileName": "body/bodies/female/light.png", "zPos": 10, "parentName": "body", "name": "Body_color", "variant": "light", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" }, { "fileName": "legs/skirts/straight/female/navy.png", "zPos": 20, "parentName": "legs", "name": "Straight_skirt", "variant": "navy", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering" }, { "fileName": "torso/clothes/shortsleeve/shortsleeve/female/sky.png", "zPos": 35, "parentName": "clothes", "name": "Shortsleeve", "variant": "sky", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" }, { "fileName": "torso/waist/waistband/female/rose.png", "zPos": 65, "parentName": "sash", "name": "Waistband", "variant": "rose", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering" }, { "fileName": "torso/waist/buckles/female/gold.png", "zPos": 75, "parentName": "buckles", "name": "Buckles", "variant": "gold", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering" }, { "fileName": "head/heads/human/female/light.png", "zPos": 100, "parentName": "head", "name": "Human_female", "variant": "light", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" }, { "fileName": "head/nose/straight/adult/light.png", "zPos": 105, "parentName": "nose", "name": "Straight_nose", "variant": "light", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" }, { "fileName": "facial/earrings/simple/left/adult/blue.png", "zPos": 115, "parentName": "earring_left", "name": "Simple_Earring_Left", "variant": "blue", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" }, { "fileName": "facial/earrings/simple/right/adult/blue.png", "zPos": 115, "parentName": "earring_right", "name": "Simple_Earring_Right", "variant": "blue", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" }, { "fileName": "hair/sara/adult/fg/blonde.png", "zPos": 120, "parentName": "hair", "name": "Sara", "variant": "blonde", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" }, { "fileName": "hat/formal/tiara/adult/tiara_silver.png", "zPos": 130, "parentName": "hat", "name": "Tiara", "variant": "tiara_silver", "supportedAnimations": "spellcast,thrust,walk,slash,shoot,hurt,watering,idle,jump,run,sit,emote,climb,combat,1h_slash,1h_backslash,1h_halfslash" } ] }

Also the hash #?body=Body_color_light&head=Human_female_light&sex=female&hair=Sara_blonde&earring_left=Simple_Earring_Left_blue&earring_right=Simple_Earring_Right_blue&earrings=none&eyes=Eyes_blue&nose=Straight_nose_light&clothes=Shortsleeve_sky&hat=Tiara_tiara_silver&apron=none&shoes=Sara_sara&legs=Straight_skirt_navy&sash=Waistband_rose&cape=none&facial_left=none&neck=none&buckles=Buckles_gold&weapon=none
fails to load

[cdvv7788]

I see:

{
  "name": "Straight skirt",
  "layer_1": {
    "zPos": 20,
    "female": "legs/skirts/straight/female/",
    "pregnant": "legs/skirts/straight/female/",
    "teen": "legs/skirts/straight/female/"
  },
  "variants": [
    "black",

And that is in the hash like legs=Straight_skirt_navy (which makes sense, name with underscores instead of spaces.

Then you have eyes=Eyes_blue but the item is (I am guessing because the old version doesn't load it either):

{
  "name": "Eye Color",
  "replace_in_path": {
    "head": {

Is this path 100% correct?

[Gaurav0]

That's what it was supposed to be. If eyes is broken it doesn't surprise me, we were trying to implement something where eye choice was based on head, expression, and eye color.

[cdvv7788]

I will just switch back on a best effort to make them compatible (even if not perfectly), we can worry about this later on.

[jrconway3]

I mentioned elsewhere, but I have a solution for Eye Color based on Vitruvian and Color in Place:
#234

If this is something we can implement later (not immediately, but relatively soon), we can skip out on making Eye Color work right now if its too complicated.

[cdvv7788]

#242 I restored the previous behaviour for now.

[Gaurav0]

@jrconway3 wrote:

Is it being ordered alphabetically or something? I think the order is different now. In the original we manually set the order. The Pattern should be the last thing, and they should be sorted with the respective version.

Yes, reading generate-sources.js it looks like it is. Before we ordered things by manually specifying the order in source-index.html.

I don't want to keep doing that, however. Maybe we should add an optional order field to the sheet definition json files?

[cdvv7788]

The tree is generated on the fly without much regard for the ordering at all. First come, first served. We can figure something out if the order is important.
For the variants, I wouldn't spend a huge amount of effort for this tho, Ideally we can get rid of those in their current form soonish.

[Gaurav0]

I think we should have an optional order field and have it apply to the last item in the path array. If it is missing, alphabetical or any determinate order should be fine.

For higher level categories, we can use constants in the source code to determine order. Again, just leave the order out if it's not important.

[cdvv7788]

We could also try ordering at build time so the order is implicit in the meta file. Would have to test how consistent it stays through different operations tho.

[jrconway3]

Yeah I would like a manual override option for the order. Only implement the override if that option exists, otherwise you can stick to what you have now. I have skimmed through a number of assets and they look fine to me, it was really just this Shield that lined up pretty badly.

[Gaurav0]

Re: Eye color

It looks like dynamic replacements are hardcoded to only replace the ${head}. So things like ${expression} aren't working.

[cdvv7788]

Oh yes. I wanted to discuss if there wasn`t a better way to implement this. Having this stuff in the meta json file would be best if possible.

[Gaurav0]

I'm sure there is.

chargen.js implemented it like this mainly to keep the size of index.html down to something reasonable and to keep the number of sheet definition files from exploding.

generate_sources.js could generate everything and put it in the metadata file, but then the metadata file would explode in size.

In chargen.js, we have a function es6DynamicTemplate that does the heavy lifting at runtime.

I think the right mix of both approaches is best.

[jrconway3]

I present to you:
#234

I'm not too worried if Eye Color doesn't work right away if we can implement this fairly quickly. IMO this would be a far, far better replacement, but we didn't have the capability of doing it before.

Basically, if we can simply swap the eye color using palette swapping (color-in-place) then we don't need this feature at all. We can simply specify a second palette swap option on certain assets.