Jump to content

animats

Resident
  • Content Count

    2,333
  • Joined

  • Last visited

Posts posted by animats


  1. 57 minutes ago, CoffeeDujour said:

    they are trying to do too much with too few devs

    That's certainly the feeling I get from Server User Group. It's not like the few Lindens there are reporting the progress of large teams we never see. It's more like the few Lindens there are desperately working to keep it all going and improve it a little. I get the feeling that two or three of the Lindens do all the heavy lifting.

    • Like 5

  2. 33 minutes ago, Rolig Loon said:

    The other popular way to indicate which options are current is to display only the active ones, toggling them when they become inactive.  So 

    llList2String(["Deactivate","Activate"], (iButtonState = !iButtonState) )  toggles both iButtonState and the displayed option at the same time.  Then you use the new binary state of iButtonState to go ahead and make the actual changes.  Users are never confused about whether the feature is activated or not because they only see what's possible at the moment.

    I tend to think that's more confusing, as in "Where did the button go?" If it's already on, a marker is more appropriate. If you can't do it, say because you don't have permission, greyed out would be ideal, but we don't have that option. There, removal is a legit option.

    paintcolors.png.394c5472ebeb70437d70e505639b69b6.png

    Pick a color. Any color. Deleting the current color here would be confusing.

    There are other Unicode tricks, such as "C̵a̵n̵n̵o̵t̵ ̵b̵e̵ ̵p̵u̵s̵h̵e̵d̵", well known to the people with excessively clever display names. Try not to overdo.


  3. 9 hours ago, Dyna Mole said:

    That is correct.  You create a list by using the Add Name function.  You remove a name by using the Remove Name function.  You see what names are currently on the list with the View List  function, which is only available if there are actually names on the list.  All of those functions simply manage the list. 

    Once you have created a list, your Access menu gives you the option of using it or ignoring it. (After all, there are times when you might want to allow Anyone to enter your home but not allow people on the whitelist to mess with your control panel, so you would want to be able to turn list access off.)  If you click List from the Access menu, it allows anyone on the list to enter and be able to use the Redecorate/Window/Door functions  It also sends you a chat message to remind you of who is on the list, just in case you forgot.

    Ah. Now I get it.

    (Someone coded a multiple choice  "radio button" in a dialog box, but didn't do it very well. Useful Unicode symbols for dialog buttons:

    ☐ Ballot box

    ☑ Ballot box with check

    ☒ Ballot box with X

    • Bullet

    ⬤ Big bullet

    ○ Empty bullet

    You can use those in dialog button names to indicate the current state before the user clicks the button. If it's an on-off toggle, after the button name, use the empty ballot box for "off" and one of the other two options for "on". For a multiple choice, use "Big bullet" for the currently active option, and nothing or "empty bullet" for inactive. Since this is how dialog buttons work in just about everything else except Second Life, users will get this without explanation.)

    escalatorcontrol.png.883ea49a9277ef3c03fda9babb447869.png

    Like this. Any questions about how that works?


  4. 7 hours ago, Zoya McDonnagh said:

    After adding them, did you hit the List button on the panel? (Not View List, the one that says List. )

    Tried both buttons. (Why is there both a List and a View List button, anyway?) Same list.

    I tried adding a bogus name, and it won't let you do that - it checks that the name is a valid user name. So it's not a typo.

    I'll have to try again, now that we've both been offline.


  5. How does the Linden Home door access list work? I added someone, just using their name (that is, "username", not "username Resident"). The box accepted the name, it shows on the list of allowed users, but they still could not open doors. They don't have a separate display name; new user.


  6. I pull the boat up to a public dock, stand, and start to walk onto the dock. The boat disappears before I'm on the dock. I fall into the water. No good.

    Parcel return time for Bellesaria water and shore areas is a bit aggressive at 1 minute. You don't even get a full minute. Sometimes as little as 5 seconds when exiting a boat. On mainland, you can usually park on roads or shores for 5 minutes.

    With 5 minutes, you could even launch and retrieve boats with a boat trailer.

    • Like 12
    • Thanks 2

  7. On 7/16/2019 at 10:39 AM, Fritigern Gothly said:

    I never said it was practical, but I have noticed that many people are afraid to put more than just a handful of values in a list. My intention was only was to point out that a list can hold more keys than some people may think.

    I've done some testing. List updates seem to be constant time up to length 128 or so. Then they slow down. Technically, O(1) to 128, then O(N).


  8. A real world note. I'm a horse owner, and I keep my horse at a barn which has a half dozen school ponies. For many years, the ponies always had many teenage girls riding them and fussing over them. But in the last two years, that's disappeared. The ponies are still there, and occasionally used for lessons, but they just don't get the attention they used to. I guess everyone is on their phone now.

    • Sad 2

  9. By the way, Realtor® is a trademark. Only members of the (US) National Association of Realtors can use it, and they are rather aggressive about enforcing that. "Real estate broker" is the generic term.


  10. I went there to say goodbye. Walked around for an hour, looked into some vacant rentals, tried the sushi bar, flew around in a mini-helicopter and took video. I'll miss that place.

    But it just wasn't used much. I've never seen more than three people in its five sims.


  11. Here's a scan in both directions. This is vertical, in both directions.

    Ray cast in arrow dir from <195.04470, 16.08895, 35.56000> to  <195.04470, 16.08895, 25.56000>
     Hit #0: <195.04470, 16.08895, 35.31000> Walkable rug
     Hit #1: <195.04470, 16.08895, 35.25266> Opulent Garage
     Hit #2: <195.04470, 16.08895, 35.15000> Stone floor
     Hit #3: <195.04470, 16.08895, 33.88510> Ground
    Upward ray cast from <195.04470, 16.08895, 0.00000> to  <195.04470, 16.08895, 35.56000>
     Hit #0: <195.04470, 16.08895, 33.65000> Stone floor
     Hit #1: <195.04470, 16.08895, 33.88510> Ground
     Hit #2: <195.04470, 16.08895, 35.11000> Walkable rug
     Hit #3: <195.04470, 16.08895, 35.15014> Opulent Garage
     Hit #4: <195.04470, 16.08895, 35.30999> Cast ray tester 0.3

    castraytestbox.thumb.jpg.175dbf48cffc26b453eba763d7fd7f12.jpg

    Cast ray tester.

    Going downward, there's a rug, the floor of "Opulent Garage", a stone ground slab, and Linden ground. The floor of "Opulent Garage" is thin (0.102m). The "walkable rug", added for pathfinding purposes, is 0.200 thick, because pathfinding does not reliably recognize walkables less than 0.200m thick. So here, the floor of "Opulent Garage" is totally inside the "Walkable rug". Which is why the cast ray hits "Walkable rug" before "Opulent Garage" in both directions.

    Similarly, "Stone floor" penetrates into Linden ground, so it gets detected before the ground surface in the upward scan.

    This gives a sense of why scanning in both directions is ambiguous.

    • Like 1

  12. 8 minutes ago, Wulfie Reanimator said:

    Raycast will be your only friend here, but what I suggest is that you add a higher number of collisions to the ray, then cast the same ray from the opposite direction. This will give you a kind of a "cross-section" of surfaces (which you could combine into a strided list) and you can assume anything between those values is solid material.

    Already doing that. That's what produced the red section in my picture above. Works fine as long as the ray cast is started outside the obstacle. It's hard to guarantee that. Especially inside buildings.


  13. 29 minutes ago, Rolig Loon said:

    You at least have a rough idea of which way is "out". 

    Not that helpful. I'm writing my own pathfinding system.

    patharoundcars.thumb.jpg.14cbf50a67cb8b7582ace3688da63499.jpg

    New pathfinding system.

    • First, it generates a path with llGetStaticPath. That's the straight green and red sections here. (Those colored lines are temporary prims; after about a minute they disappear, but they're around long enough for debugging and screenshots.)  LlGetStaticPath will go around static obstacles and only put paths on walkable surfaces. It doesn't notice anything not in the static navmesh, and has no concept of vertical clearance, so it will go under tables and such.
    • Then it scans forward and backwards from each llGetStaticPath waypoint, using llCastRay to detect obstacles. The red section has an obstacle.
    • Then it runs a maze solver, which uses a grid of cells and works around moderate-sized obstacles, to get past the red section. Doing the whole path with a maze solver in LSL is too slow, but using one to get around obstacles works. Those are the yellow lines.
    • Then there's some cleanup; shortcuts are tried and used to make the path not so rectangular.

    For this to work, the llGetStaticPath waypoints have to be in open space. Otherwise, the endpoints for the maze solver won't be clear and there's no way to get a valid path.

    patharoundcorner.thumb.jpg.0b1d334d0c0c97d4a5537b5867500a85.jpg

    Here's a hard case. Here's a path around a corner. LlGetStaticPath did that by itself. Then the path was checked with llCastRay calls,  to catch any above-ground obstructions. Works fine.  The translucent circles are LlGetStaticPath waypoints.

    But if there's an obstacle right at that corner, on top of a waypoint, it will fail. The maze solver needs free space on either side of the obstruction. If a waypoint is obstructed, I need to search along the path for open space for the start and end points. That's where finding open space reliably gets hard.


  14. Here's a surprisingly difficult problem - determining whether a volume in SL doesn't have anything in it. I'm doing path planning and need to know that.

    Out in the open, this is easy. Use llCastRay pointed downward and see that the first hit is the ground or a walkable surface. Indoors, though, it's hard.

    What llCastRay tells you is the first face of an object hit in the direction of the ray cast. If the ray cast starts inside an object, you don't detect that object. So if you ray cast from an arbitrary point, you can get a "no hits" result if the start of the ray cast is inside an object. The bigger the obstacle, the more likely you won't detect it.

    If you ray cast from known open space, you can reliably detect an object. So a chain of ray casts from a known good location can check that a path is clear. When an obstruction is found, though, it's hard to find the far side of the obstruction. Ray-casting in the backwards direction from past the obstacle only works if you know how far is "past". And just because you hit an object doesn't mean you're outside it. If it's convex, you can hit it anyway. Big problem with mesh buildings.

    llSensor doesn't help. That just senses the root location of an object, not its surface.

    Volume detect only works for moving objects, and you have to start from clear space.

    Reading object bounding boxes isn't helpful inside mesh buildings - you just get the entire building.

    Am I missing some simple trick, or is this going to take a lot of ray-casting and bookkeeping?

     


  15. Donald Trump just tweeted on "tokens".

    "I am not a fan of Bitcoin and other Cryptocurrencies, which are not money, and whose value is highly volatile and based on thin air. Unregulated Crypto Assets can facilitate unlawful behavior, including drug trade and other illegal activity.

    Similarly, Facebook Libra’s “virtual currency” will have little standing or dependability. If Facebook and other companies want to become a bank, they must seek a new Banking Charter and become subject to all Banking Regulations, just like other Banks, both National and International. We have only one real currency in the USA, and it is stronger than ever, both dependable and reliable. It is by far the most dominant currency anywhere in the World, and it will always stay that way. It is called the United States Dollar!"

    With this, the SEC actions earlier this week, and reaction to Facebook's new money scheme, Linden Labs/Tilia picked a really bad time to issue an unregulated "token", claim it has no value, and then claim they have no responsibilities for customer assets. The cryptocurrency community has created too many "take the money and run" "coins", and the crackdown has come.

    LL / Tilia now needs expensive securities lawyers to figure out how to be compliant. The worse the user terms look, the more likely the SEC will consider it a scam.

    • Thanks 1
    • Haha 1

  16. orville-walkable-bug.thumb.png.ef20eb0f23699fe84be4ac88f11420c6.pngOrville Airport, Orville sim. A LL-built seaplane airport. I do some animesh NPC testing at this seldom used place. They've been behaving strangely there, detecting invisible obstacles and unable to cross certain lines.

    This is an old Linden sim, all prim, little if any mesh. The grey area is completely flat. It's a few big prims. The boarding stairs are prim, about 50 (!) prims in a linkset. Almost everything in this sim is tagged "static obstacle" for pathfinding purposes, so it's good for pathfinding testing. Pathfinding can get a character up those steps into the terminal, all the way to the control tower. But moving around in the open space in front of the terminal gets weird.

    This view shows the navmesh for "Type A" characters, avatar-like. Notice the bumps in the flat ground. That's a bug. Somehow, those steps messed up the navmesh for a considerable distance around the steps.

     

    orville-path-bug.thumb.png.69de468fba3c9fb1947d01573748a8f1.png

    Static path viewed in the viewer. Note the up and down movement. The cement surface is flat, so that's wrong.

    Somehow, those boarding stairs mess up the navmesh for tens of meters in all directions. This is the only place I've seen this. Any insight on what makes this place special?

    (I'm working on some path planning which uses both llGetStaticPath and llCastRay. In this place, they disagree on where the ground is, causing some problems. I need to know if this is a widespread problem, or an unusual special case.)

     

×
×
  • Create New...