You don't necessarily need old pyro solver as the "sparse" one can simulate both sparse and dense grids You may still chose to sim on a dense grid occasionally especially if you care about velocities outside of the density or flame usually for advection needs for particles, vellum, ...

You can use Ray SOP usually in Minimum Distance mode and output Prim Num and Prim UVW attributes as posprim and posuv Similarly you can use xyzdist() vex function to get those from closest surface location also

hard to comment on what you are missin without seeing what you did, but yeah essentially looks like a specific profile shape swept along curve and rendered with rough refractive material and absorption

this however you can get island id's using Connectivity SOP in uv connectivity mode

probably thickness (pscale) on your cloth or collider or both on your Vellum Cloth you can check Visualize Thickness to see (or also on Vellum Solver in Visualize tab) if that one seems ok, it may be pscale attrib on your colliders

you don't need backticks, with backticks you are inserting HScript expression into the code string, which will get resolver first and then the string is used as VEXpression, so it's similar to typing the number there to use detail() VEX function with an operator path you have to specify the path with op: prefix, so in your case i@loopN = detail("op:../eachP", "iteration"); however I'd suggest using Spare Inputs to reference geo from operator path instead

be careful with .pressButton() though as that will trigger callback script on your parm if you have any, which may not always be desirable

if you call .menuItems() or .menuLabels() on such parm (which clearly evaluates the script) it would return already updated values also setting the menu items or labels directly on that parm using parm template would change them however none of those seem to have immediate UI change effect only opening the menu or also simple clicking on different node and back would show updated ones even without doing any of the above I'm not sure which clean function would refresh the UI what you can do as a workaround, at least seems to work for me is do callback script for your parm A to do this: hou.ui.paneTabOfType(hou.paneTabType.Parm).setShowParmDialog(1) which should refresh the UI and therefore force parm B to show item from updated menu B but I'd consider this a bit dirty, maybe someone knows a better way

B menu should be calling the script any time you open the menu, sort of generated on the fly if needed, therefore it would pick up the changes in which situation do you see the B menu's items during changing A that you would notice it's not updated? EDIT: an, I see, you are using Normal menu so you see the label of chosen entry instead of the actual value

you can do this for example in point wrangle after your Connectivity SOP int class = prim(0, "class", @primnum); // get class of point's prim string grp = sprintf("@class=%s", class); // ad-hoc group string for all prims with that class value vector rbb = relbbox(0, grp, @P); // rel bbox of point's p within bbox of all prims in that group v@Cd = chramp('color',rbb.y); // profit how_to_foreach_prim_with_vex_fix.hip

Edge Cusp SOP should be what you need

Have you tried Edge Cusp?

it's the i@id attribute that's messing stuff up, it was added as a way to match points by id, but the fact that it is using id whenever it finds it instead of it being an option is causing such issues also you don't need for each anymore if you have piece attrib, in your case i@class was_working_fix.hipnc

you can directly stamp string attribs, if you put your string attrib name into Attribute Stamps parameter on Copy SOP and then use stamps() expression to retrieve it Test_fix.hip

https://www.sidefx.com/forum/topic/56984/