Havok 4 Jump Differences

There is a considerable difference in jumping in Havok 4 compared to Havok 1. If you have noticed this and would like it changed please vote for this Jira issue. Apparently there is a loss of 1 to 1.5 meters. I found a link to this issue at Daikon Forge.

A comparison can be made on the beta grid where there are still some Havok 1 regions available.

On a related note, I will probably be making a free version of the jump assist gadget to help compensate for the difference for those who enjoy jumping.

Windlight and Particles

Yesterday I posted something on the JIRA about particles not displaying properly in the current relase of the First Look: Windlight viewer. Basically I'm not seeing enough particles no matter what my max particle count is. In the below snapshot there is a comparison of the same effect in Windlight and on the Release Candidate viewer. My issue was a duplicate (oops--there wasn't one that I could see dealing with that problem when I checked, but apparently I'm not good at using Jira) but I attached the snapshot to the original issue.





That brings me to another point I wanted to mention. Second Life currently has a little bit of a problem keeping particle textures in memory or whatever and ready to be displayed on the effect. This makes short particle effects start off as grey rectangles before the particle texture loads and can be quite annoying for trying to make a short particle effect look nice because even after the texture is loaded once it might need to load again the next time it's used. There is a workaround for this for creators: the particle texture should be put onto a prim. For example, for my chain lightning staff I am working on I put a tiny cube inside the staff. The cube has all the particle textures I'm using and even though it's hidden by the rest of the staff the texture still loads and the particle effect never has any problem with showing grey blobs instead of lightning.

Windlight Firstlook

The Windlight Firstlook is available. I'm testing it out currently and I am having mixed feelings which mostly lean towards extremely displeased. The environment looks great. The shading on prims looks fine.

Avatars look awful.

Dreadful.

Ugly.

Any type of shading or shadow on any avatar for me looks awful. It's like the shading is not blending at all. Ugly lines going across the avatar. It's like doing a gradient with only eight colors.


I updated my video card drivers. I tried all kinds of settings. If I turn off all the shaders I have no problem, but then it looks worse than it does in the old client.

Blah.

I was really, really looking forward to Windlight and now that I can't use it without grimacing whenever I see a person while nobody else seems to be having this problem is kind of upsetting. The environments looked really nice. The reflections were nice. Everything was nice and smooth on pretty high settings, but no matter what the avatars looked so poorly shaded.

I posted on the SL forums, so maybe someone can help me.

edit: of course jira is not loading in my browser either.

Rolling Restart Bug Fixes

I just read about the rolling restart Linden Labs plans for the 6th and this bug fix made me smile.

• SVC-912: Sky Eclipse’s avatar crashes regions EVERYTIME she logs in, regardless of where she logs in

Poor Sky Eclipse!

Havok4 Beta Grid

After reading a post on the Second Life Blog about the upcoming physics update I decided to go check it out on the Beta Grid. I don't know much about the technicalities about what they are changing but it was mainly this blurb that made me curious:

"Some slight dynamic changes - avatar movements have changed slightly"

Firstly, the spacebar does not work quite like it did before. Previously, you could achieve a bit of a slide across the ground by using the spacebar or in the air. This—although technically a bug—has been used but quite a number of people as part of their fighting style for C:SI and other similar combat systems. The debate over whether or not it is an acceptable action should come to a grinding halt when the Havok4 physics stuff is on the main grid. Spacebar works only to stop the avatar's momentum. It will not give any sort of speed increase whatsoever.

Sliding along the ground does not appear to happen anymore. This was always an annoyance: tripping over a prim and going sliding across half a sim was just annoying. I have not tested this to my satisfaction yet, but a number of perfectly level floors with a prim added that would have normally caused a slide has yet to cause any sort of sliding.

This is good and bad. I'll just have to rewrite a couple of scripts (probably minor changes) to make them work as intended since they were designed with the sliding problem in mind.

There also appears to be a new llMoveToTarget bug introduced. If the avatar is standing still then a llMoveToTarget simply will not work until the avatar starts moving. I need to do more testing for this, but I think applying a small push will help.

Anyway, I'll post more if I figure anything out.

Dashing and Double Taps

Projects have been coming along the past few weeks until yesterday when I started and finished the basic working bits of a new project. I made a dashing system. It is somewhat similar to dashing and dodging found on SL already in other combat systems, so it's not an original idea.

I started doing this to finally figure out how to detect double taps without needing to use complicated timers. Currently, I have the double tap detection function with a maximum of a half second delay between button pushes. Originally I had it at two-tenths of a second, but after handing a test version to someone it was apparent that would be a bit too fast for some people. I may, or may not add a customizable option for the delay speed so people can set their own preference.

The only thing it truly needs right now is a limit. Right now it can be used infinitely which—although it's really fun!—is not exactly fair and balanced for use in certain combat systems.

It works in mouselook mode and the default third person camera mode, but it is designed with the mouselook mode user in mind. Dashes are done on a horizontal plane while on the ground, but if the person using it is in the air then they can dash at any angle. This seems like it could be a lot of fun for sword- and gun-play.

Not only do I plan to include this with my swords (when I finally finish making animations—ugh!), but I am going to package it with any guns I make. There is a chance it will be added to the Ninja HUD, but I'm somewhat worried about including it in something that does not attach to a standard weapon spot such as the Right Hand attachment spot for most swords and guns. The reason behind this is that it could be misused as a sort of cheat while sparring with any combat system that has a similar dash or dodge capability. I tested with one of my C:SI swords and sometimes would get a C:SI dash and sometimes my own and sometimes both. It would be pretty obvious if someone was using this in combat: the sound is different and the movement speed is different, as well as the distance traveled (I think).

I have a few more ideas that I may try to get working if I can figure out the mathematics involved. Math is by no means my area of expertise. I'm more into classical rhetoric than crazy math. The ideas I have that I want to do are definitely beyond my current understanding and I don't know if there will be an easy way to cheat through it by guesswork. Then again, while I worked on the dash script I was nearly pulling my hair out from attempting something so overly-complicated and unnecessary when there was a much, much simpler way to approach the whole thing.

Actually, now that I've typed all that mess about not being able to figure out how to do what I want I think I have a half-baked idea on how to do it. I'll have to try later tonight.

On a side note, some of the gadgets from the Ninja HUD will be available for sale singly, possibly with more features and options. Namely, the Water Walking gadget and Smoke Bomb Escape will be made separately.

I think I will make a double tap detection template script for my LSLWiki page.

Dealing with Alpha Textures in SL

Felidae and I worked on a Shinto shrine together recently, and during that time I came across the problem Second Life has with showing a prim with an alpha texture on it in front of another prim with an alpha texture on it. After some searching around and testing and scratching of heads we figured out that if the textures on the object in front of the background object is 1024x1024 it does not disappear as easily. The same placement and same exact camera angle with a 512x512 texture made it disappear entirely.

I really had a good time work on this project. It is very satisfying when working with someone else and all the pieces fit together perfectly.

We do plan on offering the shrine as a free item sometime soon, but currently we don't quite have it packaged for that.

UPDATE: Here is a SLURL to the shrine.

Grappling Hook Update Update (whee redundant)

I searched the SL forums and apparently there's a problem with multiple attachments taking controls or releasing controls (thread). A fix was to allow it to be passthrough controls or something which of course I've never done nor do I know what it means. A quick wiki search returned zero help as well. Meh. Guess I'll do some more searching.

Obstacle Course Obstacles (awful title)

Yesterday evening and night I spent most of my time on Second Life working on an obstacle course. I doubt it'll end up being useful for any sort of training, but it is kind of fun. It's mostly finished, apart from texturing. By "mostly finished" I mean that the basic course is almost ready for use. I'm going to add some checkpoints and time tracker scripts so it'll report your time. Eventually I'll have a time tracker for each of my courses and a top ten list and... ugh. There's too much stuff I want to do.

The most annoying part thus far has been getting the falling bridges to work properly. In theory it seemed a great idea, but it's really quite a pain to acheive any sort of consistency with it. The prims used for the bridge become physical when an avatar runs over them. That sounds easy enough, right? The prims can't be flush against each other though or Second Life counts them as 'interpenetrating' which essentially means it won't enable physics. Okay, so I thought the easy solution for the bridge was to simply put a very small gap between the prims. That works insofar as enabling physics goes. If the bridge is a perfectly horizontal bridge the one millimeter gaps cause the running avatar to trip and go hurtling forward uncontrollably.

Argh.

I ended setting the bridges at a ramped angle. The sliding issue doesn't seem to occur quite as frequently, but it still happens often enough to be an annoyance. Another thing that occurs is sometimes when the avatar jumps off of one of the falling prims, for some reason, the jumper flies very far up into the air gaining at least an extra fifty meters or so higher than a normal jump. I suppose that's just a quirk of Second Life physics and nothing can be done about it.

I could change the falling bridges to just change positions after collision and not enable physics at all, but where's the fun in that? In the earlier tests of the script I had something like that and discarded the idea.

How badly broken will the the falling bridges be when I log on to Second Life today? There are a couple kinks in the resetting script (I think—I couldn't see why it wasn't working completely last night). Sometimes the prims reset to the incorrect positions. Oh well. Another thing to figure out.

The rest of the obstacle course functions fairly well. It's fun being smooshed by the chompers and flying off the course. I need to add some particle effects and squishy sounds for that.

That will come later. I had enough stress today that I don't want to look at scripts yet. I think I'm going to go see if I can find something to chop.

Chop chop.