Open Source Box Office Released to SL!

You know Kim and Perse, I know you don't want to see this thread derailed but I want to see Jonas explain himself. You see, we are all supposed to put on these events for love. Pay the DJ's out of our own pocket.... err wait a minute. You mean the DJs aren't expected to work for love? How about the live musicians? They charge a pretty penny. Are they expected to work for love? Why aren't you railing at them?

I mean, we are only trying to figure out a way to actually do this. Money to pay DJs and musicians and hosts has to come from SOMEWHERE. Where should it come from if not from those actually coming to see the show? Do you think money falls on us from the sky? Why is it only the event venue managers that you rag on? Why not everyone else? Why not rag on Yumi when she says that scripters should be paid? They should do it for love too? Right? oh and clothing manufacturers? And well, all content manufacturers actually. You do buy things occassionally right? Why shouldn't they do it for love too?

And to answer your gripe about rich content, sex clubs don't need the FFRC. They already charge.

Last but not least, you show up in our sim to talk to Perse face to face you can talk to Etain and myself first.

Sorry for the late reply, the thread posting notification was very late in coming.

Re: the sensors... Yes, I know they're not the best, but it is open source and that can be changed.

Re: my contest entry... Look, I wasn't expecting to win it any more than the next guy, I put together a feature rich box office more for the challenge and learning experience, I didn't ask to win, if you feel that strongly about the quality of the winning product, you really should have entered yourself. There is no possible way that a winning entry could win over the hearts of every scripter out there, and every one would have faced the same level of criticism. If you're upset that you didn't win the contest, that's on you, man, for not even trying.

I fully support the FFRC in their endeavors, I believe they are an incredible organization with a great cause.

I really do welcome the criticism, as it only points out areas for me to improve and create better scripts that avoid public outcries of unfairness.

Please, don't get me wrong here. I'm having trouble expressing myself here, because the thing is, I also agree with the goals of the FFRC and think it's a great group. I also wouldn't say that the winning script is "disappointing" - it's actually well done.

The only issue I have is with the wording of the contest terms - that is, what script was expected. As I say, the high value of the prize, together with the "clever hacks" comment, suggested that something revolutionary and/or fully perfected was required, which may have put some folks off.

I'm sure there's some kind of formula that could be used for covering an area in detection reliably - it sounds like the sort of thing that ought to be an established problem somewhere...

Probably, Yumi, I may think something is clever more easily than you. =D By hacks, I meant simply working around the system as it exists in SL. That thread was in response to one particular scripter's assertion that the entire box office was impossible. Yet, it exists. So, in that particular light, it is a hack we needed: a solution to the charge that the entire thing would necessarily be impossible given the limitations of SL.

In my book, Peter (and all of the entrants, actually) met the clever hacks definition because they made workable what one scripter suggested was impossible.

To my friends, Eta and Vivianne, thanks for speaking up for me. I didn't even know you read the forums, Etain! lol. Sounds like many folks are operating on the same page now, anyway. I do appreciate your concern and your willingness to share how big of a project this was for us in terms of how it impacted me specifically.

I'm sure friends of the entrants would be able to share similar stories of inviting them to do stuff and being told "sorry, busy working on the box office script." It is truly appreciated by many, not all of whom read the forums or will post here. Thanks Leonard and Peter for jumping in and helping answer questions folks had. Also thanks, Gabe, for your committment to this project. Gabe put in money out of pocket for the prize, and also is now offering to pay out of pocket for anyone who doesn't feel the product did what we had hoped it would. I wouldn't expect anyone to take Gabe up on his offer, however, as the open source box office Peter created (with support of Leonard who significantly impacted the improved version) is pretty much exactly what I had hoped for as the end result. It meets requirements, it is configurable, and it goes a very long way toward making box offices that will effectively serve the main needs of event hosts and venue owners. I just want to say that a lot of people made a big committment to this project and it's very appreciated. Cheers folks!

Its a bad habit I'm picking up... Generally I've found one's enjoyment of a game is inversely proportional to the amount of time spent on the forums dedicated to said game. Call that Etain's Law of Boards Suck if you want.

In response to Yumi's feedback, I have made a few changes to the box office and updated the copy on the FFRC land.

I made the following changes:

1) Sensors no longer take off immediately, such that they can be edited as needed.
2) Sensor routes can be relative to the current position, so the owner does not have to set up specific coordinates, instead can tell it to go 10 meters one way, 10 another, and come back.
3) Event "program" notecard can now be specified in the event setup card.

Any other feedback is welcome and appreciated.

Taking into account more of Yumi's feedback, I've additionally changed the box office to only listen for the sensor itself to prevent the griefer attack in question, and also moved the SENSOR SETUP card to the main box office, for even easier access.

Thanks, Peter, for your willingness to go above and beyond. Also, thanks to Yumi and to Leonard for helping give feedback that helped Peter to accomplish that.

Hats off to you folks.

Ditto x eleventy billion.

I just checked out the box office script (the source code).

Overall, it looks totally ok, so any of my following comments should be taken more lke ideas (and personal preference) than criticisms!!!

1. There's a date in the header, but I'd also like to see a version number somewhere in the script, maybe in a 'constant', like 'string VERSION = "1.0.0";'. This version could also be said outloud when the script is started up. This helps diagnosing potential problems -- if someone is having problems, you can ask them to check the version, and then tell them to use the newer version which have fixed this bug.
   
2. Variable naming is very understandable and well done!
   
3. buildTimeString and compareTime: I don't exactly see why this is constructing a string (like 05:50:00) and comparing it. Well, I see that gEventStartTime is loaded from the config, and is the same format, so maybe that's why. Still, it might work faster if you just had time as an integer, and kept comparing that. (Like integer intTime = hours * 3600 + minutes * 60 + seconds). Again, this might be just my personal preference, but it might be faster, too. And you can do compares with (intTime1 < intTime2)
   
4. I would've wanted to see more functions, though I know this is also a tradeoff -- the more code you have, the less memory it remains for the running script
   
5. In the event setup routine, 'llList2String(tmp,0)' is being ran many times, in fact, one would be enough (if the result would be stored in a temp string).
   
6. In the 'listen' routine of the running state, processing of the case 'if (channel == 1)' runs onto the gCurrentlyOn part... so anything the hosts chats, the script hears, and processes as if it was a 'currently on' list.
   
7. Have there been any memory usage tests? How many people can this script support before memory gets too low? -- This might not be a problem, though, but worth testing, to see.
   
8. Each person who doesn't get warned, gets a 'record' in the memory. What happens if a group of 30-40 ppl. come (one after another), and each leave in a few minutes? I think they'll still end up in the gWarnedList, which might grow to an unmanagable size, then the script might crash (and anyone can come and stay then without being ejected
   
9. Running state: until the event starts, the script check the time every second: 'llSetTimerEvent(1);' I think this should be 15 or 30 seconds (or even 60 seconds or even a calculated delay), so it puts less load on the server. 1 second timer is too too too much in this case
   
10. I liked the 'token' usage in the messages, nice idea!
    
11. I would also like to see some more validation, error checking: for example, if the 'gift for payment' is specified, the script could check if such gift exists in the inventory, on startup!
    

Again, these are mostly ideas for improvement, your script absolutely does the job (it wouldn't have won if it didn't

BTW, how are versions maintained and patches incorporated?

Peter has been working steadily on this product for us. He agreed to provide service for the script for a month which has been awesome and we did some demonstrating tonight that yielded in more information about how the script behaves. Gonna do another test run this weekend and see if we can find any more bugs. It's kinda fun! Making me think I should try out preview grids sometime. hehe.

In any case, it's quite exciting to see as Peter takes on the daunting task of building on what was already a very useful script. We learned important stuff tonight. Come to the tail end of the FFRC meeting on Sunday if you want to be involved in more bug testing.

Are you aware the the main purpose of the Foundation For Rich Content is to provide funding for events? That we have given away thousands and thousands of Lindens to event hosts, for events ranging from art exhibitions to live music to game shows to sailboat races.

You are totally clueless about Persephone Phoenix--but she can address that. The Foundation for Rich Content only defines "rich content" insofar as what we vote to fund (and to date, we've funded all applications that have come to us). Any other group or individual in SL is welcome to define "rich content" in any way they choose--and to support such content. The more people doing this the better for all of us.

Though I disagree with many of Yumi's points regarding the running of the FFRC Box Office competition, that last sentance isn't fair to her. Yumi does do her part for providing interesting content to SL. She hosts NCI's Euro-Time New Player Show & Tell every week. I know she also runs classes and events on her own, too.

Thanks, Carl. I should add that I've felt very uncomfortable on this thread, running the risk of offending an organisation that a) I agree with, and b) that's given a newbie a big break!

It's pretty plain that's all that's happened here was a misunderstanding with the specification, which is not exactly uncommon with scripting anyway

On that note, if Peter is around here - just a thought about the updated script: it might be a good idea to have a LIST of all the rezzed sensors, and then have the listener listen for everything on the sensor channel but ignore anything that's not on the list. The reason being that - lag being what it is - it's possible that the sensor might take so long to finish its journey that the next sensor has been rezzed before it returns. (The user might have configured it with 10 or so waypoints and a 1 second scan interval, ouch! )

That's a very good point on the sensors Yumi. Thanks again for the input, I'm sure this will be updated tonight or tomorrow.

Yumi, your input has been valuable. Again, I'm sorry for any role I might have played in that misunderstanding. Cheers and thanks again for your feedback on the box office.