Read the story or listen to the 911 call

According to Google, the new CADIE AI experiment has taken full control of all Google app development.

Rumor has it that this includes a revamped SU ruby API with full access to all internal commands, multicore processing, massive poly count support (billions of faces), a full-blown realtime photoreal render engine, and no more shadow bugs.

Though CADIE was not explicit on timetables ("she" is busy scouring the web and tracking down the author of the Conficker worm), analyst estimates were for a new release before the end of the month.

Sorry, Chris I added a question mark if that helps...

According to Google, the new CADIE AI experiment has taken full control of all Google app development.

Rumor has it that this includes a revamped SU ruby API with full access to all internal commands, multicore processing, massive poly count support (billions of faces), a full-blown realtime photoreal render engine, and no more shadow bugs.

Though CADIE was not explicit on timetables ("she" is busy scouring the web and tracking down the author of the Conficker worm), analyst estimates were for a new release before May 1.

@thomthom said:

Yup, some times you just have to go for a cup of tea or two.

Preferably chamomile, to soothe the nerves

Brodie,

I understand your frustration with things going slowly. I've never personally experienced #1, and have only seen #4 when developing.

I can tell you, though, that in regards to GroupByTexture, you'd wait at least as long for SU to explode all groups and components if you manually started the procedure as with a ruby script exploding them (though you do save time by not having to manually select and initiate the explode process - I've tested it).

When exploding a large number of high-poly (relatively speaking) groups or components, SU will bog down, period. That's just the nature of the beast.

The lack of feedback is marginally fixable (I can put in status messages), but your #3 item defeats that effort, and that's an internal SU issue that no ruby author can control.

@thomthom said:

Back to the topic, it would help so much if SU implemented a proper progress API which gave a UI which didn't lock up and had an cancel button. A neat bonus would be a pause button that would freeze the script's operation. Though, this is something the SU team would have to implement.
Though, I have been theorising on this issue as well. I'm wondering if it would work to pop up a webdialog with a progress bar, or a spinning wheel, which would give indication of work. Of if the webdialog would freeze as well.

I've requested (multiple times) a native Progress Bar for the API. It just hasn't been added.
I've tried webDialog-based PB's and they don't work (at least I haven't gotten one to work, and that with direct Google input).

I had noticed problems with wxSU as well (one reason I didn't adopt), but not specifically with Windowizer4. I'll have to dig in and see what I find out.

Thanks,

I think that's been reported to Google, but it's a good reminder that groups and components need some help.

My apologies, everyone. My day job, night job, and family are keeping me very, very busy. I've been in contact with Max, and we are trying to work out a functional solution.

UPDATE: I just sent Max a file to incorprate into his toolbars for testing. If everything works as I hope, an update should be right around the corner.

@unknownuser said:

I put IDXRenditioner.bundle in the file, but I still get the same error.
What's really strange is that IDXRenditioner.bundle is a Mac file for IDXRenditioner and is not, and should not be, in the PC Plugins folder.

I've reloaded IDX Renditioner so I know it's the latest PC version 1.1.5.78

The "SmustardOrganizerExcludeFolders.txt" file should only contain the names of subfolders in the Plugins folder, not specific files.

Please contact me at Smustard, as there are a few specific things I'd like you to try.

Personally, I've not seen that crash happen, but that doesn't mean it can't happen. The problems I've noticed come when trying to create a nested group when not in the same nesting level. Perhaps that is what was meant by the warning.

That's not the first request for no dialogs, so I'll update the script. Meanwhile, could we remove this one, please? It contains permission language that does not exist in the current downloadable version (3.0) of Weld. (Don't worry - I'm not mad)

Thanks,

My suggestion would be to download some ruby scripts that do things similar to what you want to accomplish, and go through them line by line along with the API (in case some things don't make sense). If it still doesn't make sense after looking at the API (unfortunatly, that is quite possible due to the state of the documentation), ask here, and someone will try to help.

I came from an AutoCAD/AutoLISP background, and what I suggested to you is what I did - pored over example scripts to see what they did and how they did it, and learn the nuances of the SU-specific ruby methods.

That's about the only tutorial available, at least for now.

I think a semiautomatic would be the best bet.

You would have to go into the component, but with the tool active, a single click on each face would change the thickness. The reason it isn't likely to be a good fully automatic script (at least not with a quick turnaround) is that it would be difficult for a script to determine which face should do the moving.

But a "click the immobile face" script would be fairly easy. A webDialog would give you the means of inputting the desired dimension and a "maximum range" outside of which, no action would be taken (to prevent a 1m void from becoming 18mm wide). It could also have a toggle for "click the face to move" if that were useful.

#THIS IS JUST AN OUTLINE.  COLLABORATION WELCOME...

require "sketchup.rb"
require "select.rb" # a library file from Smustard for selections

class FaceMover < SelectSingle

  def main(item,view)

    return nil unless item.typename == "Face"

    # GET THE FACE NORMAL, THEN LOOK "BEHIND" IT FOR THE OPPOSITE FACE

    # CHECK THE DISTANCE TO THE OPPOSITE FACE, AND COMPARE WITH THE DESIRED DISTANCE

    # CHANGE THE FACE VERTEX POSITIONS IF NECESSARY

  end

  def showDialog

    # CREATE WEB DIALOG

    # CREATE CALLBACKS WITH DISTANCE INPUTS

  end

end #class FaceMover

# CREATE CODE FOR MENU

This is somewhat difficult to explain. There may be some folders in your Plugins folder that don't need to have their contents loaded by Organizer (Podium and Subsmooth are two that come to mind) - and in fact, trying to load their contents can cause problems (as you have experienced). Fortunately, there's a solution for that.

The .zip included a file called SmustardOrganizerExcludeFolders.txt. Open that and add to it any folder names that you didn't create as part of your organizing efforts. I suspect you may have a folder that includes "IDX" in its name. You would add that name to the .txt file. That will prevent Organzier from trying to load any ruby files in that folder and will thus prevent the error messages.

If you still have problems, let me know.

While I haven't found a way to do an "eyedropper" from a dialog, remember that the W4 dialog is modeless - you can use the paint tool's eyedropper to select a material from the model and see what its name is in the Materials dialog, then select that same material from the dropdown in the W4 dialog.

I know that's not ideal, but it's the best available option for now.

Ditto!

I have confirmed that Organizer won't be the hangup for a Toolbar plugin, nor will subfolders. The Toolbar plugin can piggyback on Organizer's file parsing structure and utilize the "SmustardOganizerExcludeFolders.txt" file for determining folders to not parse.

Everything is looking very good for a plugin that can read the available .rb files and create toolbars & buttons for them, and not create buttons for .rb files that aren't on the user's hard drive. It will be the best of both worlds - buttons for available scripts and no distribution issues (as it won't be necessary).

Max,

I'm working the bugs out of a system that will allow you to create the toolbars without distributing or modifying the scripts. It is a new method that queries if a script is available to be loaded, and if it is, then it will allow a button to be created. If not, it skips that button.

This would solve many problems - no script distribution issues, no installing scripts that might not be needed by various users, and all the relevant buttons for the available scripts.

The remaining issue is dealing with Organizer and subfolders, but that's not too big an issue.

@linea said:

Pisses me off that "christian" religious nuts can spout this bigoted crap but if anybody else said this sort of nonsense they would quite rightly be arrested for inciting prejudice. Muslims can't blink without alledgedly inciting terrorism, and we are letting this idiot into the country?!

Since he's already there, please keep him!