Trusses are now created as components with each individual member of the truss a group. Arrays of trusses are multiple instances of the same component.

I think this plugin may actually have some potential now.

A couple more screenshots for fun.  A well designed truss is a beautiful thing to behold:





I really appreciate everyone's feedback, this has helped guide me in the right direction on all of this and improved my understanding of SketchUp immensely.

This is the same truss I used in my 28'x48' garage:



Now I need to work on the energy heel option for this truss type.

The left and right overhangs can now be set independently, however the right overhang defaults to match the left overhang to help speed user input:



I've also created a new page for the plugin with some basic documentation:

http://design.medeek.com/resources/medeektrussplugin.html

Just an FYI, the energy heels are enabled fully for the fink truss but not for any other truss type and the TRIAL version is actually not limited in any way.  I will probably keep it that way until the plugin is significant enough to actually warrant charging for it.

I've had a number of requests for monopitch or monoslope trusses.  Shown below is a sample of potential configurations of this type of truss.  Has anyone ever seen a (5/3) or (6/4) or a (3/1) monopitch truss?  The first number is the number of top panels and the second number is the number of bottom panels to clarify.

I have the raised/energy heel working now for a fink truss where a vertical member and strut is required (heel height greater than 12" approx.).  Still working on the wedge and slider cases, they are actually easier to calculate and program, but I figured I would tackle the difficult one first.

When the angle between the strut and top chord exceeds 10 degrees I then apply a scarf cut to the strut at its centerline (try a raised heel height that exceeds 24" and you will notice the difference).

Here is an example of a fink truss with a 18" raised heel.  Notice there is no scarf cut at the top of the strut where it meets the top chord. 

I have recently created a new map for Washington ground snow loads.  The data used in this map combines previous data from older snow load studies with updated data from automated SNOTEL sites.  The snow load calculations are based on a inverse distance weighting algorithm.  The new map can be viewed here:

http://design.medeek.com/resources/snow/washingtongroundsnowloads.html

In an effort to make the data as transparent as possible I have included links to each stations data and its log Pearson III analysis from within the detailed report.

I am currently testing some new features with the Medeek API.

One of these is to offer state snow loads in addition to the ASCE 7-10 national values for ground snow loads.

Note the addition of the variable "localdata" which when set equal to "1" will trigger a local lookup of the snow load values.  By default without setting the localdata variable the API will only give national level values (normal behavior) and the response from the API will remain the same as previous revisions of the API.

Also note that when a localdata lookup is triggered the API must perform a reverse geolocation of the latitude and longitude.  You will probably notice the response time from the API increase by approximately one second.

Currently the states that have snow load data are:

New York
Massachusetts
Utah
Montana

Each State has different methods at arriving at their snow loads, so the addition of each State's data can be a time consuming process.

The plan is to add all of the States that have data that differs evenly slightly from the ASCE 7 ground snow load map.

---------------

Google has a reverse geocode API that I use to get the address based on the latitude and longitude.  Based on the city/county/state I then make a determination with the API as how to determine the local snow loads, each state is different and from there is also depends on each county/municipality depending on the state, so adding new local data can be significant work.

For instance Nevada County in California is based on tabulated values for each elevation however there are an East and West zone and also a small transition zone between them.  The snow load for locations within the east and west zone are merely a function of elevation and linear interpolation between the tabulated values, using the elevation service from google with the tables computation is a snap.  However, snow loads within the transition zone require interpolation for each zone and then interpolation between the two zone based on distances between the zonal boundaries.  It is rather complicated but quite easy to program once you wrap your head around it.   Then to make matters even more complicated the municipality of Truckee with the county has its own special tabulated values and transition zone, so this requires its own programming.

When you use the local data option you always will get the ASCE snow load in addition to any local snow load data.  If there is no data for a location you will notice the API returns "NO DATA" in the local snow load field and the local source field.

As suggested by a current client I will probably add in the geocode (address input option) since it may be easier than first finding the lat/long for a particular location.

I have since incorporated the local data into the regular API so you don't have to use the TEST address to now use the local data option.

I have updated the documentation to include the new options, please take a look at:

http://design.medeek.com/resources/medeekapi.html