I made my first patch of the viewer client code the other day! Actually, it’s a very small patch; it just cleans up part of SConstruct, the script that controls how the source code is compiled into an executable.
Interestingly, the patch doesn’t address either of the things that were bugging me in my earlier post about the build script. But, as it turns out, neither of those issues were real problems (just problems in my head), so they didn’t need to be changed after all!
Tags: ossviewer
I’m trying, once more, to get a working development environment for compiling the Second Life viewer. Long-memoried readers will recall that I had set up a local subversion repository about a month ago. Some time after that was set up, I decided to base my modifications off of the First Look viewer. That, plus the fact that I had set up my first repository while I had a mild case of the stupids, inspired me to start the repository over from scratch with the FL sources.
I’ve got everything set up again, and can compile, but… bleck! What a yucky build script!
Continue reading »
Tags: ossviewer
What a super idea! I’ve got the YAYZERAMA HANDS too now!!
Features like this (and other cool things, too!) could be added to the viewer client, ‘specially now that it’s open source, but so many features require just a little bit of help from the server to do it properly.
For example, right now there’s no good way for the sim to remember “This prim has a saturation of 0.5 on all its sides” and tell that to everybody that comes by, so there isn’t any way to share the desaturated goodness with anyone else! (Maybe you could store some cryptic data in the prim’s name or description for other special viewers to notice, but that would be a dirty, dirty hack. Yuck!)
Sure, we could tug on the Linden programmers’ shirt tails every time there’s a new client-side feature we’d like the sim to store a little bit of data for. But, even if they were just twiddling their thumbs all day and waiting for something to do, there would never be enough time to add something for every feature that someone thinks up. (Plus they’d have to do a grid-wide update every 15 minutes.)
A better way would be to give each prim a little pocket where it can hold some arbitrary data to give to viewers that see it. There would be a hard limit on the size of the data (maybe 1k, or 5k), and it would be completely up to the viewer software to decide what to do with it. And of course, scripts would have to be able to read and write this data!
Ideally, objects and prims in SL should be sent as XML, kinda like this:
<primitive
name="My Awesome Prim"
description="The best prim ever made."
shape="torus"
texture_uuid="top: [uuid], bottom: [uuid]"
contents="[first_item_uuid], [second_item_uuid]"
size="8m 2m 2m"
skew="80%"
awesomeness="23.5" />
Then the scripts could do something like this:
if( llGetAttribute( "shape" ) == "torus" )
{
llSetAttribute( "awesomeness", "infinity" );
}
Or if we had a decent scripting language, like ruby, it would be like this:
if self.shape == "torus" self.awesomeness = "infinity" end
And if you had a special viewer client that was programmed to understand the “awesomeness” attribute, the client could do something cool like write “This prim is so awesome!!” on your screen with a big squiggly arrow pointing to it.
That would be awesome.
P.S. If you’re worried that this would contribute to sim load because of the increased amount of data being sent, remember that textures are the #1 cause of teen pregnancy
P.P.S. Yeah, I know this could be a big ol’ security hole. What isn’t? ‘specially if you’re using a custom viewer client provided by some homeless person down the street.
Tags: ossviewer
Another post? It’s like a post overload!
I’ve set up a local subversion (svn) repository to manage the viewer source code as I make revisions, allowing me to easily save old versions, view what I’ve changed, and revert to the older version if something bad happens. It’s not accessible over the internet (at least not yet), which means that it is of very limited usefulness to other people. But hey, I know how fun it is to read about what other people are doing that doesn’t really affect me personally, so now my readers (I think I have some of those? Maybe I’m thinking of lemurs.) can enjoy the same luxury.
Here’s the plan for repository layout:
You might be wondering why I would maintain a directory with the untouched source code, when I can always revert any changes that I’ve made. My reasoning has to do with managing changes to the linden branch and merging them into my own branch as needed. When a new version of the source comes out, I can update the linden branch, see what changed, and apply those changes to my branch—without overwriting any changes I may have made to the same files.
I might also make more branches off of jacek if I ever decide to implement something that takes a really long time to code, then merge the changes back when I’m done.
Tags: ossviewer
Minor news bulletin: I compiled the latest viewer source and successfully connected to the grid today. I’m not sure exactly why it worked this time, but there are a few major possibilities:
But there’s no way of knowing exactly which it was… so, um… yeah.
Tags: ossviewer
I’ve compiled the vanilla viewer 3 times so far, twice as “release” and once as “releasefordownload”. I’ve also connected to the Grid (Agni) several times, but each time the connection was apparently interrupted or died or was deauthorized soon after log-in.
Tags: ossviewer
Just brainstorming features (large and small) that would be both possible and desirable to add to the Second Life viewer client. Things which would require server changes don’t fit here, only things which can be accomplished by changing the client only. I’m also focusing only on new features for this post; I might make another post of bugs that should be fixed.
Tags: ossviewer
I’ve dived head-first into the client source code. For the moment, I’m just orienting myself, poking my head around to see what goes where, building up a mental map of how the pieces fit.
An obvious next step is to attempt a compile of the viewer as-provided, before making any changes. That way, if something doesn’t work, I will know that at least it used to work, so something I did broke it.
I’m also familiarizing myself with Linden Lab’s issue tracker, wiki, mailing list, etc.—all the new stuff that appeared. I’ll probably see if there are any little bugs in the issue tracker that I can fix.
In the meantime, I’m noting areas of the source code that interest me, so that I can focus and specialize in them. At the moment, improving the user interface seems to be where I get my kicks. The things I noted in my exploration of XUI as being impossible without access to the source code are now, of course, possible.
Lots of new toys to play with.
Tags: ossviewer
This is quite simply the most important SL news ever. Don’t I seem excited? Well, I am. You could say I am cautiously optimistic.
Linden Lab has put a lot of thought and planning into this move, as evidenced by the info-laden open source page and new wiki. I can only hope they know what they are doing.
Yes, part of me worries about the negative effects we will almost certainly see in the near future. This has the potential to be much worse than the CopyBot scare, and with good reason—this turns the Grid upside-down. The assumptions that had been in place are now defenestrated, and business models will have to adapt, and adapt fast. Except for scripters and sex workers, there is no SL market I can think of that will not have to fundamentally rearrange itself.
Honestly, Linden Lab should have given an announcement several days prior to the source code release, to give time for preparation. I would not be surprised if many content providers close down temporarily, until they decide what to do.
We will probably see theft and panic. Temporary economic instability. But people will adapt. New business models will emerge. And most importantly, new tools will be created to improve Second Life.
Let’s have hope for the future. The next few days will be rough as vendors panic, but things will calm down. Later, probably within a week, some new tool will be released to exploit some security hole, and more people will panic. But things will calm down again.
And then we’ll see some really neat stuff. The kind of stuff that restores your faith in humanity.
That’s how I see it, anyway. Time will tell.
Tags: ossviewer
Recent Comments