llGiveInventory (Object Protection?)

[Slang Heron]

Hi, First I'd like to thank everyone who contributes to this forum.. I've read many helpful posts in here over the past year that have helped me learn to become a better and more efficient noob scripter.

I am looking for some advice or maybea nod in the right direction regarding protecting items you give people through llGiveInventory.

Let me explain...

I create a combat/life meter... in the system I have certain 'product maker' items... for instance a toaster...

When clicked by it's user, the toaster will listen for 'bread' being added and when Bread equals 2, the toaster will cook two slices of toast.

When ready there are two things I do depending on what kind of item/product maker the player is using... Rez the object to be temporarily attached or Give the player the item to be stored in their inventory for future use.

So.. My problem is this... I've had to be the owner of these items, as if I was to give players toasters, there would be nothing to stop them dragging toast to their inventory, bypassing the need for 'bread' to be bought for RP$ in game.

For llRezObject I've managed to secure the items using Rez Number/Start Parameters... If the item is rezzed by any other means than the toaster rezzing bread when done, the toast will llDie();

But, for llGiveInventory, I can't seem to think of a way to protect the items, as the product maker wouldn't be rezzing the object, it would be giving it to the player.

I tried to have a 'Rez Server' which worked well, meaning I don't need to store the items given inside the product maker, but then I came across the 10m llRezObject limit which negates the point of 1 on sim server... so as far as I know, that idea is out of the window as every house would need a server.

Any advice or point in the right direction would be greatly appreciated.

Thanks in advance.

 

 

[Innula Zenovka]

I don't quite understand the circumstances in which you want to give the items to the user rather than to temp attach them.    As far as I remember, there's no range limit for temp attach, so you should be able to rez them from a server anywhere on the region, send the rezzed item the avatar's uuid, and it will attach to them so long as they are somewhere on the region..   I certainly made something a couple of years ago that sits on a platform a couple of thousand metres up in the air and temp attaches stuff to players, and I think that's how it works (can't remember now, and can't come in to check).

Alternatively, you could rez the object, send it the target av's UUID, and then have the object get the av's position with llGetObjectDetails, then move nearer to the av using llSetRegionPos and then attach when it gets there.   But I don't think that's going to be necessary.

If I've misunderstood, and you are giving the items for some other reason, then it's easy enough to make them unusable after they've been worn once.    I can suggest a few methods if you need them, so please ask again if you do.

[Slang Heron]

Hey Innula, Thanks for your reply.

I was thinking just now and realised I'd been over thinking this in terms of the llGiveInventory, I can use a server for llGiveInventory as it isn't subject to the Object Rez limits.

The llGiveInventory i use for things like weed joints, a player can use the product table to roll them, Papers + Grams = Joints.

The RezObject i use for temp things like drinks and food. The reason I wanted this type of item to rez where the player is located,  is purely for aesthetic reasons, ie a drink rezzing on the bar when bought from a cash register.

Your suggestion might actually be my solution in terms of rezzing at a server and moving to the required location, as this would definitely allow me to give players the product makers with only the script inside, not the actual products. 

Thanks for your help 

 

 

 

 

[Innula Zenovka]

Thanka, @Slang Heron  It shouldn't be too difficult to have the server or the rezzed object decide where the object should move to, so as to appear on the table in front of the avatar before attaching.

The alternative, using llGiveInventory,  would be to use this sort of schema:

float fLifetime = 60.0;//how long to remain attached
integer used = FALSE;
list lUnusableParams;//e.g. set it invisible, size <0.01,0.01,0.01>
list lUsableParams;//set it visible and the correct size
default {
	state_entry() {
		llSetLinkPrimitiveParamsFast(LINK_THIS, lUnusableParams);
		if(used){
			if(llGetAttached()){
				if(llGetPermissions() & PERMISSION_ATTACH){
					llDetachFromAvatar();
				}
				else{
					llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
				}
			}
		}
	}
	on_rez(integer start_param) {
		if(used){
			if(llGetAttached()){
				llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
			}
			else{
				llDie();
			}
		}
	}

	attach(key id) {
		if(id){
			if(used){
				llRequestPermissions(id, PERMISSION_ATTACH);
			}
			else{
				state worn;
			}
		}
	}

	run_time_permissions(integer perm) {
		if(perm & PERMISSION_ATTACH){
			llDetachFromAvatar();
		}
	}
}


state worn{

	state_entry() {
		used = TRUE;
		llSetLinkPrimitiveParamsFast(LINK_THIS, lUsableParams);
		llSetTimerEvent(fLifetime);
		//do stuff
	}

	//[..stuff]

	timer() {
		llSetTimerEvent(0.0);
		llSetLinkPrimitiveParamsFast(LINK_THIS, lUnusableParams);
		state default;
	}
}

So long as you make the object no-mod (so the script can't be reset) and the script itself copyable (so even if you pull it out of the object, a copy remains inside the object) that should make it pretty difficult to use it more than once, I think.

But I think rezzing it and temp attaching it is the way to go, if it's at all possible.

Edited January 19, 2018 by Innula Zenovka

[Slang Heron]

Thanks again Innula, Especially for taking the time to write that out.