Jump to content

animats

Resident
  • Content Count

    2,051
  • Joined

  • Last visited

Posts posted by animats


  1. Here's another possible look.

    portmerion2.thumb.jpg.825ec7a8106bdb35d16cead2c6c163a1.jpg

    Portmeirion

    This cute little place was the setting for The Prisoner, a 1960s TV show. It was built in the 1920s in roughly the style of an Italian village, but in Wales. It's a summer resort, with whimsical architecture. Useful for building ideas. About the right density for SL. See it in Google Street View for more detail.

    Be seeing you!

    • Like 1

  2. 6 hours ago, Coby Foden said:

    Rez the boat on land on your parcel. Hop on, start the engine, throttle up... ----> woosshh... 😃

    That's what I'm doing now, and since I have only to cross about 4m of Linden sandy beach, it doesn't look that awful. But there have been snickers.

    • Haha 2

  3. For waterfront homes like that, has anyone come up with a good way to get a boat from your own property across the narrow strip of Linden land, and into the water? I've considered a truck and boat trailer setup, but my place has a sandy beach. A rocky shore like this would be tougher.  Anyone have something good?

    boatlift.jpg.8cb0fc87cf0e0cd9cc530d1bb26da592.jpg

    Might work.

    • Like 4

  4. Right now, 3000-5000 scripts doing nothing can use up most of a region's script time. That's really a bug. At Server User Group, we're told that efforts are underway to reduce the overhead of idle scripts substantially. I hope LL succeeds at this.

    This problem wasn't fully realized until recently. Then some people found sims with no avis and nothing much going on in sim overload. Some others discovered that you can put an empty sandbox into script overload with a few thousand scripts that are sitting there doing nothing. This is getting attention from LL because it's a huge server load that costs them and benefits nobody. Discussed previously in another topic.

    So I'd suggest not putting massive efforts into removing idle scripts at this time.

    • Like 2
    • Thanks 1

  5. 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 3

  6. 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.


  7. 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?


  8. 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.


  9. 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.


  10. 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

  11. 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).


  12. 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

  13. 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

  14. 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.


  15. 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.

×
×
  • Create New...