Looks sort of like the houses of refuge we used to have along the coast here. Not many left.

PLUGIN UPDATE

@paulofukuta said in [Plugin] Multiple Component Edit Warning:

When I install the Edit Flag v2.4.0 plugin in SketchUp in Brazilian Portuguese, the tool name does not appear. How could I fix this bug?

There were unicode character bugs in some of the language files resulting in silent failures for the menu command labels.

I fixed all the bugs in the language files with version 2.4.2 (see below).

@elijahpekaar said in [Plugin] Multiple Component Edit Warning:

@ashscott Is there a possibility of getting an updated version for 2024 sketchup?

I am the author of Ash's extension. (He hasn't been here in almost 2 years and not posted in the forum for almost 7 years.)

Changes for SketchUp 2024 and Ruby 3:

v 2.4.2 : 2024-04-27 by Dan Rathbun

• Updates specific to SketchUp 2024+ and Ruby 3.2:
  - Changed File.exists? call to File.exist?

• Re-focus the Sketchup window, so that the Edit Flag warning dialog no longer seizes the focus from the main modeling window.

• Fixed the scrollbars showing in the edit warning dialog.

• Added system font identifiers for both platforms to the "font-family" style for the dialog. The text should now show in the system font.

• Localization:
  - Fixed unicode characters in files: es, fr, it, pt-BR, pt-PT
  - Added language hash files: cs, ko, ja, pl, sv, uk, zh-TW, zh-CN.
  - Localized the extension description and name for the Extension Manager.

• The extension is now signed.

• --> Get the latest version in the SketchUcation Plugin Store
• --> Get v2.4.2 at the SketchUp Official forum

@ezyuzin Any reasons why?

@robertWan said in AI-Created Extension for SketchUp – Issues with CTRL Modifier Functionality:

Using Sketchup::InputModifier::CTRL to check if the CTRL key is pressed.

Where did you get Sketchup::InputModifier::CTRL from? This is NOT a constant defined by SketchUp's Ruby API. Nor is there an InputModifier submodule. Be careful as the AIs have been known to just "invent" coding objects or functions to satisfy themselves in providing "solutions" (which are not guaranteed to work.)

FYI, the toplevel constants defined by SketchUp's Ruby API are listed at: Top Level Namespace

In the tool's onLButtonDown callback method, I think you should be using COPY_MODIFIER_KEY or COPY_MODIFIER_MASK instead of MK_CONTROL to test the flags passed in by the SketchUp engine. See the Sketchup::Tool abstract class overview.

Also, your extension submodule should be wrapped within a unique top-level namespace module. Ie:

module RobertWan # top-level namespace
  module CustomSelectionTool # extension submodule

    class SelectPlaneTool
      # ... the tool code ...
    end

    def self.activate_select_plane_tool
      Sketchup.active_model.select_tool(SelectPlaneTool.new)
    end

    if !file_loaded?(__FILE__)
      UI.menu('Plugins').add_item('Select Plane Tool') {
        CustomSelectionTool.activate_select_plane_tool
      }
      file_loaded(__FILE__)
    end

  end # extension submodule
end # top-level namespace

The easiest fix for Ruby 2 and higher, is to use a refinement that only that file can "see" and use.
I inserted the following at the top of the file (after deleting the Set reassignment):

require 'set'

# Create a refinement for the Set class:
module DBUR
  module RefinedSet
    refine ::Set do
      alias :insert :add
      alias :contains? :include?
    end
  end
end

# Use the refinement:
using DBUR::RefinedSet

By request from @paddyclown, here is the "fixed" file.
It still needs a drastic overhaul, but this will get it working (fingers crossed):

DBUR_QuickSelection.rb

@Didier-Bur ping (I do not know how to send this by PM in this new forum interface.)

The Gemini AI says:

The term "gobbledygook" was coined in 1944 by Maury Maverick, a congressman from Texas.

During World War II, Maverick was the chairman of the Smaller War Plants Corporation. Frustrated with the excessively long, vague, and pompous language of bureaucratic memos, he issued a memorandum to his staff telling them to "stay off gobbledygook language." He defined it as "talk or writing which is long, pompous, vague, involved, usually with Latinized words."

Maverick explained that he came up with the word by thinking of the sound a turkey makes—a "gobbledygobbling" sound. He felt that the pretentious and convoluted language of officialdom sounded just as ridiculous as a turkey's gobble.

@Dan-Rathbun said in C SDK save in 2022 or 2023 formats:

What is different in the v22 and v23 file formats that need to be maintained?

I took a quick look at the release notes and I see only 2 new features that would be saved into the SKP file data:

v23 : Added Ruby Overlays and the model now has a flag collection with a Boolean state for overlays.

v24 : Added the Ambient Occlusion style properties (a state flag and numeric setting.)

Opening a SKP file on any older version back to 21 would just ignore any unknown data. This is known as SketchUp's versionless format since v21.

So WHY would you need to backsave to what v22 or v23 saved as ?

Ie, v22 did not add any new features that made the SKP any different from what v21 saved.

And, v23 only adds the listing for the overlays collection and would just ignore the new AO style attributes (added in v24) it does not know about. It might leave the attributes as is within the model data but do nothing with them, OR ignore them so as to not write them out when it saves a v23 SKP.

I think it is expected that you use SUModelSaveToFileWithVersion() with a SUModelVersion_SU2021 constant.

What is different in the v22 and v23 file formats that need to be maintained?

The only other thing I can think of is to compile 2 external utilities with old versions of the SketchUp SDK and have these utilities backsave the SKP files using the SUModelVersion_Current constant.