Jump to content

capital_Designs

Member
  • Posts

    10
  • Joined

  • Last visited

Reputation

4 Neutral

Personal Information

  • Location
    United States

Recent Profile Visitors

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

  1. @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!
  2. 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.
  3. 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!
  4. 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!
  5. 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!
  6. 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,
  7. 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!
  8. 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!
  9. Huh. This is not the behavior for me. When I loaded a 2019 file yesterday, the lighting dev. params defaulted to an old settings "saved set" from 2016, not just "customized". When I loaded a 2019 file just now, it defaulted to my 2020 saved settings. Any ideas why I'm not seeing the expected behavior? Maybe this is related to not using the "default" save as the typical save? Thanks Jesse for your insight!
  10. This also threw my numbering off for a while. I was able to get it to work *without* updating all of my customized symbols to the generic Spotlight "default library" versions. (By customized I mean dedicated line weight, class structure, and colorized labels for symbols - stuff that would be annoying to re-do) My process was to go to Spotlight - Spotlight Preferences - Parameters (this is where you drag and drop to customize the OIP's display order... or what shows and what is hidden when a Lighting Device is selected. Sure enough, the "User U Address" and "User Address" were being displayed even though according to Jesse, they "were removed". I guess this means that they just aren't recognized by vwx anymore, but that they weren't deleted? I unchecked those from "Show in Shape pane", and dragged them to the bottom of the list. I made sure "Universe", "DMX Address", and "Universe/Address" were grouped together up high for visibility's sake. (If you make changes here, don't forget to Save whatever customized ordering you have. It makes life much easier. Also, that "Save as default" checkbox in the bottom left is your friend). Once all that is set, you can confirm your new display order in the OIP when you select any lighting device. That was when Spotlight Numbering of Addresses started working for me with the below process (specifics included in case this helps anyone): I typically start with no fixtures selected (so that it will default to "manual" selection)... open up Spotlight Numbering. Select a check in "Use" for Universe. Typically when I do this, it's by position, so I click "Apply the same numbering to all units". Then I just put in the Universe # into "Start". Also select a check in "Use" for DMX Address. Typically I'll do "Automatically increment the numbering" & then "Increment by DMX Footprint and offset:" because I like to make it easy for the Head LX. So, if I know the DMX Footprint is 47, but I want it to be a clean "jump" of 50, I put 3 in as my offset. *As long as I have properly setup the DMX Footprint* Then I click ok and number away. Outcome is as expected. 5 units are incrementing in the order I clicked them: 2/1, 2/51, 2/101, 2/151, 2/201. All (3) fields relating to u/address are updated in the background. (4) if you include "Absolute Address". Hopefully that helps someone!
×
×
  • Create New...