Jump to content

NeoBokrug Elytis

Resident
  • Posts

    160
  • Joined

  • Last visited

Reputation

231 Excellent

1 Follower

Retained

  • Member Title
    Curator of Artisinal Trash

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. My observations aren't really related to the current Thunes acquisition.
  2. @Patch Linden Any word on the feedback about how... unoptimized it is for a mesh body? That's a pretty big complaint I often hear from not only technical folks, but popular content developers in SL. If this truly is for onboarding new users, it's important to keep the FPS high, and the baseline mesh to be seen as an example of well-made content in SL.
  3. I think it's current incarnation was already tone-deaf and out of touch. I won't argue with you there. But I think that by removing the potentially endless "pay for more credits" option, would shore up what is arguably the worst received aspect of this project. By paying for extra credits to play, it has a lot of the keynotes of the early phone app development days. Folks would spend thousands of dollars non-refundable tokens for the privilege to play a game. But when that mechanic is coupled with something like traditional games of chance specifically branded as a Casino, it feels exceptionally... dangerous. In the wild-west days of Second Life, when LL got rid of actual casinos and banks, residents understandably felt punished. When LL made Skilled Gaming a thing, and let other folks bear the burden of following the laws, residents were confused. Now that LL is hosting "totally not gambling, just for funsies, you can buy more credits too" social space, residents feel as if Linden Lab is being a hypocrite. At least that's what I'm reading everywhere. I think removing the purchasable credits, upping the amount of default play time per day, and adding more via account membership level, would hit a lot of the goals Linden Lab wants. Draw people in to socialize, add some premium accounts to the monthly bill. There are already fun gambling themed games that have no rewards other than bragging rights already on the grid. Some of them are exceptionally well done. I kind of see those as a personal pocket slot machine game. Aside from the cost of the game itself, nothing is really lost or gained. I think it's cool that Linden Lab is exploring creating new activities for residents. And I think Linden Lab intended to make a fun social space where people could play games together. Hence: SocialCasino Linden. But I also think there are many more cooler ideas the time for spent on this project that could have been used for something different; and that the general poor reception of this requires re-evaluating its execution. I think in order to begin making this right, LL should consider refunding L$ purchases, and making positive changes.
  4. Additionally, the more scripts an object has, the longer it takes a region to store the state of those scripts before detaching the item.
  5. The Wastelands is a post-apocalypse themed residential community. We're 15+ years strong. Learn more about us in this Second Life Spotlight blog post. A teleport to visit us: https://maps.secondlife.com/secondlife/The Wastelands/
  6. New bug for this release: https://jira.secondlife.com/browse/BUG-231876 llRequestSimulatorData() frequently and silently fails.
  7. I did further tests -- and allow me to explain a bit of background before I go into my findings; We have an arena in The Wastelands that rezzes different tiles for different arena configurations. The arena is VERY old 2007 code that I did not write, and has had a few new features bolted on for expanded functionality. But the basis for how it functions remains the same. It has historically been a good measure of rez delays because it has to rez 81 tiles in total for a single map. These tiles were made before llSetLinkPrimParams, and all the other beautiful functions we have now. Due to previous rez delay issues where more scripts equals more rez delay, the arena tiles got a refactoring back in August to be a single script. Until then, they still worked fine, so there was never a need to update them. Now all the updated scripts share the same base code, but may have a little extra code to handle collision and timer events. All the hazardous tiles typically have a collision and/or timer event associated with them and extra primitives as part of their link sets. The clear tile has no such events and is a single prim. That is why I mistakenly thought that additional prims were the cause of the rez delays. After the Server Meeting, I decided to continue my testing. I added another prim to the clear tile that rezzes faster. To my surprise it rezzed just as fast as it did before; that is to say without any delay. Which completely debunks what I thought was happening with child prims. (And now I feel bad for wasting Server Meeting time) Then I made the tile a single prim again however, this time I added an empty collision event to the existing script. When the arena was told to render a new map, the delay for the clear tiles was there. Pretty interesting! I had thought that certain events in the script queued up the delay. But... I then reverted the script to its original code, recompiled, and told it to render a new map. The delay was still there, despite the code and prim being EXACTLY the same as it was before. The only change is that this was compiled today, where the old script was compiled back in August. Anyway, the majority of everything rezzed by scripts has a solid 2 seconds delay. This is on a freshly restarted region, and I can't figure out what is so special about the OLD clear tile, versus the "new" clear tile.
  8. One of my regions that used to start at around 75% scripts run, but eventually hangs around 60% scripts run, now shows 100% scripts run. [ETA] I believe my region is on the newer configuration change. However, there seems to still be significant scripted rez delay that used to only be seen when regions were performing poorly. Prior to these changes, the longer a region ran, the more "tired" it got and the rez delay would increase to what seemed like a two-second cap. After this roll, the rez delay seems to exist before a region becomes "tired". [EDIT] Additionally, it appears that the more child prims an object has, the longer the rez delay is. All the script rezzed objects just have one script in them, but some have several child prims ranging from 1 to 5 prims. [SEE BELOW FOR MORE INFO]
  9. I was just speculating as to the reasons why Firestorm was crashing, because systems that old are going to struggle with SL. Could be that you just need to dust the system out; and/or the thermal paste on the CPU is completely dried out after 14 years. If you're brave and know what you're doing I would look into fixing that. The Windows 7 machine is significantly newer than the first specs you posted, with a 10-year-old Core i3 processor. The Core2Duo has 2 cores and 2 threads, while the Core i3 has 2 cores and 4 threads (with probably a far better chipset on the motherboard). And while raw processor speed plays a role in how well SL runs, it still uses other cores/threads for a few tasks. Win 7 has less system resource usage demand, and copes better with just 8gb of ram. Now, "running SL just fine" is technically correct -- but I wouldn't say it's a good experience.
  10. Authy has a desktop app, I can't remember if it requires a telephone number. Bitwarden/Vaultwarden has TOTP support as well.
  11. I hate to be brutally honest, but I would not consider your current setup as an acceptable solution to run Second Life. You should consider upgrading. Before I get into why your setup has issues, I will throw out the best advice I know: Open up your PC while it's off and dust it out with a can of air. Most programs crashing could easily be attributed to overheating. That 13-year-old Core2Duo is really going to hurt your ability to run Second Life. SL is mostly dependent on single thread processor speed at the time of this forum post, and I am going to also assume you have just as old of a motherboard for your setup; so the CPU talking between components are going to be agonizingly slowed down. 8 GB of RAM is what I could consider to be the bare-bones minimum to run Windows 10. The NVIDIA GTX 730 is very old bargain GPU -- and while SL is less dependent on the GPU these days, the 4 GB of onboard GPU RAM is not doing anything to help. I have seen single buildings in locations eat up more than half of what would be your GPU memory with textures alone. Right now I think your PC is running out of memory in either your system RAM or GPU ram.
×
×
  • Create New...