BUILDER'S BUDDY OR NOT?

BUILDER'S BUDDY OR NOT?
I'm debating about using Builder's Buddy with the Seconds Grid sets, or not.

The Builder's Buddy system (BB for short) is a a set of two scripts: the Base script, which goes in a base prim, object or linkset; and a component script, which gets inserted into each separate linkset of the build. What you do is create you build and divide it into a number of linksets of 1 or more objects, and add (or use one of the existing) linksets as a base. You add the appropriate scripts to each bit, and then take copies of all the component linksets into your inventory and add those to your base. And finally after you've done that, you can set the relative positions of each component, and rez/clear them as you want. If you move the base linkset, all the component linksets move with it. You can find scripts for this at the SL wiki - http://wiki.secondlife.com/wiki/Builders_Buddy_v1 - and at GitHub - https://github.com/Outworldz/LSL-Scripts/tree/master/Builders%20Buddy/Builders%20Buddy - which seems to be the most recent version for OpenSim.

Because the rezing of the components is actually copying them from the base's inventory, it's a great way to both make builds that exceed the SL limit of 256 links, and in SL (where I first started making Machinomics) a way of making build when you don't actually own any land. I could work on and shot at these builds in public sandboxes, usually a few thousand metres above the ground, and when done derez the component linksets quickly. Of course there were certain constraints as well. The scripts use a DefaultPRIMCHAN which is the channel that the base communicates to the components with and they had to match or derezing and other commands don't work.

Because this is an integer it could be a signed 32 bit value between −2,147,483,648 and +2,147,483,647! Having a 10 digit number available gave me some leeway in identifying each set and subsequent sets on a build. I'd start one build a day at most, and base the "top level" DefaultPRIMCHAN number on that date. For example, if I started a build on the 4th September 2014, I'd make the root number YYMMDD_0000 or 1409040000. I'd also add that number to the name of the base linkset, e.g. _DOLBYS 1409040000. At the same time I'd add a an "identifier" to the names of the component linksets. In the example above, the base of DOLBY'S BASE was a central column linkset, and there were several component linksets: ROOF, COMMAND, MAIN, KITCHEN, WAREHOUSE, and two SOLAR ARRAYS. I'd give each and ID number and they might get named like ROOF 1409041000, COMMAND 1409042000, MAIN 1409043000, KITCHEN 1409044000, WAREHOUSE 1409045000, and ARRAY 1409045000 and ARRAY 1409047000. Those numbers would then be used to define the DefaultPRIMCHAN for further linksets that could be rezzed from one of the main component linksets. For example ROOF 1409041000 might only be a linkset containing the floor of the roof plus any railings and doors. If you wanted more, you'd insert a BB base script in one of the objects in linkset, and use 1409041000 for DefaultPRIMCHAN in that copy of the script. Extra objects placed on the roof would get a component script with the same number, and be added to as per above. And of course one of those objects could also have a BB base script with hidden comments, all using 1409041001 for for DefaultPRIMCHAN (and each getting that number at the end of their names.

In practice this meant that I could get away with three levels of BB scripting. The first level would be a "shell" building only the exterior of the set. The second level might add walls and doors to a level of that build (or external details, which you wouldn't need to rezz if you were shooting inside the set), or signs on the walls already rezzed. The third level ,which might use a sign or rubbish bin in a space that'd been rezzed in the 2nd level, might add actual funiture and props to a room. That had advantages when working in public sandboxes - you only rezzed what you needed and could keep the prim count low. If this had been a regular build in SL or OS, things might have been more permanent, but they'd also be on owned or rented land. The disadvantage to such a technique is that I had to be absolutely methodical in my building practices. I needed to build from large/top level down to small/bottom, to ensure consistency in the channel numbers. Also major changes were major affairs, because they would require reworking each BB base/component set. Also, using a B next to the edge of a region was problematic. If your rezzed linkset lies outside that region it might not rezz properly.

So the question I have is whether or not to use this technique for the Seconds Grid?

I can have as many regions as I want, of whatever size I want, and I can let builds sit in a region for as long as I want. Not only that, but because I'm also the admin, I can "hide" regions by either renaming their ini files in the /BIN/REGIONS folder, or even commenting them out (using ";") within those files. There's no rush in building. but there might still be advantages in shoots, by only having the bits you need to shoot rezzed, you can orbit around the the scene without a dozen walls or props being in the way. It's also easier to move a whole set around, just move the base object/linkset! Also, if you have components that you you want to keep separate, and not in a huge linkset, you can do that with this technique. At the same time however, you add an extra script for every base or component object/linkset you have, especially in the base because the script's still running even if nothing's been re4zzed..

The air ducts/aircon equipment on the Support level would be much better as a BB set, to be rezzed only if they're needed. I must think about this before I go much further.
https://github.com/Outworldz/LSL-Scripts/tree/master/Builders%20Buddy/Builders%20Buddy