@kanastrous said:

In SU8Pro - if I change a setting (shadows, or hidden geometry) in one scene, the changed setting ripples through -all- of the scenes, whether desired or not.

For example, if I want to hide one item in Scene 2 of 5, as soon as Scene 2 (and -only- Scene 2) is saved, the item is now hidden in -every- scene. Ditto style and shadow settings: it becomes impossible to have changes in style, shadow, hidden geometry etc from one scene to the next.

I figure that somewhere there is something like a save-current-changes-to-current-scene versus save-current-changes-to-all-scenes but I can't locate that on any of the menus and (surprise of surprises) the 'Help' index is of zero use, in tracking anything down.

Can anyone tell me what I am missing?

Thanks in advance

karl

Open the scenes window. At the bottom are check boxes for what gets saved with a scene. They can vary scene-to-scene.

@sonjachr said:

thanks for the quick answer. Unfortunately the c=round(pre) is not working for Sketchup2013 (wrong number of arguments (1 for 0)), it is only working for Sketchup2014.

It is my understanding, that I have to include the class in my root Namespace to get my Extension included in the Sketchucation warehouse. It is the only class I am having problems with.

I really need help on this.

Thanks

Oh yeah, I forgot that the argument to Float#round was added as of 1.9, so that won't work prior to SU 2014. Seems that you have two possible ways to go to remain portable to 1.8 and obey the "no monkey-patching" rule:

1. Define your own class and use that instead of the builtin Float. This can be a pain, since it is easy to forget and write a=1.23 instead of a=TEST::MyFloat.new(1.23).

2. Do the less object-oriented way and define a function in your module that does what you wrote, but takes both the Float and pre as arguments. Then use c=TEST::precision(a, pre). Sort of like this:

module TEST
   def self.precision(f, pre)
     # probably should validate arg types and values here...
     return f.round if pre==0
     ((f * 10**pre).round.to_f )/ 10**pre
   end
end

@sonjachr said:

Need help on this problem, please:

[pre:19bvdgse]module TEST
class Numeric
def precision(pre)
return self.truncate if pre == 0
mult = 10.0 ** pre
(self * mult).round.to_f / mult

end
end
a=123.4567
c= a.precision(2)
end #module[/pre:19bvdgse]
getting the following error: "undefined method `precision' for 123.4567:Float"

your help is very much appreciated

Thanks

Your code creates a new class TEST::Numeric that is independent of the buitin class Numeric because it is within the TEST module namespace. Float inherits from the builtin, not from your class.

That answered, it is generally considered very bad practice to modify builtin classes. You have no way to be sure that your patch won't collide with someone else's or break their code. Why not just use c=a.round(pre) ?

@pbacot said:

Can't on a Mac.

Ditto. The values I type are ignored, they don't appear in the VCB and don't affect the point's location.

@aroundthebend said:

Here is one other screen shot with Finder viewed in Icon mode. The 4th file looks great in this mode. Thanks again slbaumgartner for his Ruby script and QL file for the Mac OS .

P.S. I've just spotted my typo in the file names

You are welcome! I notice that the checkbox to save a custom icon disappeared some time after SU version 8. But my stuff still works through SU 2014.

Steve

Nice! My guess would be that it was laminated over a form rather than bent from pre-made plywood. I don't know whether they used vacuum bagging yet when the original was made, but it wouldn't be terribly hard using that technique. That would also make it possible to include a tapered center layer.

Steve

I can reproduce this but can't explain it. Seems like a bug to me!

TT's snippet earlier in this post contains a couple of bugs: it will raise an exception if the
argument isn't a Face (or something that supports #edges), and it will find false surfaces
built where more than two Faces meet at a soft Edge. The below fixes these issues.

def get_surface( face )
  return [] unless face.is_a?(Sketchup;;Face)
  surface = {} # Use hash for speedy lookup
  stack = [ face ]
  until stack.empty?
    face = stack.shift
    edges = face.edges.select { |e| e.soft? && e.faces.length == 2}
    for edge in edges
      for face in edge.faces
        next if surface.key?( face )
        stack << face
        surface[ face ] = face
      end
    end
  end
  surface.keys
end

@goskone said:

\I am just baffled why in the hell is Library hidden????

~/Library has been hidden by default since Mac OS X 10.7. Evidently Apple decided that naive users could cause (or maybe were causing) support issues by making ill-advised changes to the contents. So they put in place a (very low) hurdle that "don't peek under the hood" users won't cross.

@dtrarch said:

Take a look at Faststone Capture
http://www.faststone.org/FSCaptureDetail.htm
Very slick and affordable.($19.00 US)
IMO the only one you will ever need.

dtr

Provided you are on Windows - I see no Mac version.

Steve

Dave,

Thanks for the suggestion. I took a quick look at the Snagit site and it left me with the same question I had about the native tools. Namely, if the tool requires you to use a mouse action to designate the target to capture (click a window or drag out a rectangle) how do you cause the Mac to retain the original application's cursor in the screen capture? Normally it changes the cursor as soon as you activate another app, including a screen-capture app. The online documentation made it seem like Snagit has this same issue? I confess I didn't download Snagit to try it, just took a quick look at the online docs.

Thanks
Steve

ComponentInstances don't own separate copies of the primitive geometry, all the geometry is owned by the ComponentDefinition. So, if you alter anything about a primitive (Edge, Face,...) in the ComponentDefinition it immediately affects all of the ComponentInstances. You can only set per-instance values for things that are not shared by all the instances, such as transformation, name,...

I know that the drawings shown are to illustrate how to color zones in SketchUp, not claimed to be realistic WiFi coverage maps. But in case anyone didn't realize: you will need to measure both signal and noise (or "quality") at a bunch of locations to create your map, which will have more complicated shapes than the circular zones depicted. Walls, cabinets, furniture, etc. block WiFi signals in complex ways, and noise sources such as cordless phones provide varying interference. Generating the "heat map" in the first place is harder than painting it in SketchUp!

As an alternative, you could save an image of the floorplan from SketchUp and use it as the base in the free version of NetSpot to create the WiFi map. That isn't a pure SU solution but it works...

Hi,

You will need to learn about writing a Ruby plugin for SketchUp; there is no way I can see to do this via the standard GUI. I don't know your programming background or skill level, so I don't know whether that would be a major challenge to you or something you feel you can do.

If you decide to proceed, the only parts that sound at all complicated are optimally placing the boxes into the container (unless you move them by hand) and continuously tracking the weight of the container (that would be easier if you wait until it is loaded and then invoke a Ruby function to calculate it, otherwise you are going to get into Observers, which aren't the simplest aspect of SU). The 'spreadsheet' Gem, which is compatible with SU 2014, makes it easy to read most file formats. Drawing the boxes is quite simple.

Steve

@driven said:

Hi Anton

libffi.6.dylib is included in the Sketchup Ruby framework.

is it possible to utilise that for your needs???

just thinking out loud...

john

fiddle is the Ruby 1.0.0 wrapper for libffi. I haven't tried using it, but require 'fiddle' returns true on SU 2014, so maybe John's idea is your easiest route?

After much hair-pulling and tweaking by hand, I got a GEM to compile under Mavericks and SU 2014. It was such an ad-hoc mess that I don't recommend trying it!

Unfortunately, the Ruby installed by SU is not configured correctly to enable compiling a GEM. Among the many issues I wrestled with: the build script for that particular GEM assumed there was a ruby interpreter available at the path set up by SU - which there is not, only the framework library; the mkmf system determinedly generated makefiles for the native architecture (64-bit) and the system-installed Ruby - which led to all sorts of clashes; some libraries and features that are normally part of the Ruby distribution were suppressed by Trimble after finding they caused bugsplats in SU.

This is a shame, because one of the supposed advantages of a GEM is that you don't have to be an expert code developer to build and install it. However, after what I went through I can sympathize with Trimble and TT: fixing it is way harder than it sounds!

@ahjkuipers said:

Finally: the solution

The face I used was part of another face. And in that case it seems that the control over the order in which the vertices of the smaller face appear is taken over by the other face. Your answers helped me to discover that phenomenon. Is this assumption correct?

There are situations in which add_face will reverse the Vertex ordering of a Face to keep it consistent with other Faces that it touches or intersects. That is probably what you are seeing.

My experience has been that the operation of add_face is so loaded with undocumented special cases (and some bugs) that there are only two safe ways to deal with it: either make no assumptions at all and search or test the Entities collection after it completes, or very carefully try all possible test cases to make sure that you know what it does for all of them. When user input is involved, it is very hard to be certain there are no remaining bugs...

I believe you are getting confused about the difference between a Component definition and instance. The dynamic_attributes dictionary is associated with an instance, not the definition. That's so that individual instances of the dynamic component can vary from one another according to these attributes. When you create a new instance from the Components window, it does not "inherit" dynamic_attributes assigned to other instances.

@ahjkuipers said:

Still not happy with your answers.
Take a look at the next method, based on my old one.

` def helpme(a0, a1, a2, a3)
ents = Sketchup.active_model.entities
face = ents.add_face(a0, a1, a2, a3)
for i in 0..3
puts face.vertices[i].position
end

dosomething

end`

There are eight possibilities to define the rectangle but the output of the method will give seven times the same answer and exactly once a different one. I need all eight different answers. The dependency of clockwise/ccw is not really the problem because the method 'dosomething' already copes with this item.

There are eight possible ways to list the points of the rectangle, but since Entities#add_face will force the normal to be downward when z==0, there are actually only four possible returns in that case. All eight can only occur when the Face is not at z==0 so you can get both upward and downward normals.

However, Entities#add_face does a lot of work behind the scenes. In addition to forcing a downward normal at z==0, it checks for duplication and intersection of Entities and edits both existing Entities and your new Face to account for them. If you run helpme two times in a row without deleting the Face between, add_face will detect that the two Faces are geometrically the same (despite the original point ordering) and will return the pre-existing Face. You can add 'puts face' in your code to confirm this - same object ID! That is probably why you are seeing the same results seven times (did you delete the Face before the eighth?). I tried it while deleting the Face between cases, and I got four distinct results as expected at z==0.

You don't say anything about how dosomething works or why the Vertex ordering matters, so the best advice we can offer is something like TIG provides above, which remembers the original ordering of the points and uses this to sort the Vertices. It is possible there is a different, better way to accomplish dosomething's purpose.