No Mod, but they need to Install stuff

ok this is my issue/disfuntion.. i made a Patio, think the wood deck behind your house, and it has a Rezzer in it (on touch the Patio gives a menu, u chose what to rez and it rezzes the item, then the item moves into pos relative to the patio). the items are Planters, Table and Chairs, and Hamock which can be bought seperately, they are each no copy, no mod, no trans

the Patio is no copy, no mod, no trans, so the next owner cant drop things into it...

how would i go about setting it up so the next owner can drop the Planters, Table and Chairs, or Hamock into the Patio so the rezzer will find them without making it Modable???


thanx everyone

I don't think it's possible without making it modable. You could make it mod, but keep the scripts no-mod. The next owner wouldn't be able to view the scripts, but they could add to the contents, change the name, etc. Also, making the rezzed objects no-copy could be bad. If they get derezzed for any reason, they're gone forever (no longer in the patio contents since they were rezzed). Plus, if the customer moves to a new place, they'll need to take each object to their inventory, then put them back in the patio contents. Most objects I've seen for commercial rezzers are copy/no-transfer to avoid the problems associated with no-copy rezzed objects.

llAllowInventoryDrop()

look into that command.

be warned, if you use this, it presents many security holes, including the possibility of having your item completely copied off by script

you could use an updater, using remoteLoadScriptPin, preload all models with the extra items, but only provide rezor code for them in specific scripts. or you could just make several versions, one plain, one with this or that extra feature, etc and set them to relative prices.

considered incliuding a 1-prim rezzer? the rezzeer can be moddable.

u mean somethign like.. touch the patio.. rezzer/installer rezzes and (copyable so they get more then one install) then they drop the parts in it and it rezzes the planters and such in position? that just might work.. lol almost sounds to simple, ill give it a try in the PM..

thanx everyone

Ok after taking Winters suggestion and giving it a go it seems to be the ticket... and b/c I’ll be able to use the installer over and over for different projects which is always nice.

Ok I’m in the process of making the installer but have run into a wall (a lack of knowledge). I need the rezzed part/ Planter to have the position and offsets in its own script (if I don’t do it this way and I create new parts for already completed & sold Patios the old will not contain the scripting to place it in position.. ok enough confusing you all and myself..

Basic purpose of this post...
I need a shout & listen that will know the diff between parts :\
This is what I’ve got working as far as hearing the message and then shouting the string, but it needs to be more like this:

Patio: If I hear the word “base” from any “part” I need to llShout “Part (that said base)” + v + (string) vBase. the v is so i know its POS or ROT message

Part: I need to only llListen to messages sent to me, then rip the vBase & rBase out of them for vectors and rotations


// Patio Listen
listen(integer PCHANIN, string name, key id, string message)
{
//Set all incoming messages to lowercase.
message = llToLower(message);

if(message == "base"
{
llOwnerSay(message + " was heard";

vBase = llGetPos();
rBase = llGetRot();
llShout(PCHANOUT, "v" + (string) id + (string) vBase);
llShout(PCHANOUT, "r" + (string) id + (string) rBase);

//Test Output
llOwnerSay("v" + (string) id + (string) vBase);
llOwnerSay("r" + (string) id + (string) rBase);
}

}


If I just confused you I'm sry : (
but this is as far as i could get b4 my brain melted, lol

thanx again ppl =)

It's alright, takes a bit to get the hang of scripting. Just hang on and it will begin to make sense.

Now that the cheerleader stuff is out of the way

See if I am on track. You need a rezzer to rez the parts, but you may change the parts at some point later. So each part needs to know where it is in relation to the rezzer. Right?

If that is correct then you could just store the offsets for the pieces in llSetObjectDesc(). When they are first rezzed at ZERO_VECTOR & llGetRot(), they can use llGetPos() & llGetRot() to know where and which way the rezzer is facing. Then you can add the offsets from llGetObjectDesc() to this and move them to where they should be.

For the offsets you will need the rezzer's position & rotation and the same for the part. Then rezzer_pos - rezzed_pos & rezzer_rot - rezzed_rot. (Not 100% sure on the rotation part. I'll play with it some in world tonight. Hopefully I'll be able to make an example script for you)

the formula for rezzors (or positioning relative to an object) is

base(rezzor)position + desiredOffsetPosition * baseRotation
and the rotation for the non-base object is
objectRotation * baseRotation

or
//-- calcuated from the base
llGetPos() + offset * llGetRot()
and
calculatedRotation * llGetRot()

you can send the llGet* information to the object(to be rezzed) and have it do the calculation, or just send the already calc'd information

you can get 'calculatedRotation' by setting up the base(rezzor) at ZERO_ROTATION, placing the object(to be rezzed) and recording it's rotation

With the constraints you've stated, it doesn't make sense to drop the hammock, table, etc. into the patio (or rezzer generated by patio) and then rez them. The reason is that if you make all this add-on items non-copyable, then there's no automatic way to get them back into the patio/rezzer. So any individual customer could only use it once (without forcing them to stand on their heads to put the objects back into the rezzer). So why bother? Just let them rez it themselves, and position it themselves. Customers ought to be allowed to reposition the table, planters, etc. anyway, so it doesn't seem like you're providing any benefit.

Instead, given that you're going to do these communications anyway for the position, just provide a menu option for the add-on items to position themselves relative to the patio, without ever forcing them to go through automatic rezzing.

Also, shouting the information seems wrong, too. These items are going to be near each other, so llSay should be fine. Perhaps even llWhisper.

Finally, you should do at least a minimal amount of authentication so that neighbors don't interfere with each other. I suggest making sure the listener and talker have the same owner.

I'm curious to know how this is possible.

before we had copybot, we had the prim mirroring script... which caused as much drama as the other... it had uses, but it's use for theft outweiged it. it reads prim attributes and creates an exact copy. ask around someone may have a usable copy (I quit giving it out, and only gave out protected no-mod versions when I did)

This has what to do with llAllowInventoryDrop?

you drop said script into the prim... IIRC you can also use this with a script that gives you the objects contents, or makes it do other fun things like grief people with the prim owners name on it, or one of those fun "gimme debit debit permissions so I can suck your account dry" scripts...

(all assuming of course you know the trick to get them in and running)

You can't drop scripts into prims manually, and those dropped in using llGiveInventory have to be reset/recompiled before they are running.

caught me while submitting my edit

Sweet. So I assume you've sent this trick to the security email address? I'd kind of like to know how much of a risk it is, since there's something of mine that makes use of the function. IM me in-world or leave me a PM if you're willing to discuss it.

I did, quite some time back...

just tested, seems to be patched, sorry to scare you, last time I checked it hadn't been... (haven't had much time inworld of late).... it involved droping LOTS of copies on at once, it would reject several then overflow, ignoring the rest. dunno if there are other methods. I noticed child prim behavior is a bit different now too re the thing about textures going to the child (no longer droppable on child, only on prim that specifies allow drop)

Yeah, it's really dumb that you can't drop things on child prims at all. The reason this would be a SWEET ability is because there's no simple or script-automated way that I know of to get the key of a child prim in a linkset, thus reducing the amount of potential spam attacks you would be vulnerable to. I think I'll put in a feature request for the hell of it.