I need to be a little clearer on one item...when I loaded the french version and everything worked great, I replaced the fr_linkTools.html file with the linkTools.html file from the english version, and simply renamed it from linkTools.html to fr_linkTools.html. As I mentioned before, this got me everything in English except the title of the dialog window, which remained 'Liens'.
Sorry if my previous explanation on using the linkTools.html was a bit confusing, or misleading.
Hi Didier,
Thanks for getting back to me.
I tried the updated .rbs file you sent, and got this:
Windows Internet Explorer error message: Cannot find 'file:///Links%20Manager/linkTools.html'.
The syntax is exactly as shown, including the triple backslash. When I close the error window, the Links Dialog Window opens, but it is completely blank now.
If I download and install the french version it works perfectly. I also tried using fr_sulinks.rb, with fr_linkTools.rbs in the Links Manager folder, but I left in the english version of linkTools.html. This also worked perfectly, with the exception that the Links Dialog Window was titled Liens instead of Links.
Since I am no code guy, I am of little help in determining the problem. I am unsure how to get the Ruby Console to report the error you requested that I copy and paste, but would be glad to comply with some instruction on how this is accomplished.
Thanks again.
I've updated, but am having a problem viewing the dialog window... see below.
I've tried downloading the file twice, both times 'file corrupt'. Also tried running directly from download site, 'file corrupt'. This is for Pro version Windows download. Could be a problem with massive downloading of the update maybe?
I think this plug-in is long overdue...great job ThomThom! I can't tell you the number of times I've tried a boolean operation, or a volume calculation, only to get the "this ain't a real solid dude" message.
"It isn't a real solid...well what's wrong with it?"
"Not gonna tell ya...but it's wrong for sure. Good luck finding the problem man."
Now instead of hunting aimlessly for the micro gapped edge, or the itty bitty hanging triangle that can only be seen under exponential magnification, you point us right to it.
NICE.
What I would like to know:
How many SketchUp programmers are on the 'Development Team'. I think there might be a misperception that since Google owns the product that there are a large number of people committed to SU development...and hence the expectations of serious, comprehensive enhancements to the program with each new release. If I was to hazard a guess, and measure the 'Development Team's enhancement contributions in a year, vs one lone ruby programmer like TIG, or Fredo, or thomthom...I'm thinking not many. Sorry for the slap Google, but these guys are seriously kicking your butt.
How many SketchUp 'Pro' users are licensed, and are there in fact enough users who will likely pay for an upgrade to warrant investing the time and money into the program that we 'Pros' keep asking for. It would seem to me that the majority of users are on the 'free' version of SketchUp...while kudos goes to Google for their generosity on this one, I would suspect it serves little to motivate them to respond with enthusiastic gusto to 'Pro' users requests.
How many individuals are there who use 3D modelling software for visualization that have little or no interest in advanced rendering. Certainly the number of increasingly amazing photo-realistic rendering software offerings doesn't indicate a lack of interest in this area does it? I always thought the two kind of went hand in hand, and apparently a lot of 3D modelling software developers do as well. Isn't that a forward looking reason enough to give attention to better memory handling, more robust UV tools, and at least some consideration to modifying meshes without having to draw hidden lines on planes?
I love SketchUp, and Layout too for that matter... but currently I love the Ruby developers more.
We have confirmed this behavior. Update the SketchUp file, save, choose update reference in layout, the layout viewport window updates to reflect the changes made in sketchup, but the referenced document remains hi-lited in red, and "out of date" notation.
All of our files our kept on a server, which up until the latest release has had no issues with linked files showing the updates correctly.
The program is working and updating as expected....it's just a bit unnerving when it indicates otherwise.
In 'document setup - references' when choosing "update" on files that are marked "out of date" and are hi-lited in red, the files seem to update fine, but the "out of date" notation and red hi-lighting do not change. Doesn't happen with every file, but enough to make it bothersome.
Great! When do you anticipate the release of the Pro Version?
Hi Al,
Downloaded and really like the potential for this program. It would be helpful if, once the dialogue is created for all attributes pertaining to a component, that the order of creation would be maintained when you A) use the report function, or B) edit the attributes. The current method reorganizes all of the attributes alphabetically. Even after selecting an order of printing by rearranging the attribute list, once close the list resorts to alphabetical layout again. This is likely easily solved and would greatly simplify use. One could determine and assign attributes in the order expected to report them when creating, and then print or edit that user determined order as required. I think that would be a lot better than having to always rearrange everytime you want to print...
I would gladly buy the Pro Version when available.
I reported this in the general section as a query and there have been some responders with similar experiences in the new 7.1 release.
When it comes to intersection inferencing of overlapped or engaged planes, it is virtually non-existant, at least until you toggle transparency display. Once transparency display is toggled intersection inferencing works as per 7.0 and previous. Without transparency display turned on however, it is really hit and miss. If you zoom to where a boundary edge would intersect a plane you can often dance around the point long enough to promote an inference 'X', but getting an inference 'X' along the intersecting edge of planes is impossible. Toggle transparency display on...magic, works beautifully. Obviously, large models with lots of planes and edges makes working in transparency display an equally frustrating experience, so this option is not really acceptable.
OK, good to know it's not isolated to my office. Now to figure it out.
I'm modifying my last entry...the inference issue is related to 'intersecting' planes, be they grouped or not.
I'm finding that since loading 7.1, inferencing between overlapped groups is really poor. Let's say I make 2 boxes, group each one independently, then move them so they overlap/engage one another. If I try to begin a line where one of the edges of one box intersects the plane of the other box, usually I get a good solid inference...not anymore. The only way I can get any kind of inference is either by zooming in really close and hovering around for a few seconds, or by clicking transparent display. Once transparency is on, inferencing works like it used to...or so I think. Is this anyone elses experience? I've tried numerous setting options, but can't find the cure...help!
I copied Google a couple of times. Here's what I eventually discovered. Any model that had textures loaded when saved would bugsplat upon opening. If any other rendering style was saved, the models would open no problem. If I was in a model and then switched to textured rendering style...immediate bugsplat. So, I did some background work...updated my display driver to start. Then I went into my startup template .skp file and saved it as the new 7.1 version. I have components, materials, and styles folders referenced to same titled folders on the server and do not have these folders on my PC, so with the new update, all of these folders were re-added to my PC....I deleted those. (don't think this was the issue however). I then loaded my template .skp file and loaded all texture folders from the server, and saved. Closed and then restarted SketchUp...all worked great and have been enjoying new found speed in all files since.
No idea what fixed the issue, but somewhere in what I described above the problem disappeared.
Tried download this morning. Model I was working on in 7.0 resulted in bugsplat everytime I tried to open in 7.1. Reloaded 7.0...no problem. I tried various other models with 7.1, they all seemed to open fine, but for some reason there is a glitch in the one file that 7.1 doesn't like...bummer, as it's a large file and I was anxious to see the new speed improvement others are experiencing.
We use 1 layer for dimensioning in SketchUp. Parallel projected views for plan and all elevations. For each view incorporate all of the dimensions you want...then in 'window-model-dimensions' choose 'select all dimensions', close the dialog box and 'group' the hi-lited dimensions. Open Outliner, name the group something logical, then after export, hide the newly formed group and move on to the next view...repeat. We usually group all of the dimension groups pertaining to 1 object after all dimensioning is complete. We used to use layers....good luck with that if you try it.
I find this little quirk a bit bothersome when it comes to locating arc centerpoints. If you have an original arc and offset it, the entity that's created is not an arc, but rather a curve. Curves have no 'radius' value under 'entity info' and show no option for arc centerpoint when right clicking the curve entity. Is there anyway to avoid this substitution of arcs to curves when offsetting. I understand that arcs require all segments to be equal, and that when offset, the end segments change and are no longer equal length segments with the rest of the arc. Does anyone have a curve centerpoint suggestion?
That was an interesting tutorial, what I am referring to however is meshing prior to export, not after import. If I make a plane with curves in it in Sketchup, selecting 'hidden geometry' shows nothing except for the plane boundary. When you export however, a rendering program then shows the massive triangulation (or not so massive, depending on the vertices in the curves specified in Sketchup)that Sketchup has decided as the best way to polygon the surface. The imported mesh model that is shown on the clip is optimized as far as uniform distribution and shape of the polygons...a model created in Sketchup never has this uniform distribution, that is what I was hoping to be able to do, create a uniform mesh in Sketchup prior to export. You can manually divide the plane into a more uniform distribution of polys by simply adding lines, but unfortunately then your texture UV mapping controls only work on the individual manually created polys and not the plane as a whole...really ugly.
One thing I find problematic in Sketchup is the deadly 'long skinny triangles' that get created prolifically on planes where smoothly curved edges are employed. These babies are a nightmare when using displacement mapping in a third party renderer. Is there any program that you know of that can be exported to which will allow optimizing of the mesh parameters, maybe even converting to quads where possible, all the while maintaining the UV parameters that were exported out with Sketchup? MOI has an excellent mesh modifier built-in, but no UV capabilities, or compatible file formats with SketchUp exports. 