Jump to content

SamIWas

Member
  • Posts

    287
  • Joined

  • Last visited

Everything posted by SamIWas

  1. The container solution is exactly how I do DMX addresses, because it's the only real way to deal with it. An alternative, but error-prone way of dealing with it, is to use a user field for your display info. I really want VW, or at least spotlight, to have an "auto calculation" parameter type where it could auto-create certain field styles based on a combination of other field info. I use this extensively in Filemaker. For instance, when I have a Universe and Address field, I have a separate field which auto calculates to the universe, a dot, and then the address in three-digit mode (Universe 6, address 37 calculates as 6.037), for paperwork. This would be invaluable for things like circuit name and number, so that circuit 2A 5 doesn't become 5 2A when you rotate your symbol.
  2. Not still the case. I have a class with 36 characters, including spaces and dashes.
  3. I programmed Vectorscript for ten years before I finally delved into creating custom plugins. I don't know why it took me so long. If you can write Vectorscript, it's pretty simple to create a custom plugin. I've now created numerous tools for cabling, networking, racks, and others. I did it for the same reason you are looking for: to have the info on the shape panel instead of the data panel. And because with a plugin, you can do drop-down menus, checkboxes, enter actual dimensions, hide parameters based on others, etc. So much more versatile than data.
  4. I have been a Vectorworks and Filemaker user since around 2004. I write complex scripts in Vectorscript and entire multi-table, relational, script-driven databases in Filemaker. I still, after more than a decade of trying, cannot get VW and FM to talk to each other over ODBC. Every few months, I get the desire to try again, and every single time, it's an abject failure. Something that should be fairly simple (especially for someone with a fairly deep understanding of scripting) and would change the way I develop my workflow, but I just can not get it to work. If someone has managed to get VW and FM to talk over ODBC on a mac, I would love to hear from you!! Obviously, it can work because LightWrite and Vectorworks do it.
  5. For me, Cinema4D's UI is the best UI out there. Infinitely customizable and easy on the eyes. You can arrange your windows however you want, group them, tab them, adjust the font and color or every item. Just great. And FAST.
  6. Yes. All I need is what OpenGL does with "show edges", but actually showing all of the edges (or better yet, based on angle) and no shading. That alone would fix everything I've been looking for.
  7. You better watch it! I asked for this on a Mac users forum and was strongly criticized for even suggesting such a thing. Essentially, if Apple doesn't have it, then Apple should never have it because it's not a product which should exist. But, what I found is that MacOS doesn't even support touchscreens. As in, you cannot go buy a touchscreen and plug it into your iMac or MacBook and use it. Amazing. EDIT: I should add that I mean standard, off-the-shelf touchscreens.
  8. If you're in a sheet layer, then you need to select the render option in the Object Info Palette. As for the original topic, I've never understood why hidden line takes so freakin' long. Read above about it doing full calculations, but find it crazy that there hasn't been a simple line render before.
  9. I've been trying for more than a decade to get Vectorworks and Filemaker to talk using ODBC. Not with Vectorscript, but just through their built-in options. I was successful like one time many years ago for a brief trial on one file. It amazes me how difficult it is to get that working. As for the OP, exporting all of your info should be a pretty simple script. I have a large number of scripts which import information out in tab-separated files for import into Filemaker. They all use the calls Sam Jones specified above: Open(filename) PutFile; Write; WriteLn; Tab(1); A quick example of just the write lines: Write(GetRField(h,'LED Ribbon','ID'));Tab(1); IF GetRField(h,'LED Ribbon','Location')='' THEN WRITE ('-') ELSE Write(GetRField(h,'LED Ribbon','Location'));Tab(1); IF GetRField(h,'LED Ribbon','Position')='' THEN WRITE ('-') ELSE Write(GetRField(h,'LED Ribbon','Position'));Tab(1); These are all using the same record format, but you could use any number and mixture of them.
  10. Sure. Then that goes back to designing my VW plot layer or class structure around the grandMA patch: Having to build classes solely for patch. Then I have to make sure all those classes are turned on or off in whatever viewports and saved views. That is a LOT more work then just being able to specify a patch layer in a user field.
  11. Thanks Raymond. SetFPat did work to put white behind he text. It just means adding those lines for every piece of text in the PIO, which is a little annoying. But, the important thing is that it works!
  12. Not sure I follow. The plugin gives you four options for exporting layers from Vectorworks to MA: Design Layers, Classes, Fixture Type, or Position. Now, I don't know how you draft your plots, or how you do your layers on MA. But I know that my plots have layers for scenic, rigging, fixtures, cable, racks, etc. And I have classes for lots of things, but I do not class fixtures based on layer. In no way would I design my Design Layer and Class structure around exporting to MA, so those two are out. Fixture Type and Position remain. On MA, I have layers separated by "genre"...so "Conventional", "Movers", "LED", "Worklights", "FixtureMart". Since those don't jive with anything I would do in Vectorworks, those are out. I'm not sure how having a user field for layer is entering data twice. Where am I entering the layer info in the patch and a user field?
  13. Did you go into the data tab of the Object Info Palette? If you don't see the fields there, then you definitely have an issue. If you want the data fields on the shape tab, then you have to create a custom plug in object, which is a whole different animal.
  14. I have a PIO that I've created which has some text elements and those text elements must have a background fill to be readable. My VW preferences are always set to create text without background fill, and unfortunately, this appears to affect PIOs regardless of PIO code. This is a snippet of the code: FillPat(1); FillFore(65535,65535,65535); FillBack(65535,65535,65535); PenPat(2); PenFore(objcolor); PenBack(objcolor); TextJust(2); TextVerticalAlign(3); TextFont(GetFontID('Avenir Next Bold')); TextSize(18); TextOrigin(0,0); CreateText(concat(distbase,CHR(39))); No matter what I set FillPat two, it doesn't seem to make the text have a fill color. I'm not finding something to set the fill color attribute to "solid" without using FillPat. Am I missing something?
  15. This could be done as a plugin object, which would give you more control, or as a simple symbol with a record attached, which would be easy and could be made in minutes with no scripting involved. For the simple symbol, do the following steps (not detailed with every step): Draw your symbol as it will be needed, with the text formatted in place Select all objects involved, and create the symbol, being careful to select the right insertion point Create a record format with the fields you need to change in the symbol such as height and depth (in this case, it will only change the visible text labels). Add fields to the record format of the number type, and format them as a dimension. Edit the symbol Make sure nothing is selected in the edit symbol window and attach your new record format in the OIP. Select each text field then use the "Link Text To Record" command to assign a record field to a text object. The attached file has an example. Data Symbol.vwx
  16. This is absolutely possible and something I do daily. If you're trying to copy and paste a large number of items I've had it fail on more than one occasion.
  17. I feel your pain. If you were scripting it, you wouldn't have to even go as far as adding the locus and whatnot. The script would simply get a handle to the object, get the coordinates of the object (which would be the insertion point), then use HRotate(90) to rotate the object 90˚ counter-clockwise about that point. PROCEDURE RotateObject; h : HANDLE; sx,sy : REAL; BEGIN; h:= FSActLayer; GetSymLoc(h,sx,sy); HRotate(h,sx,sy,90); END; Run(RotateObject); At one point, when keyboard commands actually worked reliably, i had mapped a version of this script with 5˚ increments to my scroll wheel, so I could select a fixture and rotate it using the scroll wheel.
  18. Thanks guys. I think I got it worked out. I delved into what I assumed was the offending symbol, and did some work on it. Turns out that the guy who built it modeled everything down to each pin on each fluorescent tube in the fixture. And those pins were mesh rounded cylinders. Two pins each end of each tube, times 8 tubes per fixture, times 120 fixtures = 3840 high-poly little pins that aren't even visible, but still being processed. Also found some geometry which was rounded but could get away with a low-angle chamfer instead. Once i did that, I went from several minute per setup to maybe 8-10 seconds each time. I'm working in someone else's template on this production, so I'm working with what I'm given.
  19. I fixed it automatically going into OpenGL, which has helped somewhat. I guess that was my main issue. Still...it shouldn't take over and not let you stop it. But even when starting a render on a viewport on a sheet layer...sweet jesus...can't do anything else. Which is odd, as I thought that worked in the background. I'm definitely going to go through this symbol library I was given and clean it up. There's no reason it should take almost 10 minutes to process the geometry for about 100 Image 80s. The MacBook is the highest-level one made, so it does have a real graphics card.
  20. I'm working on a file using symbols from someone else. It's his template for him, so I'm not looking to change all his symbols....yet. But seriously....every time I click into a 3D view, a process bar at the bottom-right corner of the green pops up labeled "geometry". It takes literally 5-10 minutes on a high-spec MacBook Pro each and every time. And there does not appear to be a way to stop it. Once it starts, Vectorworks is useless for that period of time. Is there some way to kill this process? I'm sure i can search the forum of a while, but I'm trying to complete these plans.
  21. Currently, yes. That is how the plugin works. That's one feature I do not like, and one reason I don't use it. The VW drawing should not have to be designed specifically around export. The layers should be able to be derived from a user field.
  22. Yeah, multi patched fixtures on the same layer shouldn't create an error.
  23. I really wish the official version would allow patch layers by a user field or something. I really don't like having to design my VW document's classes or layers around the patch.
  24. Thanks guys, Apparently, it was a current-launch bug. Today, the problem is no longer happening. What's also weird is that all of my other PIOs use the same text-scaling procedure, but it didn't work in this one. So I corrected it without the scaling. Today, when I opened up the work file, the text was massive. I changed it to match my other PIOs and now it works correctly. So, it looks like all of that was related to the same thing. It's all working now. Alas...I didn't think to turn it off and back on again.
  25. I have a tool I created for placing exhibit graphics. It's just a simple box and two pieces of text, controlled in the OIP. All of them react to a "Top" or "Bottom" setting in the OIP as well. When I select "Bottom", everything lines up as expected. When I select "Top", the text flies off into space, even though the correct dimension is being calculated. Here is a sample of the script: --------------------------------------------------------------------- {---------------CREATE RECTANGLE-------------} rectwidth := PWIDTH; rectheight := PDEPTH; IF PDIRECTION='Bottom' THEN BEGIN TextOrigin(0,(-.5-RectHeight)); TextVerticalAlign(1); END; IF PDIRECTION='Top' THEN BEGIN TextOrigin(0,(.5+RectHeight)); TextVerticalAlign(5); END; TextJust(2); BeginText; concat(PNAME) EndText; IF PDIRECTION='Bottom' THEN BEGIN TextOrigin(0,(-5-RectHeight)); TextVerticalAlign(1); END; IF PDIRECTION='Top' THEN BEGIN TextOrigin(0,(5+RectHeight)); TextVerticalAlign(5); END; TextJust(2); BeginText; dimtext EndText; --------------------------------------------------------------------- If RectHight is set to 1.5", as is default, and I select "Bottom", the PNAME text is at -2" and the dimtext text is at -6.5", as expected by the calculations. If I select "Top", PNAME should be at 2", but the text ends up at 21' 6.56". dim text should be at 6.5", but it ends up at 14' 9.54". Am I missing something, or have I encountered a bug? I don't recall having this issue previously on other scripts. Could it have anything to do with the source number being a dimension instead of a number? Oddly enough, if I put the calculation for one of the top locations in one of the text fields, it shows the correct number, while putting the text off in some weird location. If I need to include the entire script, I will. EDIT: I forgot to mention...if I change the TextVerticalAlign to 1 from 5, the text jumps to the correct coordinates, but is below instead of above that coordinate.
×
×
  • Create New...