Rezzing an object; by anything other than direct action?

[Domitan Redenblack]

I have a script that is recording Rezz time & date in a database. Is there anything other than dragging it from inventory into the world that can cause a Re-Rezz to happen?

It is Copy+Trans+NoMod, and is not meant to be rezzed by another object in world.

 

ty

 

 

[Darkie Minotaur]

The respective wki article shopuld cover the.

[Domitan Redenblack]

Thanks, Darkie.

Hmmmm.... If I want to remember the original (first) rez date & time, but I have an on_rez with resetScript, how can I do that?

Or should I not resetScript when on_rez ?

 

 

[Darkie Minotaur]

Just to make sure I got you right:

You got a reset script that reports to the db and then resets? Right?

[Void Singer]

if you want to remember the first rez date, the you either

... don't use reset in the script

... save the first date within a prim parameter

... save the first date externally

 

and be aware that even though you have a script that reports the rez time, it may not fire if the object is rezzed on no-script land, or on land where scripts are disabled.

[Domitan Redenblack]

Hmm... thanks Darkie and Void...

 

My default state has both a State_Entry, an On_Rez and a Changed handler... Do I need all in the default state?

 

default {        state_entry() {        //);        sAgentName = "error";        kQueryID = llGetNotecardLine("Agent", 0);    // request first line of notecard "Agent" = agent name    }    // When notecard read, first line is name of Agent for infoBoard placement    dataserver(key query_id, string data) {        if (query_id == kQueryID) {            if (data != EOF) {    // not at the end of the notecard                llOwnerSay("your Representative's Name is " + data);    // output the line                sAgentName = data;            }        }        //        // ownerName;Time, vendorName, rezzLocation        sRegionParcel = llGetRegionName() +             s_ + llList2String( llGetParcelDetails(llGetPos(), [PARCEL_DETAILS_NAME]), 0);        SLDB_PutData(             sRegionParcel + s_ + getSLdateAndTime(),             ["REZZ"],             ["REZZ" + s_ + objVersion + s_ + sAgentName + s_ +                 llKey2Name(llGetOwner()) + s_ + (string) llGetPos()], FALSE);        //        //            }        http_response(key id, integer status, list metadata, string body) {                // First, make sure this request is one of the ones used in this script (as opposed to one being called        // by another script in the same object).                if((id != kSLDB_put_id) && (id != kSLDB_get_id) && (id != kSLDB_del_id)) return;                if(status != 200) body = "ERROR: CANNOT CONNECT TO SERVER";                // And spit out the information we got.        llOwnerSay("SLDB setup: " + body);        //        llOwnerSay("Ready for use. To resize the vendor...\n(if not in use) "             + "type local chat '/237 size <number>' in meters (min 1.0, max 8.0)");    }    on_rez(integer rez) {        llResetScript();    }        changed(integer change) {        if ( change & CHANGED_OWNER ) {            llResetScript();        }    }    }

 

 

[Void Singer]

well I see some obvious problems in there...

instead of resetting, try adding this function line to the state_entry, on_rez, and changed owner sections..

uTryNotecard(){

    if (~llGetInventoryType( "Agent" )){

        kQueryID = llGetNotecardLine( "Agent", 0 );

    }else{

        llOwnerSay( "Required notecard 'Agent' not found, plaease add it to inventory" );

    }

}

and you'll also want to do something about it saying it's redy for use after getting a cannot connect to server message

[Domitan Redenblack]

Sorry, thoroughly confused now...

 

1. Does llResetScript( ) always cause state_entry to be run?

2. If so, do I need to read the Agent notecard anywhere but state_entry?

3. out of curiousity, does a "script reset" trigger on_rez?

4. In a no-mod object, can the new owner reset scripts? What should I do then?

5. the "Agent" notecard will always be there; this is a no-mod object. Do I still need to check and read after fixing items 1-3 above? Can the Agent notecard be deleted from a no-mod object?

6. do I really need anything other than state_entry? Is state_entry called each time the vendor is rezzed from inventory?

7. will changed be triggered if the new owner drags the vendor across a parcel boundary? Unlikely, but I think I need to handle that...

thanks!

 

[Void Singer]

1. Does

llResetScript

( ) always cause

state_entry

to be run?

if it is present in the defalt state, yes, otherwise the default state is entered

 

2. If so, do I need to read the Agent notecard anywhere but

state_entry

?

only if you reset... but that's kinda sloppy... you could have it only read once and never again, then you wouldn't need to check for changed or on_rez, alternatively, you could just check in one of those two events...

 

3. out of curiousity, does a "script reset" trigger

on_rez

?

no, it's the same behavior as if you had just compiled the script, all variables start fresh, all events are cleared, the default state is entered and state_entry fires if present for that state

 

4. In a no-mod object, can the new owner reset scripts? What should I do then?

there are ways that it can be done, or even happen because of borkage... do not rely on it for security... you best bet is to have the script try to go back to what it was doing normally, or be broken.

 

5. the "Agent" notecard will always be there; this is a no-mod object. Do I still need to check and read after fixing items 1-3 above? Can the Agent notecard be deleted from a no-mod object?

yes... there is a work around to prevent that, but it relies on a bug in jira that is very likely to be fixed.

 

6. do I really need anything other than

state_entry

? Is

state_entry

called each time the vendor is rezzed from inventory?

no, state entry is only run when the state is entered... right after compile, reset, or state change only.... on_rez is the event that fires on every rez.

 

7. will

changed

be triggered if the new owner drags the vendor across a parcel boundary? Unlikely, but I think I need to handle that...

CHANGED_REGION will fire in the changed event... if you only filter for other events, then you shouldn't have to worry about any other events... for instance

if (CHANGED_OWNER & vBitChg){

would only be trigged by the changed owner event

[Domitan Redenblack]

If I also do this in the default state, will it get triggered every day? ... (Something tells me I need a re-think of the Default state)...

 

    run_time_permissions(integer perm) { // Check for permission to debit owner                if (perm & PERMISSION_DEBIT) {             state ready_to_select;        } else {            state hold_for_permissions;        }     }    

 

 

[Void Singer]

why would you want to trigger a check for debit permissions every day?

instead, check before the object does anything....

if (llGetPermissions() & PERMISSION_DEBIT){
    //-- do stuff
}else{
    //-- report problem to payee and move to a different state
}

in that other state you could request debit permissions again whenever the owner took some action.

 

I assume this is some kind of affiliate vendor system? my suggestion would be for it to check that it can debit when it recieves payment from someone, if it can't, have it fire off two messages... one to you that says it's unable to request an item for delivery because the owner revoked debit permissions, and one to the person paying that says it can't retireve the item and is unable to refund their money because the owner revoked premissions. it should also tell them to contact the owner, or file a fraud report with LL.

ETA:
because debit permissions should NEVER go away unless there is an owner change, so fraud is highly likely... and this way A) if it was an accident, the owner can take care of it, and B) it makes it harder for the reseller to keep ripping you or customers off, and C) if it happens multiple times there's two people to file a fraud report for each instance of it happening, and very good odds that LL can suspend that account quickly.

[Domitan Redenblack]

Thanks, Void, but what if the Owner is not online? Not good to set that precedent for customers... and not be able to even tell them when the board will work. I have seen shops where the owner is not present except on weekends or worse, etc.

The amount in jeopardy here is only L$10 or L$20 at most, sort of like a tip jar.

1. I think instead, I will have the daily timer trigger a separate state which does only the database update, and NOT reset the script etc.  Resetting the script will have the effect of requesting debit permissions again and again if that request is in the default state, yes?

2. Debit permissions would be in the default state only, and so be triggered only when the Owner is present and moves the vendor from inventory to in-world, and so will be present, etc. Make sense?

3. Important Question: does Region Restart trigger a reset scripts or the default state?

 

 

[PeterCanessa Oh]

Why would you want to reset the script anyway?  It's good that we can but it's usually not needed.  Remember you can always switch to the default state (state default;) without also resettting all the permissions and variables.  I'm using quite a bit of HTTP-in at the moment and I need to make sure a reset is as unlikely as possible, otherwise the URLs change and nothing can talk to the server!

Your questions:

1.  Resetting the script will remove any existing permissions, so you'd NEED to ask again.

2.  Yes, that makes sense

3. No, the script should continue as if nothing happened - except for HTTP-in URLs, if you're using them, being invalidated and released (for which check CHANGED_REGION_START)

Edit: - bloody smilies!  Apparently a semi-colon followed by a close-parenthesis is a 'wink' (as above).  I must remember not to put properly punctuated LSL commands in parenthesis

[Void Singer]

by shutting it down the first time debit permissions disappear, it prevents further abouse of both you and other customer who might try to use it. the only way for an object to lose debit permissions at this time is for an owner to manually revoke those permissions, using one of the few viewers that will let you. which means they'd have been present when they did it. there is a vague chance that something could be screwed up by LL or it have been a mistake by the owner.

you don't have to automatically request permissions in on_rez, or default state_entry, you can simple wait for the owner to take an action like touching the object. it just sits and waits until then. that way it's a fail safe in case the script does get reset somehow, without the owner present... which shouldn't happen either, since only manual and scripted resets (from within the same object) should reset an active script. the only time a script should reset is when a script within the prim tells the script to, or the owner, or someone with edit rights for the owners things resets it...

 

ps,
I should have said 3 messages, because one shouldn't assume some disaster by LL didn't cause it... messages go to customer, owner, and wharehouser (that's you if it's a resale vendor, or you are getting a cut. otherwise, not needed)