My C-64 is a dream to program on.

lol... So is havok going to make coffee for us in game? If not, nope, it sucks Oh I agree, and still no formal date on that either. Imagine, a smoother physics engine with a smaller footprint... I can understand why it'll take time, but when? Jack have they even given us a release date or version yet?

Agree.



Agree.


Wow, im very agreeable this morning.

Erm.... they do .... its called the forums ... this one and the scripting one mostly ...

lol - good point

I think that here and in other threads as well as at the Town hall meeting with Cory, a number of pointed questions and comments highlighted areas that could be improved. That's great; as users, we've done our part to provide Linden Lab with lots of great input on ways that might help improve SecondLife and LSL.

I can't help but feeling that it's a bit.. unreasonable to demand instant attention from an otherwise busy Linden development staff. Linden has been one of the more responsive, more... interactive... development companies I've known of; the fact that we're talking to developers at all is nothing short of remarkable. They're fighting the good fight, and definitely taking the ideas they've been presented with more than a grain of salt.

I can also tell you, if I were Cory and read this thread, I wouldn't want to walk dive into dealing with these messages and hostility. I certainly wouldn't want to sit and defend point by point the answers I was kind enough to provide.

I'm satisfied with the answers given-- they've got a roadmap and they're dealing with issues and making improvements in a manner that seems appropriate to them. Based on the excellent state of SL so far, I'm inclined to accept their future plans and leave it at that.

Are there LSL coding restrictions? Sure! Can we do amazing things with LSL regardless? You had better believe it. Enough said, let's try to keep it positive and supportive. If you want a reply to your concerns, there will likely be a future Town Hall meeting at some point down the road.

Trimda, you know how it works. The board gets to decide what the programmers work on. The board is god. The board is going to give the game custom gestures so people can hump before they do havok 2. Why? 'cause porn makes money and the board knows that.

The board will never ok a month of work so we can have garbage collection and mallocs, unless we convince them it will mean more naked girls.

Edit:
To remove reply to above quote edited from original post.

Ok, maybe strike the User from that. Having a Composium such as this would really allow LL to interact with the key stakeholders of LSL. Us the scripters. The forums are a diluted form and do not often foster a true converstation between us the customer and LL. Rarely do we see comment from a Linden in an official form.

It's very easy to say that memory limits are more important than XML-RPC, because for some people, they are. To me, they are not. Please try to keep in mind that we have been asking for inter-object communication since...

...what, 2002?...

...and now, as part of the XML-RPC and new e-mail functionality, we are finally getting it. They might as well do all that stuff at once. I, for one, am extremely pleased. Linden Lab doesn't have 100 coders to hammer away at this stuff all the time. They have to choose what is best.

Now, as far as the tone of this thread is concerned. Try to avoid writing a series of long accusatory posts about why so-and-so is not being responsive, etc. This is not productive. It's one of those things that can be said once in a while, but belaboring the point is not going to help anyone.

Finally, I think it is best that they give us the option to select a memory model, like in good old Turbo C++ 3 for DOS. For example, we could have tiny, medium, large, and huge. Maybe it would be best for the LSL engine to just autodetect this, starting off with a tiny memory model and only switching to a larger one if it runs out of memory. That way we wouldn't get newbies selecting a huge memory model for a texture rotation script.

Hmm, no wonder Cory is kind of wary about increasing memory for scripts.

Because of the nature of LSL's stack and heap (at least the way I understand it), it is extremely difficult for an external entity to simply increase the memory available to a script.

A script's stack starts at the 'top' of its memory block, the heap at the bottom. When these two entities collide, it is known as a "Stack Heap Collision", which has been considered to be synonomous with an "Out of Memory Error".

Theyre not the same.

Take this scenerio:

A script has been runnning under the 16k model for, lets say, 1 day. It has allocated a relatively decent amount of memory for both its stack and heap. Now, in a new release scheduled for that day, a memory increase to 32k is implemented. However, in this script, the stack and heap stay in the same position relative to each other, reguardless of the increase in memory. So, when the script runs memoryIntensiveTask(), it will stack heap just like a script still running on the 16k model would.

I think, to implement this change without severely effecting current running scripts, the devs would need to either:

1. Create a relatively advanced memory re-allocation program, that goes to every script, and repositions the script's stack and heap so that they're taking advantage of the new space. This process would probobly involve pausing script execution for a few minutes, since memory corruption would ensue if the script wrote to its memory while this proecess was executing.

2. Auto-recompile all scripts. This is the easiest path to take, since the script would, upon compilation, clear its memory space, and begin its stack and heap at the new, expanded bounderies. Of course, this method would really piss off people in the community that rely on their scripts remaining functional.

3. Require a compilation to take advantage of the memory space. Scripts already running before the change will still be subject to the 16k limitations, but scripts recompiled after the change get 32k. This would be absurdly difficult to implement (though easier then #1), since when already-running scripts are granted the 32k (behind the scenes), address offsets may change, and cause corruption within the script memory space.

Automatically resizing the memory space would be a difficult task to accomplish, since LSL memory is written to in a very block-like simplistic style.

Of course, I could be totally wrong....

----

And to address how out-of-hand this thread has become:

I dont think more Cory bashing/general dev bashing will really help our situation. LL has a distinct outline for when features should be implemented. Its been a LONG time since LSL has gotten something as simple as a new event!

For me 1.3 is the greatest LSL improvement I've seen in my lifetime as an SL citizen. LSL hasnt really changed much since mid-beta, when I arrived, so its very exciting for me to witness such a monumentous occurence.

==Chris

EDIT: Touch-typing at 2 AM... self-explanatory

I'd just be fine if there was a better way to call upon functions/variables in other scripts the linked messagest. Even if each script remains at 16k, if I could do a something mroe direct like:

llSay(0,llGetStringVar("script2","foo");

or

integer foo = llCall("script2","function",["arg1",2,3,"arg4]);

At least then we could more easily use multiple scripts to get around the 16k limitation, plus have the additional benefit of function libraries.

You might benefit from taking a course in assembly language. You can learn a lot about these things. LSL, PHP, Java, Z-machine code, perl 6, and anything else that is byte-compiled spends some time in an intermediate stage which is essentially assembly language for whatever architecture (VM) it will run on.

Relative rather than absolute jumps will take care of most of the problems. They probably use these anyway, as they require less space to store. Rearranging memory in all running scripts is fairly straightforward (although time consuming) once you select a method for doing it. All the jumps and variables are just pointers to memory locations, and rearranging them should not be too cumbersome. Some operating systems do this all the time. Solaris is notorious for doing this - it makes it somewhat slower than other unices, but when the machine is getting hammered, it stays up because it took the time to keep all its ducks in a row.

At the machine level, things are generally laid out like this...

1. Code segment - Your compiled code lives here. Usually it grows up from the bottom of the allocated memory space.
   
2. Data segment - Your data lives here. I think they allocate and free it at runtime. It would be logical to assume that it starts at the end of the code segment and grows upwards in the memory space.
   
3. Instruction pointer - This points to the current compiled instruction being executed within the code segment. (Some architectures call it instruction pointer, others call it program counter.)
   
4. Stack pointer - This is the index into the stack, which usually grows down from the top of the memory space. Every time you call a function, the current instruction pointer is pushed onto the stack, and then all the variables that are being passed to the function. The VM branches to the address where the function lives and pops all the variables passed to the function into local copies within the function itself. (In other words, it goes by value, not by reference. If it was by reference, it would pass the pointers instead.) When the function returns, it pops the return address off the stack and the VM branches to the instruction following. Any return variables are also passed back to the caller via the stack.
   

In order to rearrange memory, you would have to freeze the script, move everything to the new memory space, trace up through the stack, grab all the data and pointers to data, arrange it in its new space, and then let the script resume. You have to do it just right, but the algorithms to make it happen are very old and well-understood. I remember using 'renum' to redo the line numbers in BASIC programs on an old TI-99/4A computer from the 80s. It took care of all the GOTOs and GOSUBs and READ DATAs and other crap.

Ja, and maybe they could even guarantee it to work, unlike link messages which get dropped sometimes.

I am extremely interested in specific cases and examples of link messages failing. My experience has always been that the only way they get lost is if you flood them so the event queue fills up and you lose some. That will happen with any event. llCall as Alondra outlined wouldn't be suspect to that one because its not triggering an event. However if you or anyone has an example of a script that loses messages for some reason besides too many events at once, please let me know and send me an example if you could.

Not only do they get dropped, but many queued slow down the script's execution.

Try sending a couple in quick succession in a sim that is busy. One of them might be dropped. I have seen it happen from time to time.

Yes, at least my experience of dropped linked messages is due to the event queue filling. However, this usually occurs due to dips in sim performance or whatnot. Perhaps I rely too much on timing (and a lot of time the favorable condition of Kissling as far as speed). But wiithout implementing a full error correct method (i.e. sending confirmation messages to link messages), there is no nice way to ensure that things are executing (and thus clearing the queue) in the order/timing/speed desired. And the "error correction" ordeal would of course quite negatively impact script execution.

Basically, one of the main benefits I see with llCall (and I believe I recall other ideas for similar implementations in the past) is the ability to have greater control over the floodgates.

[Hope this make sense.. I feel like poop and my head is kinda working in VIC20 time]

BTW the other day it happened to me in one of the vehicle sims, obviously not very busy at all. I sent two link messages in quick succession and one of them didn't make it. You just can't rely on them for anything critical, unless you build in error correction.