Archive for the 'Scripting' Category

Flabbergasted: Why don’t users report issues?

bugs-icon First of all, I do know that, despite the inflammatory headline, many users do in fact report bugs, and those users are a valuable asset and are appreciated.  But without any way to know specific numbers, I’d guess that maybe 75% of the bugs that are experienced by C:SI users go unreported.

This is especially frustrating because I have on many occasions heard people - either first-hand or through stories related by very close friends - saying derogatory things about C:SI developers (and me specifically) because of the bugs.  This is pretty unfair in my opinion, and such people are a part of the problem they are complaining about.

Not everyone says nasty things, of course, probably most people simply don’t say anything at all.  I guess I can’t fault people too much for that, it is after all not their job to spend their own time helping us with a product they had to spend money on, though in some cases it is only the end users who are in the position to see a problem.

For instance, there was apparently an incident last night (on Meiji?) that was reported to me by my buddy Zai, where several people had their C:SI weapons break in a short period of time.  This seems to be the same problem that has been discussed several times recently both here on this blog and the C:SI forums, and which is so sporadic and uncommon that no dev has been able to reproduce it. 

Every time I’ve written about it, I’ve asked people to report when it happens, with as much information as they could give, and only a few people have responded to the call (a special THANK YOU to those that have!!!!), certainly fewer people than have experienced the issue.

For whatever reason, though, of the supposedly several people who experienced the problem last night, so far as I know at this point only Zai has reported it.  It may be that the others have reported the problems to other devs, I don’t know yet, but I do know that only one person reported it to me personally.

Because I know Zai in real life, I was able to discuss the problem with him and ask him questions in real-time over the phone, and I think that the information he gave me was very enlightening.  For instance, he is the very first person to my knowledge to describe the actual symptoms of what it means when the "weapon broke". 

According to him, after the script errors occurred, people could still attack with the swords, but while the weapon would still play the attack animations, there was no damage, no blood sprays, and no sounds. In addition, it didn’t seem to be happening to the Wave (or at least not to him personally).  I have yet to find another person to validate that information, but if it is true and is what most people who experience the problem are seeing, then I believe that it tells me at least which one of the scripts is most likely to be the culprit.

If the info he reported is correct, then I am pretty excited to know that I can localize the problem to a (hopefully) single script and start really looking into it.  This is the first big break we’ve had on this bug in terms of locating the offending code, though thanks to Darien we might know *what* is happening, just not where.

So I’m asking again, please, we really do want to fix this bug.  If you experienced this issue or experience it in the future, please send us a notecard or IM with as much information as you can remember about what happened.  Did it happen during a fight?  Did it happen drawing the sword?  Could you still attack, was there blood, sounds, etc?  You never know what important details might be critical to fixing the issue, so please please please send us any information you can.

Popularity: 36% [?]

BUZZ: 1-prim interfaces (llDetectedTouchPos)

I just read the most exciting news by Frans Charming on SLOG about a discussion during the Mono Office Hour regarding interactive user interfaces on a single prim face.

Essentially, scripters in Second Life have long wanted to be able to tell exactly where an object has been clicked, rather than simply which object was clicked.  There is currently no way to gather that information, which is why if you look at any HUD attachment with what appears to be multiple buttons in View Transparent (CTRL-ALT-T) mode you’ll see that each button is a different prim.

By creating new LSL functions (NOT just for MONO, despite the fact that this was discussed at a Mono Office Hour) that return both region-relative world coordinates (llDetectedTouchPos) or uv-mapped texture coordinates (llDetectedTouchUV), Second Life content creators will be empowered to make much more functional user interfaces without as many prims.

Already my mind is churning out reams of ideas of how this could make scripter’s lives a little better, but quite naturally the very first thing that occurred to me was that the ability to gather per-pixel touch information on a prim will enable the final stages of html-on-a-prim, which seems to be born out by the actual (heavily edited) transcript :

Periapse Linden: Ok, so our special guest today is Qarl.
Qarl Linden: woo.
Periapse Linden: The Linden who brought you sculpties
Seifert Surface: yay.
Siann Beck: Hello Qarl
Qarl Linden: hey all.
Periapse Linden: He’s back with a great new idea he’d like to get feedback on.
Qarl Linden: so i have to give credit where it’s due -
Periapse Linden: So go ahead Qarl and tell us about Detected Touch
Qarl Linden: Seifert originally asked for this feature a year ago.
Vincent Nacon: yeah I believe I fed him some of those ideas…. if he checked his email :P
Qarl Linden: i got sidetracked and didn’t get to it ’til now.
Qarl Linden: https://wiki.secondlife.com/wiki/LSL_Touch_Position
Qarl Linden: :)
Seifert Surface: i think people have been asking for it from waaay back in the day
Qarl Linden: yeah, true.
Vincent Nacon: yeah I’ve been wondering how that will work
Qarl Linden: what we’ve got here is the ability to get more information about touch events.
Vincent Nacon: by polygon?
Qarl Linden: you get to know where on the surface, and where in world the touch occurs.
Qarl Linden: you get the face number as well.
Vincent Nacon: err… how many faces are there?
Qarl Linden: it’s continually updated as the mouse is held down - so you can implement dragging.
Qarl Linden: 6 faces on a cube - etc.
Seifert Surface: vincent: faces as in faces on a prim
Chance Abattoir: Where on the surface, that’s rad!
Seifert Surface: 1 face on a default torus
Qarl Linden: and the POSITION, as well.
Vincent Nacon: oh was thinking about sculpty part
Vincent Nacon: muhahahaha!
Qarl Linden: texture coordinates, etc.
Siann Beck: That sounds awesome.
Qarl Linden: right now we’re asking for feedback - make sure we don’t miss anything important.
Seifert Surface: presumably if we ever get 2 sided planar sculpties, theyd have 2 faces
Qarl Linden: presumably. :P
Seifert Surface: :P
Vincent Nacon: wait… didn’t we already have something like that
Vincent Nacon: the drag I think
Qarl Linden: there’s a similar call: llDetectedGrab().
Vincent Nacon: yeah
Qarl Linden: but it’s not so good for a variety of reasons…
Rex Cronon: list llDetectedTouchAll()
Vincent Nacon: yeah, tried to make a joystick imput by using that
Vincent Nacon: input*
Qarl Linden: it reports movement relative to the camera position…
Vincent Nacon: yeah
Qarl Linden: not so useful.
Vincent Nacon: it was neat at first but meh
Qarl Linden: now you’ll be able to put an entire GUI into a texture, and determine with the position info which button was clicked.
Qarl Linden: chess boards, for instance - won’t need 64 prims.
Seifert Surface: the continual updating works with the touch event firing lots right?
Siann Beck: That’s awesome. A lot of vendors can be re-designed.
Qarl Linden: exactly.
Vincent Nacon: so… if we’re going to have touch_position on surface, what does it means for html-on-prim?
Seifert Surface: right
Mbrb Rau: 1 prim vendors…
Qarl Linden: yes - that’s one of the motivations for this work -
Qarl Linden: so that prim web browsing will be easier for us to implement.
Vincent Nacon: yeah, figured
Vincent Nacon: well that’s good, hope it won’t be much of a problem with flash
Qarl Linden: naw - it’ll still be controlled with parcel media…
Rex Cronon: could it be possible for a script to load a notecard that has html code on a specific face?
Qarl Linden: flash is hard because mozilla has a truly horrible plugin interface.
Vincent Nacon: now that’s a thought
Qarl Linden: we’re looking at webkit and others for that…
Qarl Linden: maybe notecard->html … but that’s not REALLY useful…
Vincent Nacon: so how the position will work? gobally or local?
Seifert Surface: rex: really you want to be able to alter the webpage on the fly from a script
Qarl Linden: only if you can’t get your own webpage.
Seifert Surface: say for a scoreboard or something
Qarl Linden: yes. exactly.
Qarl Linden: but you can do a LOT by passing parameters to a webpage in the URL.
Rex Cronon: i want to have display that is not connect to a web page
Vincent Nacon: and for non-flat surface… how will that set the local position? based on UV map maybe?
Seifert Surface: html file in a string?
Qarl Linden: i’ve seen an example where HTML is in the parameter…
Qarl Linden: yes - it’s the UV map.
Vincent Nacon: ah ok perfect
Chance Abattoir: When will this script go into testing?
Chance Abattoir: function
Qarl Linden: soon - i’ve got the implementation finished - just a couple more tweaks.
Qarl Linden: a month timeframe, i think.
Qarl Linden: but no promises.
One month.  Wow.  Seems LL has decided to get a whole bunch of internal projects done in a big hurry :)
Finally, another bit of news that might be interesting :
Periapse Linden:  1) We are going to start the Big Merge of Mono with havok4 next week

Popularity: 33% [?]

Proceed with caution - Second Life® Utilities

It’s a bit of old news now (in Internet time, at least), but not long ago there was quite a bit of buzz in the Second Life® blogosphere about a new program called Second Inventory, whose stated purpose is to allow a Second Life® user to create a local backup of their Second Life® inventory - Scripts, notecards, textures, the works.

Of course, there was an immediate buzz (see Dedric Mauriac, Vint Falken, and Your2ndPlace for example and comments) in the SL™ blog scene and lots of interesting speculation, discussions, and outright accusations on SL-related forums about how the software could be used to steal from content creators.  I don’t know and won’t speculate here on whether that’s true, but I could actually envision myself using this software for it’s intended purpose, as there have been many times when I’ve wished that I had a local copy of a script or texture that I can no longer find or that Second Life® seems to have lost. 

Most recently Second Life® had lost the notecard for my ZHAO animation override, but even more importantly (and more frequently) I’ve lost several important scripts over the last two years.  Unlike my real-world software development environment, Second Life® has no version control, automated backups, or even adequate inventory search functionality, and this has led to my rigidly following a practice of doing *all* of my SL™ scripting work offline using SciTE-ez, lslint, and Subversion.

So, as I say, I can see wanting to use the Second Inventory program myself, but I just can’t get past the most powerful of trust issues : It requires your Second Life® username and password.  Having developed several kinds of utility software for myself using libsecondlife, I’m well aware that this is a requirement for which there is no workaround, and that’s not the part that makes me uncomfortable.  The part that makes me uncomfortable is that I am just fundamentally wary of giving my password to anything but official Second Life® software.

There’s another program generating a lot of buzz in the blogosphere right now that provides a pretty concrete example of why that unease is justified : G-Archiver.  Jeff Atwood of Coding Horror fame recently received an email from Dustin Brooks (who reverse-engineered the program) describing how he had discovered that the program sends user’s GMail login and password info to the software’s creator.  Mr. Brooks apparently discovered the sign-in credentials for 1777 GMail users!

Now, I’m not saying Second Inventory is a phishing scam, I don’t know if it is or isn’t (I tend to believe it’s not, but not as strongly as I believe that the Nicholaz viewer is not), and that’s not the point I’m trying to make.  The point I’m trying to make is that thousands of people get fooled by malicious programs because they don’t have a fundamental mistrust of software that asks for sign-in credentials.  Even fairly intelligent and tech-savvy people fall for these kinds of things, perhaps in part because they *do* understand the technical reasons behind the software asking for such sensitive information, and they are very comfortable with technology.

I strongly suspect that with the Second Life® viewer being released as open source and libsecondlife growing steadily more capable, we can expect to see an explosion of third-party utilities and programs.  While that’s generally a good thing in my book, and I look forward to seeing what kinds of things such software will enable with respect to bridging the real and virtual worlds, I think it’s important to remind potential users to proceed with caution.

Popularity: 68% [?]

Testing Tools : Fight Results Report

This morning I locked my previous post on the device that I was previously calling the "Duel Data Monitor", due to a disturbing recurring theme that people seem to be worried that it will somehow adversely affect the C:SI system, which I have absolutely no desire to do.  Rather than attempt to keep up with the comments on that post, which I am feeling FAR too sick for (I suffered a relapse this morning dang it), it is easier for me to just state my position here.

My desire is to create a device that records fight data as an aid to the C:SI developers in their goal of creating the best melee combat system Second Life® has to offer.  I have no desire to do anything that will reduce hard work and training to a "set of numbers".

There is a great deal of data that would be useful to C:SI developers if we could gather it, and I strongly believe that it is in everyone’s best interests to do so.  There is, apparently, a lot of concern over publishing that information, so it will not be available publicly.

The only people that will have the ability to record fight data will be beta testers and the C:SI developers themselves, and the devices that allow such recording will be strictly limited to those two groups of people.

I had thought that it might be interesting and instructive for a much broader group of people to be able to review the results of their own duels (note that the device could only ever be used to record the fights of the device’s owner anyway), but I cannot at this point come up with a way to reconcile that possible benefit with the notion that it might serve to lessen the accomplishments of others, so I have given up on that idea for the time being.

I hope that will address any concerns people have.

Popularity: 42% [?]



Bad Behavior has blocked 279 access attempts in the last 7 days.

Close
E-mail It