Some suggestions

I don't know if any of this suff has been mentioned before. It's damn near impossible to search for anything and I'm not gonna sift through this whole place looking. Anyway...

1) It'd be nice if they could move some of the less proprietary code into dynamic library files and release the code so we can help. Considering the game content is almost all player created, why shouldn't the users also do some of the work on the code? Look what great things came out of the Halflife core being open and dynamic lib format (TeamFortress Classic, Counterstrike, etc).

2) It'd help substantially to move more stuff clientside. Make the development tools 95% client side and the object doesn't appear in world until we want it to. Then we can do the remaining tweaking necessary. And/or make a 3D studio max plugin that'll export an object as a proprietary format the system can use and we can so wee can make our own models in whatever way we want. The system can use polygon count instead of prim count to decide on object size. After all, a cylinder causes more lag and takes more verticies than a box; they shouldn't necessarily by equal in terms of system resources.

3) the browser integration I mentioned in the "in world forums" post.

4) Database objects. Readable and writable from scripts. Not like major databases or anything necessarily, mostly just a list of variables. The larger the database, the more resource units it takes (see #5)

5) Residents have a "resource allowance" based on land owned, money paid, etc. Each object in an inventory takes SOME (though maybe only minimal) server resources. Every polygon on a character is at least another vertex that has to be stored on the server and sent out. Every item in the inventory is at least a few bytes of data. All of that adds up. Maybe have another type of membership that's like $2 a month that's non-landowning but has a $100 weekly allowance and more allowed resources. Have rentable "banks" to store more inventory in. I think this will be CRITICAL eventually, if not already.

That's all I can think of now, especially since it's an hour after I should have been asleep. If anything here has been mentioned before, just say so politely instead of yelling, please.

In response, Kayla:

1) I would check the Wiki for how many of the LSL commands came into being. Many of said commands can be reverse-engineered - it just takes some know-how to do so. I'd be happy to offer my advice on some of them as needed.

2) I have a feeling some of the locals already want to see me shot for posting this to virtually every other thread, but I've managed to develop a mesh importer for Second Life already. The downside is it's a resident script, not a "feature," so it still uses prim counts instead of "faces."

3) I've been discussing this with a friend. There are pros and cons to it, but more pointedly, it might be a good idea. Maybe. Might have to omit General.

4 and 5) I don't think this would go over well, simply due to the present technology implemented. Since I also have a perspective on how 3D models are created (it's what I do), I don't think individual vertices for each avatar are "stored" one by one... that would be a bad idea. Rather, I think values for the avatar's appearance, either by slider or "seed" number, are beamed to the client and then constructed in real time.

Additionally, any intelligent business is created to grow as the userbase grows, to meet the demand. If there were a server crisis, or the current grid were unable to keep track of every scrap of data, we would suffer far worse problems than we do presently. As it stands, you will note that sims tend to have 15,000 prim limits. Since they, too, store data, the only grid-based problem would be in the asset server... and last I was told, it was (mostly) okay.

Prim banks and proportional user fees to "content" would scare me, by the way. Both because I have better things to do than ferry myself back and forth to retrieve my stuff, MMO style (an archaic concept), but also because I would hate to be penalized per month for working long and hard to create stuff. But I respect your opinion.

As I was falling asleep, I realized prims probably are stored by their parameters, not vertices. Like I said, it was after my bed time So, prims still are are equal to the same amount of resources. I still think the almost limitless inventory size will slaughter the system when it becomes more crowded, assuming that's not the case now. I understand where you're coming from about not wanting limits and such but as the user base grows and as more items are created as a result, it'll become an issue. I was also thinking instead of keeping your entire inventory on the server, maybe, and having a resource limit, your inventory could be stored on your system, PGP encrypted with the server's key so it can't be edited by the user. That way, you could store as much as you wanted without the server having to know what you have. It'd also function as a form of backup for the server, in case of inventory problems. Or, maybe have your regular inventory, limited to a certain number of resources, but also your "portable hole" which is the inventory on your system, so you can keep things you use most or at the moment in your server inventory and other stuff in the hole, which could be aceessed at anytime. Unfortunately though, I think resource limits would definitely be necessary if database objects were introduced, and I think database objects will be necessary in order to fully realize the potential of SL.

I'm gonna check out that mesh importer thing, though. I haven't looked at scripting much yet, though I plan to once my new computer gets here.

As for reverse engineering script code, that's more or less a server thing. I was thinking more along the lines of being able to modify the client itself without affecting the way it communicates with the server.

6) Another thing I was thinking would be good to go along with more cleint side only systems would be the ability to test textures and whatnot locally. It wouldn't take much to make a manequin window that you can try stuff out on using textures on your system and you wouldn't have to be uploading so many textures trying to get something right. Then again, maybe they WANT us to have to upload so much.

See, that's the thing - they do. I know it's really inconvenient in general - but a part of that is the fact that it keeps people from "hacking" certain things into the game at the client level. A part of the reason there's such a gulf between the server-side (aka. back-end) and client-side (front-end) resources is this fact - simply put, if 95% of all data resources were managed by the client, there would be a higher probability that someone would develop a Second Life based internet worm or the like which... needless to say, wouldn't be good.

That said, I would wait for an official statement from Philip or one of the LL employees concerning system resources. While you might be absolutely correct on resources - I'm banking on the fact that they're far from their capacity in the "now" time frame and, furthermore, have mapped some plan for the future as to how the system will maintain all of those resources, anyway. My guess is if it ever got really bad, we would probably see upload fees to the system skyrocket to compensate in the short term. Given they still rest at L$10 a shot, and the system still manages my resources well enough, though, I'm going to have to assume things are (mostly) fine.

However, I would like to see some client-side tools other than those created to facilitate prim building in the import sense. I'd write one myself if I knew a 3D modeller that emulated prims in Second Life well enough - but really, I just don't have the time presently to write my own 3D tool from scratch.

On textures, though, I feel we do need some newer polish on the system. One of the biggest problems I have presently is the fact that textures "warp" in relation to the size of the prim they're on. While this is usually not a problem, when you have textures at odd angles (eg. 26 degrees), and the prim is, say, 1 x 2 x 3, the texture on it will "warp" in relation to the size of the prim to appear compressed or elongated in ways that just screw with certain builds... and can't be accounted for with just scaling the texture as it's in a different frame of reference.

I'd like the option to turn "scale texture by size of prim" off, thanks.