Peter Rowlands (변기호)

and yeah, auto-naming based on menus is really only relevant for specific use cases, mainly: > A common use case is for VNs to have route selection or chapter selection...

I guess I'm confused as to what you are asking for, since capital-L `Label` is an actual LSB command type, and `Label`s are what livemaker uses as branch (Jump/Call) targets....

ok, so yeah all you really need to do is just figure out how you want to rename Labels and put that into a cli tool. I can add a...

since the CSV format (#42) now uses label name as a column, we could probably also just add a flag for insertcsv that does "replace label for each scenario with...

Is there a particular reason you are against patching them into the lsb? Setting the strings in the lsb doesn’t affect anything other than adding a few bytes that get...

fwiw there's also nothing preventing us from inserting comments into an lsb either, there is an actual Comment command class, and there's a `Mute` field in every command, that is...

> iirc, when you make an actual livemaker project, intermediate LSBs (that are used for debug builds and live testing when editing a project) also keep the original useful strings...

I don't think it will affect performance at all, given that all of LM's system LSB's are already doing name lookups all the time. And yes, obviously it's not useful...

Basically the idea is to have a format that allows for potential future translatable object types (beyond menus and scenarios), and that will still handle the case where user appends...

This will also allow us to potentially have a single `extract...` and single `insert...` command that recursively searches a project dir for any (non-system) LSB, and automatically extract/insert all translatable...