The hex string is the pointer address of the ruby object. The problem is, a given object (entity, face, edge, anything), doesn't always have the same pointer address. If the object is unused in ruby (differing from being "used" in SU; SU doesn't store it's objects permanently in ruby), it may get discarded during garbage collection. The next time you ask for the entity, it will be the same entity, but it won't necessarily have the same address. A lesson I learned the hard way making a C ruby extension.

entityID is, to my knowledge, the only way to safely retrieve an entity.

Since that is a ruby constant, or whatever, not an SU specific thing, I wouldn't have expected it to change. I don't think the version of ruby is different between XP and Vista (1.8.6 right?).

Here are a couple alternatives I found around

File.expand_path(__FILE__+'/..') 
File.dirname(File.expand_path(__FILE__)) 

I'm trying to figure out how locking inference works with creating a tool. But I'm a little lost.
As best as I can tell, lock_inference will fail if the point you pass ("view.lock_inference pt") is just a point, but it will succeed if you pass a point that is on an edge or face. Passing in two points, however, doesn't seem to do a single thing different than passing one point. It just uses the first. So is anyone able to explain what passing two points should do?

The next question is that the line tool allows you to hit an arrow key and lock inferencing to an axis. Is this something that should be repeatable in a user-defined tool? Any help, especially with the axis issue, would be great! Thanks.

While you'll still need a method to determine if the Outliner is visible or not... you can just call this:

UI.show_inspector "Outliner"

to toggle between rolled up and rolled down. (At least in SU 7, didn't try 6)

I'm not much of a script programmer, my experience is mostly in c++ and c#. My forays into ruby are really my first experience with script languages. Not experiencing other choices, I'd have to pick ruby. I like that you can inherit classes; I don't like that it's a little to loose when it comes to that . I really like how easy it is to extend ruby with c and c++, and the tools available in c to communicate with ruby. I hate ruby's garbage collection (but that's only an issue when extending in c/c++). So good and bad, but having nothing to compare it against, I say it's good enough.

Avariant's pick: Ruby

Wow, that's a weird one. Deleting the texture doesn't make a difference, nor does changing the texture.
You said it's an old model? Maybe it's a "backwards-compatibility" bug, like somehow when they updated the material from it's previous version to SU6/7 (when you opened the file), something was missing that keeps it from being displayed. I'd say bug for sure.

The fact that creating new materials from it result in non-working materials somewhat supports the theory. They probably do a bitwise-copy of the existing material, making an exact duplicate, so whatever is corrupted in the original is messed up in the new ones.

If you check the texture.filename for the material that doesn't show up, it's a network path. Maybe that's why; maybe it times out looking for the path and so never shows up?

\Arc4063\fasademontasje th. angells gate\fasadefoto\montasjer jpg\Jomfrugt. 5 oppriss hjørne.jpg

So I checked the instance methods, to see if the exposed methods correspond to the API. I'm not sure if it should or not, my ruby knowledge is thin here for sure (extending classes where methods may get called but are / aren't defined in the base class).
However, I checked the instance methods of every single observer class and they match the API exactly (some have additional methods, but all have at least what the API says. Except MaterialsObserver.

Sketchup;;MaterialsObserver.instance_methods
["MaterialUndoRedo", "onMaterialRemoveAll", "MaterialSetCurrent", "MaterialChange", "onMaterialAdd", "MaterialRefChange", "MaterialRemove"]

Sorry, but this is a serious "what the hell?!" moment. Most of the methods completely lack the "on" part. Yet, onMaterialChange does get called rarely, so the method is being used, even if the base material observer doesn't define it. Attempting to override "MaterialChange" instead of "onMaterialChange" never gets called.

Am I off base or is this a Google Fubar?
None of the other observers have any methods that don't start with "on", or differ at all from the API.

Didn't onMaterialChanged used to get called whenever you changed the base color of a material? It now only gets called when you change the texture filename and I can't remember if it used to work differently... Has anyone used the MaterialsObserver lately, successfully?

Thanks!!

I have. It didn't have any effect. A previous post here implied that invalidate only works somehow in the context of a tool. Even if it did work outside of a tool, I don't think it would help here; you can use the mouse to move the 3D view around as much as you want (which assumably refreshes and invalidates the view repeatedly) and it doesn't fix it. So it's not an issue with updating the display, but more somehow updating the material, visually. As soon as you modify the geometry or make changes in the material dialog, the texture updates correctly, but not until then.

I'm having a bit of an issue with texture size.

I'm changing a material's texture by "material.texture=blah\blah\filename.jpg"
Works fine, except:
If the material has a texture previously, that texture has a real world dimension, something like 1' x 6". When I apply the new texture,
a) the SU material dialog shows the dimensions correctly (if it's a square image, it's like 10" x 10"),
b) the view, however, shows the texture using the exact same dimensions as the texture before, even if the aspect ratio was totally different. As soon as I type in the SU material dialog, the view corrects itself, but I can't seem to get the view to change by any ruby command.

I've tried "texture.size=x" and "texture.size=[x, y]". These both work to change the actual values, and are visible in the material dialog, but the 3D view doesn't reflect the change of dimension until I interact with it using the SU dialogs or tools.

Any thoughts? Any way I can get the texture to force a change?

Material attributes, stored in a material's attribute dictionaries, are not loaded correctly from an .SKM file.

When you apply attributes to a material, and save that material as an SKM, the attributes are saved correctly. If you rename the SKM as a zip and examine the document.xml, the attribute dictionaries are all listed, all correct.
But when you load that material into a new scene and apply it to a face, the attribute dictionaries are not restored correctly.

What I've observed is that the number of dictionaries is reported correctly, but each dictionary reports it's name and keys/values as those stored only in the first dictionary. That you get multiple dictionaries with the same name seems a bug straight off the bat. Shouldn't all attributes with the same dictionary name be stored in a single dictionary?

To reproduce:

1. Create a face.
2. Apply any material to it (front face).
3. Select that face.
4. open ruby console
5. in ruby console:

   mat = Sketchup.active_model.selection.first.material
   mat.set_attribute("Dict_A", "Prop_A", "AAA")
   mat.set_attribute("Dict_B", "Prop_B", "BBB")

6. Open Materials Dialog
7. Select "In Model" materials
8. Select "Save Library As"; Save where convenient
9. Close and reopen SU
10. Create new scene. Create a face.
11. Load the library saved above.
12. Apply the previous material to the face
13. select the face
14. in ruby console:

    mat = Sketchup.active_model.selection.first.material
    mat.get_attribute("Dict_A", "Prop_A")
    mat.get_attribute("Dict_A", "Prop_A")
    array = mat.attribute_dictionaries.to_a
    array[0].name
    array[1].name
    array[0]["Prop_A"]
    array[1]["Prop_B"]

The results of the above ruby commands will demonstrate that the attributes are not loaded. However, the documents.xml file in the .skm clearly shows that the attributes are stored, and correct. The bug is on loading.

Ah, thanks!

If I have multiple instances of component "x" in a different group or component, "y", when I call selection.add(x.instances), the instances get selected, but so do these ghosts (just lines, no faces). It looks like its the same instances of "x" but without the transform that would be applied by "y". Am I doing something wrong, or is this a bug, or...something? Thanks.

Ok. Has this been reported to SU as an official "bug"? It would be very nice to get it fixed some day.

Sorry for digging up an old post, but I can't find anywhere the answer to the question posed here, the question I need answered as well.

When you apply attributes to a material, and save that material as an SKM, the attributes are saved correctly. If you rename the SKM as a zip and examine the document.xml, the attribute dictionaries are all listed, all correct.

But when you load that material into a new scene and apply it to a face, the attribute dictionaries are not restored correctly. What I've observed is that the number of dictionaries is reported correctly, but each dictionary reports it's name and keys/values as those stored only in the first dictionary. That you get multiple dictionaries with the same name seems a bug straight off the bat. Shouldn't all attributes with the same dictionary name be stored in a single dictionary? I suspect this is a Sketchup bug in loading the attributes from the SKM. Does anyone have any info about this?