animats

Yes. Visit the south end of Corsica and head west on the coast road, and you'll see a few large signs on tiny parcels. File ARs. Oversize, encroaches on Linden land, glows - all reasons to AR. Amusingly, the biggest ones are ads for ad space. They don't have actual customers or revenue. They seem to have bought up some of those little "Taxi" ad stands and put huge signs on them. So much uglyness with no benefit to anyone. (Corsica really needs some more roads through the under-utilized abandoned land in the interior. Once you get 100m from road or sea, it's mostly bleak abandoned land. LL might plant forests on abandoned land. If they used good trees, SL could have leaf tourism.)

There's an SL history museum near the Ivory Tower, but it's not year by year.

2017-2019 is rather depressing. 2017: "Linden Lab gives premium members the ability to view 90 days of their transaction history."

Very nice. Much like Hangars Liquides. I look forward to the opening.

Designating some streets as "through routes" and using a different pavement marking would be a nice touch. No LI cost. Then you could drive around without having to have the world map open.

That's working now in the viewer. In Preferences, set "Number of non-impostor avatars" to about 3. The viewer will no longer choke on large numbers of avatars. The sim still will.

Yes. Draw a crowd in SL and the sim overloads. This is a severe limitation on SL. I think it's technically possible to fix that within the current architecture, but it's a bigger job than the current dev team can tackle. And once it worked, you'd need multiple CPUs per sim, running up server costs.

Thanks for all that work. "NoGeometry" is not unexpected. That's a documented feature in the mesh file format: ""NoGeometry" -- optional, boolean, must be true -- If present, there is no geometry for this submesh. This submesh is just a placeholder to let the simulator/viewer know that there is a texture entry for this submesh with no geometry at this LoD. No additional fields may be specified if "NoGeometry" is present." - from http://wiki.secondlife.com/wiki/Mesh/Mesh_Asset_Format A bit ugly, but gets the job done. Right. That's why I originally wanted this. I wrote an impostor generator for Blender which generates a low-LOD mesh with a new material not present in the higher detail LODs-. I didn't want to modify the user-created higher level of detail model, adding dummy triangles and materials. That would confuse the user, and possibly mess up something they're doing. Mesh cleanup on their model might delete the dummy triangles, for example. Some mesh functions will try to do something with the dummy triangles, confusing the user. Running the impostor generator more than once might add dummy geometry on each rerun, and preventing that requires bookkeeping data somewhere. So, not a good solution. I read the documentation and found the "NoGeometry" file data item. If only I could generate that... Yes. The Firestorm uploader has useful messages about what matches and what doesn't match across LODs. But the messages are in the "Firestorm.log" file, which only developers read. If those messages were displayed to the end user during uploads, there would be much less confusion about material and object matching problems. Thanks for chasing this down. Now what?

There used to be a "Route 66" sim which was a small town in the middle of a big empty desert. It's gone. Nobody can afford a big empty desert in SL. I'd like to have long roads through unpopulated woods, open country, mountains, and such, connecting some points of interest. That's sort of what "open space" sims are for, but they are not used much. We do have that long open water route between Bellesaria and Jeoghot now, but there's nothing comparable with land.

Nice. Looks like Sky Captain and the World of Tomorrow. How big is this space?

Thanks. Somehow the built-in LOD generator pulls this off. Tiny triangles? Degenerate triangles? I dunno.

Er, yes. Censored to avoid naming and shaming, per policy. This thing is huge. 25 meters high on a 4m x 4m parcel. That's a standard size Linden road in the background. The sign overhangs the road. This one is in Corsica. There are probably more.

Some test results: [23:57] Array update timing test 0.3: Timing tests. [23:57] Array update timing test 0.3: Fill array of 1024 in 2.313786 secs. [23:57] Array update timing test 0.3: 1024 updates to list of 1024 elements in 4.798160 seconds. [23:57] Array update timing test 0.3: Fill array of 512 in 0.421613 secs. [23:57] Array update timing test 0.3: 1024 updates to list of 512 elements in 2.094694 seconds. [23:57] Array update timing test 0.3: Fill array of 256 in 0.088729 secs. [23:57] Array update timing test 0.3: 1024 updates to list of 256 elements in 1.275658 seconds. [23:57] Array update timing test 0.3: Fill array of 128 in 0.039960 secs. [23:57] Array update timing test 0.3: 1024 updates to list of 128 elements in 0.670230 seconds. [23:57] Array update timing test 0.3: Fill array of 64 in 0.039129 secs. [23:57] Array update timing test 0.3: 1024 updates to list of 64 elements in 0.674368 seconds. [23:57] Array update timing test 0.3: Fill array of 32 in 0.000000 secs. [23:57] Array update timing test 0.3: 1024 updates to list of 32 elements in 0.601021 seconds. [23:57] Array update timing test 0.3: Done Performance is independent of list length up to 128. Then it gets worse, linearly. So using multiple lists no longer than 128 seems to be an useful optimization.

I doubt there's a faster way, but I'll ask anyway. Is there any way to update a single element in a list, by index, that's faster than llList2List? I know, lists are immutable and a new one has to be created for every update. I was hoping that, just perhaps, there was a built in Mono optimization for lst = llList2List(lst, [n], ix, ix); which could, if recognized by the compiler as a special case, be done very efficiently. But there's not. Making 1024 random updates to a list of 1024 integers takes 4 seconds in Animesh 1 on the beta grid and 8 seconds in my home sim. Because, of course, it's recopying the whole list for every update. Is there any trick for manipulating large arrays in LSL? (I'm trying to write an A* algorithm. Doing this in LSL is like pounding a screw.)

Missed that. Is there a video?