Having a script/menu change information in another script

[Yurtiel]

I have been steadily learning new scripting methods in an attempt to make a HUD/meter system and have run into a problem I can't seem to find any information on.

 

What I require to happen is that I would set up an in sim server system where a user (In this case a specific group) can go into the "Server" side of the system and be able to dynamically change the stat set up of the HUD, it will then send this information out to all adjacent receiving items (In this case the HUD) and will change the information of the script inside the object to mirror the information that has been put in.

 My main question is how to make it so that the script in one object, can change the number information in another script and the script will remember the change (It would only be for number values, all other equations would be done by the HUD itself, but I want to set up a server side stat set up system.)

An added bonus of informational wealth if possible would also be how to use dialog boxes (Menus) to do this same thing but on a local scale.

 

Any help would be appreciated please.

[Ohjiro Watanabe]

A few ideas to try:

 

I would keep the data in a list. When I want to send it convet the list to csv so that it is in text format.

I would probably use llRegionSay to send the message on some negative channel.

The hud would listen on this channel and if they got a message convert it from csv to a list and do whatever with it.

There is no way to persist (save) data within secondlife so it is lost when the script is restarted. The only way you could do this (to the best of my knowledge) is to have an external web site. then you can send the data to the web site and it can save it using aspx or php or some such.

To send data to the server same kind of thing, use a different channel to avoid cross talk.

If you google "lsl prim to prim communication" you will find some example code.

 

 

 

[Qie Niangao]

Yeah, but I'm not sure which script is expected to remember the data and for how long. It may be that simply keeping it in the server script is good enough -- I mean, 99.999% of the time, such data persists through sim restarts, etc. (but not through script resets).

What's probably not going to work is to expect the HUDs to remember this dynamic state information all on their own. In particular, you need to handle the case where the values change while somebody isn't around wearing their HUD to get that new value, so I think instead the HUD, on_rez, sends a sim-wide query for the current settings and the server sends back what it remembers. So, yeah, that broadcast query to any server in the sim would use llRegionSay() on some obscure hugely negative channel, and the reply would use llRegionSayTo().  If the values can change while HUDs are rezzed on the sim (probably so), then that would be an llRegionSay() broadcast from the server to all HUDs.

(This gets way more challenging if the information needs to be shared across many distant sims.)

(Sorry, but I'm not understanding what's wanted with the "local scale" dialog boxes.)

[LepreKhaun]

---

Yurtiel wrote:

I have been steadily learning new scripting methods in an attempt to make a HUD/meter system and have run into a problem I can't seem to find any information on.

 

What I require to happen is that I would set up an in sim server system where a user (In this case a specific group) can go into the "Server" side of the system and be able to dynamically change the stat set up of the HUD, it will then send this information out to all adjacent receiving items (In this case the HUD) and will change the information of the script inside the object to mirror the information that has been put in.

 

 My main question is how to make it so that the script in one object, can change the number information in another script and the script will remember the change (It would only be for number values, all other equations would be done by the HUD itself, but I want to set up a server side stat set up system.)

 

An added bonus of informational wealth if possible would also be how to use dialog boxes (Menus) to do this same thing but on a local scale.

 

Any help would be appreciated please.

---

Greetings and welcome to the forums!

I don't know what scripting methods you've mastered to date but I can see that you're completely unfamiliar with this one, which is why you're having difficulty in finding what you need: You have yet to get to the point where you know what the questions are that need to be asked. Knowing the terminology of the subject will aid in finding the information, so we'll start there, as well as break everything needed down into manageable components.

What you've described is called a database which can be defined here as a permanent, organized collection of data that may be accessed by other program(s). On its simplest level, a database could consist of just a file that a number of programs know the location of and may range in sophistication up to a complex arrangement of relationships maintained within the data and accessed remotely by programs having various levels of permission.

Data, which you've called the "number information" is stored and organized in a database in what are called "records". These are typically "Name:Value" pairs basically and you'll not need much more than that, since the accessing programs (which are called "users" and, in your case, will be HUDs) will be doing any additional equations.

But that only covers the data itself, you also need to supply "methods" to access the data. A method is just computer-talk for an interface to the underlying data, giving not only access to it but allowing the other program(s) ways to manipulate that data as well in defined ways. These methods form the "database management system" (DBMS) and you'll need to learn what that's about to design and implement your own.

The DBMS supplies an interface, which is known as the "database API" and it will be this that your HUDs communicate with. Communication brings one into "protocols" and they get increasingly more complex with the distance. In other words, if your database and user(s) are all within one object in SL, link messages would be the protocol one would use. If they are in different objects but within the same region (sim) then the LSL chat protocol must be used and greater than that, internet protocols (e-mail or http) are required. And, as Qie pointed out, the most complex arrangement is having the database maintained outside of SL, on it's own web server, since now one would require not only mastery of everything else, but are required to master another domain as well, which entails learning (say) PHP, MySQL and server management.

While learning all this, you also need to implement an authorization scheme since some of your users will be what is called "administrators", those that have greater powers over the data than other users. And, since there's plurals involved in both users and administrators, you're going to have to implement a locking mechanism that avoids deadlock.

Fortunately, all of this has been done before and you'll find many algorithms to study. It's simply a matter of knowing what questions you need to ask for each step, which I hope this is a start for you. And, if all else fails, you can certainly ask in the Wanted or Inworld Employment forums for someone to do this for you.