Rick Nightingale

Have you noticed the threads here about bots? Those are a strong possibility with empty profiles, especially if the same ones visit repeatedly. However, I sometimes check out profiles of visitors on the island I am on, and it surprises me how many old accounts have empty profiles when I'm sure they are not bots, but actual people driving the avatars.

I think, given that I've repeatedly said that whitelisting is essential in the system, that your final comment is a bit reactionary and out of order.

You are making people's choice of accepting or not a bot on their land as 'need to opt out' or you get them. Why should I need to opt out of something? If someone finds the bot useful, fine they can opt in by whitelisting it. Make it 'opt in' and I won't have a problem. Having the deny-bot function in the parcel settings is as close to 'opt in' as we can get (unless it's also turned on by default, then it truly would be 'opt in'). Even in law in the UK, all online marketing and tracking stuff legally has to be specifically opt in now. Not that everyone obeys it, but at least it's been recognised. It's my choice (or should be)... and I shouldn't have someone just expecting bot access to my land unless I take action to stop them. Your assertion that I should have to take action if I do not want your bot is unacceptable. Bringing other problems into the issue like security orbs is simply irrelevant to this discussion.

@M Peccable I can see your point, but I do not think it should be a reason to not implement the deny-bot measures. Really, I'm not bothered by privacy issues in SL. What's the point? I am bothered about having bots landing on my land uninvited. It's disruptive and rude (of the operators). Real people I don't mind because I can interact with the visitor, making the disruption at least worthwhile. Even if the bot rezzes at 1000m and is invisible, I see it on the radar and find it disruptive. That would include your bots unless I have a reason to want them. I might - I used to own waterfront mainland and arranged it to facilitate passing boars (edit: I meant boats but passing boars were also welcome), so some system to aid sailors might be welcome even by me. I would probably still not allow a bot but be very willing to rez a prim to achieve the purpose. I don't see bots as an acceptable way to do anything like this for the reasons I gave at the start. It's my land and should be my choice; not being told I should accept it just because someone else wants to pop bots around for some purpose of theirs however useful and benign that might be. Just saying the bot will avoid my parcel but land in my neighbours is just moving the problem (and unreasonable expectation) to them. It's not the answer. I'm not sure what the answer is... but that's no reason to not implement systems to give us paying land owners the choice to decide what is welcome on our land.

It's a great move, thank you LL @Linden Lab. We really, really need it at parcel level on mainland as well though. @Extrude Ragu has an interesting point I hadn't thought of (probably because I've never owned an estate, so my knowledge of how all that works is vague). Whitelisting is essential to still allow 'allowed' bots in the region. It had not occurred to me that a bot could join a group and get access... if those groups are free to join and if that group whitelist overrides the bot-deny, there's a loophole. So... bots should only be allowed to evade the bot-deny if they are individually whitelisted, not just a member of a group that has access. Does that make sense to those who own estates? (I'm also thinking still of parcel-level control too... and how that applies there.)

I think Love is just making a humerous reference to a previous thread that ended up discussing if AI generated images can be considered art... as often happens it had some stong opinions on both sides (mine included - can you guess which side?) and ran the risk of people being offended. Hence the "No, wait..never mind."

Ahh... I knew about naming the .dae files like that to get them auto-selected in the uploader when I load the main file as a convenience. I didn't know that it also applied to the names of the mesh objects within the file. I always thought the different LOD files' meshes were just matched up by alphabetic sorting anyway. Renaming the objects from my original names before exporting to replace "'.PHYS" with "_PHYS" and removing the ".L3" from the LOD3 model names did indeed work; the physics models were applied in the correct order. It remains though that I've never had to name my mesh objects with the _LODn suffix to upload them before, and I've done a lot of big linksets like that. They have always been matched by sorting alphabetically, even if given different names as long as they sort in the same order. And why just the physics models being mismatched? All the LOD objects were matched together, but not the physics. I do think there is some odd behaviour in the difference between sorting the visible mesh objects and the physics objects - well, what I've done shows there is. Perhaps the uploader, looking for the "_" suffix is being confused by the other "_" characters in the object names? It seems the case since just removing all underscores from my original names and leaving my ".L3", ".L2", ".PHYS" suffixes* etc. as they were worked perfectly with 50+ objects in each set. With the underscores in, they were scrambled even though they sorted alphabetically identically. The only thing I've done differently in this project is to use a lot of underscores in the names; I usually use periods. Don't know why I changed really but I wish I hadn't. Whatever... there's a funny issue there but since I know not to provoke it now, I'll not do so (as the doctor said, if it hurts when you poke it, don't poke it.) *That's just the way I've named them since long before the _LODn suffix for filenames came along, but I will change to _LODn in the objects names from now on, just to avoid this odd sorting issue... along with avoiding any other underscores in the name,

@Wulfie Reanimator Yeah, I just read that one. At least now I know, lol. Relinking it is hardly a problem though Unlike having to rename 300 parts in Blender to remove underscores! My fingers hurt.

It's the underscores I think. I just renamed the physics names to remove the underscores (from the original name list, not Fred, and I left the L3 names with the underscores in, it still sorts in the same order) and it worked.

@EnCore Mayne In my experience the root is always random on multipart uploads. I've read that it's supposed to be in some sort of order, but never, ever have I seen anything other than random root selection. I would love to know what the 'logic' behind that is. Back to my issue... I have solved it, but not asnwered the big question: Why??? This is a screenshot of the two model lists, just to prove that they are named as I said. The data objects are named identically to the mesh, just in case: If anyone can spot a mistake in the above, that I haven't in checking it until I'm almost blind, I'll eat my hat. Now... to fix the issue, I renamed all the highlighted parts to Fred[n]. So, Fred1.PHYS, Fred1.L3, Fred2.PHYS, Fred2.L3, etc, working down the two lists. Suddenly everything worked when I uploaded it to SL. So... it seems the Mesh Uploader (because Blender has no clue that the physics model is different, only the uploader treats it differently) can't sort Door_Frame and Door_Lower_xxxx in the physics model. I've never had such an issue before. ETA: I would try to get an independent repro (different design, different PC, LL viewer, same names) and start a JIRA but I just want to get my work done for once.

This one has me well stumped... I have a build, that I've narrowed down to these five meshes after the sorting trouble started: Door_Frame.L3 Door_Lower_Left.L3 Door_Lower_Right.L3 Door_Upper_Left.L3 Door_Upper_Right.L3 The Physics models are named similarly but ending .PHYS instead of .L3. The mesh names and object names are identical. I've checked the spelling (at least 50 times) and repeatedly counted and checked the models in each set. I export the sets as Model.dae and Model_PHYS.dae. If I upload all the set as above, the Frame physics gets applied to the Lower Left door, the Lower Left door's physics gets applied to the Lower Right door... and it all goes pear shaped. With the full build, everything after the above items ends up with the wrong physics model. If I leave out the frame from both LOD3 and Physics sets, the four doors get the right physics. If I export the frame and the upper two doors, that works. My physics models are fine, the mesh is fine, everything checks out perfectly individually. However, as soon as I have the Frame and a Lower door in the export, with or without anything else, it fails and attaches the Frame's physics to whichever the Lower door is there; Left if both are. Any clues, anyone? I'm close to tearing my hair out here. I've been fighting with this for three hours now! ETA: There are no scale offsets or rotations, nothing like that. It's simply failing to sort from what I can tell. Also, it's only the physics set which is suffering this; the four LOD models (which are all named in the above format) work as expected.

You certainly can tell them apart. I wasn't always a big, handsome devil:

On the last name note, and given the last discussion I saw on the matter: I saw my first Sausage a few days ago, and it was Silly!

There's a suggestion form link in this post: Edit: ha - beaten to it. You have to be quick around here.

That sounds fun! When I used to go sailing a lot, I made a thing that displayed my real-time location in an external browser window (on a second monitor), using the SL maps API. Allowed zooming in and out, pre-loaded map tiles, also gave heading/speed/rate of climb (for flying) etc.. Worked quite well for navigation and "that bit looks interesting on the map - let's sail that way". ETA: it also had a big custom map from one of the sailing groups that I could switch to in place of the SL maps. That had sailing POIs like harbours so was quite useful.

I can't recall which forum, but I'll tell you what the issue was: When baking, if you have other mesh objects hidden near the object being baked from, they will still influence the outcome even though they are hidden. No-one ever told me that. I had my lower LOD models in the same location but hidden and that was really messing with the baking. The times my baking worked were when, just by chance, I didn't have anything else there hidden or otherwise. The answer is simple: Either move everything away, or, much easier, uncheck the little camera icon next to the mesh objects you don't want to influence the baking, in the outliner - the icon next to the 'eye' that lets you hide or show each mesh object visibly. I still consider baking a 'dark art'. Texturing in general is my weakest point because I have the artistic talent of a stone. That said, my current argument with Blender is trying to bevel a relatively simple profile on a door. Me: 'Bevel this simple edge loop around the corner of the molding'; Blender: 'Ha ha - you must be joking - look at this shading mess I can make all over it'. Three days I've been trying to get a successful, smooth-shaded bevel on the thing. While I'm far from an expert, you are always welcome to shout out in world if you want help. At the moment I'm on the beta grid a lot, arguing with mesh there.

You are absolutely right regarding all those tutorials. I've found the same things, and one can spend hours watching all of them repeating each other never to see one do that little, necessary step. I recently discovered the answer to a baking issue that has been spoiling some of my bakes, which I've spent countless hours over the last two years researching and watching videos, and never got an answer. The Blender manual doesn't mention it, at least not anywhere I've looked. I've followed tutorials to the letter on how to bake from my mesh, and it hasn't worked. I found the answer in a single sentance on a 3D forum somewhere just a few weeks ago with just the right combination of search words and reading twenty or so results, the first nineteen of which were useless. Now all my bakes work, finally! If you are making mesh for landscaping, that's a perfect use of 'Local Mesh' in Firestorm. I've used it several times now. I can make the mesh and use it in world, on the main grid, like a local texture is used without paying to upload. See the mesh on the land, go back to Blender to adjust it, refresh the Local Mesh in world... much easier than guessing how it will fit in the Beta grid. I have a meandering and up-and-down pathway across my land in Mesh now that looks like it was built right onto the land, because it was.

Cue Gold Five: "Stay on target!" No that's not a reference to weapons FTGPZS! Well, it sort of is. We have a weapon here... I don't mean a script function or an estate management checkbox. I mean the momentum of the whole thing. When I started this, with a limited idea (although a genuinely useful one that we should have) it was to, let's say, encourage action in a way that we could get behind without falling foul of the rules. Just in case that wasn't obvious from the start It's great that there is now movement to add estate level controls to our tool bag (it needs whitelist capability too). Parcel level controls would be better, and hopefully something that will come with time if we keep it in the sights. And of course the script function to easily differentiate a bot from a 'human' (or whatever sentient (or not, I guess, it is SL) species one is today). Just for my own simple experience scripting on my land that will be useful to save resources. It's not perfect. It's not a solution in itself and is open to abuse. That though is LL's department to deal with, if/when it happens that unregistered bots or even fauxbots proliferate. I'm sure such things have been are are being considered now, along with how residents feel about it all (well, I am in an optimistic mood aren't I?). If LL needs a bladerunner, I'm available for hire for a nominal fee that includes noodles. Whatever... it's a start. It means someone out there is listening and acting on it. That was the whole point. Edit: That's the sort of waffly post I make after a full bottle of red and need a break from UV mapping in Blender.

You're not wrong.

This is the way! If you have the means of course. I've been very happy on my rented 1/3 slice (but with half the region's prims) of homestead, even with neighbours.

If you do not have ALM on, there is a low limit to the maximum number of light sources the viewer will render too. I don't recall what but it's not many. With ALM on I don't think there is a fixed limit, but what I said above still happens a lot. It's a pain in my own build. One way I get around it is to make sure that light sources can only just illuminate the room they are in, by setting the distance of them, or using projectors rather than all-round point sources. That stops lights shining into the floor above too. Whatever you can do to minimise the number of lights effecting a room like that will help. I wish point source lights would stop at walls naturally instead of shining right through. You could also try linking the light source (if possible) to the ceiling, which will make the whole object still in view as long as you can see the ceiling. Must admit I've not tried that myself as my builds don't have a simple ceiling to link to like that without complications.

Flickering textures sounds like you have prims/mesh faces overlapping, perhaps with one just a tiny fraction behind the other. Move away a bit and the viewer loses the ability to differentiate them so they alternate, and one face flickers in and out of the other. Does that sound like it? It's one of the annoyances trying to build stuff from parts; SL isn't all that accurate about placement. Or... do you mean illumination is flickering on surfaces? That's usually because you have turned away from the light source. Once the light source itself is out of your field of view, the viewer tends to forget about it and the illumination goes away. Yet another annoyance.

They'll just copy it 🤣. Sorry, couldn't resist. I can imagine the WTF level of frustration, but there's really nothing that can be done. Whatever reason they have for doing it, they likely won't respond usefully to any confrontation about it. Maybe learn to make mesh and make yourself something unique? Not an easy task from the beginning but perhaps it's a good excuse to take the plunge into creating. Turn the situation to the positive for you.

I've seen worse Besides, I took a look. If I ever get the flying bug again I'll try that sleek aluminium job that's on the runway; the Recruit was it? Looks right up my street that one.

Stand up. Although I guess after four hours you've probably relogged. That's another way.