@starseeker I recall all the vestiges of interfacing with muves were ripped out in 7.30, and someone noticed. Do you recall what the migration plan is/was for read_muves?
there's of course a user that relied on it, now wondering where it went
I couldn't recall if there was a tool / command in ajem that did that mapping or if you'd added an option to one of the commands for reading a mapping file?
I'm trying to remember - are you referring to read_muves? muves_read doesn't show up in CHANGES
right, read_muves sorry
Let me take a look...
From what I got from the docs, the command basically iterated over the region map file, and set the MUVES_Component attribute on the corresponding objects. That's an interesting use case I'd not remembered, and not one I know of anywhere else... might be a way to generalize it if it doesn't exist (by restoring, but just not calling it read_muves).
create combs or set attrs based on a text input file
Well, kind of. If the user is depending on knowledge of the parsing of the MUVES files, that's not really generalizable (and is no longer present in current code.)
It would simply be standardizing on a text input that is similar (if not identical) with a line describing a mapping, each line being an identifier followed by whitespace followed by a list of names or ids. basically just say "here's how you can create a text mapping file" and that format would just happen to match most regmaps. Alternatively, we could go the nirt route and define the input using a parser grammer, and have a a couple pre-canned formats, but that'd be new work and doesn't address this guy's issue.
https://github.com/BRL-CAD/brlcad/blob/refs/tags/rel-7-28-2/src/mged/muves.c
I remember that file. What was the migration plan?
Last updated: Jan 09 2025 at 00:46 UTC