SketchUp 8 M2 is out!

[Bob James]

@tig said:

The filmandstage.rb file belongs in Tools - so move it.
The extensions.rb AND sketchup.rb files MUST be the current ones in Tools NOT these ones in Plugins! [probably out of date legacy files from a much older version ? so remove them]...
So... any files that the latest installer puts into Tools should be there, and any files with the same name that you see inside Plugins should not be there!

You have a few scripts even I don't have - I thought I was anally retentive...
You have lots of scripts that I suspect you rarely use if you think about it... Consider disabling those...

Actions:

1. Move filmandstage.rb to Tools
2. Remove extensions.rb and sketchup.rb from the plugins folder
3. Inspect the new Tools folder and remove any files from the plugins folder that appear in the Tools folder.

@tig said:

You have lots of scripts that I suspect you rarely use if you think about it... Consider disabling those...

I just find it hard to pass up the great tools you Ruby gurus create - even if I only use them now and then.
True, some are rarely used, but if I take them out by re-naming them I doubt I could rememeber which I'd need to re-name after shuting down and re-booting.
The ideal world would allow me to group plugins by category of what, in general, they do; and be able on the fly to activate/de-activate from a drop-down menu.

Thank you, TIG, for taking the time to point these out. Much appreciated because the problem with greyed-out functions happens to me all the time and I waste a lot of time re-booting.
@Jeff
See how "our" sub-topic fits here? I make those changes once in Dropbox and, voila!, they are changed on all three machines: home, work and laptop

[Bob James]

@unknownuser said:

...the difference is that my actual plugin folder on each computer is in it's proper location with symlinks going to the dropbox folder instead of me running my plugins through a link to another location..

i really don't have a clue as to wether or not there's a performance difference or possibilities for problems doing it your way and maybe it's totally fine.. it just seems cleaner or more proper to keep the actual plugins in their intended spot..

Dropbox puts a copy of the plugins folder in its proper location on your hard drive - that is, it's not only on Dropbox.
In my attachment of my SU folder you can see the plugins folder. I originally re-named my plugins folder to "plugins copied to DB" (just in case I screwed up the process ). After making the symbolic link (correctly as it turned out), dropbox copied the Dropbox version into the SU folder. (The Plugins-1 is another paranoia copy ). It's interesting to have both Dropbox/Plugins and SU/Plugins folders open at the same time, make a change in DB and see it instantly change on my hard-drive SU/Plugins

@unknownuser said:

but i guess this isn't really the right thread for this discussion..

I think it's closely enough associated with the general topic of "how to fix the plugin situation so that the greyed out problem goes away".

---

[jeff hammond]

@bob james said:

Dropbox puts a copy of the plugins folder in its proper location on your hard drive - that is, it's not only on Dropbox.

oh, i see.. yeah, i'm doing something a little differently then..
in my user/home directory (not sure what the windows equiv is.. but it's just this place on my drive.), i have a dropbox folder and that's what is syncing to the dropbox servers(?)..

inside my dropbox folder (the one on my computer), i have a symbolic link (alias'.. or maybe it's called a shortcut on windows?) which is coming from my plugins folder.. my actual plugins folder isn't directly connected to dropbox.. i have a middleman in there.. (which i've also been using to install my rubies from lately.. i just put them in my dropbox folder and they are sent to my plugins folders on all the computers)

but yeah, i think a few people are doing some sort of cloud syncing with plugins lately.. i wonder what, if any, problems may arise (well, i know of a few problems that could come up.. i'm talking about sketchup performance problems in particular)

[rv1974]

Hi John!
First off thank you for refining our beloved baby.
May I put my humble request here please:
I beg for solving 'grey menu' issue! It's close to impossible to work 'this way'.
And could it issued as kinda 'hotfix' ASAP before the main release?
Thank you in advance

[Krisidious]

@rv1974 said:

Hi John!
First off thank you for refining our beloved baby.
May I put my humble request here please:
I beg for solving 'grey menu' issue! It's close to impossible to work 'this way'.
And could it issued as kinda 'hotfix' ASAP before the main release?
Thank you in advance

you should read the previous 8 pages real quick.

[rv1974]

@krisidious said:

@rv1974 said:

Hi John!
First off thank you for refining our beloved baby.
May I put my humble request here please:
I beg for solving 'grey menu' issue! It's close to impossible to work 'this way'.
And could it issued as kinda 'hotfix' ASAP before the main release?
Thank you in advance

you should read the previous 8 pages real quick.

Well I did before posting here. You see I had this issue before M2 (which had no cure for this).
The answer 'Grayed-out context menus are typically a problem with one or more of the scripts you have installed'
does not sound good to me. Even if this statement is right (which is doubtful), The one third party ruby MUST NOT ruin the whole application.There must be protection against it. So I do believe that it's host software critical defect that should be fixed ASAP.
Purging the plugins folder (your recipe) which I I did a couple of times before did not help (at least in my case).
And basically I think the quantity turns into the quality: More nagging customers the better

[Khai]

anyone know if the "flicks" bug has been fixed?
(where you zoom into a model, rotate round it, and suddenly the view is thrown several miles from the model and can be almost impossible to find the model again. resetting the views etc has little effect)

it was so bad in 8 I went back to 7... but from what I can tell, I maybe the only person it happens to

[thomthom]

@khai said:

anyone know if the "flicks" bug has been fixed?
(where you zoom into a model, rotate round it, and suddenly the view is thrown several miles from the model and can be almost impossible to find the model again. resetting the views etc has little effect)

it was so bad in 8 I went back to 7... but from what I can tell, I maybe the only person it happens to

Do you mean where the camera zoom in big steps if you have the cursor over empty space? It's a big difference in the zoom steps depending on whether the cursor is over geometry when you zoom or not.

[Alan Fraser]

I can't say that I've ever come across the 'flicks' bug (as described) in all my years of using SU. I've occasionally imported 3rd part geometry which has come in very small and is difficult to navigate...especially if it's a long thin shape (easy to overshoot); but that's about the extent of it.

[TIG]

rv1974

You seen to misunderstand.
As more plugins were developed the gray-out issue was reported.
It was a mystery for some time until the cause was stumbled upon - it was noticed that several of Fredo's tools made 'commands' within context-handlers, so this rapidly increased the number of 'commands' used in Sketchup and could overwhelm it - so in effect it then started disabling some earlier 'commands' to make space for the new ones.
Thankfully once it was realized Fredo [and a few others] quickly fixed their code, and we now know of no plugins that have this 'fault'.
However, the gray-out reports continued to increase as new tools became available with additional 'commands' needed to use with their toolbars/context-menus etc.
This adds to the total number of commands Sketchup has to handle and so it can reach the fatal limit.
For some unexplained reason, this number-of-commands is relatively low - perhaps in the hundreds - so if you have lots of plugins auto-loading from the Plugins folder then you can get the gray-out menu items. A good solution would be for Sketchup to handle considerably more commands - x2 or x10 etc... BUT that needs Google to redo parts of their code...

Currently, there are several ways of reducing the number of commands loading and thereby avoid the gray-out issue.
If a tool is an Extension and you are unlikely to use it very often, then you can deactivate it in Preferences and restart, if you need the tool later you can always activate it again...
If the tool simply loads from a .rb/.rbs file in the Plugins folder you can find the file and rename it - so xxx.rb becomes xxx.rb! etc - only .rb and .rbs files will auto-load, so after a restart the "!" versions are ignored [note that any companion scripts in subfolders do not auto-load and so they need not be renamed at all]. Later, you decide you really do need to use a particular tool you can always open the Ruby Console and load it manually, thus load "xxx.rb!" - the code inside a .rb! file is still read OK and then the tool will load, it's active just for that session [unlike an Extension which would have to be disabled again to stop it loading every time].
As an alternative to renaming scripts you could simply move their files to a Disabled_Plugins folder but that is more drastic...
There are many scripts that you probably don't need to be loaded up every single day... do some spring-cleaning and stop getting gray-outs...

[thomthom]

@tig said:

For some unexplained reason, this number-of-commands is relatively low - perhaps in the hundreds

Google sources says it's 1000.

[TIG]

It's probably something like 1024 - following some 'binary logic'.
Which is better than 512... but not as good as 2048 or even 4096 !
Presumably someone somewhere in Google needs to 'allocate more memory' to this ?

[thomthom]

You'd think so, but he seemed quite specific to it being 1000...
http://forums.sketchucation.com/viewtopic.php?f=15&t=27941#p243583

@jhauswirth said:

The problem is Ruby scripts are calling-
UI::Command.new
and not attaching the new command to a menu item.

If you want to verify this run-

for i in 0..1000 do
cmd = UI::Command.new("Tester") { UI.messagebox("Hello World") }
end

I can see Ruby scripts creating new commands on each right mouse click.
Every new command creates a unique command ID in SU and there are only 1000
command IDs available. Normally a command is attached to a menu and when
the menu goes away the IDs are recycled, but since these commands are not
attached to a menu, they don't get recycled.
I'm going to try and figure out how to dump the list of commands (they have
menu item text) so that people can see who's causing the problem.

[TIG]

Well if it is exactly 1000, then they just need to change it to say 2000 or 10000 !!!
This is NOT rocket-science after all...

I am frankly amazed that Google have not fixed this seemingly straightforward issue... BUT instead they have chosen to expend effort on inventing RBZ/installers etc, which as you know, I feel fixes a problem that didn't exist [or if it did exist then it simply replaced it with an alternative problem]... all while the population explosion of installed plugins continues [which is at least theoretically made even easier by RBZ] - which is still wreaking havoc in the context-menus with gray-outs... which should have been fixed!

[halroach]

@jbacus said:

@unknownuser said:

...and I'll update you guys why it was so difficult to use. Has anyone else had any problems with that?

I'd be keen to hear why you prefer the old "Film & Stage" plugin to the new "Advanced Camera Tools" as well. We think the new version works better than the old one, of course

john
.

I just installed M2 and it jogged my memory why Advanced Camera Tools make things really confusing and even harmful in an un-sketchup like way of thinking:

1. creating a camera automatically creates a scene (sounds nice at first) but when you delete that scene the camera is still there. that can be fine, but when I click to look through that camera the scene is created again, why!?. Things have to be more straight forward and simple. If cameras are necessarily linked to creating scenes, deleting the scenes should logically delete the cameras. If they are unlinked, so creating a camera shouldn't automatically create a scene. It must be a straight-forward process! The reason this is annoying is because it is in combination with the next few points...

2. When you select to look through a camera - you enter the camera mode (with the dolly tilt roll etc. movements) - that's fine. When you select a camera scene, it does the same! That can be very problematic when going through different scenes when some aren't cameras... If I select a camera scene(A) and immediately select a regular scene(B) the minute I move my view a bit the camera is moved to the new scene(B) - I now have 2 scenes that are the same, when all I really wanted to do was move between scenes... That creates a LOT of confusion. And since scenes aren't undo-able you're totally screwed if you accidentally worked in a natural way and skimmed through your scenes with page up page down... without right-clicking on 'done' every time you happened to go through a camera scene...

3. When you copy a camera instance it doesn't automatically create a scene, does it!? not until you look through it and then it still refers to the old scene. So I now have two cameras in two different locations referring to the same scene... that's royally screwed!

4. I generally liked to use the cameras to copy scenes from model to model. I'm not sure what kind of scenes will be created now when I move to the new model. In any case with the old film and stage it was very straight forward. Maybe a bit tedious selecting each camera and then creating a scene for it, but at least it was straight forward and it worked every time...
   Try copying 5 different cameras between models and tell me it's not hell... You can always say this plugin wasn't intended for copying cameras... - for me, that's what makes sketchup what it is! Sketchup is all about copying and pasting - it's the only 3D program that does this well - and it's one of the things that make it SUPER!

5. Camera scenes are always created at the end of the list of scenes. When you have 200 and up scenes, and you want to create this camera scene right at the beginning of the list you have to click 200 clicks in the scene manager... On the other hand when you add a regular scene, you are able to add it anywhere by right clicking on the already created scenes. Why should camera scenes be any different!?!?

6. camera volumes adds a ridiculously large selection box around the camera. Once I used to be able to select the 'move tool' and I could easily rotate the camera from the outside... that's impossible now - at least with the move tool.

Fortunately "Advanced Camera Tools" can be disabled in the extensions list under preferences - so I can use the good old film and stage!

Ideas for further development:

1. It would make things simple and straight forward if entering a camera scene didn't automatically put you in "camera mode". then you could browse through different types of scenes without worrying scenes will get confused/erased. have a toggle in the preferences for automatic camera mode!? what ever it is, it has to be well thought out... KISS - keep it simple and stupid!

2. like you can copy and paste cameras between models, it would be nice to copy and paste scenes between models (without adding ruby plugins that still don't do it well or intuitively). click on a scene tab or on a bunch of scene tabs or on the border of a scene tab (something new maybe). press ctrl-C and you've got the scenes copied for pasting in the same model or in another model. Think about it like copying power point presentation pages from file to file. you can always insert a new page in between existing pages by having the mouse on the line in between...

3. camera volumes - It would be nice if you could scale the volume and that would adjust what the camera sees accordingly...

4. You guys need some serious beta testers for things like this... I'm up for hire!

[jbacus]

@tig said:

Well if it is exactly 1000, then they just need to change it to say 2000 or 10000 !!!

This number can't be infinitely large. How many commands are "enough" to meet your needs?

Just so that someone has said it... you guys could also leave fewer extensions activated. It was my hope that by making it easier to install and activate plugins you would find it easier to keep only those you really need for a particular model active in the application.

Hundreds of active plugins put strain on many parts of SketchUp. We can (and will) continue chasing bottlenecks in the code, but you guys can play a role here as well.

john
.

[TIG]

Clearly 1000 is not enough commands for a lot of users, so perhaps it could be nearer 2000 .

Many users are lazy and don't do house-keeping...
The gray-out issue appears on these forums at least once a week, often 'faulty' scripts are blamed, but it's actually been shown to be a limitation of Sketchup itself and therefore just 'too many scripts' !

I agree that if most tools were made as Extensions then switching them on/off via Preferences could help... BUT the Extensions list itself is not entirely helpful in that it does not order them alphanumerically, and you get an annoying warning after you un-tick each one.

I do have a longterm plan to Extension-ize my main tools, but as this is 'unpaid' tehn unless I need to reissue a specific toolset and I have the time then why should I be too bothered, especially if I am pressed for time doing some other 'real work'...

[thomthom]

@tig said:

Clearly 1000 is not enough commands for a lot of users, so perhaps it could be nearer 2000 .

Why not just set it to 10 000 or 100 000 ... if there needs to be a limit at all.

@tig said:

I agree that if most tools were made as Extensions then switching them on/off via Preferences could help... BUT the Extensions list itself is not entirely helpful in that it does not order them alphanumerically, and you get an annoying warning after you un-tick each one.

+1
The Extension list is not very user friendly. Especially them messageboxes.

@tig said:

I do have a longterm plan to Extension-ize my main tools,

Ditto. Will be updating as I go along.

[jpalm32]

dae inport: Unicorn.dae Size 14,000KB- Import 3.5 Minutes; get this explode -Gave up after 8 minutes.
Same file in VUE 9.5 Import 1 Second; Ungroup less (That's less 3 Seconds)
I don't understand!
Import was accurate, which it didn't do prior to update, but who cares.
How can one program be that much better??? VUE has it's problem also but man....

[jbacus]

@jpalm32 said:

dae inport: Unicorn.dae Size 14,000KB- Import 3.5 Minutes; get this explode -Gave up after 8 minutes.
Same file in VUE 9.5 Import 1 Second; Ungroup less (That's less 3 Seconds)
I don't understand!
Import was accurate, which it didn't do prior to update, but who cares.
How can one program be that much better??? VUE has it's problem also but man....

Ungroup in Vue is a different operation than Explode in SketchUp. Exploding this model in SketchUp merges all the geometry. Merging, while quite useful when modifying the model later, is pretty 'expensive' computationally. Vue doesn't merge geometry on explode.

john
.