Vote on prop 695: 1.8 = 3 major features, and that's it.

Yes, all three exist. Torley was listing features she appreciates that were included in 1.7.0.

WORD!!!

YES INDEED!

Cue that Vivaldi "Four Seasons" music video here.

Thanxies.

Honestly, I just couldn't care less about Havok 2. I'd much rather see improvements in the builder's tools (a greater variety of prims, CSG) and avatar enhancements (more clothing layers, a face layer so you can wear a mask or a facial hair texture on top of a skin, more attachment points). I suppose physics are important for those of you who are into first-person shooter games and vehicle afficionados, but for social players who like to hang out with friends, shop, play casino games, dance, and show off our sexy prim hair and blingy jewelry..... physics is less of a priority.

I don't see Mono as that big of a deal either. Mono and .NET have a great deal of value for application programmers writing real-world applications because they allow you to reuse old code without having to translate it into the language du jour, but the code you write for SL is inherently SL-specific. I don't imagine that there's a lot of application code out there just waiting to be used inside SL if only you didn't have to port it to LSL. I also don't see there being a large learning curve prohibiting your average coder from learning LSL. If you know any existing imperative language (C, C++, Pascal, Fortran, BASIC, Java, Smalltalk, Visual Basic, Bourne shell, C shell, MATLAB, IDL, etc.), you should have no trouble learning the syntax and semantics of LSL. And I don't know of any Lispers, Schemers, or Prolog gurus that are not also proficient in at least one imperative language. Learning the API functionality is the most difficult part of learning to script in SL and no amount of syntactic sugar will help you with that.

These categories are not mutually exclusive.

Yes.

For the Resis who like to party and show off bling will also like to display a luxurious collection of fine-ass vehicles.

And what do you need to pimp your ride?

HYDRAULICS, YO!!!

You wanna bump-'n'-grind with ya bling and ya sexy clothes in da back seat while your car is crunkin' down tha highway, across tha smooth sim crossings of the future, so you can ride wit' da tru stylee without bein' embarassed of a wack set of wheels. And what does that involve?

Physics!

There are many connections too. And an obvious feature may have many not-so-obvious, lateral benefits. Someone who says "I could never find a use for that" may find themselves surprised down the line.

Super Mario Physics - SL version of this would be schweeeeet

And the other case I could make in favor to make smiles:

1. KRUMPING. Also known as clown dancing, it involves physical contact. Right now on the dancefloor, if you bump someone, especially in the middle of their moves, it can look pretty awkward.
   

1. Casino games could spill a lotta coins out, representin' tha BLING BLING DOLLAH (courtesy of Hustlah Linden), without boggin' down the sim. I'd imagine Pachinko would be a go too—at last!
   

1. Gold chains could swing around your neck instead of looking so stiff.
   

1. You could drop a joint and it'd roll more convincingly.
   

I agree with Kazuo, theres still too many flaws in 1.7 that really need to be addressed first before they do anymore wacky updates.

You might, however, have issues with the limitaitons of LSL.

For example:



The above is from the wiki

Python, to pick an example, is a pass-by-reference language and doesn't suffer that problem. I've no idea how that changes under Mono and the CIL, though.

Anyway, I'd rather use a language that I'm familiar with in other contexts than learn Yet Another Proprietary Scripting Language. It enhances my skills with the language I already know, saves me time and effort (however little) that I'd have to use learning something that is only applicable in this one place, and still lets me get stuff done in SL.

Ya know, honestly...

I'd just be happy if I could enable AGP on my ATI video card :/

I've been in the software biz for 30 years and I'd like to try to set some reasonable expectations here.

These three features represent major fundemntal components of SL. Changing a fundemental component of any system is a major undertaking with a high probability of causing major disruptions in the system.

I do not know of any reputable software house that would allocate anything less then 18 months to implement just one of these changes and frankly I would call 18 months overly optomistic. Frankly, I think that we are lucky to see 2 - 2.5 years for the implementation of each feature.

The fact of the matter is that it takes time to do things and it takes even more time to do things well. This is a fact of life that is just as true for programming as it is for carpentry or anything else.

I really see this as a creditability problem. The way to fix the problem is:
1 for LL to prioritize the features.
2 Focus on the highest priority feature.
3 Allocate adequate resources to the task (now that we have decided which feature to tackle first it becomes a task)
4 Devlope a realistic schedule task (and do not schedule or assign date for the remainng features)
5 Adhere to the schedule
6 Deliver a high quality implementation on time
7 Focus on the next highest task
8 start the process at step 3

This way LL will restore their creditability and we will receive a high quality implmentation on time.



As customers we have to realize that:
1 It takes time to do things well
2.We:
a. Can have things fast
b. Can have things good
c Are unlikely to have things good and fast
3 The best way to eat an elephant is one bite at a time.

Fixing the limitations of LSL to add a few goodies like pass-by-reference is likely to require far less development time than replacing the entire VM. Again, with respect to the learning curve, replacing the VM to allow for language independence seems to me to offer a small return relative to the development effort involved. There are many other small improvements that could be done with much less development effort that would enhance the overall user experience of SL far more than a Mono implementation, IMO.

But it would also get us pass by reference (ala Java and C++ both inherehtly support this plus a lot of other features)

I just added my vote to this Lordfly.

I really am trying to not call on names any more when i post but i have to comment on all that Xero Epsilon has said thusfar. You do understand that with the implementation of Havok II and mono these will lift to unfathomable loads off of the SL servers. With the left hand being Havok II all things physical will run better and less weighted (processing wise) on the sim and with the right, monocode, the execution of object scripts will be able to go exponentialy faster elevateing another huge load on the system.

To all thoes that say fix 1.7 first, surely you see that these ARE the fixes to many of the ailing issues. Are there other issues, sure, but Im curious as to how much of that is being seen due simply to the growing complexity of the system.

On a side note I'm wildly curious to see if things such as the new psyx's cards that have been developed will be implemented into SL, it being a server side technology I'm going to throw out there that we might see use of this technology before the end of next year.

Havok II + mono + Psyxs cards = 9 loaded sims to a server nicely anyone?

*voting NOW*

Why?

Let's take these from the easiest to the hardest.

HTML, presumably on a prim: what does this mean? Does this mean something like...

llSetHTML("<TABLE><TR><TD>Velocity</TD><TD><?velocity?></TD></TR></TABLE>",front_face);
llSetHTMLVar("velocity", velocity,0);

Or does this mean?

llSetURL("http://mywebstore/",front_face);
llRefreshURL(front_face);

Or what? Rendering HTML is computationally intensive, and pretty much has to be done by the CPU rather than the GPU. What are you going to do with this?

I'd rather they started out by incorporating a more efficient and faster XyText.

llRenderText((string)velocity,front_face);

Havok2... wasn't this supposed to be the big improvement for the 2.0 release? I can see this as being a big win, but if they're taking so long there's gotta be some reason. I'd rather they shared some info as to what the big problem is. If Havok2 means "oh, and half your inventory just turned to junk" I'd rather they wait. Maybe set up a preview-preview and get Huns Valen and Jillian and the rest on it to see what it's going to take.

Mono... this seems likely to be the hardest part. SL is a real-time system, and real-time code is a very hard problem. LSL is a very "static" language with limited and controllable resource requirements, designed to allow average and novice coders to get work done safely in a real-time environment. Mono has no comparable mechanisms... I really wouldn't expect anything less than a from-scratch implementation of Mono that would likely end up being slower and less efficient than LSL to be workable. Is anyone allowing unrestricted access to anything like the Mono/.NET or Java runtimes in a shared real-time environment? Is anyone selling .ASP services that allow clients to run arbitrary .NET applications on shared webservers?

HTML is a "nifty" feature but eh, we can deal.

Mono I would kill for. Scripts that are easier on the server and have better functions, classes, etc so forth? Even for people who don't script, you would notice an improvement in your second life. I've never seen a person who never ever used a script. SL Amish do not exist. As for the current scripting language being easier to learn, as I understand it the current script engine would not go away, it would be around for those people who want to use it. for the record here is what I know about mono. Please note the mono feature section and the language availability (specifically vb.net) In my opinion, vb.net is easier for a laymen to learn than LSL.

Havok2, I will personally sell my soul to the dev that kicks it in the a$$ and gets it in there by 1.8. Seriously, it's only slightly used, in mint condition, one previous owner. have your people draw up a contract. The reasons I want this so badly are 1) I make vehicles, I love using vehicles. 2) for the more common user, the physics engine seems to be the number one source of sim crashes. not always from heavy physics use but simply because scripted objects seem to be in part handled by the physics engine and even overlapping non-physical scripted objects will sometimes cause issue. 3) I'm lead to believe it will allow for sim crossing improvements. This one I think also is caused by region communication delays and precaching but havok2 would also probably help a bit. 4) how about small physical pets? large multi moving part physical vehicles? for those combat junkies out there, bullets not tunneling through things because they're moving too fast, not being crashed by push weapons.

Yep, it's all been said before, but throw us a bone here. How about a highly technical buglist? blocking issues, non-blocking issues, current implementation, history of implementation. we'd all shut up a bit if you'd give us something. Either we can give up, or have something real to look forward to. If the answer is a buglist and implementation problems 3 miles long great, it wouldn't be anyworse than years of waiting with absolutely no hint of it getting closer. I'd even accept, "it's shelved for the forseable future" or "it's being implemented in parrallel with 2.0".

I love ya'll to death for coming up with SL at all, but ya did such a good job I have these huge expectations and that can lead to big let downs.

oh, and yes, votes applied.

I'm not convinced that Mono would be easier on the server. I've actually implemented scripting and actual development languages for real-time control systems, and there turn out to be really twisty tradeoffs that you have to use a conservative approach to... at least if you want a system that's reliable and responsive.

I HEARTILY ENDORSE THIS PRODUCT AND OR SERVICE!

well, I believe the compiling to bytecode would improve performance, but I think I see what you mean. For starters I would be happy if the new scripting interface contained functions that provided the same abilities (although with better names and arguments, possibly blocking and returning values rather than raising events for returned values), allowed C# syntax, VB.net syntax, pass by reference, and compiled to bytecode. oh and arrays, and data abstraction. maybe inclusion? inheritance, shared memory? sort of like passing a pointer to something via link message and having that available in another script. ooh! think of that if any variable in the sim were available via reference, maybe protected in the owner or creators namespace, you could pass anything with the on_rez integer.

I don't know what LSL compiles to, do you? It could well be a bytecode, it's certainly not run-time parsed like a traditional command language.

I don't understand what you mean by "C# syntax" here. There's nothing really wrong with the basic syntax of LSL, and for the functionality it provides it's pretty much the same as any other C-derived langauge. New features would need new syntax, but personally I'd rather it used Javascript for its model there. The JS language itself (ignoring the horrible runtimes in web browsers) is about the best OO language design out right now.

What I'd MOST like to see added to LSL are little things, like compile time constant expressions, a constant keyword, and the special treatment of negative numbers by the parser replaced by treating them as constant expressions.

After that, standard-compliant CSV format so you could depend on the clean conversion of CSV-formatted strings, llList2TypedCSV and llTypedCSV2List for efficient parameter marshalling and unmarshalling, and regular expressions.

Internally I'd like to see them use references rather than copying lists. That would have a bigger impact on script performance than ten plain and fancy bytecode implementations singing "Waltzing Matilda" and dancing the can-can.

If generalized texture layers for avatars isn't in 1.8 I'm going to have a tantrum. It won't be pretty.

The Lindens have officially tallied this into the "cant do" column, citing technical reasons.

Thanks all for the support.

LF

Thanks kelly . Alright, how about a status report from the 3 groups incharge of those large features, either posted on this site, or presented in world at a town hall.

The link Kelly mentioned above has Chris reminding that a Townhall on SL production and such is coming up next week. Probably want to head back up to this thread and re-post your questions:

/20/7a/74510/1.html

Note I'm already applying one question that will probably help in this regard, dropping in 'agreement' posts would not hurt.