Script Practice

[Rolig Loon]

The default value for a float is 0.0

[Wulfie Reanimator]

40 minutes ago, NikosTheWizard said:

Oh, thats neat! Question though, the gHoldTime float, has no starting value, yet its used before its set. Is there like a default float value it uses?

In LSL, all variables are implicitly given a default value when they're declared.

integer  = 0
float    = 0.0
vector   = <0,0,0>
rotation = <0,0,0,1>
string   = ""
key      = "00000000-0000-0000-0000-000000000000"
list     = []

 

Edited August 2, 2017 by Wulfie Reanimator

[NikosTheWizard]

I imagined so, thx

PS: I figured the HTTP part, but unless i learn how to make a site to store data it's mostly usefull to transfer data from 1 object to another

Edited August 2, 2017 by NikosTheWizard

[Rolig Loon]

17 minutes ago, NikosTheWizard said:

it's mostly usefull to transfer data from 1 object to another

Or to trigger a remote operation like, for example, a vendor managed by the server object.  And you can store data in volatile storage in a script in any object.  Permanent, non-volatile storage is more of a challenge.  Unless you are dealing with trivial amounts of data that you can store in prim properties, the classical solution is to send it off world to an external server.  If you have an Experience to work with, however, you can store data in KVP.

[NikosTheWizard]

17 hours ago, Rolig Loon said:

Or to trigger a remote operation like, for example, a vendor managed by the server object.  And you can store data in volatile storage in a script in any object. 

Oh hang on, correct me if i'm wrong. Doing so will store data for a while, not permantly right? I mean if i transfer data to another object, when the data storage prim's sim restarts, it will all be gone, right?

[Rolig Loon]

4 hours ago, NikosTheWizard said:

Oh hang on, correct me if i'm wrong. Doing so will store data for a while, not permantly right? I mean if i transfer data to another object, when the data storage prim's sim restarts, it will all be gone, right?

Right.  That's why I identified it as volatile storage, and why I outlined other options.  It is possible to store small amounts of data in prim properties (in a prim's Description field, for example, or encoded in its color vector), for example.  As I said before, the classical solution for dealing with larger amounts of data is to send them to an external server.  These days, you could use KVP instead, keeping the data in Linden Lab's own servers instead of sending them off world.  Doing that would mean using an Experience, of course, and is only possible if your scripts are running in regions where that Experience is enabled.

[NikosTheWizard]

Interesting.. I'm planing to build like an arcade with some friends, and i want to store values for each player's "tickets". I'll do some further research thx

[Rolig Loon]

In that case, if you own the land and are a Premium member (or if the landowner is a Premium member), you could enable an Experience there and use KVP to store all of your ticket info.  It's simple and straightforward.  Start your research with 

 

[Qie Niangao]

27 minutes ago, Rolig Loon said:

4 hours ago, NikosTheWizard said:

Oh hang on, correct me if i'm wrong. Doing so will store data for a while, not permantly right? I mean if i transfer data to another object, when the data storage prim's sim restarts, it will all be gone, right?

Right.  That's why I identified it as volatile storage, and why I outlined other options.  It is possible to store small amounts of data in prim properties (in a prim's Description field, for example, or encoded in its color vector), for example.  As I said before, the classical solution for dealing with larger amounts of data is to send them to an external server.  These days, you could use KVP instead, keeping the data in Linden Lab's own servers instead of sending them off world.  Doing that would mean using an Experience, of course, and is only possible if your scripts are running in regions where that Experience is enabled.

Experience-based KVP is absolutely the right way to go here, assuming the parcel on which the scripted object resides can always enable the Experience.

Just a possible confusion here: It appears Nikos was asking about volatility of script memory upon sim restart, which is not really a common problem. (It may have happened before in SL history -- nothing new under the sun, etc. -- but it's not at all a normal occurrence.) Script memory is, however, totally volatile when the script itself is reset, which is what has motivated scripters to find any shred of state memory that does survive such resets. Experience-based persistent KVP is by far the best form (unless you need to do complex queries that demand an external relational or nosql database).

[EDIT: Oh, there was also discussion of inter-object HTTP, which is another can of worms because a script's URL is ephemeral, changing every sim restart. I'm still reading the "data storage prim" question to be about what happens to the script's internal memory, which should survive sim restart, but unless special measures are taken to re-establish addressing, HTTP-communicating objects will lose connectivity upon sim restart.]

Edited August 3, 2017 by Qie Niangao

[Rolig Loon]

26 minutes ago, Qie Niangao said:

Just a possible confusion here: It appears Nikos was asking about volatility of script memory upon sim restart

Yes.  Thank you, I misread that, since the common concern is about what happens when the script restarts.  A sim restart should not normally affect script memory (although anything is possible in SL.... )

28 minutes ago, Qie Niangao said:

[EDIT: Oh, there was also discussion of inter-object HTTP, which is another can of worms because a script's URL is ephemeral, changing every sim restart. I'm still reading the "data storage prim" question to be about what happens to the script's internal memory, which should survive sim restart, but unless special measures are taken to re-establish addressing, HTTP-communicating objects will lose connectivity upon sim restart.]

That's a good point.  There is a way to get around that problem, but only if your communicating scripts are all on regions that have the same Experience enabled.  If that's the case, you can store the server's URL in KVP, updating it automatically if the server script is reset.  Then you simply tell a remote script to check KVP before sending a message by HTTP.  You could run a server as a product vendor, for example, receiving orders with HTTP messages and delivering the product by llGiveInventory, using KVP as your backup system for keeping the server's URL current and for maintaining customer records.

[NikosTheWizard]

Ugh so, i've got a very basic idea of experiences. Since i'm still having trouble i want to ask, is there a way to test some scripts on a land not-owned by me?
Is there such thing? I know there are sandboxes, but what about a sandbox that allows usage of experiences?

[Rolig Loon]

12 minutes ago, NikosTheWizard said:

what about a sandbox that allows usage of experiences?

No, that's not possible, if you think about it a bit.  You can't set up land for "Experiences" generically.  You have to enable specific Experiences on the land. As that KB article explains, the landowner must be a Premium member and must be the one to set up the Experience.  Once that's done, s/he can invite anyone in the group to the special role of Experience Contributor --  that is, a scripter with authority to create scripts that are set to that Experience.

[NikosTheWizard]

1 hour ago, Rolig Loon said:

No, that's not possible, if you think about it a bit.  You can't set up land for "Experiences" generically.  You have to enable specific Experiences on the land. As that KB article explains, the landowner must be a Premium member and must be the one to set up the Experience.  Once that's done, s/he can invite anyone in the group to the special role of Experience Contributor --  that is, a scripter with authority to create scripts that are set to that Experience.

Ah... So for me, a non-premium user, the only way to test my experience script is to rent the land for the "Arcade" and then try it out. Anyhow i guess i'll just look further into experiences to be ready when i can actually try them. Thx

[Rolig Loon]

Renting won't do it.  You have to own it, or you have to be working for the owner, who is a Premium member and has set up an Experience there.  I'm non-Premium too, so I work as an Experience Contributor and I script for someone else.

Edited August 3, 2017 by Rolig Loon

[Wulfie Reanimator]

If you're just looking to do the arcade for fun rather than some serious business, you could simply make a HUD or something that stores the data about tickets and whatnot. The same HUD could work as a relay to any of the machines in the arcade, checking how many tickets are left and handling transactions.

As long as the scripts in the HUD are not reset, it'll be fine.

Edited August 4, 2017 by Wulfie Reanimator

[Ruthven Ravenhurst]

5 hours ago, Rolig Loon said:

Renting won't do it.  You have to own it, or you have to be working for the owner, who is a Premium member and has set up an Experience there.  I'm non-Premium too, so I work as an Experience Contributor and I script for someone else.

I think she meant rent in the "I take ownership of the parcel, but pay rent on it" sense. I have a parcel that I "own" that i rent from Azure, and can enable my experience on it

[NikosTheWizard]

5 hours ago, Wulfie Reanimator said:

If you're just looking to do the arcade for fun rather than some serious business, you could simply make a HUD or something that stores the data about tickets and whatnot. The same HUD could work as a relay to any of the machines in the arcade, checking how many tickets are left and handling transactions.

As long as the scripts in the HUD are not reset, it'll be fine.

Script HUD... Haven't thought of that! Although i'd like to make the arcade to make some profit (nothing too much) however my idea is that anyone could play a game by paying lets say 1L$, and depending on their performance on the game, they'd win some tickets. Those tickets would be stored and the player could exchange them for an item later on.
I have thought of something else too, but i wanna ask:

Since its possible to utilize one item's description, is it possible to get data and/or change one item's description from within the Agent's inventory?
My idea is that every new-player who joined the arcade would get an empty object called "Tickets" with the description of "0". Everytime they won, the description would change, and i could store the amount of tickets they have there! Is this possible?

[Wulfie Reanimator]

3 hours ago, NikosTheWizard said:

Script HUD... Haven't thought of that! Although i'd like to make the arcade to make some profit (nothing too much) however my idea is that anyone could play a game by paying lets say 1L$, and depending on their performance on the game, they'd win some tickets. Those tickets would be stored and the player could exchange them for an item later on.
I have thought of something else too, but i wanna ask:

Since its possible to utilize one item's description, is it possible to get data and/or change one item's description from within the Agent's inventory?
My idea is that every new-player who joined the arcade would get an empty object called "Tickets" with the description of "0". Everytime they won, the description would change, and i could store the amount of tickets they have there! Is this possible?

Scripts have no access whatsoever to anything in a user's inventory. However you could just tell people that the HUD must be worn to get the tickets and change the HUD's own description, but there is a small problem with permissions. You would need to make the HUD no-modify and no-copy.

If it can be modified, the user can obviously change the amount of tickets they have.
If it can be copied, the user can earn lots of tickets and make infinite copies of the object, gaining infinite tickets.
This leaves the transfer permission, which you can't also disable, since you can't disable all permissions on an object.
Since users would be able to trade their HUDs (with tickets), it's possible someone might try to profit from selling tickets directly.

These are the kind of things you'll have to keep in mind while trying to design any kind of system, LSL on its own isn't exactly secure unless you get really clever. c:

 

Also, to me it sounds like you're getting really excited about scripting and that's awesome, but trying to script an entire arcade is a pretty big and complex project. You can easily take too big of a bite and choke on it (or burn yourself out due to constant headaches and getting stuck).

I would suggest you focus on smaller things, like trying to just script a simplified version of the ticket system that allows you to gain/spend tickets through a second object that doesn't do anything but give/take tickets.

Edited August 4, 2017 by Wulfie Reanimator

[Rolig Loon]

As Wulfie says, the permissions system makes it extremely difficult to make a foolproof ticket system without using Experiences.  There are certainly vendor and rental systems in wide use that have leaped most of the hurdles, but they have been developed over quite a while and have all sorts of redundant systems that I would hesitate to start rewriting from the ground up. If you're interested in some approaches, you might look into scripts that some merchants use for gift cards.

[NikosTheWizard]

Pitty. I guess i'l stick to the HUD, will do some testing.
By the way, i know making a good arcade is... well impossible for my level of experience, but i have set a few small goals. Slow and steady wins the race
Anyhow for now i believe i'm covered, i'll do some practise on my own, thanks again everyone

Edited August 4, 2017 by NikosTheWizard

[Berksey]

Nooooooo~! Don't stop!

I was waiting for you to come up with a HUD that lets us bop annoying users on the head through their monitors!

You learned so much so fast, I really had my hopes up this time... <-<;

I thought you were gonna be the one to do it... >->;

Oh, well...

Edited August 11, 2017 by Berksey

[Ivanova Shostakovich]

   Oh, he won't stop. He's hooked. Scripting fever has him by the..... Well, it has him.