@joshb said: I'm obviously new to ruby and appreciate all the pointers. Pay attention to the "Sticky" threads at the top of the forum. (They have the "S" in them.) This will get you going: Ruby Newbie's Guide to Getting Started

Great! Thank you.

@unknownuser said: I'm curious - Did this technique for designating zones ever get implemented in the OpenStudio plugin? I never got a chance to implement this, but I'm working on something similar for the next release, but was just a bit easier to code. It will take a loose selection of geometry (a clean building plan diagram) and will convert each surface into a Space object, and will extrude them to the requested height.) Another big change for the next release is that geometry is drawn in a space vs. a thermal zone. You then assign spaces to thermal zones. This allows you to design in more of an architectural view and then combine rooms into zones. Each space can also have space type assigned. Load and even constructions can then be assigned to a space type. It is a big change so I will add a lot of new video tutorials after the release.

@dan rathbun said: @jan_pamplona said: if we make a simple rectangle or a plane, i think the default is that the "face" facing you turns into a front color automatically, right!? NO... it does not have anything to do with "facing YOU". When you draw a face, it's normal (The direction the front surface is facing,) is always toward the negative axis. But the PushPull tool will reverse the face if it needs to do so. Thank you very much sir,, yeah, i remember now, im so dumb :,) it's just that i forgot those things because im drawing 2D plans and not noticing about the Push/Pull,thanks

@tig said: Unfortunately dimensions have scant access in the Ruby API... Thanks TIG, I was afraid this would be the answer.

Just noticed ANOTHER standard Ruby extension that bears on this subject. With a path to the local standard Ruby lib dir pushed into the $LOAD_PATH array, you add the following to your module: require('tmpdir.rb') This standard extension adds the class methods: Dir::tmpdir and Dir::mktmpdir If you read the file, you'll recognize the Dir::tmpdir method as the 'progenitor' of the edition in the Google 'webtextures_loader.rb' file. (Google "lifted" it, and stripped out the Win32 specific part.) So (above) when we talked about whether to rely on the WebTextures plugin, my advice is, to instead rely on the Standard Ruby library.

Thanks. I'll try that soon when I get the chance.

I thought I was doing something wrong. Then, I don't worry about this discrepancy. Thanks Tig

Thanks Tavi.. dang it.. dat's a bummer... oh well then it's SQLite3

@dan rathbun said: ... your talking about one of the standard Ruby libraries. I answered a similar question here: http://forums.sketchucation.com/viewtopic.php?f=180&t=39648#p350463 Many thanks, worked great.

You have read the FAQ page I made? [Info] C/C++ Ruby extensions & SketchUp plugins

Okay, now I know!! And yeah at first my question made sense to me, but now it doesn't! Thanks

If you are using Layout you are better off doing your text in Layout. This is a pretty old tool! Try my 2dTools 2dText - it's much more flexible than this old thing... BUT the size is fixed height - you can make it sat 100mm and then make three copies scaled at x2 and x3 use layers called TEXT-100, TEXT-200 and TEXT-300 etc. Put copies on different layers and have only one layer on in a scene-view. Then you can switch the layers as needed so text size seems to varying. 2dText is a 'component' so making layered copies means you can edit one and they'll all change across the layers and the scaling will be kept too...

@tomot said: Interesting! I have 2 scripts, on replicates joists the other studs both use count. One script constantly gives me an '<' error in the console the other does not. ....very aggravating! Yep.. and same with: entities.add_instance(count, t) The word 'entities' is a method name. It often works OK, but is poor form. Using something like: grp_ents.add_instance(joist, tx_vec) is much better, and more understandable.

@jolran said: However there is no "glue_to" method for groups in the API. Right.. and you should not use a Group, for the job of a ComponentInstance. Groups are best used for temporary editing both manual and in scripting. By collecting objects together into a Group, you can: move them from one edit context to another, protect them from being modified by crossing edges, apply a tranform to a set of objects all at once (where they move, scale or rotate all together.) I would say, that when you get a "set" of objects the way you want, and then wish to use that set multiple places in the model, it's best to then convert them into a ComponentInstance. Especially if your going use scripting, to manipulate them, or glue them to faces.

@voljanko said: I can not set my browser (chrome) to show the comments. You are seeing the localized language version of the API page. Somehow you must try to set Chrome to English, so you can see the main English pages that have the comments. This is a known issue with the API Doc pages, and complaints have been logged with Google.

@tig said: Please don't use global $ variables unless you really have to Rats! I can't count how many times I have been reminded of that issue. My typical response: I use global's so I can verify the 3d point location in the Ruby console, I need this to verify any mistakes I may be making (which happens frequently !) when I'm developing a script which corresponds to 3d points on my gridded 1/4" notepad. It would be really nice if @ variables where able to display the same information in the Ruby console.

Yeah, that worked, and not having to explode my group fixed a lot of problems. Thank you!

My code was a quick example to show that you could get the correct angles. Of course edges=face.edges can easily be replaced with edges=face.outer_loop.edges or we iterate through the loops to get their edges in turn... BUT if its for only one vertex it's then easy enough to find the two edges belonging to that vertex [and that face] and run similar code on them to get the angle between them, using the face normal and vectors cross comparison to trap for concave corner angles >180 degrees... remembering to trap for ==180.degrees, as well as < and >...

Now I seemed to have corrected it. I had to ensure the vectors I used came in the same direction as the edge loop.