[Are you afraid of the future?]

I believe the future will get worse before it gets better. When AI becomes advanced enough to drive out humans from most jobs, that's going to cause some big issues, but I think it will eventually even out, depending on how we proceed. A life of humans and robots coexisting and not having to worry about working to pay the bills could be nice.

[Getting OpenJPEG 2+ to work?]

8 hours ago, Henri Beauchamp said:

OpenJPEG v1.5 and newer got totally crippled for SL usage purposes. The JPEG2000 level of details plain does not work with those versions (they can only decode textures successfully at full LOD), and JPEG2000 encoding is also bogus with them.

That's why I kept OpenJPEG v1.4.0.635, fixed/improved with many patches, either backported from newer versions for security fixes, or created by me (and recently from Kathrine Jansma  for an AVX2 optimization) for the Cool VL Viewer (the patched version has been made part of my viewer sources for these reasons)...

However, please be aware that the ”rainbow textures” you are experiencing may also be the result of bugs in libcurl's HTTP pipelining code (the only 100% working and safe version of libcurl with regard to pipelining is v7.47 with LL's patches, as used by default in my viewer)...

Mind if I snag your version of it?

[Getting OpenJPEG 2+ to work?]

I've been fiddling with compiling the official viewer, and it seems OpenJPEG 1.5 is broken in the latest build. I've looked around and found Kitty Barnett's patch in Catznip for v2.3, which sorta works, but I've noticed when textures aren't fully loaded, they appear corrupted looking.

I've noticed that Firestorm is using v2.4 for OS builds, and I can't figure out what they did to make it fully work.

Any help on this would be appreciated.

[A Tool For Writing LSL Scripts In Another Programming Language]

15 hours ago, Profaitchikenz Haiku said:

Yes, but from my Fortran days I would immediately look at sparse arrays as the best solution to this. In effect they were lists of lists.

Multidimensional lists can be done with one list using math to get the true index of an item. They can't be jagged arrays though from what I can figure out, as that would require traversing the list, and keeping track of how many items is in each sub-list, which adds a lot of overhead. I hope that makes sense.

[A Tool For Writing LSL Scripts In Another Programming Language]

5 minutes ago, Mollymews said:

ah! I see now what you are intending. To write a compiler that outputs CIL which can be executed on the runtime server ? yes ?

Not exactly. What I wanted to do was make a "transpiler" (https://en.wikipedia.org/wiki/Source-to-source_compiler ), which would just translate some source code into LSL that could then be copy-pasted into the viewer's editor.

[A Tool For Writing LSL Scripts In Another Programming Language]

1 hour ago, Mollymews said:

If you are going down the path of make LSL look like other languages, I wouldn't mind being able to use named linkset properties.

for example there is a linkset with names say: Crate, Apples, Bananas, Carrots. Where Crate is the root prim. Apples is the first linked prim (link number 2)

then in code I can write

Apples.Texture = [1, "red", SELF, SELF, SELF];

the pre-processor knows to translate this to LSL:

llSetLinkPrimitiveParamsFast(LINK_SET, [PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 1, "red", <repeats>, <offsets>, 'rot']);

SELF means get the existing <repeats> <offsets> and 'rot' from the prim and insert the values into llSetLink...

extended example:

Apples.Texture = [1, "red", SELF, SELF, SELF, 2, SELF, SELF,SELF, 90.0];

translation:

llSetLinkPrimitiveParamsFast(LINK_SET, [
    PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 1, "red", <repeats>, <offsets>, <rot>,
        PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 2, surface2name", <repeats>, <offsets>, 90.0]);

then the most complex:

Apples.Texture = [ALL_SIDES, "red", SELF, SELF, SELF];

llSetLinkPrimitiveParamsFast(LINK_SET, [
    PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 1, "red", <repeats>, <offsets>, <rot>,
        PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 2, "red", <repeats>, <offsets>, <rot>,
        
        .. for each surface of Apples 3, 4, 5, etc
]);

named properties for all the others also. Like Apples.Color = [...]  Apples.Text = [...] etc etc

then finally

Crate.Properties = [ Apples, PRIM_TEXTURE, ALL_SIDES, "green", SELF, SELF, SELF,
                     Bananas, PRIM_TEXTURE, 1, "yellow", SELF, SELF, 90.0,
                     Carrots, PRIM_COLOR, ALL_SIDES, <1.0,0.5,0.0>, SELF]
                   ];

the pre-processor flagging a error when a named link is not found

This is a pretty interesting idea, but I'm not sure if I want to mess around with the preprocessor. Still would be cool to have though.

[A Tool For Writing LSL Scripts In Another Programming Language]

I would like the community's opinion on this subject to see if it's a worthwhile project to pursue.

For a while now, I've been thinking about creating a program that lets you write LSL scripts in another programming language, such as Python, or Java. With such a thing, you could introduce new abstractions to LSL like classes, dictionaries, switch statements, and shortcuts for tedious code. However, there's a lot of differences between these languages, so there would be some inescapable oddities like requiring typecasts on list items.

I'm confident that I would be able to create this tool by myself, but I would like to know what other people think of such an idea. Which source language would people prefer to use for writing LSL scripts?

Thanks for your time!