How to get Havok 4 and other upgrades...

There have been posts here and in other forums about how LL should start over with an SL2 and dump all content so there's nothing holding them back... I don't think that's going to happen, it would be suicide. Too many people have too much stuff that is, honestly, worth more to them than any pseudo- or real- money LL could afford to compensate them for its loss with.

BUT... perhaps they should be thinking about a way to migrate to a completely new platform in some kind of phased transition, with emigration to a new grid as the end point.

It would start out with a small grid with a new code base, like the preview grid. When you enter it, it would attempt to convert your inventory over. Your old clothes might not map quite right to the new mesh, some of your scripted objects might break, and so on. It wouldn't be a permanent grid, everything in it would be wiped when they came up with a new version of the new world. It'd be a "Disneyland" SL2.

Then there would be a permanent new grid. Still, small, but one that stayed around. You could visit it as a tourist, but still not bring anything back.

Then you'd get a sync-up with a cash reset and inventory merge. You could either resync your inventory, or just have new content you'd acquired in the old world added (the asset server would have to add a bit to each asset to indicate whether it'd been synced or not). Once this is done you could actually buy land in the new grid, sell content, set up stores. You'd have the same 'wallet' in both grids, or you could go through a currency exchange (maybe with an exchange rate that encouraged transfers).

Finally you'd get the option to transfer your land and builds. For estate owners, their sim would be bulk-converted to the new format and taken off the old grid. For landowners on the main grid there would have to be some way to avoid LL having to duplicate the computing resources.

Perhaps you could request a transfer, and if every landowner in the sim either approved or didn't respond, the whole sim would transfer after a month. Or you could pick an unclaimed spot in the new grid and buy a matching parcel for L$1/m and have it transferred then and there... no waiting. You'd lose your old parcel (it would become permanent protected land).

Alternatively, landowners could vote three ways. "Accept transfer", "Reject transfer", "Move me to (landmark)"... and they'd get moved to available old-grid protected land and let the rest of the sim transcend without them.

Some such scheme could be made to work without forcing LL to carry the cost of running two full-size grids concurrently, and without forcing people to abandon content.

The only thing that would really need dumped to move to a new system is scripting, as the primitives should be really easy to port so long as current features were kept in SL v2.0.
Scripting currently is a bit messy, something more object oriented might be better (both in the programming and SL sense), but it would very different from LSL as a result, though keeping states would still be nice (perhaps as objects, not sure, not thought about it that much). But ehm yeah, even then it could still be possible if all functions were lifted out of scripts and replaced with the correct Object.method() substitutions then recompiled while retaining variables, you'd then have messy but still functional scripts under the new system.

So ehm, yeah, a completely new system needn't mean a complete overhaul really, everything should be fairly easy to port.

Changes to the avatar mesh could easily mess up clothes. New avatar mesh layers would almost certainly require new clothes. Let's say they make the jacket a real layer, like skirts: there's a lot of combination jacket/skirt combos using the skirt as the bottom part of a long coat, that would need to be converted. They could do things like combining jackets and skirts in the same folder into two jackets and a skirt, with one of the jackets being a combination of the old jacket and the skirt.

Improved prims would need similar translations. Particle systems aren't scripts, but are likely to need translation as well. If they improve the lighting model, a lot of content is likely to need conversion, even if it's not scripted, converting a texture and a tint into (say) texture and tint and hilight settings...

And scripting wouldn't need to be dumped: they already have plans for maintining scripts through a conversion to mono. They've spent so much effort on making that conversion possible that supporting legacy scripts should be taken for granted.

But a real new platform, with new physics, new lighting, new rendering, new models and meshes... you think the last few updates have been bad. They would need to give people months to convert, and they'd need to make gradual conversion possible.

The biggest problem is that until they got everyone switched over, they'd be maintaining two different codebases. It's already rocky enough with one.

In what way would they change the avatar mesh though? If they added more detail then it wouldn't break textures as they'd still map in the same way.

Same with adding jackets, all they need to do is have a maximum tightness jacket (which all current ones would default to) behave as they do now, since maximum tightness implies skin-tight and can thus equal part of the skin. If things like flared sleeves and such are added then just have current jackets default to zero for all settings and behave as a skin layer.

And what would the problem be with improved prims? More options for cutting etc wouldn't matter since current prims wouldn't use them so would look the same, more detail is a non-issue really. Options that create extra faces are similarly not a problem as you just make them the last faces registered for scripts and such, therefore not affecting the ones we already have.

And what changes can they make to particle systems? Really all they can do with them is add in new options for other types of particle control, or additional flags (for example, I would like particle systems capable of attraction that don't destroy the particles when they reach the centre, but which allows their momentum to carry them through the centre and out the other side, only to become attracted again, but this only requires a new flag).

Havok X should drop in for the most part, since physics control isn't much different. Unless they added ragdoll or something but that would be a new feature, and shouldn't affect existing things that don't require it, only new ones that enable it.

Really all a re-write should need to do is change the underlying data structures and systems for managing content, the content itself is the whole point of the world and should not be changed as it currently exists, there's no reason to do so. I mean, think of content that has been created by people who are no longer active? And what of products that are broken? Such changes, phased or not, would be extremely foolish on LL's part as it would destroy portions of the world, result in huge headaches and a ton of work for builders on things that they've already finished.
People are paying for the world they are in at the moment, and the updates have only been proving that people don't want radical new features that break existing things, all they really want is a world that works better. Havok 2 or whatever would add more options if LL allows, but most importantly is that it is more efficient and thus faster running.

I envision the following:

Once Havok X is integrated into the SL client and server architecture, the old client and server architecture should go into a feature freeze.

The old client code should be integrated into the new client much the same way the original playstation hardware exists in the playstation 2.

The grid wouldn't change at all in the initial rollout, the client would simply be updated to include the new rendering engine and code. The look/feel experience of SL would remain unchanged during this period.

All new mainland sims would be built using the new server architecture, and when agents cross over into the new sims, or are in viewing distance of a Havok 2 sim, their client would simply start rendering with Havok 2.

Ok, it sounds oversimplified, but I imagine it is quite possible to do.

A sticky point would be drawing with 2 different engines at once. I am wondering if it is even possible to do that.

If that could be done, I'd worship the devs forever.

It wouldn't be suicide if we actually owned the data we purchase with L$ and sometimes RL cash. But we don't, so if LL were to wipe the grid and start clean with SL2 we couldn't import stuff we had previously purchased.

Sometimes two codebases are less work than one. They maintained two codebases for the parallel 1.11 and 1.12 releases. They had two codebases for the first attempt at porting Havok, but they didn't have a way to merge them without breaking content.

Almost all of the open source projects I know of have a "release" brannch and a development branch. New features go into the development branch, but uimportant bug fixes are made in both.

If, as it seems, something like Havok2 is more work than they can fit into a release schedule, then they need a way out. This would be a way out. The new branch would get the changes, the old branch would just get bug fixes, and IF there turned out to be enough changes by the time the development branch was ready to go out that a lot of content needed refresh... this would be a way to do it.

Um, what?
We DO own our data. The things I've built I own and have a copyright on (same kind of copyright I have on a drawing I make: it's unregistered, but I can still enforce it to a degree).

I think what he was saying is "possessed" as opposed to "owned". Sure you may own it but what good is that if you cannot possess it to re-upload or use on another platform?

This is the main problem with SL as I see it. If they decide to close it down tomorrow everything we invested in is gone. There is no other platform we can use that "data" on. Therefor it would be worthless and useless.

Would it be possible for LL to make an upgrade kit available for content creators to act as a guide and conversion tool in order to prepare their content for the new system?

Could there be a means of simply offering the new Havok x capabilities merely as additional options to users? For example, objects that don't use the latest Havok x options may be inferior to newer objects that do use these latest options, but at least they would still function as they do now with the current more limited options. Creators would have the ability to enable or disable these options.

This might be best for new options which don't translate easily from the old system whereas some Havok x upgrades may not require any converting of old content and will just apply to all objects as normal. But then again, I really don't know if any of this would be possible.

I hope they would if they were to do something like this. That's a good idea, and what I hoped to see in this thread.

There is no current plans, as far as I know, for such a radical change. There have been a bunch of people, though, calling for LL to make a complete break with SL and abandon all the content when they finally release SL2.

What I'm suggesting, and I'd like people to remember, is that there are ways to negotiate a complete break without breaking people's stuff.

Yeah, I wouldn't put too much stake in the idea of LL completely abandoning SL for a newer version. They are putting their hopes on Real World businesses seeing SL as a viable business platform and that means keeping their current SL businesses happy. No businesses would like the idea of all of their hardwork being destroyed in an instant due to system upgrades. It is therefore in LL's best interest not to demonstrate such a catastrophe even if it would be for the long term improvements of the system. The big timers such as Anche Chung, Electric Sheep and others I'm sure would not stand for something so drastic and carry enough sway to insist that change be done in a gradual fashion. People need stability if they're going to seriously invest in something.

Well I dreamed I saw the silver spaceship flying
In the yellow haze of the sun
There were children crying and colours flying
All around the chosen one
All in a dream, all in a dream
The loading had begun
Flying mother nature's silver seed
To a new home in the sun
Flying mother nature's silver seed
To a new home in the sun.

After The Goldrush. . . Neil Young

Originally Posted by Andrew Linden 2/06/2006

"The Havok2 port was in progress (for the third time) several months ago and is currently stalled again. The problem is that the amount of work required to clean up the code and port the new physics engine is too big for the attention span of LL development process. Rather than tackle it as a monolithic project a fourth time we have to break up the cleanup work into smaller pieces that will go out with the normal updates. A small amount of this cleanup has already been deployed, however the first big chunk (a lot of work salvaged from the third port) hasn't been done yet -- I hope to get to that this month. There are probably two or three more initial cleanup stages that won't introduce any new features at all.

When we actually get around to making the port we'll most likely be working with Havok3 since Havok Inc is no longer 'supporting' Havok2. That's okay, since there is very little difference between Havok3 and Havok2, whereas there is a big difference between Havok1 and Havok2. The only thing relevant to us that was added in Havok3 is a feature called 'continuous collision detection' which allows for more correct collision details and prevents accidental interpenerations during the integration step of the physics engine. Unfortunately, it costs extra CPU cycles, and it isn't clear to us that we'll be using it (it can easily be disabled to fall back on Havok2 behavior).

Incidentally, we're thinking we might stop supporting 'joints' in Havok1 before we move to Havok3. Joints are buggy but very difficult to fix while supporting the legacy format, which is why we haven't fixed them yet. Joints are in desperate need of a complete redesign, and would be much easeir to re-implement after Havok3 rather than trying to provide legacy support during the port. Eliminating joints would remove a big chunk of the work required for the final transition from Havok1 to Havok3, making the whole project easier to break up into achievable pieces."

Don't throw away LSL. I hate OOP. Yes, I know I'm in a minority, but I fully believe OOP to be a hype-fed fad that has no technical merit.

LSL could really use some improvement, but there's no need to throw it away and throw away the skillbase of hundreds of skilled LSL programmers in the process. Just add some better data structures to it and it'll be fine.

OOP has the advantage of being much quicker to develop in once you know how to do it, it's much easier to develop a full system and implement it with a minimum of mistakes, easy testing and much more modularity than other methods. Ultimately it is less efficient, however it is entirely possible for languages to support objects and thus be object oriented while allowing for traditional "linear" (I think) scripting like straight up C code.
I think though that my personal preference would actually be to have the current style scripting, but with the ability to directly trigger events within other primitives/objects (if you have permission). With your own custom-named events and such rather than having to feed things around with llSay and llMessageLinked with various laborious checks and such just to get a message from one prim to another without interference. But that's not the point of this thread heh.

Returning back to topic, re my last post I still don't see any feature that genuinely requires an overhaul. The implementation of Havok X would allow for new features which are a non-issue since current objects won't use them and thus are unaffected. Current objects are only affected by the current system, which can be re-implemented using Havok X to behave the same (ie same gravity fall rate, momentum for vehicles etc) but using the Havok X engine to make it more accurate/faster/better performing. Once the coding is done it's essentially a "drop-in" changeover, you stick it in and nothing should change except performance and new options to play with. Assuming it's actually tested correctly

For real-time controls an event-oriented language like LSL works very very well.

No technical merit? Excuse me, but I just finished a 10 week class where I went BEYOND the scope of the class while working on my project: A Flash Game.
What forced me beyond the bounds of the class?
Wanting a way to have my enemies act differently based on an external file. Each enemy would carry an array of directions and follow them.

WITHOUT OOP I WOULD NOT HAVE BEEN ABLE TO DO THIS.
Without OOP I would not have been able to DYNAMICALLY give a different array to each enemy (gasp, an object) and a piece of code that told it what to do with that array.



I agree, however, OOP has its use as well. And they can be combined. Look at Flash: Flash is a VERY event oriented program (ActionScript wise)--onClipEvent(load, on(mouseOver), onClipEvent(enterFrame), etc. But it has OOP as well--see my statement above.
If there was a way to make LSL both like AS, then I'm sure we'd find a use for it. SL is really just a 3D version of Flash that lacks a concept of "frames" but that's just a reference to time passing anyway (it is very possible to create a Flash program/game that uses one layer and one frame and nothing on the stage prior to it being loaded--everything gets done in SctionScript).

Sure you would. You could have done it with property lists, structures and function pointers, closures, there's a boatload of mechanisms that can be used to implement the same kinds of components and actors you implemented as objects.

I've used object and actor designs in Lisp, APL, Scheme, Tcl (with and without Itcl), Forth, C, Fortran, and a variety of problem-specific languages. I've done it using object mechanisms and simply using structures or properties.

Objects are a tool for designing a program. Object oriented languages make objects easier to implement in some ways, though many OO languages are so tied to a specific object hierarcy that actually make it harder... and you end up re-architecting a lot of the object model beforeyou can work on your program. Half the complexity in C++ comes from workarounds from shortcomings in their object model. But you don't need an OO language for OO design.

You do need a few things that LSL doesn't give you. You'd need data and function references at the very least, and some kind of compound data type like structures. You could use lists as the structures if they had call-by-reference and sublist references.

Actually that's not entirely true either with the ability to create static objects (ie you can access all the methods without having to create an instance of that class) to easily share code between many different classes/files, so I think at the moment all major programming languages to an extent support all styles of programming. The key is learning to use the right ones at the right time =)

*cough* A structure is part of OOP. A Class (OOP at its finest) is merely a structure with a few other bits tacked on.

I really don't want to get personal here, but maybe you shouldn't comment on this sort of thing until you've had more experience than a 10 week class in programming. I know that's condescending to say, and I apologize for that, but I don't know how else to say it.

Programming is one of those things where you might think you are good, but 2 years from now you'll look back on your old code and wonder, "What the hell was I thinking". It's the sort of skill set that is a process of constant improvement, with almost no limit. There's always a temptation to think you are more skilled than you are.

Also, when in school, it is tempting to get attached to a particular tool, even if that tool has a somwhat limited use. There's a lot out there. Don't turn everything into nails, there's a lot of other tools out there. Once you venture into designing a large system in a pure OOP language you'll probably find yourself making lots of hacks to accomplish common tasks, negating many of the claimed benefits of OOP.

A few other bits.

I assure you, data structures existed before OOP was even some CS professor's wet dream.

I agree, those are the two fundamental things I think LSL is missing.

1. Associative Arrays/Hashes/String Indexed Arrays - Would make it a lot easier to shlep sets of tuples around. They need to be nestable though, to get multidimensional data. Since you can cast an integer to a string, they don't particuarly need to implement normal integer index arrays in addition, though there would be some performance benefit to integer indexed arrays.

2. Very basic indirection. Something like PHP's method of calling a function using a string variable would even be enough. Would let us make callbacks we could pass into other functions as string parameters. PHP style variable variables would suffice for data indirection.

Of course I doubt we'll see any fundamental language improvement before mono. It is kinda frustrating coming from an open source world to SL. I'm used to being able to improve the tools I use if they aren't sufficient, with LSL we are pretty much stuck begging.