Archive for May, 2008

Taketori sales halted until further notice

Due to Second Life being full of fail and the Lindens taking several hours to finally even notice the problem, I’ve disabled all sales of the Taketori Katana until further notice.

Once I’m convinced that Second Life has returned to some semblance of stability, and that people can no longer continue to take advantage of the fact that my network vendors are scripted to err on the side of customer friendliness - delivering a product to the customer in certain circumstances sometimes even after a refund has been given due to Second Life hiccups, then I will re-enable sales.

Popularity: 30% [?]

Kick bug fixed - Could it be? Really?

Seems that some regions that were updated in today’s rolling restart include Kelly Linden’s fix for the infamous "C:SI Kick Bug", which was introduced with Havok 4 and removed the push part of the C:SI weapon’s kick attacks.  This was a major annoyance for many of us, and required a dramatic change of strategy for most.

Zero Gee sent me an IM notifying me that Samurai Edo was included in today’s update and that it would be a good time to check whether the fix was included, so in-world I went and work be damned :)

It seems that the behavior is a little bit different (kicks are more vertical than previously), and that might take a bit of getting used to, but overall it’s a great deal better than kicks doing nothing at all, and I’m very pleased to report that Kelly Linden is now my favorite-est Linden of all!

Popularity: 33% [?]

C:SI Weekly Statistic - News and Changes

Many of you already know that I’ve moved the C:SI Weekly Statistics to the Official Combat: Samurai Island Website, which has been a goal of mine for quite some time :

Because I’ve finally moved the stats to their rightful home on the web, I will be removing them from my site at some point in the near future, most likely today.

Another thing I’d like to mention about the statistics is that I’m working on extending the information that can be retrieved by the community.  I’ve gotten a lot of requests from admins and owners of C:SI-themed sims for the ability to track more detailed information for individual sims, so I’m trying to incorporate enhanced functionality where-ever and when-ever I can.

For now, that basically consists of the ability to track wins and losses for a given region on a weekly basis rather than just for all time (previously you could only get historic totals), as this gives a more current view of fight activity :

region-stats-example

There are some pros and cons to the method I’ve used to gather and store this information, mostly as a result of the criteria that I used when designing how it would work :

  1. It must not break any existing functionality.  This is absolutely the #1 priority, and the safest way to ensure that it doesn’t break existing functionality is to ensure that it doesn’t touch existing code and data.
  2. It must not overburden the database or web server.  We have a pretty good hosting plan with plenty of horsepower for our needs, but every hosting plan has it’s limits, and it was important to make sure that this didn’t cause us to exceed those limits.
  3. It should not require any extra work from the other devs.  We all have a full plate, and nobody has the time to do everything that sounds interesting.  This means that I had to find a way to implement it without causing weapon or script updates, or really anything else that would make the others have to work on it.

Because of those criteria, what I have ended up doing is creating an in-world LSL script separate from the weapon scripts, which reports the relevant data to our website for storage. 

On the pro side, this means that #1 and #3 above are met.  It’s entirely independent of the normal C:SI script and data, so it shouldn’t cause any problems with the existing system.  There is a little control over #2 as well, since by making the script myself I have some control over the polling interval, though of course nothing is bullet-proof.

On the cons side, however, is the fact that it is *entirely* opt-in on a per-region basis.  While this may not be considered a con by many, it does at the very least mean that if you want your region to be tracked, you have to know about the system and also know that you need to ask me for the relevant scripts.  Not every region owner will know about this at first, and I suspect many will not be interested in any case.  So the weekly win/loss records per region will not be universally available, at least while the system is in it’s current incarnation.

I’m sure there are still many kinks to be worked out, and there are currently only two regions actively involved (Phoenix Syndicate and Samurai Edo), but I’m hopeful that this is a good start and that people who run C:SI-themed regions will be interested in participating.

As always, I welcome your thoughts and opinions, leave ‘em after the beep!

Popularity: 18% [?]

Reproducing the Detach-and-lose-item bug

missing I found some very interesting information on Keiki Lemieux’s blog this morning : Keiki posted some repro steps (discovered by Nock Forager) for consistently reproducing the "Inventory Item permanently disappears when detached" bug that I posted about before and which can be found in JIRA as issue VWR-6610

The really frustrating part is that, as I reviewed the posted reproduction steps, I realized that I too have been bitten by this bug literally dozens of times.  When I am working on a sword, I have to detach and re-attach it by necessity any time I edit certain scripts that contain physics calls like llMoveToTarget.  This is less of a problem in Havok 4, but the previous simulator code would not allow such calls to work until the object was re-attached after an edit, so I wouldn’t be able to test the changes until that was done.

So it turns out that my typical process of creating a ‘backup copy’ first, then dropping and re-wearing the sword is actually related to the same damned bug.  I’ve learned to identify the symptoms of this, which typically is demonstrated by the fact that when I attach the sword it does not show up as "worn" in the inventory window (which I leave open when working for the purposes of keeping various backup versions), in fact it doesn’t show up at all, which is not normal behavior. 

When I noticed this in the past, and knew from experience that the sword would be forever lost on the next detach, I would rename the sword (while it was still in my hand) to something like "lost fucking sword" or something else unique and crude so that when I filed a bug report and included the name, the guys at "The Lab" should be able to easily identify it’s orphaned record in the database.  Fat lot of good it seems to have done filing those bug reports, because nearly two years later the bug still exists and seems in fact to be much more prevalent.

So once again, if you’ve been bitten by this bug, I encourage you to go visit the JIRA listing and vote and leave your comments.

Popularity: 27% [?]



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

Close
E-mail It