[Plugin] S4u Make Face

ideas_arte

Thanks for the plugin, here the Spanish Language

[attachment=0:1xlaqm1z]es.zip[/attachment:1xlaqm1z]

¡Muchas gracias Oxer!

JQL

hdpv,

I noticed there's no menu entry for this plugin. Is this true? Can you make one?

I'm asking for this as it would be great to assign a shortcut to the tool...

Thanks,

João

hdpv

Hi JQL!
Menus PLugins>> Suforyou >> Make Face
I have update the s4u_MakeFace 2.0.0
-Optimization
-Espagnol language.

JQL

Nice!

ken

OK, downloaded the new version, V2.0.0. Was testing the plugin. Now after the installation, if I use the plugin, Sketchup has bug splat after closing. And installing this plugin was the only operation in Sketchup I have done this morning. If I open Sketchup and do not use this plugin, Sketchup closes correctly.

As for an error code, none displayed. Just the Bug Splat form as shown.

Note the prior version did not cause a bug splat.

Houston we have a problem.

Ken

Image 3.png

Box

Yep, I can confirm what Ken says, it is a repeatable bugsplat.

hdpv

Hi all!
I have post the version 1.0.0 while i find this error.

mokhtar

First, Thanks so much for you job on plugins HDVP, really all the plugins that you did so amazing and very useful .
Second, I wanted to ask you about a problem in S4U MakeFace 2.00 because really i can't resolve it, I don't why it don't make all the edges and just some edges like its appear in the attachment ?

S4U MakeFace problem

Box

At a guess it looks like you are trying to work at too small a scale.
If the piece is very small the faces can't form.
Try scaling up by 10 and trying again.

hdpv

@mokhtar : Can you post your sketchup file?

hdpv

Update s4u MakeFace v3.0.0
FixBug crash Sketchup!

Esense3d

Thank You

German Language File

pilou

French UI

fr.zip

hdpv

Thanks! I will add soon!

Pherim

I get an error on loading with the newest version on SU2016, both when installed via Extension Store and manually:

Error Loading File s4u_makeface/s4u_makeface_loader.rb
Could not find included file 's4u_makeface/s4u_makeface_loader.rb'

TIG

The author needs to change his files and remake the RBZ [v3.0.1] and get it re-signed/republished...
The base-level 's4u_makeface.rb' which sets up the extension has a path set for the extension's loader to be:
's4u_makeface/s4u_makeface_loader.rb'
BUT that file does NOT exist !
There are two files added by the signing process:
's4u_makeface/s4u_makeface_loader.rbe'
's4u_makeface/s4u_makeface_loader.rbs'
If the base-level 's4u_makeface.rb' were to say:
's4u_makeface/s4u_makeface_loader'
it will work - however, editing this file manually breaks the signing hash!
So v2016 won't like it unless it's running in 'Unrestricted' mode.
So it must be done by the author and re-signed.

This is a typical error caused by the new and unfortunately half-baked v2016 signing process which has been introduced.
An author testing his code with all .RB files in the subfolder will find it works, but making the RBZ with them included and then signing it, will then fail unless the specified loader path is left 'open ended' - i.e. it does not include a file-type suffix, and IF the author chooses any encryption at all - i.e. RBS or RBE - because only unencrypted RB files will work.
The new signer does not allow a mixture of RB and encrypted files [that used to be possible].
Also [at least at the moment] the signer perversely allows the author to add both types of encrypted files [RBS and RBE] into the same signed RBZ - although RBS works in ALL SketchUp versions anyway and publishing in RBE only protects the author's IP when there is no RBS version out there... ill-advisedly shipping them together means any 'hacker' can easily see inside the RBS anyway, and compromise the RBE's encryption.
Of course, publishing only RBE means the extension won't work in anything other than >=v2016 !
Also, if the signed RBZ includes encrypted files, then it may currently not be exempt from malicious tampering !
If someone were to [ill-adisedly] add their own 's4u_makeface/s4u_makeface_loader.rb' file that would NOT break the signing hash check in v2016, AND if the loader looks for an open-ended path [with no file-type specified], then the RB will load instead of the encrypted versions and this could do something wicked [it's RB/RBE/RBS load-order, with mo check on the signed/hashed files - at the moment ! ] - but of course unless you stupidly got the RBZ from an iffy site it should all be OK - but that's more to do with the source being trustworthy - like EWH or the SketchUcation PluginStore - rather than the RBZ being signed, which unfortunately on its own could offer only illusory assurance...