Jump to content


  • Posts

  • Joined

  • Last visited


7 Neutral

Personal Information

  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Scott C. Parker Hi Scott! Thanks for following up on this. I actually had this issue resolved in Service Pack 3. I actually kind of assumed this was isolated and fixed, and was thrilled when I updated to see it functioning as expected. I didn't follow up since I figured it was fixed for others as well! Just clarifying, in my above posts, it was all Service Pack 2.1. I'm now on SP3 (Build 636848) I cannot replicate the height issue any further. I'll still answer the questions below in case it proves useful... Almost always Top/Plan 2D. 2: On the floor (+0"). Then I move it to height after it becomes a hanging position. And the positions in question that were misbehaving were all made into symbols. The remaining strange issue I have with placing lighting device objects is that the "active" (selected) Label Legend still isn't automatically being applied when I place a fixture. There is another post dedicated to this issue, and it was not resolved for me with SP3. Any insight on that would be great! [Here's the post:]
  2. Ah, gotcha. Thanks! Yes. MacBook Pro M1 Pro, Apple Silicon. Glad it's not just me!
  3. Is anyone else having this problem? I did a quick Forum search and turned up empty-handed. Starting from a new template file, which has several pre-made Label Legends in it, if I click to make sure one is set to "active" in the Label Legend Manager, when I go to place any light, the "active" legend isn't applied. The OIP "Use Legend:" dropdown shows that it's using a legend called "None". The options at the OIP dropdown are "<none>", "None", and the 3 standard legends in my startup file. I don't remember there being two options for none before... so that's making me suspicious. This is also happening for me when I open previously saved plots, in addition to the File...New (from template) test. It doesn't seem to matter which legend is "active" in the Label Legend Manager. Once I select any unit and in the OIP change the Use Legend dropdown to the desired legend, all is well. "Assign Legend to Lighting Devices" also works, so those are behaving as expected. Thanks in advance,
  4. I'm on 2022, and that feature is still available for me, so it must be some other issue. It works the same as it always has, choose a label legend for a fixture in the OIP. Select the fixture on a design layer. Hover over one of the field grab points, wait for the diagonal arrow pointer change, click to grab it, move to where you want it, click again to drop it there. I had no problems on both an older startup file passed through the years, and a blank 2022 start.
  5. @jcogdell Those resources have been forward ported through several versions of VW, and so far have maintained their functionality (through 2019, 2020, 2021). So this particular file was most recently a 2021 VWX file (where it was working as expected). Once I opened it in 2022 the issue appears. I was working from 2D Top/Plan, inserting using the Lighting Device Tool. Totally understand - let me know if you need any other info!
  6. @Rob Books Hey Rob, just following up on this. Is there any particular reason that the Series 1 Lustr and Series 2 Lustr seem to follow a similar shape that wasn't continued for the Series 3's? Both the Series 3 (standard lenses) and Series 3 XDLT seem to have reverted to the "standard" S4 outline shape, not the boxy, LED shape that has gotten so familiar. Thanks for any insight...
  7. @jcogdell Unfortunately, I am working from a file that I know had positions made with the "Create Symbol" option selected (since I can see those created symbols in the Resource Manager), and the behavior matches the above cases. A Lighting Device is associated to the hanging position by being dragged close enough to it, the "Position" info auto-fills, but no Z change for the device. I've confirmed the Hanging position has a Z height. VW 2022 SP2.1 Build 627588 / Macbook M1 Pro Apple Silicon Any suggestions?
  8. @markdd will correct me if I'm wrong... but to help you on your journey, @Kengene : Just remember to draw everything "laid down" (as if it's tipped over on the deck) first! This will ultimately allow the Schematic Views to work properly. I have found myself trapped a few times if I don't really stick to this method. Draw "flat", then tip!
  9. I just discovered that they were provided when @AWaters asked about them, and I completely agree. I think that reclassification would be great. Just to prevent confusion. Exactly my thoughts. It's that "one other axis" that I was thinking about as well: the Tee sliding along the arm. And the issue of where the Loci actually wants to be. Also, thanks for your workaround suggestions. Like you suggested, I have been doing reports using my own symbols which has always worked well and gotten the core of the data I've needed (how many sidearms / where are the sidearms). @AWaters solution of relating the lighting device to the rigging position and jumping over the sidearm is what I'd personally do now if I needed 3D representation of sidearms. It sounds like making the sidearms rigging objects or hanging positions would be the next step. It's certainly the only option now to have 2 versions of the fixture symbol (with and without a c-clamp) for efficiency as well as accuracy. A long term solution could be the option to choose "clamp/hardware" from a OIP dropdown and have a selection of C-clamp/Mega-Clamp,Tee, etc. I'm sure that's been requested before so I'm drifting off topic. Appreciate your responses and the discussion.
  10. Having replicated this issue myself just now, @TomWhiteLight I wonder if you or someone could share what the proper method is for using this symbol as a static accessory. I assume I'm using it improperly or have an incorrect setting engaged somewhere. Or maybe the Safer Sidearm just isn't designed to be used as a Lighting Accessory but instead only as a hybrid symbol with the Symbol Insertion Tool. In my workflow I have previously always used my own hybrid symbols to represent the different kinds of Sidearms, and haven't actually inserted them as lighting accessories to date. Clearly this symbol is supposed to be inserted as a lighting accessory, but isn't functioning properly in my tests, so I'm curious as to what I am stuck on. Like @AWaters said, when I try and associate this static accessory [Light Acc City Theatrical Safer Sidearm] with a lighting device, it seems to place it somewhere in the middle of the Z height of the 3D portion of the lighting device, or below the 3D geometry of the lighting device, like in the screenshot below. This differs greatly from how I had placed it in Top/Plan (see below). I'm left wondering why the 3D orientation (rotation and +Z height) were completely changed when it became associated with the lighting device, and how we are supposed to use it when hanging a light from a vertical position. Here is how I inserted it: Again, the thought being that by inserting a Hybrid symbol from the default libraries, I am interested in using the 3D portion of the symbol to communicate how it is hung in real life - off of a vertical position or "boom". The sidearm's 1/2" (or so) Pipe would be at the height of the fixture yoke where the C-Clamp is drawn attached in 3D, and the rotation would be taken from what I drew in Top/Plan. Instead what seems to be happening is that the symbol is following the behavior of any scroller lighting device accessory. It seems to have a +Z height of +0" starting at the "front" of the fixture, aka the gel frame slot. Mind you, this is the expected behavior for a scroller accessory, since they are mounted to the front of a fixture. However, it doesn't carry over to this type of accessory. Adding any +Z to the sidearm, +18" for example, causes the accessory to be moved "down", further away from the front of the fixture. So, further away from the yoke's mounting point. I cannot put in a negative value into the Z field for an associated lighting device accessory, which I'm assuming is purposeful and has to do with the relationship to the "parent" lighting device. Like I said, my personal workflow has been using homemade symbols for various "Iron" in the past (sidearm, c-clamps, cheeseboroughs, etc). Curious to see how the provided Safer Sidearm symbol is designed to work as an accessory so that I may incorporate that in the future. I'd rather not be stuck in the 2008 way of doing things if there is a more efficient way! Thanks in advance!
  11. I haven't come across any in the provided libraries for 2019 or 2020 (Vwx and Service Select libraries). Also, I can confirm they are not there now, so they're not just hiding from you.... this time.... Hopefully others will also confirm. Best of luck!
  12. Hey All, Here's a link to a Google Form I quickly setup to gather this information from fellow users. https://forms.gle/3sVHytYDvoaxwau77 Feel free to share with various circles you are in. The more data we have, the more useful it will be for @Chris Baccala and the team! To start out, do not be afraid that your issue has already been reported by another member. I say, assume you are the first to report it. It will be easy for me to sort through the raw data later, remove duplicates, and report back to Chris & Team with the results. Depending on how many reports of symbol discrepancies I receive, I'll attach the "live" results to another spreadsheet that can be viewed & searched before submitting. That would prevent a dedicated person from wasting an hour or more adding every Symbol discrepancy they are aware of all at once, when it already has been reported. I imagine that eventually, a quick search through that spreadsheet could save some time. Any feedback on the form itself - reply below or message me and I can make changes for clarity. Thanks in advance for any input!
  13. This makes sense, for sure. Thanks for this insight, Kevin! It makes sense that they had to be preserved. Do you or @jcogdell have an explanation for why I was seeing an old customized save set of mine when opening a 2019 file? When a 2019 file is opened in 2020 for me, the Lighting Device Parameters Dialogue isn't displaying as "customized and not default", which Jesse has described above as the expected behavior. It either displays as an old saved set (2016) or as my new saved set (2020). I'm opening these old files for the first time in Vwx 2020 and seeing this behavior. I also simply could have misunderstood what Jesse said. Thanks in advance,
  14. Hey Chris @Chris Baccala, no problem! The way I see it, the better these default libraries are, the easier it will be to manage them for years to come. Thanks to you and everyone in Content Development for everything you do for us! I have started a detailed list of issues in a Google Sheet and will soon setup a Google Form for people to fill in and add to the sheet. Here is a link to (a view only version of) the sheet: https://docs.google.com/spreadsheets/d/1t5sY7zBRl4epnXOSteMh_NdAiftlffQFHY8ZIG8j-n4/edit?usp=sharing As a general starting place, I'd say start with the ETC Source 4 Library, which could use a fine-tooth comb ran through it. I just confirmed several issues that still exist, and they are listed on the spreadsheet above. I would describe all of them as simple fixes: typos, line weights, etc. When I set up the Google Form, others will be able to add specific errors & discrepancies they've found, and I can summarize that info and get back to you with Library names. However, you might be able to get a head start on some of this since I have typically found there are more errors in a manufacturers symbol library when they haven't been updated in a few years. So, "date last updated" should be a good reference point. I fully agree, @markdd! I imagine there is a rulebook of standards that they are using, otherwise how could they output new symbols so quickly! So, it would be great to get as much as possible within that vectorworks standard. Maybe @Chris Baccala or someone else could inform us why the capital "W" in Wattage attached to a record of a symbol doesn't translate directly into an Instrument Summary? It is curious to me as well. Again, all fixable if you don't use the Instrument Summary tool "as-is". Exactly my point. That way: new users, students, people migrating from other workflows (autoCAD, etc) don't immediately have to go to the wonderful symbols made by Mr. Shelley, who has always maintained pristine standards, as you've said. Of course, it is still a good option. @Kevin Allen Indeed, another good point. In the default libraries, if you edit the symbols, there are various ways you might find the 2D objects organized. Some have line weight by class, some are just manually set. Some objects / lines / polylines are set to the "correct" class, others are not. I know you said specifically you were describing Lighting Devices, but I think it's clear at the symbol level there are differences if a fixture hasn't been recently "touched-up" or modernized. Thanks all for the responses!
  15. I'm still wondering if it is only my files / version / default library showing this, however: There seem to still be random differences in some "standard" lighting instrument symbols that ship with Vectorworks. I say still because seemingly, differences have always existed. Specifically in the Vectorworks Library: Objects - Ent Lighting Instruments. Looking at an ETC S4, for example. Most people will agree that's as standard a unit as you can get. When inserted from the Vectorworks Library / Objects - Ent Lighting Instruments / ETC Source 4.vwx / Source 4 location: several instruments appear to have either a different line weight, or minor differences in the data attached through the Light Info Record. [See image below - 14deg & 90deg are very obviously a different line weight]. Like I said, it seems these symbols have always existed with minor defects in the library, especially in the early days of lighting-specific Hybrid Symbols being provided and updated by VWX. So, many of us chose to go the route of duplicating the VWX provided symbol, and editing a custom version of each instrument type we may use. I still do this today. Whether our goal was to specifically color-code fixtures, or provide unique information in the Record, we also needed to make these basic fixes (like ensuring identical line weight) to the 2D portion of the symbol, as well as correct any discrepancy in the Light Info Record (like basic naming schemes). Example: I seem to remember that some of the S4 symbols around 2010 had their Model Name as "Source4 36deg" and others had "S4 26deg" or another variation. Could these both be recognized without confusion when reading an instrument key? Sure, to someone that is not new to the industry. Does that mean we should be teaching students that consistency with naming doesn't matter? I'd ask the same of any specialty: Architecture, Landscaping, etc. I think the obvious answer is a resounding "no". Of course, back then it was all new and we were happy to accept the symbols provided and do these little corrections ourselves. At least, I was. I found it was also a way for me to dig deeper into understanding the program. But, that was years ago. I understand that there is a small army at VWX working on constantly updating or creating new symbols for us to use, either in the default library, or in service select libraries. (That is awesome!) I also understand that sometimes it takes broad brush strokes to get the sheer amount of different instrument types and variations into the program as they are requested. However, since these problems existed since at least Vectorworks 2010, I'm wondering if/why there hasn't been a finer-tooth comb ran through some of these older symbols. Especially when they are "industry standard" instruments like the S4. In addition to the difference in graphic standards between these fixtures (their caps are different, too), there is an odd discrepancy in the "Wattage" field as well. The same (2) fixtures that are a different line weight also contain a random space in between the number 575 and "W". That difference, and the Weight of those same (2) fixtures not being rounded, leads me to believe that these must be older symbols that for whatever reason, weren't updated when all of the others were. And what an interesting choice to leave them with those differences. I take it that this was not on purpose, but rather was just overlooked. Yes, some of these details are rather small (like the space between Wattage), and they may disappear when quickly looking through paperwork... so feel free to poke fun at my nit-picking. However, I would argue that this isn't just an inconvenience or something that might "look odd" when printing a Plot or a Report. I've found that while teaching drafting standards to beginners, where everything should look uniform, and should present the data as cleanly as possible for ease of communication, it is odd to find some symbols provided by Vectorworks that are a different line weight for no apparent reason. I've just had quite enough students / young assistants ask me over the years: "Why isn't this symbol like the other symbol already? Isn't it in the same library?" while going through and updating / customizing the version provided from Vwx. So, I'm finally asking! What IS the reason for this, if any? Is there a location where we can post various discrepancies users may find in lighting symbols to make it easier for the symbol team to manage? P.S. I should say this has happened not only on my personal machine but on several other machines with brand new installs. So, it doesn't seem to be an isolated case of a bugged out library resource that isn't being updated over multiple years. P.P.S. Before anyone even says it: Yes, I know it is possible to make my own copy of these symbols and therefore fix the line weight and record data to my liking. Hopefully it's clear in the post above, that I am specifically talking about the defaults that are provided by Vwx with discrepancies. Not about how to "take matters into my own hands". Looking forward to what this great community has to say! Thanks in advance!
  • Create New...