Search the Community

This is an active bug in Spotlight 2023 SP6, but I've seen it for a few years. The attached file and screenshot show what's happening, so I'll try to keep the post itself as short and to the point as I can. Synopsis The Instrument Summary Tool's Show Counts function gives false results when you have multiple lighting device symbols with certain identical data in the Light Info Record (LIR) and OIP. Specifically, the [Inst Type] and [Model Name] fields in the symbol LIR and the [Instrument Type] field in lighting device OIP's are involved. Description As seen in the screenshot, There are 12 instruments in the drawing, but the counts in the Instrument Summary are wrong. The Instrument Summary list is organized by symbol name, with each symbol having a separate line and its own count. The root issue appears to be that symbol name is not the top-most criterion used for counting. This means that instruments generated from different symbols can be counted together on the lines for each separate symbol, multiplying the true number. In the demo drawing, I have four instruments generated from four discrete symbols representing Arri Skypanel S60-C's. The two black and white symbols were imported directly from the resource library, then the red, blue, and yellow versions were created by duplicating the original symbol and changing the 2D geometry color. Because the relevant fields in the LIR's are identical, they all get counted under each symbol. Note in particular that the yellow symbol is not even present in the drawing, but still shows the count for the other four due to the bug. It's worth pointing out that anyone using the two black and white skypanel symbols taken from the VW resource library will encounter this bug without having made any customizations. There are other examples in the resource library of sets of symbols with identical LIR's which will cause this bug out of the box. I created the bottom three rectangle symbols in the Instrument Summary from simple 2D geometry which I turned into a symbol, attached the LIR and copied the [Inst Type] field from the skypanel symbols, then duplicated. I included the Lighting Symbol Maintenance dialog in the screenshot to show the LIR values of the various symbols. The counting bug takes on different behaviors depending on which of the data fields match and which don't, as noted in the screenshot. The bug variations for the rectangle symbol counts come from the [Instrument Type] in the OIPs being different from [Inst Type] in the LIRs, whereas they are the same for the skypanel symbols. For the dark grey rectangle devices, the OIP [Instrument Type] matches the skypanel device OIP's, and for the white and light grey rectangles it is different. Comments FWIW I have encountered this bug numerous times through sharing files and collaborating with other users on film set lighting plots. As a team, we frequently create customized variations of the resource manager lighting device symbols, most commonly to represent instruments which are not in the resource manager, or for different accessory buildouts. It is quite easy to duplicate a symbol, tweak the geometry or colors, then begin using it without updating the LIR fields, but it is rather tedious to make sure each symbol variation has unique data in the relevant places to avoid this bug. In my experience many Spotlight users aren't familiar with the finer points of using the Light Info Record in the first place and don't know how to update it. To my mind, the ideal solution would be to fix the count algorithm so it uses symbol name as the first distinguishing criterion, as that would remove the requirement to give each symbol unique data in the LIR and OIP. Thanks as always for all the work the mods and devs put in to keep VW humming. instrument summary count bug.vwx

I've just realised that a bunch of hatches in the library I previously used are not there anymore in 2023. Particularly a couple of great German ones called 'Plan Shading' and 'Urban Planning' seem to have vanished. Can anyone enlighten me and advise how they might be regained?

Our section viewports are loosing profile line after viewport update. Advanced settings are correctly set up. Has something changed since version 2022 and we have to be aware of or is it bug? Is there some way to fix it in meantime? It is the same for files migrated from 2022 as with newly created in 2023. Anyway, this 2023 release is huge, overwhelmingly rich on new feature and enhancements... so many great improvements. So much work to play with them all! 😄 Well done Vectorworks team!

Using Vw2023 SP1, I modified one of the built-in Elevation Bench Mark styles to my liking (using guidance from @sbarrett in THIS other thread). I added them to my file (started in Vw2022, migrated to Vw2023) and everything looked fine. Now I've returned to that same file several days later, added some more EBMs (using that same EBM Style) to other SL section viewports, and now the EBM Horizontal Leader line is transparent. This has also affected the EBMs that I had placed previously, now they have all lost their Horizontal Leader lines. Sometimes changing the EBM to use an offset leader would trigger the correct Solid color linetype, other times not... SO -- I found that by each time I edit the EBM Style, the Leader Pen Color is changing from Black to White (!?!) This change is also reflected in the placed EBMs in my SLVP annotations. See the attached recording: Note that I am not changing any settings in between the Leader Pen colors changing. ebm color changing.mov I have also attached a sample file with the EBM Style which demonstrates this behavior. What - the what - is going on? I'm really hoping to keep using Vw2023... but... 2023 ebm test.vwx

As a test I rendered a SLVP of a Renderworks Camera in both Redshift Exterior Fast and Renderworks, not changing any materials, only changing the Background Render style, and the windows in the Redshift version show much more refraction than in the Renderworks version. The roof beams are shown accurately in the Renderworks version, but in the Redshift version they have an unrealistic amount of refraction. The windows are standard Window PIOs. (Note: to make sure it wasn't due to some low quality setting on the Redshift Exterior Fast, I also ran a Redshift Exterior Final version and got the same inaccurate results, just muuch more slooowly).

After unsuccessfully trying to install Enscape in VW 2023, I found on Enscape's forum that the two don't work together yet. Is this true? https://forum.enscape3d.com/index.php?thread/21777-vectorworks-2023/&postID=77782#post78128 How can this be? Who changed the coding to let this happen? They worked so well together. Is there something going on here? These are the things that drive users crazy @Wes Gardner@Matt Panzer @KPrice. Does anybody have any answers. The Enscape forum said wait for SP1. What? SP0 just came out. Sorry, I'm so frustrated: I have a new thing and I want to use it.