|
Youpee Uriza
Registered User
Join date: 18 Mar 2007
Posts: 14
|
04-09-2007 03:48
Hello All,
I am developing an ATM Tier payment system. The owner of the sim has several land. he will be placing the ATM is his sims.
What is needed is that the residents of the sim will go on the ATM and then pay tier there. The user can input any amount. If the amount is less than the tier, the whole amount is returned to the resident. If it is more than the tier, a remainder is returned to the resident.
I have already done all validations and check on the tier and updating a database. Am stuck on how the resident will pay and how the refund will work.
I know for refund we can do it thru llGiveMoney. But concerning the Permissionrequest, do I need to be online for it to work. How does it work?
Pls guide me on how to implement the 2.
|
|
ed44 Gupte
Explorer (Retired)
Join date: 7 Oct 2005
Posts: 638
|
04-09-2007 05:23
If your objects gives refunds and change, your pbject's owner needs to give it debit permission. That will work fine; even while the owner is offline, his/her money is online. So you'd better not have any bugs in your code.
There are rental signs available that will accept pi parcel tier and track how much time the tenant has left, both free ones and paid ones. Just search the classifieds.
|
|
2fast4u Nabob
SL-ice.net
Join date: 28 Dec 2005
Posts: 542
|
04-09-2007 06:32
I agree with ed44 -- I worked on y own rental system for quite a while and ended up buying one instead. The price I paid was *tiny* compared to how much time it would have taken me to implement many features.
Moreover, now I don't have to worry about updating and maintining the rental system's code -- one less thing to take care of.
-2fast
|
|
Youpee Uriza
Registered User
Join date: 18 Mar 2007
Posts: 14
|
04-10-2007 05:00
Hi,
thanks for reply. I have managed to do the system. it is up and running.
I have another question concernign ATM system. Suppose the owner has many sims and he will be placing the ATM in all his sims. And after some months, we have to do an update in the scripts of the ATM. this will a very tedious job to go on each ATM and change the script.
Is there a way to have a centralised script system where all ATM talk to the central one. Pls advise.
|
|
ed44 Gupte
Explorer (Retired)
Join date: 7 Oct 2005
Posts: 638
|
04-10-2007 06:29
One problem with updating scripts is that they would lose their settings, unless you are implementing some sort of persistent storage. I presume your atm's remind ppl how many days left they have on their leases, etc?
|
|
2fast4u Nabob
SL-ice.net
Join date: 28 Dec 2005
Posts: 542
|
04-10-2007 06:37
The most common way to get objects located in different sims to talk to oneanother is using email. The llEmail method sends messages and the llGetNextEmail method checks for messages.
A typical approach is to use llSetTimerEvent along with the timer() event to periodically check for new email.
The recipient's email address is [key]@lsl.secondlife.com and the sender's email address is [key@lsl.secondlife.com as well.
The sender needs to know the key (asset ID) of the reciever. There are various means of distributing keys of senders and receivers -- the simplest is to store keys in a notecard that gets distributed to receivers, senders, or both. You can get the key of an object by calling llGetKey from a script in the object that you want to find the key.
Another way of determining the key of an object is to call llSensor, specifiying the name of the object name and using llDetectedKey to get the key.
Note that an object's key changes when you take it into inventory and rez it again.
Since it is so easy to determine the key of any given object, it is possible for someone to send email to an object to get it to do something (like think it was paid rent). Of course, the attacker needs to know what message to send to the object; however, most implementations are straight-forward and some testing can reveal how an object behaves based on a given message.
The coutnermeasure is simple: senders and receivers use a shared password to authenticate eachother and could go to the next level by confirming eachother's keys.
-2fast
|