Discussion: Builders' Buddy - Building Positioning/Rotation Tool

Chaz,

The newest (current) Builders Buddy, as previously reported, has been posted to the LSL Library, which is reachable from the LSL Wiki.

I have found that some of the LSL Wiki mirror sites are not keeping their mirror of the library pages completely updated, and are for example, listing older versions of Builder's Buddy. To go to the "official" LSL Wiki, on your SL client, go to Help > Scripting Portal

Newfie, firstly your script rocks! Its no secret that this is one of the most useful tools I have ever come across in SL. Thank you for making it available to us.

And completely off topic and for my own historic interest how did the grid look like way back in 2003 and how big was it when you were born? And was ruth the default look of choice those days?

This is in reference to post #91, which mentions that Builder's Buddy does not compile under LSL Editor. Alphons has changed the LSLEditor as of version 2.34 so that this script compiles, yay!

But I did want to mention the line that LSL Editor had trouble with, because it seems like a fragile bit of code. This code is in both the base and components scripts. Inside subroutine "heard", there is a state change inside an if-clause:

if(iRezIndex >= 0) {
				// Attempt to rez it
      rez_object();
} else {
			// We are done building, reset our listeners
      iLastRez = 0;
      bRezzing = FALSE;
      state reset_listeners;            // STATE CHANGE IN SUBROUTINE!
}
CODE


Alphons' testing shows that lines continue to execute in the subroutine after the state change, which is probably unexpected, since this is not true if you do a state change which is not inside of a subroutine.  But it has to execute the rest of the subroutine to ensure stack coherency.  I think a stricter LSL parser would disallow this construct, so if there is another way to accomplish what you are trying to do (if simply resetting the listeners, do you need a state change?), perhaps it would be best to change this bit of code.
.

I reckon I must have been bored, because for some reason I decided to write a really thorough help document for Builder's Buddy.

I'm posting it here as an attachment, and labelling it as .09 to allow for some revisions based on feedback / corrections that, I hope, might come from people here. Final version will be labelled 1.1, to match the current release of Builder's Buddy.

The final version, I guess, will be posted here, as I'm not sure how / if I can add it to the wiki.

At the very outset of posting this, I already have some questions, answers to which would help in making the help more complete, accurate and useful.

I'd be grateful if anyone could supply the answers to them.

==================================

==================================
[THIS PART QUOTED FROM ELSEWHERE]
1. Creator UUID
key creatorUUID = "";
//The UUID of the creator of the object
//Leave this as "" unless SL displays wrong name in object properties

<< As of version 1.10 megaprims should not be a problem. However, if a megaprim is used as your base object, you may need to set the _creatorUUID_ variable to your creator's UUID. >>
____________________________________________
CHAZ QUESTION BASED ON ABOVE: I'm not sure I'm clear just what "creatorUUID" is good for. Want to be able to explain it clearly when and why people should care about this.

____________________________________________


==================================
[THIS PART QUOTED FROM ELSEWHERE]
<< 2. "The answer to that is a "definite maybe". When the linksets are moved/positioned, SL uses the coordinates of the root prim, which itself cannot go underground. However, child prims that are part of the same linkset would go underground, as long as the root prim's centerpoint is aboveground." >>
____________________________________________
CHAZ QUESTION BASED ON ABOVE: Does this mean, when using LSL to rez something, the root prim of something cannot go underground? Because it can otherwise, I think, if you just use edit arrows to move it there.
____________________________________________


==================================
[THIS PART QUOTED FROM ELSEWHERE]
3. "I never paid any attention to the rotation of the root prim of the linkset in any of my builds, so that's a requirement I may have overlooked someplace"
____________________________________________

CHAZ QUESTION BASED ON ABOVE: The rotation of the base unit certainly matters. But does the rotation of the root prim in each link set actually matter?
____________________________________________

==================================
CHAZ QUESTION ADDITIONAL:
Let's say you have done the setup, recorded the positions, and packed the build pieces into the base Packing Box. You click the build button. You see something out of place that you'd missed, so you use the RESET button to get "it" to forget, then click RECORD again for the new positions. Do you have to repeat the steps of taking the component parts back into invy, deleting previous ones out of packing box, and replace them with the ones you just took into invy? Or, is it the Base Script that memorizes the positions, so that you don't need to do this.

LSL functions will set the object or linkset's root centroid to ground level. Further calls that would otherwise move this centroid below ground will silently fail. Avatars can however position objects somewhat more underground.



No, its part of the recorded data that gets reinstated when you build/position with BB.
The user doesnt have to care about setting it any particular way.



Each component piece remembers its pos/rot. Which is why you can load the component objects into a fresh prim, add a fresh base script and it will all still work.

Incidently, the easy way to make sure you dont forget to aadd component scripts to anything is to add them, use record, then move the base object up a bit.. check if everything follows it as expected.. and if not just UNDO the base objects move to put it back in original pos, add a script to the bit that didnt move.. record again and retest as above. When its all following the base correctly you can then take each part and insert into the base.

Or, If the chunk that you forgot to put a component script into is still in place, and you can accurately rez the build around it, simply add a component script to the problem chunk, record, and re add JUST that one chunk to the base.. no need to take all the pieces again.
Now that i think about it, you could probably just add a component script, record, take add.. repeat.. for each part. no need to have all of them in place each time you push record. Maybe not, but i suspect thats the case.. each component records its pos/rot independently of the base script and other components after all.

Probably because, as as an extension to the last point in my post above: BB needs to check the creator of the components to ensure that it can correctly limit what menu items are shown to users other than its creator.
So that when i make a build, stick it in a BB and distribute it so that people can build and clean, but not use the other functions.. it all works as expected.
To prevent end users from simply replacing the base prim and script with their own to bypass any limitations i may have chosen to add to it.

Typically the creator will simply rez their own prims which will naturally have their own name on them as creator, but as is the case with some kinds of prims, like megaprims, we have no choice but to use those made by other creators.
Without the ability to specify the actual creator, it wouldn't be possible to use some of the functions which limit what the end user (not the creator) can do with BB.

...I think.

Here for what it's worth is a help document for Builder's Buddy.

I am calling it Builder's Buddy Help Document v 1.10 -2.

Subsequent versions of help for Builder's Buddy v 1.10 would be named -2, -3, -4, etc.

When Builder's Buddy v 1.20 comes out, then the help for it would be named v 1.20 -1, etc.

This indicates the version of Builder's Buddy it is for, and the version of the help document.

I suspect there are a few "lapsus digitis" still floating about in it, as the time I'd set aside for final proofing of the English was interrupted several times (grrr).

Many thanks, BETLOG Hax, for your helpful replies!

Chaz Longstaff,

One item that you don't go into in the help file is the requirement of giving each part of a build it's own unique name.

Oh, sure. I wait a week and a half for more comments, and now people speak up as soon as I figure that there's no more coming and I might as well go final with it :} Just kidding :}

>> is the requirement of giving each part of a build it's own unique name.

Is it a requirement? I think it's wise. I always do. I do allude to the fact that most people aren't as anal as me when I write, ".... This can be particularly important if like most builders you leave each piece with the remarkably unique name of "Object" :} "

But once or twice for random testing during this, I confess that I did leave some bits all named object, and it seemed to work just fine.

I think people should give everything a unique name, even if just a small part of a link set, 'cause the time will always come when you or someone else will be grateful that you did -- but I didn't want to foist my own personal meticulousness on people.

But if indeed it is a requirement, then clearly I missed a big thing. Where did you see that it is a requirement?

Well, sorry I'm so late in providing the feedback. I subscribe to this thread, but I think some of the notifications about new messages got lost somewhere.

As for the objects needing to be uniquely named: I am pretty certain it is a requirement. Since the grid is still down, I can't simply verify through experiment.

According to message # 40 in this thread by ed44Gupte: "You cannot have duplicate names in your rezzer's object list. SL will append "1", "2" etc to make them unique."

I think I saw this documented someplace, but I haven't located it yet.

My earlier experiments with combining the component script with the Cadroe ShapeGen resulted in many failures that I traced to the naming problem. ShapeGen by defualt was naming each rezzed prim as "Block". I would hit "record" on my base prim, take them back into memory (where thouy would all be named "Block", and then copy them back into the base prim, where they would be named "Block", Block 1", etc. getting renamed....When I used the Build command, the I would only see 1 prim, and that was the one in the position occupied by "Block". I don't remember if only one object rezzed, or if all of them rezzed and ended up in the same location.

Now that the grid is back up, I have been able to conduct a few tests. It would seem that I am wrong about the Builder's Buddy not requiring that the names of the objects be different. Sorry about that

I think it is good practice to have somekind of a system to naming the objects in a build so that they are not all named "object" or "block" or whatever. The appending of a number to the name, when putting the object into the base prim, doesn't seem to cause the objects to not rez or position themselves incorrectly. However, they will then not have the same name as in your inventory.

Depending on what my build is, I will have more than one naming convention. In the very least, when I manually add the component script to the component objects, I will name the objects numerically. That way, I have some idea of how many objects are in the build. I can count them easier from inside my inventory. When a build command doesn't work right, I can look back at my history and see which object by number didn't respond to the base prim when I did the record command.

I totally agree Andromeda.

I worked your advice into a "best practices" note, and updated the help with it. The help posted above is now v 1.10 -2.

Many thanks!

I have builder buddy base 1.6 and component 1.7. I'm almost ready to go buy a system because I can't get it to build things correctly. I build a cave for selling and I've tried putting the whole cave of parts in the box and each piece seperately, but each time it rotates a bunch of the prims incorrectly, some prims that aren't linked with others but leaves the other linked parts ok. I've tried putting each part seperate in and it does the same thing. Some of the prims have scripts like particles or moving textures, but the ones it rotates doesn't necessarily have one of those in there. The sim I'm in isn't laggy, and I've tried clicking position after its rezzed. Any ideas whats wrong?

Thanks,
prismatica

Difficult to say whats wrong, but i'd recommend you get the latest version as a starting point.

I don't mean to sound insulting, but in my experience its usually the user misunderstanding how the system works that makes it fail. :] So be sure to follow the instructions in the script step by step just to be sure you haven't overlooked anything.

IM me inworld *after* you retry it with the latest version if you still really need help. Maybe i can help.

Good heavens, you almost make it seem as though there's something immoral about buying something. I hope your customers won't feel the same way :}

I don't know what to say. As the creator of the scripts says, "The most current "official" version of these scripts is 1.10.". That version is here: http://wiki.secondlife.com/wiki/Builders_Buddy

Consequently, that's the version that I wrote the full help for. The help is here: /54/2b/96792/5.html#post1936546

If you're using versions that have strayed from the official release path, the help may be of less use. (i.e. all bets are off :} )

In some of the earlier versions, it was not uncommon for linksets to stick at the rezz location and not move/rotate into the correct final position. One could usually correct this by using the Position command or moving the installation box, which prompts the pieces to reposition. This had something to do with the timer being too short, I believe Newfie corrected that in later versions.

If the position command does not correct it, that sounds to me like you may have missed putting the component script into that linkset. The object will still rezz at the installation box/base, but won't move anywhere.

Its not real clear what you mean by:




Are some of your prims not linked in sets? Every object (linked set) must have the Component script inside of the Parent prim, then you have to use the Record command, then take a copy of each object into your inventory, then put those objects into the Base prim/installation box.

Ahhh! I found the explanation in the forum thread quoted below. I assume the Leading zero-s are still required? I will go test it out.




My original questions:

<<I don't recall seeing the discussion that lead up to the inclusion of the Channel Button in the menu. Am I correct in understanding that this allows you to define a different channel that the base prim will use when communicating with the component objects?

Does the menu use the same channel? And otherwise do the component objects and the menu all use the default channel? That is what I think I'm seeing in the script.

Can anyone share how they recommend using this feature?

Can this be used to have several base boxes next to each other, each rezzing and using a different channel, so they don't interfere with each other?>>

I am not familiar with the particular version you refer to, but using the on_rez( integer parameter) to convey channel information would be the most obvious way to allow the same rezzer to create numerous builds in the same sim.
So yes, in theory this is a good technique.
However does the user then need to remember and reenter each channel before they can move/derez/etc using the base? Or does the base store this information?
A variation on this method where a single button randomly selects a valid negative channel, would be as good, if not a better solution.
...even better if it stores 12 of the most recently used channels for easy selection. Possibly also correlating the channel info with the region name, so *only* channels for objects rezed in that region are displayed ....

Possibly related to what you want to do: sometimes i want to radially array large unlinkable components; i 'build', select 'done'.. rotate the base. 'build' another copy... select 'done' etc
eg: the 4 piers on this: http://www.sluniverse.com/pics/pic.aspx?id=268861
This can be easily used to rez numerous builds in the same sim with no need for unique channels.
...which kinda relates to ...
Unless you really need to leave the components with their BB scripts *active*, its probably a good idea to finalize the build anyway. In which case you dont need to worry about unique channels.

I am wondering if I can use BB in combination with the old multi product vendor of Apotheus Silverman to do a house vendor with functions similar to what is discussed in /54/d4/253268/1.html. Ignoring the vendor script for a moment - my only use for that is to temp rezz each house base prim with a nice piccie on it so ppl can choose which one they wish to temp rezz. Once they click on the base prim that they have clicked to, I think I could play with a timer to temp rezz the entire house using BB and then have llDie just kill off the build after a few moments, or would I do better to set the entire build to temp prims? Anyone have ideas on the impact this combination would make on a sim? I have not tried any of this, I just got the idea reading the above thread.

Almost anything is possible, especially if you have some scripting experience to do it.

Generally I find its best to set an object temp and then take it to inv... as opposed to rezzing it and then setting it temp via script. It's more reliable, and doesn't punch the server in the guts with all the calls to llSetprimitiveParams once every 60 seconds.

(and yes, you can: add a component script to one chunk, hit record, set it temp, take it to inv, and add to BB base contents... repeat for all chunks in the entire house)

Doing a llShout(gChannel, "!COMPONENT DIE!"); or similar every 50 or 60 seconds will ensure everyting is cleaned up as the next rezzes.

Rezing the objects as invisible and phantom, until they are in position might be useful too.
..as might doing an additional call to "position" just to make sure it all goes where its meant to go. You might even tie this in with a reading of time dilation or somethng, so the script can guess when it might need to do additional work to get it positioned properly.

What you seem to be proposing sound both feasible and a really good way to display homes.
But you will need to do some minor script adjustments to integrate BB and your plan.
Just keep in mind that temp or not, temp prims do still 'count' just like normal prims in many circumstances... it's not as straight forward as it may appear. However if your temp prim requirement fits inside the ~10% of the total prim count normally allocated to temps, then you may not notice any issues. But be aware there may be numerous variables to work around before it works as you might be expecting.

Hi BETLOG, thanks. Setting the prims to temp prior to loading them into the base prim is a great idea for display items. I can then dispense rezz boxes to customers with contents not set to temp so this is a very workable solution. I want to work as little as possible through scripted changes to prim paras as I have had some 'incidences' in the past with the sim I use, when going too wild with those Fortunately its my own sim
As for setting the prims of the display model to phantom, thats a definite. Once the rezz is complete and position confirmed, I will have an option to possibly change that to non-phantom, so that a walkthrough can be done but that of course requires a llSetprimitiveParams call so I will have to see if I want that option on the BB dialog to allow walkthroughs or just keep it phantom for display only.
As for llShout, I was wondering if I could use llRegionSay as I dont need to sim to calculate any object related distances and stuff when deleting the linked prims right? Im a noob with lsl so please don't shoot me for a stupid comment

I use a modified version of 1.9 for my own purposes, and it uses regionsay.. i think i added that part.. maybe not.. just search replace shout with regionsay.

if you do mod the scripts, its a good idea to change the channels while you are in there.. just to lower the chances of unfortunate tangles with other ones you may have around.

Thanks BETLOG, yes, channels.... 0 is not my friend, 0 is not my friend... Hehehe. I never actually realized the importance of channel numbers until I had that spot of bother a few months back when first attempting to use someone else's rather complex script as the first time model for my own feeble steps into scripting LOL It left me rather redfaced
Cool about llRegionSay, I will check yours out if I have a problem in mine, but otherwise I've got my hammer and am about to try out the ideas in my mind (my mom used to thank me for the ashtrays I used to bake at school, though I never had the heart to tell her they were mugs, actually, so scripting with me has about the same effect.) so stand back and please wear safety gear Grmmm, maybe I should stick with "default
{
state_entry()
{
llSay(0, "Hello, Avatar!";
}

touch_start(integer total_number)
{
llSay(0, "Touched.";
}
}"

That is one use for having the channel button. Basically, you use the channel button to assign a new channel to the base prim before trying to rez anything. Otherwise, the channel number defined in the script as the default channel is used. This is only assigning the channel that the base unit uses to communicate with all the rezzed pieces. The menu uses a differently-assigned channel, and this won't effect the menu channel.

I probably made my coding for the channel button a little complicated, and I assumed a lot about the user who needed to change channels. For security reasons, it is best to use a negative channel. The valid range has to be between -2147483648 to 2147483647. Notice that there are 10 digits to this.

RE: leading 0's: I'd have to look at the code closely to see what I was thinking about. I _think_ I was worried about keying-in something like "123", and having the channel end up being 1230000000 when what I wanted was 0000000123.

I use builder's buddy all the time and I love it. Here are some comments I have, having read this thread through:

1) I put a avatar name - to - channel number routine in my builder's buddy rather than using a fixed channel number. This way I only screw up my own builds if I forget to take out the component scripts after rezzing a house.

2) I put a 20-30 sec delay (llSleep(20.0) in the part of the base program where the pieces are being rezzed, because I found that generally it was needed to avoid incomplete rezzing and a mess on the ground.

3) If a linkset has more than one component script in it (e.g. if you forget to take one out of a child prim from a previous version and there's one in the root prim too) then you will see some odd stuff happening.

4) If a linkset becomes unlinked on rez (which sometimes happens with objects that are linked close to the distance limits) then it will not build properly of course: you will find that linkset's unlinked bits all rezzed willynilly around the object that contains the base script. Try making two smaller linksets out of the object, and it will work better.

5) If you make the builder box into something kind of nice looking, or maybe even make the building foundation the builder box, then you can keep it rezzed and keep all of the pieces with their component scripts, and use the builder box to realign the build if it becomes unaligned, or even to repair it when a piece is damaged or mistakenly returned to inventory. Just drag a new copy out of the builder box, and click the builder box and pick "position." This will work as long as the pieces of the build are not unlinked or changed in their linkage.

6) Oh, and I use the builder buddy with my hippotech holovendor so people can rez models of my houses. The holovendor rezzes a copy of the builder box, and the customer then simply clicks the box to rez the house. I have the script modified slightly so that when a customer cycles through the houses, each new builder box shouts the "CLEAN" command and derezzes any previously rezzed model.