Esquievel Easterwood

KarenMichelle Lane wrote: Esquievel, Your particular issue with the station you provided is it's encoding stream: ... Note that it is broadcasting a Content Type: audio/aacp - FMOD prefers Content Type: audio/mpeg The FMOD Library that SL uses can not decode this stream where as your native radio playing application such as WinAmp & VLC & iTunes have no issue decoding this stream Interesting. This URL used to work in SL, so they must have changed the encoding without changing the URL. Thanks for your help.

Thanks for replying. I realize I didn't explain that in the most straightforward possible way, so I'll try again: I can actually edit the streaming media device, go to the notecard that contains the music URLs, copy the URL out of the notecard, and paste it into Winamp, and it plays. I can paste the same exact URL into About Land>Music>Music URL, and it won't play. Typing it in manually makes no difference. If I type it into SL, it doesn't work. If I type it into Winamp, it does. Some months ago, this same URL DID work in SL. Now it STILL works in Winamp, but not in SL. Perhaps you can try it and let me know if it works differently for you. Here it is: http://66.225.205.5/ Thanks

As everybody knows, it's a struggle to keep in-world media devices loaded with streaming music URLs that actually work. Just lately I've come across a new (at least, new to me) permutation of this problem: I have streaming music URLs that work just fine in WinAmp but won't work in Firestorm in SL. Now, I have all of the preference settings correct. I can hear some music URLs just fine. However, I can take a URL that works in WinAmp, and manually drop it into the "Music URL" blank on the Sound tab in About Land, and it won't work. I hear nothing. The URL appears to be properly formatted. In at least once case, I can take a URL from a working SL "radio" device (that is, the radio still does play some URLs correctly, and where this URL used to work), and copy it into WinAmp, where it works, then copy into About Land>Music>Music URL, and it doesn't work. Has anyone seen this? Is there an explanation, or is my only option to once again comb the Shoutcast listings to find more working URLs. Thanks.

As everybody knows, it's a struggle to keep in-world media devices loaded with streaming music URLs that actually work. Just lately I've come across a new (at least, new to me) permutation of this problem: I have streaming music URLs that work just fine in WinAmp but won't work in Firestorm in SL. Now, I have all of the preference settings correct. I can hear some music URLs just fine. However, I can take a URL that works in WinAmp, and manually drop it into the "Music URL" blank on the Sound tab in About Land, and it won't work. I hear nothing. The URL appears to be properly formatted. In at least once case, I can take a URL from a working SL "radio" device (that is, the radio still does play some URLs correctly, and where this URL used to work), and copy it into WinAmp, where it works, then copy into About Land>Music>Music URL, and it doesn't work. Has anyone seen this? Is there an explanation, or is my only option to once again comb the Shoutcast listings to find more working URLs. Thanks.

Hm..well the way the spec is written for that function, it looks like it could be blocked by "object entry rules". I suppose I should test it and find out. *L*

"About the dance anywhere scripts: I never knew that; thanks. Long before that product came to market, I'd scripted a sim-wide "anim server" that does much the same thing, among other tricks. It's nowhere near user-friendly enough to be a product, but it doesn't care who tries to use it -- which would probably be a bad thing for a product. The point is, that must be a restriction imposed (with some extra scripting effort) for that product, not an inherent limitation on animation scripts." Right. As I understand it, the problem is that the main dance ball rezzes couples animation balls near itself, then moves them in a direct line to a location near the dance anywhere appliance that summoned them. The balls can't be moved through land not owned by the owner of the land where the balls were rezzed. I also understand that a new system, in which the local appliance rezzes the balls, is under development, but is not available yet. The solo dance appliance doesn't have this problem, as it doesn't require positioning balls to synch two dance partners.

"For a whole bunch of reasons, Mainland rentals are much easier for everybody if each parcel is owned by a different group. That's not practical for really huge operations, but at the scale of a single sim, unless these are tiny parcels, I think you and your tenants will be much happier if each parcel comes with its own group. Otherwise, there's really no happy compromise that gives them enough power over their own parcel contents without also being able to do very bad stuff to their neighbors." I never thought of that. I see one problem in my case though. I offer my tenants "dance anywhere" appliances (sold by a well-known club dance system vendor) that can access dances in a centralized set of dance balls. The tenants can place the appliances anywhere they want on their parcels. These appliances will work anywhere in the same sim where the main balls are, as long as the main balls and the appliances are on land that has the same owner, and as long as all of the land between the appliances and the main balls on a direct line of sight is owned by that owner. I discovered the limitations inherent in this system when I found that the Linden road that bisects my sim prevented the appliances on the other side of the road from the main balls from working. I had to buy another set of main balls and dances so I could have one on each side of the road. So having each parcel owned by a different group would blow this feature out of the water. Still, I'm curious. Can I assume that the "group land tier advantage" would work the same way if I had a dozen or more groups owning the land? I'm referring to the benefit conferred by donating land to the land group, which enables me to own a greater amount of square meterage before hitting a higher tier level. Would I get the same amount of square meterage benefit if I divide up the donated land among several groups that I get from donating it all to one group?

Thank you for your responses. I realize you're helping me and you aren't a Linden. Your information has shown me how I can prevent the worst part of the situation I described, and that's very good. I have some responses, some for general discussion, and some further questions. They are in-line, below: "1. None of the permissions I've granted refers specifically to the Auto-return feature on land parcels. Why is anyone other than me, the land owner, able to turn on Auto-return for any group-owned parcel? Because you allow them to toggle options in about land" I am a computer programmer by trade. In the computer programming world, there are implementation bugs and design bugs. An implementation bug is when the specifications for a feature are implemented incorrectly so the feature does not work as designed. A design bug is when the specifications for a feature, when implemented, cause unnecessary problems for the user. The specific permission I've granted is: Parcel Settings Toggle various About Land > Options settings "Options" is not a generic term; it's a specific tab in the About Land dialog. The Auto-return feature is not on the "Options" tab, it's on the "Objects" tab. Therefore, I expect a permission called "Toggle various About Land > Options settings" to only allow people to toggle options actually on the "Options" tab. It should not confer rights to change settings on the "Objects" tab. While I concede that the system may work the way you've described, I do not believe that the interface is designed properly. Either the permission should be called "Toggle various About Land settings", leaving out ">Options", or the permission should only affect things on the Options tab. I'm also not sure that this is not an implementation bug. Programmers understand standard notation like ""About Land > Options settings" to mean "Settings on the Options tab of the About Land dialog". If presented with such text in a specification document, a competent programmer would have limited the effect of that permission to items on the Options tab. "If the objects are on group owned land they must be either set to the group or owned by the group., otherwise they are returned, This includes your objtects. If the land is group owned you are not the owner, the group is. While you may own the group there is a difference." I suppose it is easy enough to set all of my objects to my group, I have to say that I think this is a design bug because it is unnecessarily cumbersome. I concede that group land is different in this respect, but it doesn't need to be different. The difference confers no benefit, and it needlessly complicates the situation, leading to problems like mine. Regardless of whether the land is group land or single-owner land, auto-return should not return objects belonging to people who have explicit permission to create objects on the land. It really should be as simple as that. It should never return objects owned by people who either own the land, own the group that owns the land, or are members of the group that owns the land. (It could also be programmed not to return objects "set" to the group that owns the land. I'm not sure what additional benefit this would provide, since you can't set an object to a group unless you are a member of the group and have permission to do so.) But since SL knows who owns the objects, and it knows who is in the group that owns the land, it should not be necessary to set each object to the group to prevent it from being returned. "3, The three "Return objects" permissions I've granted to ordinary group members should reliably enable them to return any single object on group land. Why can't they return such objects? They should be able to. File a support ticket about this." They should be able to? Does it work this way for other people? That is, is this a problem only happening with my group/land, or is this an implementation bug? If it's a bug, filing a support ticket will do no good; it would need to be filed as a JIRA issue. Thanks again for your help.

I "own" an entire Mainland sim. I have it divided into several rentable parcels surrounded by what I call "public" land. All of the rentable parcels, and most of the public land, are deeded to my land group. When people rent from me, they get a tag for the land group. The land group grants them the following permissions related to objects: Parcel Settings Toggle various About Land > Options settings Parcel Powers Always allow "Create Objects" Parcel Content Return objects owned by group Return objects set to group Return non-group objects Object Management Deed objects to group Manipulate (move, copy, modify) group-owned objects Here's the problem: Group members are unable to return objects reliably or appropriately. For example, if any random SL citizen loses their vehicle on the nearby Linden road and it ends up on a group-owned parcel, my group members can't return it. Or if I rez an object on group land, my members can't manually return it to me. However, somebody can turn on Auto-return in About Land>Objects on a group-owned parcel, and cause all of my landscaping objects to be returned to me. Although nobody will admit to it, this is apparently what happened when a vehicle crashed on group land a couple days ago. A tenant tried to return it, could not, got another tenant to help her, and somehow Auto-return got turned on for the public land on which the vehicle landed. Voila! crashed vehicle disappeared--as did nearly 100 carefully-laid-out landscaping objects that took me over 4 hours to reset. My objects were not deeded to the group or even "set to group", and some of them were locked (and remained locked after being returned; when I rezzed them they were still locked). So I have several questions: 1. None of the permissions I've granted refers specifically to the Auto-return feature on land parcels. Why is anyone other than me, the land owner, able to turn on Auto-return for any group-owned parcel? 2. Auto-return is only supposed to return objects not owned by the land owner or by members of the group that owns the land, right? I own the land and I'm the sole owner of the group to which the land is deeded. So why does Auto-return return all of my objects? 3, The three "Return objects" permissions I've granted to ordinary group members should reliably enable them to return any single object on group land. Why can't they return such objects? 4. If these things are not bugs, how do I set my land permissions so tenants can manually return any single item to its owner, but cannot turn on auto-return? I can't really test proposed solutions; I don't have tenants available to help me, and I don't want to accidentally have all of my landscaping returned to me again as a result of a failed test. So suggestions that I "try" this or that won't help me. If anyone can provide a clearly definitive explanation of what's going on though, I would greatly appreciate it. Thanks in advance.

Thanks everybody. My script would only offer the invitation to pre-approved avatars listed on a notecard. The idea was to set up an object that my tenants could use to rejoin my land group when they accidentally delete their tags, or so people who want to rent from me but live in a distant time zone could pick up a tag on their own (I just had an experience where I sent three invitations to a new tenant but she never got them due to IMs being capped while they were offline). I can't have SL running 24-7 just to support a bot. I don't really see any security issue here if you set up the script to only offer tags to pre-approved people. Oh well. Thanks again.

I've been trying to get a group inviter script to work correctly. I've looked at several of them. They all come down to a line like this: llSay(0, "/me by clicking this link\nsecondlife:///app/group/" + ((string)group_key) + "/about"); Unfortunately, clicking that link does not offer a group invitation. It just displays the General tab of the Group Information dialog. There is no option to join the group there. I'm testing this in Phoenix 1.6.1.1691 I need an actual group invitation script that issues an actual group invitation. What am I missing here? Thanks!