All Activity

@Tom W. when you say "storey layers" do you mean "storey levels"? My setup is that I have one storey - and any design layers containing geometry that wants to take advantage of storey levels are contained within that storey. (Possibly I could just put all design layers in that storey - I don't think that would cause anything bad to happen) A typical list of design layers for me is foundations, ground floor (existing), ground floor (proposed), first floor (existing), first floor (propsed), roof, external landscaping, etc etc. I'd just put all of these in the VW "storey". For my purposes I don't use it as a storey, just a container to allow me to access "storey levels". Then I set up my various "storey levels". As you can see from the screenshots they are typically things like FFLs, FCLs, structural setting-out levels, and anything else that might be useful. I use those storey levels mainly for the elevation benchmarks that I use quite liberally on section viewports. I do also sometimes use them for binding things like wall components to. But note that you can still use design layer elevations to bind relative to (in addition to storey levels). So if I understand correctly what you've done, then no I don't think you needed to do anything other than set up a "storey", put your design layers into* that storey, then set up whatever storey levels you like. Then where you have objects already bounded relative to layer elevations, you could jsut leave them as-is, or choose to switch to binding them to storey levels instead, if more convenient. As I probably said somewhere up the thread, I quite like giving all of my design layers an elevation of zero (for ease of copy and paste-in-place) in which case when I want to bind things relative to an upper floor level, I use the appropriate storey level. But this system would not be efficient for projects with multiple repeating storeys. The other limitation (compared to layer elevations) is that not all objects can have their elevation linked to a storey level. I wish they could be - would make things like setting the height of lightswitches on a first floor a bit smoother. *never quite sure what the right terminology is: is a design layer "within" a storey or just assigned to a storey? Probably doesn't matter but I remember when I first was trying to get my head around storeys it took a while to understand their relationship to design layers.

I HATE the Component Edit Window. Every time I edit a symbol, the thing appears. I never use it. Have NEVER used. Probably will never use it. I have command keys that are much faster. It SHOULD be anchored to the tool bar at the top of a window, unfortunately it obtrusively floats around. Is there a way to disable it completely? There's no information in Vectorworks 2024 Help. Thanks

Do you have "Display planar objects" turned on for the viewport? If so, deselect it in the Object Info palette and see if that corrects it.

@line-weight thank you for reminding me of this thread. So do you not use any Story Layers...?: I think this is what I remain slightly unclear about in my file (the first to incorporate Stories): where to have standard Design Layers + where to have Story Layers. The file started off as a layer bound set-up with all my standard design layers then I added stories midway through, really only to utilise the enhanced Elevation Benchmark functionality discussed elsewhere. So I had existing layers that I converted into story layers because they represented critical elevations like top of subfloor etc. But in your setup would you have just left them as design layers + created a separate story level for that elevation...? This is a single story building so all I'm really interested in using stories for is 1) using Elev BMs + 2) setting levels I can bind objects to without requiring a dedicated design layer for them.

No worries. It's part of a much larger project, and I can integrate the top-up script in to the next stage of the process, so it's a good solution all in all. Thanks for your help!

When I export in the IFC 2x3 version, in the export IFC settings, there is the option to export the components separately and, with it activated, the classification of each component is correct. How can I export wall finishes to IfcCovering for IFC 4 from a multi-layer wall style automatically?

In retrospect, I think Subdivision would have worked out better than my alternative. The mesh would have had issues with the round rim. It is always better to find the answer on your own if you can. Trial and error is the best way to learn. Just out of curiosity can you post a picture of your work?

@spettitt You should be able to do the control point solution without needing events, and it might be cleaner from a usability standpoint. You would just need to specify a control point parameter and then pull it using the standard PControlPoint01X and PControlPoint01Y like you would any other parameter value. If I can wrap up my immediate tasks this morning, I can fab up a Vectorscript example for you.

We've conducted initial tests with macOS 14.5 beta2, and it appears that the printing issue has been resolved. 🤞🏼

My setup is pretty simple in the end really. This was the thread I made when first trying it:

Hmm, haven't noticed this. Well, since you have this figured out I suppose that it is ok

That's right, yes. This was what I had: import vs ##################### # First - Reset the SktUUID Record on each socket in each Device prof group def SockRecord(h): vs.Record(h, 'SktUUID') vs.SetRFieldOpt(h, 'SktUUID', 'Dev', True, True) vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) def DevSockAddRecord(h): hprofile = vs.GetCustomObjectProfileGroup(h) vs.ForEachObjectInList(SockRecord, 1, 0, vs.FInGroup(hprofile)) vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) vs.ForEachObject(DevSockAddRecord, "PON = 'Device'") ##################### # Then go through each Device and post it's Self UUID. # Devices first because they are at the top of the relational chain def DevUUID(h): UUIDv = vs.GetObjectUuid(h) vs.SetRField(h, 'DevUUID', 'Self', UUIDv) vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) vs.ForEachObject(DevUUID, "PON = 'Device'") ##################### # For each socket, post it's self UUID and then reset it, so it picks up the Device UUID def SockUUID(h): UUIDv = vs.GetObjectUuid(h) if UUIDv: #vs.Message(f'Found a socket {UUIDv}') vs.SetRField(h, 'SktUUID', 'Self', UUIDv) vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) def DevSockUUID(h): hprofile = vs.GetCustomObjectProfileGroup(h) vs.ForEachObjectInList(SockUUID, 1, 0, vs.FInGroup(hprofile)) vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) vs.ForEachObject(DevSockUUID, "PON = 'Device'") ##################### # Then go through each Circuit and post it's Self UUID def CircuitUUID(h): UUIDv = vs.GetObjectUuid(h) if UUIDv: #vs.Message(f'Found a circuit {UUIDv}') vs.SetRField(h, 'CircuitUUID', 'Self', UUIDv) vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) vs.ForEachObject(CircuitUUID, "PON = 'Circuit'") # Resets for good measure def refreshskt(h): vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) def refreshdev(h): hprofile = vs.GetCustomObjectProfileGroup(h) vs.ForEachObjectInList(refreshskt, 1, 0, vs.FInGroup(hprofile)) vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) def refreshcircuit(h): vs.ResetObject(h) vs.SetObjectVariableBoolean(h, 1167, True) vs.ForEachObject(refreshdev, "PON = 'Device'") vs.ForEachObject(refreshcircuit, "PON = 'Circuit'") Which produced the below:

@Jesse Cogswell - thanks so much for this! I hope over time I can give back to this forum in the way it's given to me. I've got your first example running nicely with Vectorscript, and my next task will be to rewrite in Python so I can see how such a PIO might handle the same task. From there, I don't think it'll be too hard to pull the truss data and class the PIO geometry. I have two other big Python projects on outside of Vectorworks (though using Vectorworks data), and I don't think my little mind can handle looking at events right now. If I can get the simple version working, potentially with the 'Lock' parameter, that would be great for the moment and I'll come back to the events thread above when the time is right.

Did you put my script in your old script? My change was just 1 line in your old script but I added the whole function for context.

Thanks for this @Nikolay Zhelyazkov. Adding that line does indeed give me the parent device, but did then affect the sockets getting their self UUID. However then a follow-up script just to write the socket self UUID got me the full house. For what it's for, I don't mind two scripts, so this is great. Thank you.

Hello all, In VW 2024 we have added the ability to display all TBB parameters and records in the OIP. If the Sheet Data.Scale field is added then the Update Scale button is added too. So I think that this thread is resolved there. Best Regards, Nikolay Zhelyazkov

The problem is that Spotlight doesn't use the channel number as the internal identifier since it can change based on design and user requirements, which would then break any connection (internal to Spotlight or external) to the any other linked data. You can try using the worksheet criteria ='Lighting Device'.'UID' to access the UUID's and this may enable you to correctly map the data. What software are you using to create the patch? If it supports MVR this may provide another route to get the data in and sync it to the correct lights.

Hello. Is there any way to insert the real photos instead of generated 3D images in grafic legends? That could be great option.

Hi, Sorry what is the outcome of this discussion please? It would be a great time saver to automate the scale of the titleblock against the viewport on the drawing sheet, and in case there where multiple viewports at different scales then there should be an option for various scales. Thank you Federico

I do understand the issue regarding the correct data, but in the case of Spotlight you always add the Channel number / Unit number to your fixture. That would be the unique identifier for Vectorworks to match to. I create my patch in another software then Vectorworks as some of the modes are not correct or there is no GDTF fixture available etc. Atm I have to manual insert the patch in Vectorworks which can result in errors, with the new Excel referencing I was hoping to find a way to import a CSV / Excel and link it to an Lighting Device.

Multiple Apple silicon Macs with Apple displays. We get more crashes for sure, but it's not (yet) unmanageable. (We have a super-robust auto-back-up system in place.) Printing is a complete mess with our HP Printer. We have historically printed directly from VW using the Publish function. It worked beautifully. Now it just messes up the page formatting (that has to be manually reset for every sheet layer) and churns out so much waste paper from the printer. We have gone to a 'via PDF' workflow, but it's so much slower. Praying for a fix soon... P

Any luck this time?

I think I did it somehow 😃 I used subdivision and it turned out quite ok. Not super accurate but good enough. Thanks!!

I'd be interested in quizzing you over your set-up as I'm not sure I completely know what I'm doing (with Stories) yet, but like you say probably better in another thread... It was actually after you clarified for me elsewhere that to get the full benefit of Elev BMs you needed to use Stories that I finally decided to do so on a current project. Although I added them halfway through which wasn't perhaps the most effective way of doing it 🙂

Yes I have been doing this for a while now and it's very useful. It's one of VW's best-implemented features. Just waiting for section-elevation lines to be updated to behave as nicely. Relating elevation benchmarks to storey levels is one of the main reasons I use "storeys" even though I actually just use one storey and put all of my levels (for multiple floor levels) within it. But this is all a bit off topic for this thread, which is supposed to be about getting by without using storeys at all.