<wpwrak>
hmm, there's no way to attach a workplane to a different point, is there ? i have a whole stack of things that sits on a reference that's not quite valid (resulted from extruding an "invisible" assembly). and of course, deleting that bad extrusion kills the whole stack :(
<wpwrak>
hmm. so if part A uses part B (with assembly) and part B used part C, and i change C, then A won't see this until i load and save B. bug ?
<wpwrak>
there, i build the case with slices from 1) an-side, 2) an-side-overlap, 3) an-main, 4) an-side-overlap, 5) an-side. and on top a cut-out (which isn't quite finished yet. unfortunately, i can't set the extrusion depth nicely)
<wpwrak>
3) and 4) also had a problem: since assembly doesn't always give me points on the top of the extrusion (not sure what that depends on), i had to construct a helper line for placing that last an-side
<wpwrak>
whitequark: "export image" is now better (icon box stays, no complaints on the console), but the menu bar still has issues: after "export image", bringing up the "File" menu makes the "File" entry in the menu bar turn black. for any other entries, it makes all until the one selected black out.
mumptai has joined #solvespace
mumptai has quit [Remote host closed the connection]
<whitequark>
(points on top of extrusion) are you sure they're visible when you're saving the file?
<wpwrak>
(#80) you mean my A, B, C scenario ? this doesn't really need all of #80. slvs already tracks one level of dependency, so all that's missing is to do this on the transitive closure. if that's hard to do inside slvs, how about a cli invocation that just loads, recalculates, and saves ? then this could be done with make.
<whitequark>
no, it exactly does need all of #80, unless you're willing to inflict severe delays on every assembly reload
<whitequark>
slvs doesn't track any dependencies at all
<whitequark>
it just writes down the entire final positions for every entity into the file, so that importing it can load that
<wpwrak>
(visible when saving) hmm, loaded and saved everything, and played a bit with "show" in the final assembly, and now i got all the points i need. not sure why i didn't get them before. anyway, that bit is solved then, thanks !
<whitequark>
the WYSIWYG part is kind of annoying
<whitequark>
but for now there's no separate export anything
<whitequark>
except chord tolerance, because having chord tolerance depend on the zoom level produced some *horrifying* instability in the mesh backend
<wpwrak>
chord tolerance sucks ;-) it's very confusing to see all sorts of points that are on arcs, but in the UI, they just float around wherever, since the tolerance lets the "arc/circle" polygon go far off
<whitequark>
sucks?
<whitequark>
it shows you the representation used for most calculations...
<whitequark>
(export image) yeah, apparently
<whitequark>
I think this is a GTK bug?
<whitequark>
oh, hm: Mesa: User error: GL_INVALID_OPERATION in glUniform(program not linked)
<whitequark>
no, that was a different issue
<whitequark>
no idea
<wpwrak>
(vanishing menu bar items on image export) well, not an urgent one to fix. lemme write an issue for it ...
<whitequark>
interestingly, I do get GL errors on Wayland
<whitequark>
the representation you see will be used by the mesh backend as well
<whitequark>
it's less critical in case of construction, I guess, but treating construction differently from normal entities is nasty in different ways
<wpwrak>
the point in the selection is nominally on the arc below it. the one a bit to the right of it, outside the selection, is a center point from an arc slightly above the screen, and has no direct relation to the arcs surrounding it
<whitequark>
yes. I know what you're talking about.
<wpwrak>
i think mesh vs. construction is actually the other way around: in the mesh used for machnining, some specific tolerances would be fine, since they correspond to machine limitations. but in construction i move much more freely and sometimes have to zoom in deeply to be able to select items. so some 0.1 mm tolerance suddenly becomes quite huge.
<whitequark>
oh, ugh, I found the screenshot issue
<wpwrak>
kewl. no new issue needed then :)
<whitequark>
typo more or less
<wpwrak>
aah, speaking of little annoyances, do you get that warning ? [...]solvespace/src/drawentity.cpp:298:17: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
<wpwrak>
in #166, "manually" means "not slvs's problem". but let's automate that, too :) so, under what circumstances would Group.impFile differ from Group.impFileRel ?
<whitequark>
when you move it
<whitequark>
in general, impFileRel is the authoritative source, and impFile is a fallback one
<whitequark>
impFile can be considered deprecated
<wpwrak>
perfect
nats` has left #solvespace [#solvespace]
<wpwrak>
hmm, just had a scary thought. if availability of points on extrusions (and possibly in other cases as well) used in assemblies, depends on the visibility settings when saving the part, what happens if i update the part and save with that visibility turned off ? would uses of these points in the assembly get disassociated, possibly permanently ?
<whitequark>
wpwrak: nope
<whitequark>
that's just visibility
<whitequark>
you arent able to select them but they're still there
<whitequark>
it's the actVisible field in .slvs file / internal data strucutres