@sketch3d.de said:
Installing SU v2017 again should fix this behaviour anyhow.
Although that should work, you really shouldn't need to do an reinstall, just to fix up the "file association". See, for example
https://www.lifewire.com/how-to-change-file-associations-in-windows-2624477
Your model geometry is located too far (approx 300 miles) from the SketchUp model origin, which will cause the kinds of issues you are seeing. There are several possibilities to deal with this:
One possibility is that if you are "looking through" the hole as you push-pull, the tool naturally stops at the opposite face because there is no other inference in that direction based on the cursor's location. This doesn't happen when you are viewing more from the side so that the tool can find a meaningful distance to extrude based on the cursor position.
Taking another look, there is a deeper issue in addition to the Gatekeeper quarantine: the extension's code is attempting to load a Ruby 2.0.0 library from the Frameworks distributed with SketchUp, but SketchUp 2018 does not contain such a library, it has Ruby 2.2.0. So even if you figure out the quarantine thing, this extension isn't going to work under SU 2018!
A slow plugin is certainly a possibility. Do you have the same suite loaded on both machines? Any differences would be the place to start looking.
SketchUp itself does not provide any log of extension load times, so unless the author has programmed something (as Fredo6 does) there is nothing to help you other than trial and error.
Please see your other post on the same subject.
After you opened the grass for edit, did you select its surfaces? Intersect Faces With has to have a set of Faces to intersect!
Your dropbox files are gone, so I can't comment on them. Did you submit the BugSplats having filled in the fields for info about yourself? If so, someone at Trimble will take a look and let you know if this is a known bug or, for example, an issue with some extension. Be patient - they get enough splat reports that sometimes a reply takes a while.
Not clear from your post: did you remove the quarantine on the installer, or on the SketchUp app after installing it? You need to do the latter. A fresh reinstall may just set the flag on SketchUp.app again!
That is the attribute that remembers the quarantine, so yes, that is one of the ways to fix it.
You are falling victim to a Gatekeeper security feature (application translocation) that was added in macOS Sierra. It happens when an app is quarantined by Gatekeeper because it is was downloaded from the internet. Some people had problems with this shortly after Sierra came out, but the installer dmg for SketchUp 2018 should be ok. How did you obtain and install SU 2018? You might try deleting the app and reinstalling from a fresh download of the dmg. That will not lose extensions/plugins etc that you have now.
@hornoxx said:
@box said:
...you have hit control while orbiting which has tilted your workspace...
an other D'oh! moment for me
didn't know this tilting is even possible so
This feature is often overlooked. SketchUp by default implements a notion of "gravity" that keeps the horizon level across the width of your view - even if sky and ground visibility are turned off so there is no horizon literally visible. Especially with architectural models, this avoids strange and confusing off-level motion. But by pressing control (option on mac) you can temporarily suspend gravity to get a free rotation during orbit.
@bagtoshop said:
ok but when i click on the left arrow to aligan it to the green axes this is what
looks like. do you think its parallel to the green one ? i dont think so
Yes, it is parallel to the green axis. It looks that way in the view because you have the horizon visible (as proved by visibility of the "end" of the green axis) and perspective camera. In perspective, parallel lines appear to converge toward the horizon. Orbit so that you are looking down at the red-green plane and you will see that the line is actually parallel to green axis. You may have to click on the below to see the animation.
I don't think there is a one-size-fits-all answer, as there are many ways a dwf file can need fixup after import. Extensions such as CleanUp3 work using various criteria to decide, for example, whether two lines that don't quite meet should have met, or if a collection of line segments really should have been one longer line, etc. You can try various choices of these parameters and see whether you can find ones that produce better results. For instance, deleting everything suggests that all the edges in the model are shorter than what is considered too small.
You may need to backtrack all the way to the PDF and look for ways to tidy and/or simplify things there. You might be able to break it into pieces and work on them separately in SketchUp.
Then take a look at PDF Grabber to see whether it has parameters you can set to control its output (I don't use it, I have no idea...).
Expanding on what Dave wrote:
SketchUp displays lengths according to the units you have set in the model info window. If your choice does not have enough precision to present a particular length perfectly, SketchUp displays the closest value allowed by your choice and prefixes it with "~" to let you know that the value shown is an approximation of the true value. It is important to realize this is an aspect of presenting values on the GUI, it does not mean the value isn't stored correctly inside SketchUp. Also, it is a one-way street: you can't enter a "~" prefix when you type a value.
For example, if you set units to decimal meters with 0.0 precision, the value 0.123m can't be fully displayed even if that is the exact length of the entity in the SketchUp model. It will be "~ 0.1m" even though SketchUp internally has the correct 0.123m value. Similarly, if you set fractional inches with 1/2 inch precision, 3/8 inch will display as "~ 1/2" because that's the closest value that can be displayed.
I think @alpro likely has the answer. If the camera is perspective, rays of view diverge into the model, and this can cause the sides of objects to be visible except exactly along the center of the view.
The error message is saying that the interpreter parsed the text "for count1 in 0..5" and didn't find a line ending that it could understand. It wanted "do", ";", or "\n" (LF) and got something else. The fact that it works in 2015 suggests to me that this is an issue with the Ruby version embedded in SketchUp. Before SketchUp 2014 it was a variant of Ruby 1.8. As of 2014 it changed to Ruby 1.9 and since to successive versions of Ruby 2.x. One of the most important parts of the change was to require unicode character encoding. At least one of your screens suggests your computer locale is Russia? If so, your computer may be feeding unicode line endings that the older Ruby versions don't understand.
@rombout said:
Not sure whats happening, but removed all other. put them back restart and now it seems to work again... weird stuff
Recent versions of OS X cache both plists and the qlmanage settings. You often need to force them to refresh their caches to get things to "stick", especially if an affected app is open at the time. To force refresh of the preferences cache you can either log off and back on, reboot, or issue "killall cfprefsd" in the Terminal. To force refresh of the quick looks, do "qlmanage -r".
@rombout said:
Heavy models do take super long to save, is that due to jpg creation?
Heavy models can take a long time to save even without the jpg generation, but yes it will slow the save even more. You could get a sense of the impact by exporting the model as a 800x600 2D jpeg image, which is essentially what the plugin does.
@rombout said:
I got it working by changing the plist file
I looked some more, and it seems that SketchUp's own plist files affect what CFBundleDocumentTypes are initially registered for skp files. At some point they went from just com.sketchup to com.sketchup.skp, which necessitates the change you made in my plist.