Rick Nightingale

@Zalificent Corvinus - would I be right in thinking that you don't like the change? I really do not believe anyone at LL is daft enough to listen to most of what you say will be reported; don't you think they must deal with stupid abuse reports all the time and filter them out? Nor do I think most event and shop owners are that daft*. There will be no 'Draconian Crackdown'. Yes, I'm sure it will increase LL's workload somewhat, but that is down to them. Not us. Frankly I would make making an invalid abuse report as serious an issue as the abuse that is being misreported. Again though that's for LL to deal with and us to not know anything about. Edit: ...and I'm not exactly known for my high opinion of most people.

This is (edit: one of the reasons...) why I keep saying we need it at parcel level and whitelistable.

Let's face it - if someone runs a (unregistered) bot on their own land for their own purposes - who cares or knows? If it wanders where it hasn't been invited...

Exactly this! This is my issue with bots, and always was. They are disruptive to both my work and enjoyment of my land. Real people are welcome to disrupt me, except the one who attached himself to me with a follower script and 'abused' me. Even that gave me a bit of a laugh (I took 30 seconds to eject it) which a bot wouldn't have done.

@M PeccableWow - you're making this a bit personal and putting words into my mouth that I didn't say. Such is how people like to argue I guess. I have never said that all parcels be blocked to bots by default. I have said we need an option to turn on blocking. DO NOT tell me that I don't care about losing functionality in SL. Who do you think you are and what gives you that right? I guess I already have my answer since you think it is acceptable that people have to tolerate your bots' invasion of their paid-for land, because otherwise your product will suffer. If your product is that wonderful, let word of it spread as it surely will and people will allow it. I'll not engage any further with you on the matter. To do so would be a waste of air for us both.

As I said @M Peccable, it is unfortunate your product relies on sending un-asked-for bots to other people's land. I love to explore. Never needed a HUD to help me.

My importable whitelist idea was intended for parcel owners to implement, not for LL to blanket implement on us. It could be provided by LL but should still be up to the parcel owner to choose to implement it. I would accept it being turned on by default as long as we could just tick a box in parcel setings to turn it off too. Just like the overall deny-bots setting. It is unfortunate that it does not work for a product like yours, but the issue is with your product and the unreasonable expectation that you can send bots to people's parcels without their prior acceptance.

On a semi-serious thought... I run PiHoles for local DNS to block tracking and advertising. That works best with a whitelist/blacklist supplied by 'trusted' people. I wonder if a such a list could be compiled and imported for bots?

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.