Network Adboard Script Needed

[Jewel Laurasia]

Looking for a script set where I can have a master board in SL with pics and LM giver, and give copies of the adboard out that will update when I update the master. This would mainly be an events board. Any help would be greatly appreciated.

[Freya Mokusei]

You want this forum: Wanted.

This board is for people who need help writing their own LSL scripts.

[Yingzi Xue]

If the people you plan on giving the ad board to are going to be in a different region than the master, you're going to need an external server to transmit data back and forth between the master and the slaves.  Even if you get someone to write you the script, this would require that someone somewhere has a dedicated external server that would perform the tasks you need on an ongoing basis.  Not only would you be paying for the initial script development, but there will likely be additional costs involved for the use of the server involved, or a larger upfront cost to cover server usage.

As per above, this goes in the Wanted or Inworld Employment forums.

[Sassy Romano]

An external server is not required for this. It can be done without that.

[Yingzi Xue]

How would you handle inter-region communication across the grid?  The only in-world option I know of is llEmail between prims, which is unreliable...

 

• Due to the bug SVC-23 (present since 2005), objects may stop receiving emails completely until either the region is restarted or the object crosses a region boundary (resetting the script doesn't help). Emails sent may eventually be received after a restart/region-cross. Hence, don't rely on this function for reliable inter-region messaging.
• Due to the bug SVC-391 llEmail will silently fail (no mail will arrive) when non-ascii characters are present in the subject. However, non-ascii characters in the message body will be replaced by "?".

Both of these bug reports were closed a long time ago as "won't finish".  Some people have found success with llEmail.  I wouldn't trust it for any of my projects, as a reliable solution for inter-region communication.

llGiveInventory may be possible for avatars, but only works for objects in the same region.

XML-RPC is a solution which requires an external server/service (web site, etc.), but...

Important: XML-RPC requests often time-out due to the front-end server being overloaded. LL has continued to upgrade the server hardware periodically, but it has remained unreliable. LL developers have advised that the XML-RPC design isn't scalable (due to the single server bottle-neck) and that the service is "deprecated". They suggest using LSL HTTP as an alternative. If an XML-RPC request does time-out the script's remote_data event may or may not be triggered (and any script response is lost). See this blog entry for more about the future of XML-RPC.

The only thing you're left with is HTTP functions and an external solution, at the minimum a web space.  Reliability is something I won't skimp on.

[Sassy Romano]

Http can be done between inworld objects without needing an external interface. The only thing that needs maintaining is the url and there's no reason that llemail can't be used for that part.

 

As for reliability, it's relative. A payment and delivery system needs reliability, is it critical of an ad board is temporarily not up to date, if at all? That's up to the customer, I'm just saying, it doesn't have to have an external server for an ad board system.

[Indigo Mertel]

Jewell, if a full ready system is what you need I suggest you check Sasun Steinbeck's kiosk.net. I have used it for years with very good results: http://sasun.info/

[Yingzi Xue]

Yes, it's possible to do in-world as you described, especially if growth requirements are small.

However, the negatives of a completely in-world system should be pointed out:

 

• Keeping track of URL lists within SL by the very objects that have URL's can fail, possibly requiring yet another script/scripted object as backup to keep track of URL's independently or face complete loss of communication.
• Keeping track of URL's and texture keys vs memory.  The current week in events would be small, but what if the customer wants to configure six months or up to a year in advance?  Add in texture cycling and your memory requirements grow exponentially.
• The chance that llEmail will fail.
• Limited script memory for growth.
• Potential adverse impact on region memory usage.
• Events are time sensitive.  The last thing you want is to find out your ad board system failed and your potential customers didn't know the event was taking place.
• Having to reset or kick start a clunky in-world system repeatedly isn't good customer service and isn't indicative of a good product.

 

Granted, some of these are dependent on the needs of the customer for the ad board system, but all are good reasons to do the lionshare of the data storage externally, for efficiency, stability and expandability. 

Not saying it couldn't be done, because it can... but at what impact to the owner, users and the region(s) involved?  It all comes down to what the customer needs and what they're happy with, but as scripters we should be concerned about efficiency, for the sake of the grid.

Hopefully they find a solution that works, is efficient and grows with their needs.