Nexii Malthus

I use multiple UVW Unwrap modifiers as well, but set it all to channel 1, it's completely Okay if the separately textureable faces overlap. The importer won't understand the separate channels.

Image > Mode > 32 Bits / Channel. Apparently related to gamma correction where photoshop glitches out.

Function, so obviously not some client-side only solution. See llTextBox: http://wiki.secondlife.com/wiki/LlTextBox

Use collision_start and land_collision_start instead, the start events are already unpredictable, but the continous ones are even less so.

NexText is up to 3.3 [ Original image at: http://c438644.r44.cf2.rackcdn.com/NexText-with-RSS-Reader-and-HUD.png ] Some improvements and changes across the board. For example the underline is thinner and capable of going much thinner. Tested it out in a HUD and wasn't too happy with the results, so I went through to improve the aesthetic glitches and make it more pleasing for readability. There's a boolean OptimiseForHUDs that is meant to be used by those who want to create HUDs with this. There's various performance enhancements, but this is as far as I can go atm to improve the core. I think I'd have to start writing caching mechanisms, for example caching an often used name for applications that require instantenous rendering in production. Coding wise, the function Clear can be used to clear all the text and have started grouping variables with comments. The variables intended to be modified by the user have been put together. They can be used as globals, but you'll probably want to change them to handle cases where you want a large heading and smaller text. There's also an RSS reader (w/ HUD version) I threw together in a few minutes as an experiment. PHP script used as a proxy is offered in a notecard.

Err, not sure what that has to do with this, but nothing stops you from using multiple notecards.

Heya'll, as part of my progress on developing the next generation NexUI HUD library, I also built the new tech for prim text which will be integrated into it. But for now, it's independantly usable and practical. Just like the older NexiiText libraries. [ Larger image: http://c438644.r44.cf2.rackcdn.com/NexText3.png ] Textures / Font is by the awesome Ubuntu Font, see relevant font license. Script and objects are released as fullperm / public domain without limitations. Just contact me for a copy and I'll drop on one you. (Okay, maybe not performance, but still has a low memory footprint as well (~20kb))

I put something together that looks like a single viewer3 icon toolbar button. A quick click toggles the front-view camera. Since I hate HUDs that can't be adjusted, I threw in a slick drag&drop mode so that it can be placed wherever you want to on your HUD. It's opensourced/fullperm and I can give it to whoever wants a copy -- whether they want it for the functionality or are interested as a scripter in the drag mechanics.

Well yes, sort of. As a scripted camera though you wouldn't be able to use certain camera navigation options -- such as scroll wheel to zoom in closer. So it would be more of a fudge than a real solution. (Though, with LSL it would be possible to do some more interesting custom navigation. Hmm... you got me curious now *scripts*)

Did you get the idea from http://blog.damienfate.com/?p=749 ?

For me, it's a pretty simple difference in regards to interaction and behaviour: - Roleplay is when I pull out my Chatbar and /me a story. - Combat is when I draw out my weapon and shoot at threats. - Roleplay is that even after an event, I still have to keep writing stuff in character. - Combat is when after I'm done, I can go hang out and chill with friends and enemies alike "out of character" normally. I personally don't like roleplay because it doesn't leave enough room for normal social interaction. The consistency can be nice but is way too much and overkill. There are some groups of roleplayers that don't even let you talk in an IM to the human being behind the character. On the other hand, in normal Combat, sometimes the social interaction can be too much for some people who are more vulnerable to taking hits to their ego and pride -- or are the opposite and spew BS at other people just trying to have fun. (Although dealing with these social dynamics is an interesting challenge as a game developer working within communities)

Agreed. A lot of people don't realise the simple mechanics at work that make SL combat possible. People are here for fun. Even if someone goes out of line, communication goes a long way to resolving issues. It's all about having decent moderators around who can keep operations running smooth. Just as much as a forum needs moderators to keep things in check. It's the same thing.

Yeah, LL won't mind as they have existed long before their own marketplace, which itself used to be a third party. I have to say Con, I do feel personally a bit miffed about your thread as its' advertising, due to you being a competitive rival to me as I'm working on my own marketplace as well (although works somewhat differently and has other mechanics). I know that there are some other marketplaces out there that still exist, so those are competitors as well. In a way, I feel that third party marketplaces deserve advertising and attention, as LL has an unfair position to heavily promote their own and outcompete others via a massive budget to their marketing and control over server and viewer code to gain unfair advantages (viewer sidebar, direct delivery, single sign in / L$ account integration)

Kelly Linden wrote: When you write a script in LSL and compile it to mono we convert it to a C# class that gets compiled to mono byte code. Your function myfunc() becomes 'fmyfunc', your touch_start in state mystate becomes 'emystatetouch_start'. C# uses a delegate model for handling events - which is to say you assign a function to be the handler for an event. So to 'wire up' a state when you switch to it we need to create delegates (function pointer objects) from the methods that match specific name patterns and assign those to the events. https://jira.secondlife.com/browse/SCR-115 I'd say the matching is probably of neglible performance cost, but yes, this might be very likely causing extra memory usage. Which could become extra overhead if you like writing obscenely long function names.

You can ask the Exodus folk to copy over some of the changes I did in my own custom client:  It's a relatively simple fix to the client code.

Just use a viewer in the first place that supports combat-friendly zooming. You cannot zoom via scripts, yet. According to the client-side llSetCameraParams code, it looks like it is waiting to be implemented by LL as the methods are there. (For reference, I indulged into the code here to fix some code to allow for smooth region-coord camera movement in my custom client, was easy to fix and lazy oversight by LL, the code was almost there!) There are four clients that I know of that currently have right-click mouse zoom: Casual-Use Viewers: - Phoenix - Firestorm (For reference: http://jira.phoenixviewer.com/browse/FIRE-1125 ) Combat Viewers: - Exodus ( http://exodusviewer.com ) - Combat Cubed (my own client, not quite public yet)

@Mira Kamiguwa, I'm not sure how Blender does it exactly, but you need to se the Smoothing Groups. Which are the normals on the model. See these two videos by the GuerillaCG project, to understand how smooth shading works: Smooth Shading - http://vimeo.com/2165443 Smooth Shading Examples - http://vimeo.com/2166482 @Jacki Silverfall, that's a model straight out of Left 4 Dead (character Zoey).

They are talking about the (av) mesh, not a meshie.

That reminds me. Forgot to put a script on the wiki.

You can store a lot of information in only two textures. It's all about using the colour channels efficiently. Remember that a texture is ALWAYS stored in graphics memory with 4 channels, even if you push a 3 channel RGB texture, the 4th channel is wasted. With that in mind, using two textures we have 8 channels of information available. Texture #1 - Red+Green+Blue for Diffuse Colour - Alpha for Transparency Texture #2 - Red+Green for Normal (You can compute a proper normal from two floats) - Blue for Shiny - Alpha for Height Now that's a ton of awesome detail in two textures: Colour, Transparency, Normal, Shiny, Height for every surface you want. Of course, then the issue is, loading two 1024x1024 textures is going to be overkill, right? Well LL could implement client-side limits, say that the #2 texture would have a max size of half of #1. (server-side would seem too strict as it's a client-side rendering/memory issue only) For the question how the parallax textures worked on the video, I simply mis-used the RGB Diffuse channels as a heightmap, hence the black and white. Didn't feel like making complex client-side hack to support a secondary texture slot -- although the above thoughts describe the concept I had desired for my implementation, for such client modifications.

A stackexchange for LSL is already disabled -- http://openlsl.stackexchange.com/

Why do you want to know this information in the first place? You'll find that there can be a lot of grief to doing this stuff unless the client exposes itself intentionally with the users' knowledge. The grief specifically stems from de-anonymization, as in knowing what specific client a specific user is using is a privacy issue. If you only care of anonymized data though, Media on a Prim could do it I guess. But that only goes as far as people wishing to enable that feature and whether their client supports MoaP in the first place.

Totally agree with you Medhue. Animations are just really easy low hanging fruit to fix and have an incredible amount of potential compared to any other animation system out there. There is some really good tech here beyond the obnoxious barriers that are the aforementioned bugs as well as the BVH parser. It is just a shame that these issues aren't being tackled and these are things that make life a lot harder on content creators.

Interesting, sorta looks like an older version of http://www.animeeple.com/