What is the Upper limit of LSL and its functions?

[MrBalloone]

Could I for example:

Rewrite an Open-Source Emulator in LSL?

Run Linux? An example of this would be to have a laptop in game, running Linux. Or something like a game console.

And of course there is never a debate like this without the following question:

Can it run Doom?

 

I honestly want to know what is the limit to LSL and\or Second Life's capabilities?

[Lucia Nightfire]

No.

[Mollymews]

we can play some browser based games from within SL with MOAP (media on a prim)

is also possible to add a LSL interface to a browser game using HTTP but the browser game would need a HTTP API to do so

http://wiki.secondlife.com/wiki/LlSetPrimMediaParams

http://wiki.secondlife.com/wiki/LlHTTPRequest

 

[Wulfie Reanimator]

LSL can easily run a raycasting engine like seen in Doom or Wolfenstein. One example can be found here, although it only has player movement and static walls. It's only one script, too.

LSL has all the elements it needs to fully run Doom (heck, you can run Doom in Factorio using 2.2 million items on conveyor belts), just nobody has done it as far as I know.

Running an OS... I don't think that's feasible even if you had the skill and time to create it. One of the biggest problems there would be that scripts don't have a cheap way to render things. LSL is very slow, and very low on memory.

Edit: And of course, if you want to cheat like Minecraft did, yes, you can run Doom via the built-in browser.

Edited December 3, 2020 by Wulfie Reanimator

[Phate Shepherd]

I'd say about as far as you could go before losing your mind would be something like a BASIC interpreter with a text only, or very low rez B&W display. I've done 128x128 bitmap displays in SL without using MOAP. Going much beyond that and it gets complicated very fast. An 80x24 text display would be easy enough. I've seen LSL scripts for parsing math, but can't remember if it could handle variables.

 

 

[Xiija]

i've seen some video games in sl, but they used flash or sumsuch?..

i wonder what will happen to some peoples code functionality when flash goes dark in a few weeks..

https://www.adobe.com/products/flashplayer/end-of-life.html

Edited December 3, 2020 by Xiija

[Profaitchikenz Haiku]

You could try to break up the task into lots of little sub-tasks and use link-messages to communicate between them. You can work around the upper memory limit of 64K this way. The limits them become the maximum number of scripts you can stuff into a linkset. Speed-wise, though, it's going to be a crawler.

[Rider Linden]

LSL is Turing Complete.  So in theory you could do any of projects that you outlined.

In practice however, that way lies madness, and you would probably not want to tackle them for any reason other than the perverse pleasure of bringing such a horror into the world.

You would need to operate in rather severe memory constraints. You could work around this by dividing the logic and memory usage among multiple scripts each handling a specific function (how very Minsky!).  This strategy however will start to run into limits with script timing since the number of scripts needed would balloon quickly and the simulator only has so much time each frame to execute scripts.  I/O will also be a problem, your storage would be limited to volatile script state memory and graphics could be done, after a fashion, but would be to slow for a real time display. 

I once saw a Mandelbrot Zoomer done in LSL where each "pixel" on the screen was a small cube in a linkset. I'll see if I can find the video. 

[Wulfie Reanimator]

6 hours ago, Rider Linden said:

I once saw a Mandelbrot Zoomer done in LSL where each "pixel" on the screen was a small cube in a linkset. I'll see if I can find the video. 

Never let it be said I didn't do anything nice for you.

Source:

#define FIRST_LINK  1
#define W           16
#define H           16
#define MAX_ITER    256.0

vector  cmin = <-2, -2, 0>;
vector  cmax = < 2,  2, 0>;
vector  offset = <0, 0, 0>;
float   scale = 1.0;

adjust_scale(float factor)
{
    cmin *= factor;
    cmax *= factor;
    scale *= factor;
}

float iterations(vector c)
{
    vector z;
    vector next;

    integer i;
    while (i < MAX_ITER && llVecDist(z, ZERO_VECTOR) < 2)
    {
        next.x = (z.x * z.x) - (z.y * z.y) + c.x;
        next.y =           (2 * z.x * z.y) + c.y;
        z = next;
        ++i;
    }

    return (i / MAX_ITER);
}

render_mandelbrot()
{
    // Little fake "screen refresh effect"
    llSetLinkPrimitiveParamsFast(LINK_SET, [PRIM_COLOR, ALL_SIDES, <0.1, 0.1, 0.1>, 1]);

    integer x;
    integer y;
    vector c;
    for (y = 0; y < H; ++y)
    {
        for (x = 0; x < W; ++x)
        {
            c.x = cmin.x + (x / (W - 1.0) * (cmax.x - cmin.x)) + offset.x;
            c.y = cmin.y + (y / (H - 1.0) * (cmax.y - cmin.y)) + offset.y;

            float iter = iterations(c);
            llSetLinkPrimitiveParamsFast(FIRST_LINK + (W * y + x),
                [PRIM_COLOR, ALL_SIDES, <iter, iter, iter>, 1]);
        }
    }
}

default
{
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
    }

    run_time_permissions(integer perm)
    {
        llTakeControls(0
            | CONTROL_UP         // Zoom in
            | CONTROL_DOWN       // Zoom out
            | CONTROL_FWD        // Move up
            | CONTROL_BACK       // Move down
            | CONTROL_ROT_LEFT   // Move left
            | CONTROL_ROT_RIGHT, // Move right
            TRUE, FALSE);
        render_mandelbrot();
    }

    touch_start(integer n)
    {
        if (llDetectedKey(0) == llGetOwner())
            llReleaseControls(); // Freedom!
    }

    control(key id, integer hold, integer press)
    {
        if ((press & hold) == FALSE)
        {
            return; // Early exit for frequent hold/release events.
        }

        if (press & CONTROL_UP)
        {
            adjust_scale(0.9);
        }
        else if (press & CONTROL_DOWN)
        {
            adjust_scale(1.1);
        }
        else if (press & CONTROL_FWD)
        {
            offset.y += -1 * scale;
        }
        else if (press & CONTROL_BACK)
        {
            offset.y += 1 * scale;
        }
        else if (press & CONTROL_ROT_RIGHT)
        {
            offset.x += 1 * scale;
        }
        else if (press & CONTROL_ROT_LEFT)
        {
            offset.x += -1 * scale;
        }

        render_mandelbrot(); // After every input!
    }
}

The "screen" is made up of 256 links, Second Life's maximum limit for a single linkset. Doing that by hand is extremely tedious, so I used this script to create a correct grid after I linked 256 cubes together:

default
{
    state_entry()
    {
        float s = 0.1; // Short for "size" per cube...
        llSetLinkPrimitiveParamsFast(LINK_SET, [PRIM_SIZE, <s,s,s>]);
        integer y;
        integer x;
        for (y = 0; y <= 16; ++y)
            for (x = (y != 0); x <= 16; ++x)
                if (16*y+x > 1)
                    llSetLinkPrimitiveParamsFast(16*y+x, [PRIM_POS_LOCAL, <(s * x - s), 0, (-s * y)>]);
    }
}

P.S. The above script reminded me of how much I absolutely hate the link numbering in SL.

Edited December 4, 2020 by Wulfie Reanimator

[Rider Linden]

43 minutes ago, Wulfie Reanimator said:

Never let it be said I didn't do anything nice for you.

Now, THAT is pretty sweet!

This conversation has me thinking about how to port something like Frotz into LSL...

I mean, who wouldn't want to play Zork on a prim!

[Ardy Lay]

I have a copy of adevice called Mandelbrot Explorer 0.1 that was build of prims by Uchi Desmoulins and scripted by Babbage Linden that has 35 x 35 resolution using 248 prims and renders in colors.  I have had it since Sept 18th, 2008.

 

[Wulfie Reanimator]

4 hours ago, Ardy Lay said:

I have a copy of adevice called Mandelbrot Explorer 0.1 that was build of prims by Uchi Desmoulins and scripted by Babbage Linden that has 35 x 35 resolution using 248 prims and renders in colors.  I have had it since Sept 18th, 2008.

Ah, I know what they did. They used the twisted + path-cut + hollow cube-trick to get 5 forward-facing surfaces, then formed the biggest square grid they could (35 rows, 7(*5) columns).

Coloring fractals isn't particularly hard, you can assign specific colors to specific "ranges of iterations" or even interpolate between two colors to get smoother colors, but the resolution doesn't really let you appreciate the different colors because there simply isn't enough room for you to see them.

You did give me some inspiration to improve my script though. With mesh, we can easily have a clean grid of 8 faces per object. I created a 48x42 display from 252 mesh pieces (42 rows, 6(*8) columns). I'll probably put this on the LSL Library and/or my Marketplace (for free and fullperm) later.

To bring this back on topic a bit, you can tell that even Mono struggles to get the workload done for each draw.

• Those black pixels on the "inside" of the Mandelbrot shape are maxing out at 256 iterations (arbitrary limit, we could decrease it for a faster/less accurate image), so the script does speed up a bit when there's less of the "inside" in view.
• I also had to start grouping those color updates together, displaying them one pixel at a time was already way too slow.
• I couldn't store all of the pixels until the whole display could be updated, because the script would run out of memory.
• Both the speed and memory issues could be improved with "multi-threading" the process with multiple scripts, since this specific thing is very easy to parallelize. To do something like that on a larger scale is definitely the path of madness.

Edited December 5, 2020 by Wulfie Reanimator

[Lucia Nightfire]

Some of the game making/operating problems/limitations I deal with in SL:

• 45 FPS environment
• 32 bit integers, floats
• 64 KB max script size
• 64m scaling limit
• 54m encompassed link limit
• No scriptable UI
• No backed real world programming language w/ full library of unnerfed functions with unnerfed operation
• No way to turn off interpolation at the agent/object/link level with position/rotation/scale changes
• No way for multiple scripts to synchronously access/change a single shared global memory source (memory, not data)
• No way for scripts to directly manipulate prim properties of other objects.
• No way to have surrogate regulated/themed avatars replace user avatars and every single one of their attachments
• No way to block wearing of unregulated/unaffiliated attachments on game regions/parcels
• No way to prevent unregulated/unaffiliated attachment scripts from running on game regions/parcels
• No way by script to put someone into flying mode or take them out (w/o collisions or sitting)
• No way to prevent rendering of out-of-bounds objects/areas
• No conditional viewer-side object param changes. (tree fades the closer user's camera gets to it, roof/floors/objects of building in overhead view disappears when a user walks inside or goes up/down floors)(only the visual change is seen by the user of interest)
• No scripted highlighting effects (think of shooter games that can show highlighted/outlined enemies behind walls/doors)
• No way to allow click-through action on transparent faces. (setting touch disabled does not allow click-through)
• No viewer-side tracked rag dolls, dynamic bones, colliders
• No insertable/updateable IKs with animation assets
• No procedural animation generation capability
• No animation parameter overriding (priority, start frame, stop frame, FPS, easing, looping)
• No animation global start time reference (animation just plays fro the beginning once it is downloaded from CDN)
• No preloading of animations without using invisible animesh in FoV
• No way to instantly stop animations that have loop outs (prevent the rest of the loop and loop-out from playing)
• No Animesh scaling with bone auto-retargeting, body shape manipulation or unrigged link attach point assigning
• No animesh visual orientation by link pos/rot capability (animesh is oriented by the root link's forward x axis)
• No scripted camera control in mouselook
• No way by script to put someone into mouselook aside from sitting, no way to take them out of mouselook
• No way for scripts to get camera focus position
• No way by script to have the camera place auto-focus on an agent/object w/ offset. (not just looking at an agent/object, but auto-following it when it moves/rotates without constantly setting new cam params causing a horrible chop effect)(mimic alt camming, but by script)
• No way by script to specify if an object/link is seen in mouselook. (only show everything attached/rigged to arm/hand during mouselook sword strikes)(only show arms/legs/bits during mouselook naughty scenes)
• No viewer-side linear/grid/looped based visual prim parameter animating (color transitions, light flicker/transitioning, alpha transitioning)(server-side is update intensive)
• No "Inverted" prim param to invert BOTH applied color and texture colors. (good for selection indicators and macabre effects)
• No mouse scroll wheel control input taking.
• No collision channels (don't let bullets from team members collide with each other & their owners, only universal targets or adversaries)
• No tailorable mouseover/hoverover text for object/HUD faces (custom popup text)
• No global sound start time reference (allows synched sounds and correct sound starting point, not just when CDN download completes)
• No true stereo sound (L/R channels)
• No queueing of more than 2 sounds (llSetSoundQueueing() only does 2)
• No sound param overriding (start time, stop time, amplitude)
• No "link" method of playing sounds (scripts must be in each link that needs to play a sound)
• No environment modulation effects (muffled sounds, sound deflection, reverb, pitch bending)

I could list 100 or more issues, but at this point I'm depressed. Maybe in another post, heh.

 

Edited December 5, 2020 by Lucia Nightfire

[MrBalloone]

1 hour ago, Lucia Nightfire said:

Some of the game making/operating problems/limitations I deal with in SL:

• 45 FPS environment
• 32 bit integers, floats
• 64 KB max script size
• 64m scaling limit
• 54m encompassed link limit
• No scriptable UI
• No backed real world programming language w/ full library of unnerfed functions with unnerfed operation
• No way to turn off interpolation at the agent/object/link level with position/rotation/scale changes
• No way for multiple scripts to synchronously access/change a single shared global memory source (memory, not data)
• No way for scripts to directly manipulate prim properties of other objects.
• No way to have surrogate regulated/themed avatars replace user avatars and every single one of their attachments
• No way to block wearing of unregulated/unaffiliated attachments on game regions/parcels
• No way to prevent unregulated/unaffiliated attachment scripts from running on game regions/parcels
• No way by script to put someone into flying mode or take them out (w/o collisions or sitting)
• No way to prevent rendering of out-of-bounds objects/areas
• No conditional viewer-side object param changes. (tree fades the closer user's camera gets to it, roof/floors/objects of building in overhead view disappears when a user walks inside or goes up/down floors)(only the visual change is seen by the user of interest)
• No scripted highlighting effects (think of shooter games that can show highlighted/outlined enemies behind walls/doors)
• No way to allow click-through action on transparent faces. (setting touch disabled does not allow click-through)
• No viewer-side tracked rag dolls, dynamic bones, colliders
• No insertable/updateable IKs with animation assets
• No procedural animation generation capability
• No animation parameter overriding (priority, start frame, stop frame, FPS, easing, looping)
• No animation global start time reference (animation just plays fro the beginning once it is downloaded from CDN)
• No preloading of animations without using invisible animesh in FoV
• No way to instantly stop animations that have loop outs (prevent the rest of the loop and loop-out from playing)
• No Animesh scaling with bone auto-retargeting, body shape manipulation or unrigged link attach point assigning
• No animesh visual orientation by link pos/rot capability (animesh is oriented by the root link's forward x axis)
• No scripted camera control in mouselook
• No way by script to put someone into mouselook aside from sitting, no way to take them out of mouselook
• No way for scripts to get camera focus position
• No way by script to have the camera place auto-focus on an agent/object w/ offset. (not just looking at an agent/object, but auto-following it when it moves/rotates without constantly setting new cam params causing a horrible chop effect)(mimic alt camming, but by script)
• No way by script to specify if an object/link is seen in mouselook. (only show everything attached/rigged to arm/hand during mouselook sword strikes)(only show arms/legs/bits during mouselook naughty scenes)
• No viewer-side linear/grid/looped based visual prim parameter animating (color transitions, light flicker/transitioning, alpha transitioning)(server-side is update intensive)
• No "Inverted" prim param to invert BOTH applied color and texture colors. (good for selection indicators and macabre effects)
• No mouse scroll wheel control input taking.
• No collision channels (don't let bullets from team members collide with each other & their owners, only universal targets or adversaries)
• No tailorable mouseover/hoverover text for object/HUD faces (custom popup text)
• No global sound start time reference (allows synched sounds and correct sound starting point, not just when CDN download completes)
• No true stereo sound (L/R channels)
• No queueing of more than 2 sounds (llSetSoundQueueing() only does 2)
• No sound param overriding (start time, stop time, amplitude)
• No "link" method of playing sounds (scripts must be in each link that needs to play a sound)
• No environment modulation effects (muffled sounds, sound deflection, reverb, pitch bending)

I could list 100 or more issues, but at this point I'm depressed. Maybe in another post, heh.

 

The way this sounding is that if someone was to create a similar service to SL but dramatically improve on everything, It may pull people away from SL.

That and It is sounding like porting Doom is gonna be harder then I first thought.

[Profaitchikenz Haiku]

3 hours ago, Lucia Nightfire said:

Some of the game making/operating problems/limitations I deal with in SL:

Seriously, it's challenges like this give me a reason to get out of bed each morning.

[bigmoe Whitfield]

2 hours ago, MrBalloone said:

The way this sounding is that if someone was to create a similar service to SL but dramatically improve on everything, It may pull people away from SL.

That and It is sounding like porting Doom is gonna be harder then I first thought.

then again, we are not going anywhere even if some body creates better,  we know where home is.

[Nova Convair]

What Lucia says and some more.

But

That means that LL runs a processing host. Not a problem for the Amazon cloud but that's not for free.

Of course you can't give that away for free. People would  play Doom and mine bitcoins. 😁 It's not a problem - but only if they have to pay for it on their own. 😎

[Ardy Lay]

Maybe somebody needs to buy a computer and stop trying to get LL to give them free access to the simulator host operating systems.

[Phate Shepherd]

9 hours ago, MrBalloone said:

The way this sounding is that if someone was to create a similar service to SL but dramatically improve on everything, It may pull people away from SL.

That and It is sounding like porting Doom is gonna be harder then I first thought.

Funny you say that. Linden Lab created Sansar to do just that... after years of development, it didn't work out as expected.

It used c# as its script engine.

Many will argue about why it didn't succeed, but in the end, having "better" technology  isn't always the  solution.

[Ardy Lay]

7 minutes ago, Phate Shepherd said:

Funny you say that. Linden Lab created Sansar to do just that... after years of development, it didn't work out as expected.

It used c# as its script engine.

Many will argue about why it didn't succeed, but in the end, having "better" technology  isn't always the  solution.

Sansar seemed to harbor a lot of people that were proud to be banned from Second Life.

[Wulfie Reanimator]

1 hour ago, Phate Shepherd said:

Funny you say that. Linden Lab created Sansar to do just that... after years of development, it didn't work out as expected.

It used c# as its script engine.

Many will argue about why it didn't succeed, but in the end, having "better" technology  isn't always the  solution.

Frankly, the C# implementation in Sansar was tosh. You had no precise control over literally anything, never mind the almost nonexistent documentation.

That's why I left, anyway. I'd rather work with the horror that is LSL than what we had in Sansar.

As to @Lucia Nightfire's very accurate and true list, it's not exactly applicable to 2D games that can't make use of most SL features, like Doom. Doom is notorious for being ported on the most unlikely places, like digital cameras, fridges and toasters, or the display of a pregnancy test. Kinda. If you strip away enough detail, it might be possible in LSL but simply updating colors on a 64x32 screen would be too slow for "real time" play. It would probably have to be viewed similarly to the Factorio video I linked earlier, where the footage is sped up a lot.

Edited December 5, 2020 by Wulfie Reanimator

[Profaitchikenz Haiku]

Doom has even been ported to Youtube...

[animats]

The upper limit of LSL is  rather low. After spending a year cramming an entire NPC system into LSL, I have to say it took about 3x as long as in a more reasonable programming language. The language itself isn't that bad. Structs and arrays would be nice.

The lack of memory space, and in particular being able to run out of stack unexpectedly, was the biggest headache. You can track your heap usage and avoid allocations when tight, but there's less control over stack usage. A big incoming message or system call return can blow the stack. This is a big problem for scripts doing something highly dynamic.

I'd like to have stack space not counted against the 64K limit. When a script is not processing an event, the stack is empty. It's only transient usage, so you're not using much sim resources with the stack.  Some reasonable limit to prevent runaway recursion, such as 64KB of stack in addition to code and data, would be fine.

Lucia has many useful comments about the SL API, which is a separate issue from the language.

How much you should be able to do from LSL, and how fast, is a complex issue. LSL is only semi real time. With script overload the new normal, it's hard to do real time anything from LSL.

The trick that makes my NPCs work is assuming script performance will be poor, and computing all moves just before they start. All their motion is keyframe animation, planned a few seconds before it's executed. If you see one of my NPCs with its arms folded, the planner, written in LSL, is computing busily, trying to get enough CPU time to find a path for the next move. On a lightly loaded sim, movement is continuous.

Built-in pathfinding works great in an empty sandbox. This is a LL video from 9 years ago. All the right concepts, but not enough CPU power to make it go.

Built-in SL pathfinding is making steering corrections in real time, and totally falls apart under overload. It will overshoot and hit things because the steering corrections have fallen behind. SL pathfinding will work at slow speeds in open spaces, but it's hopeless in tight spots or at high speed.

This is what LL pathfinding looks like in an overloaded sim.

This is why we can't have highly dynamic scripted objects grid-wide no matter what calls LSL has.

[Kyrah Abattoir]

On 12/5/2020 at 10:07 AM, Lucia Nightfire said:

Some of the game making/operating problems/limitations I deal with in SL:

• 45 FPS environment
• 32 bit integers, floats
• 64 KB max script size
• 64m scaling limit
• 54m encompassed link limit
• No scriptable UI
• No backed real world programming language w/ full library of unnerfed functions with unnerfed operation
• No way to turn off interpolation at the agent/object/link level with position/rotation/scale changes
• No way for multiple scripts to synchronously access/change a single shared global memory source (memory, not data)
• No way for scripts to directly manipulate prim properties of other objects.
• No way to have surrogate regulated/themed avatars replace user avatars and every single one of their attachments
• No way to block wearing of unregulated/unaffiliated attachments on game regions/parcels
• No way to prevent unregulated/unaffiliated attachment scripts from running on game regions/parcels
• No way by script to put someone into flying mode or take them out (w/o collisions or sitting)
• No way to prevent rendering of out-of-bounds objects/areas
• No conditional viewer-side object param changes. (tree fades the closer user's camera gets to it, roof/floors/objects of building in overhead view disappears when a user walks inside or goes up/down floors)(only the visual change is seen by the user of interest)
• No scripted highlighting effects (think of shooter games that can show highlighted/outlined enemies behind walls/doors)
• No way to allow click-through action on transparent faces. (setting touch disabled does not allow click-through)
• No viewer-side tracked rag dolls, dynamic bones, colliders
• No insertable/updateable IKs with animation assets
• No procedural animation generation capability
• No animation parameter overriding (priority, start frame, stop frame, FPS, easing, looping)
• No animation global start time reference (animation just plays fro the beginning once it is downloaded from CDN)
• No preloading of animations without using invisible animesh in FoV
• No way to instantly stop animations that have loop outs (prevent the rest of the loop and loop-out from playing)
• No Animesh scaling with bone auto-retargeting, body shape manipulation or unrigged link attach point assigning
• No animesh visual orientation by link pos/rot capability (animesh is oriented by the root link's forward x axis)
• No scripted camera control in mouselook
• No way by script to put someone into mouselook aside from sitting, no way to take them out of mouselook
• No way for scripts to get camera focus position
• No way by script to have the camera place auto-focus on an agent/object w/ offset. (not just looking at an agent/object, but auto-following it when it moves/rotates without constantly setting new cam params causing a horrible chop effect)(mimic alt camming, but by script)
• No way by script to specify if an object/link is seen in mouselook. (only show everything attached/rigged to arm/hand during mouselook sword strikes)(only show arms/legs/bits during mouselook naughty scenes)
• No viewer-side linear/grid/looped based visual prim parameter animating (color transitions, light flicker/transitioning, alpha transitioning)(server-side is update intensive)
• No "Inverted" prim param to invert BOTH applied color and texture colors. (good for selection indicators and macabre effects)
• No mouse scroll wheel control input taking.
• No collision channels (don't let bullets from team members collide with each other & their owners, only universal targets or adversaries)
• No tailorable mouseover/hoverover text for object/HUD faces (custom popup text)
• No global sound start time reference (allows synched sounds and correct sound starting point, not just when CDN download completes)
• No true stereo sound (L/R channels)
• No queueing of more than 2 sounds (llSetSoundQueueing() only does 2)
• No sound param overriding (start time, stop time, amplitude)
• No "link" method of playing sounds (scripts must be in each link that needs to play a sound)
• No environment modulation effects (muffled sounds, sound deflection, reverb, pitch bending)

I could list 100 or more issues, but at this point I'm depressed. Maybe in another post, heh.

 

Eventually we will get LL to accept most of these It might take a few more years.

[Kyrah Abattoir]

On 12/3/2020 at 11:51 AM, MrBalloone said:

Could I for example:

Rewrite an Open-Source Emulator in LSL?

Run Linux? An example of this would be to have a laptop in game, running Linux. Or something like a game console.

And of course there is never a debate like this without the following question:

Can it run Doom?

 

I honestly want to know what is the limit to LSL and\or Second Life's capabilities?

Honestly your first limit is that scripts have 64K of memory for both the compiled program and the memory during execution.

And sure you can communicate between scripts but this is not going to be fast, free, or synchronous.