Jump to content

Jenni Darkwatch

Resident
  • Posts

    1,703
  • Joined

  • Last visited

Posts posted by Jenni Darkwatch

  1. By and large, agreed. I've meddled with CHUI for a while now and I can't get over the huge wasted space and loss of some functionality (which I suppose might come back some day).

    Instead of relatively un-obtrusive notification icons in the top right we at most get a movable icon bar. Movable is good. Since that "bar" is really just a very collapsed window, it's opaqua and has window title controls. Bad.

    There are some other oddities with it that can be found in the JIRA (which to my surpise is actually... READABLE).

    Bottom line is that I like the idea but not the implementation. I suspect it'll take half a year to a year for it to get useable.

    Edited to add: That's on 3.5.1 (270826) btw.

  2. You can teleport or pay people in the chat interface: Right-click their name either in chat or in the list on the left (group or local). Same as before. Not even going to the other comments... please, use it before making untenable claims. I agree it's too big, but it's also the first iteration of the UI. Remember the first v2? It was almost as atrocious as v1-viewers. They addressed many of the complaints since.

  3. Oh! SHADERS!!! Now we're talking. ~g~

    Anyway. I see Ieliel's point of user-generated content and do agree with it. What I don't think is that user-generated, un-optimized content (that we already have with many, many horribly done rigged meshes) should be a showstopper for increasing the graphical appeal of SL over time.

    If SL still looked the same as it did when I first had a look some 5+ years ago I'm sure I'd long have given up on it. On the other hand, it does still need to run on fairly old hardware.

    • Like 1
  4. In game engines the impact is typically also minimized by agressively limiting the reflection range. I.e. only reflect things that are relatively close to the mirror, and only if the mirror itself is not too far away from the viewer.

    I just watched the vid about Tofu Lindens code - it seems to me that it uses a somawhat similar approach, aggressively blurring objects that are too far from the mirrored surface. Granted though, it would be a great way to radically slow down viewers :)

    Personally I think it would be a good idea to add this to the viewer for all shiny surfaces, similiar to light&shadow at deferred rendering: Turned off by default, let users turn it on if they like it. In other words: More stuff for people who can handle it without impacting people who can't handle it. Or at least minimally impact people.

    • Like 1
  5. Nah you don't necessarily need raytracing, at least not for simple reflections. Programmatically there have been cheats to allow that kind of thing as far back as software-3D games. You're right though, it would dramatically drop FPS. Considering how many people use SL still without deferred/shadows, I'd imagine for most it would bring SL to a crawl.

  6. I see the problem you mentioned, Qie, and agree. The way it is working almost makes multi-window chat pointless. While it's unintuitive, there's a workaround: Detach all chats you intend to use. If local and the IM/Group are detached, it's working as intended. I'll call it a good start, but the chat window definitely needs more improvement and some additional settings.

    Btw, I think it got flagged as "working as intended" as the dock seems to automatically return focus to whatever chat you're using. It's somewhat logical from an initial design perspective, but in the case of detached windows... very unintuitive and illogical.

  7. I've tried the beta on and off. Generally, I like the idea. What I don't like is this: The user interface for it is enormously huge. Near-blind people could probably see it from a mile away. It's simply too big and convoluted. Then there's no option anymore to open new conversations in separate windows. While I like mine tabbed I know a few people (who neither read nor post on the forum) to have them open separately.

  8. There's a theoretical SHA1 collision attack which reduces the complexity of any attack vectors. It's impractical to use, so it's still reasonably safe. The original attack vector was found 2005 and improved over the years. Today we have SHA-2 and most recently SHA-3 but neither is included in LSL. I don't think it's all that urgent to have either.

    For "strong" encryption there's an XTEA library here: http://wiki.secondlife.com/wiki/XTEA_Strong_Encryption_Implementation

  9. Basically I have usernames turned off everywhere. The floating names simply have a different colour if display name != username (Thanks Hitomi!), not to mention i tend to check who I am talking with if it's anything important anyway.

    Chat doesn't seem to honor that setting though. If the username is different from the display name it shows as "displayname (username): blahblah".

    Is there any way to hack the XML to toss the username or even better, make it behave exactly like floating names? Or alternatively at least show something arbitrary instead of the username, like say "displayname (!): blahblah"?

  10. AdBlock Plus at least for Firefox and Google Chrome is safe. It has to access the page content because it analyzes it to find ads and blank them out. There's also AdBlock (sans "Plus") which supposedly is also safe.

    It also makes the 'net a much more readable place. Just keep in mind that some ad-sponsored free pages need the income.

  11. 1. Do you have shadows turned on in your viewer? If so what do you think of the shadows that your viewer displays in SL?

    Deferred rendering is always on for me. Shadows only on those of my PCs that can handle them well. I do like SLlighting and shadows a lot, in fact I play with it a lot in my builds (which aren't meant for sale).

    2. If you were to buy a tree or chair today, would you want or expect a ground shadow texture (on a prim/mesh) to be included?

    No. Ground shadow looked wrong even without shadows - the only time they looked right to me was midday for about 15 minutes. :)

    3. What is your opinion about textured shadowing inside buildings? For example should the shadows from the window frames be built into the floor texture or do you think the viewer should be rendering all shadows nowadays?

    It depends. Simulating light from windows usually just looks wrong. On the other hand, small shadows emphasizing wood beams or cracks, akin to bumpmapping, enhance the scene IMO. Materials support should obsolete that, though it'll be years before it's widespread enough.

    4 Any other opinions or issues you have with shadowing on textures or shadows rendered by your viewer?

    Shadows just make a scene more believable, more real. Even with unreal places like space ships it's incredibly different if the builder has used lighting to good effect. I've rarely seen builds with spotlights but the few I've seen (and some I built) are pretty neat. About the only thing that sucks the atmosphere right out of a good build are inane facelights. Luckily there's a toggle for attached lights.

  12. ~shrug~

    LL can't win. If they try to fix things (like they do with SSB), people will scream. If they add new features, people will scream. If they do nothing, people will scream. No matter what they do, they lose.

    My opinion? SSB is a good idea. How well it'll work out in reality is not easy to predict. Firestorm... they've been lagging behind LL's codebase for a long time, it's to be expected that they're going to run into problems.

    Buggy code? All code is buggy. There is no bug-free code, open- or closed-source. With open source there's a good chance TPVs will fix at least the big bugs quickly. Whether LL will back-port those fixes into their own viewer anytime soon... well... depends on how much pot you smoke. Eventually you'll believe anything.

  13. In which order is this hooked up? Cisco -> Router -> PC? If so, change it to plug the Cisco into the router instead. You may have to forward some ports to the Cisco specifically but that's rather uncommon.

    Background:

    Those VoIP units often come with the recommendation to plug them directly into the internet line (cable/DSL) to make sure they work fine. Realistically though that's stupid, because it means they'll NAT traffic behind them. If you only have a PC behind it, it won't matter much aside from often **bleep**ty NAT implementations. As soon as you put a router behind it, the fun begins - they have their own NAT. As a result you end up with a NAT behind a NAT.

    There's two possible solutions to that.

    Some routers can be switched to gateway mode where they don't do NAT. That requires a bit of routing/network knowledge.

    My preferred solution is to plug the VoIP adapter into the router instead and not plug anything into the "LAN" side of the VoIP router. This works fine in most cases, in some rare cases you'll need either put the VoIP unit into the DMZ or forward a bunch of port ranges to it. If your router is halfway decent you shouldn't need to forward anything, the NAT routines will take care of that transparently.

  14. While I understand why they felt the need to close the JIRA I feel it was the most stupid and assinine move ever. Often comments had work-arounds or more details for those who got affected by the bug.

    Personally I've done what Drongle said: I stopped filing bug reports, it's not worth my time to file bugs if I don't know whether or not they're already known and documented. After all, there's no benefit whatsoever to filing a bug report. The bug may or may not get fixed.

  15. Here's a generic solution for the PCRE crash, using AppArmor to prevent the viewer from accessing the .gtkrc-2.0 file. The side effect is that some of the UI will miss the proper graphic, i.e. spinners, checkboxes, dropdowns etc.pp.

    Instructions for Kubuntu, to be run on the console:

    sudo nano /etc/apparmor.d/secondlife

    Insert this text, then save with CTRL+X:

    # Last Modified: Wed Feb 13 12:34:38 2013#include <tunables/global>/**/do-not-directly-run-secondlife-bin {  #include <abstractions/base>  #include <abstractions/user-tmp>  network,  # Dumb but doable - allow everything  /** mixrwkl,  # ...but deny access to the .gtkrc file  deny /home/*/.gtkrc-2.0 mrwkl,}

    Now restart AppArmor

    sudo service apparmor reload

    Done. SL should run fine now. This works at least with all official LL viewers including beta, dev and project viewers. For other viewers you may have to copy the profile and adjust the do-not-run... filename.

  16. Edited to actually provide a solution to the problem... that I could get arsed to even debug it is a bad sign for my mental health indeed.

    The problem is specific to KDE's GTK appearance layer. Luckily there's a relatively easy way to disable that temporarily (or permanently): rename or remove the .gtkrc-2.0 file in your home directory. If you feel like it, edit the SL startup script to move/rename the file when starting SL and put it back in place when SL is done.

    I suspect that it should also work to just install the entire "gnome-desktop" package, haven't tested that yet.

    Edited again because of a brainfart: The effect of this is that some controls in the LL viewer will not display properly. Namely spinners, haven't checked any others yet.

×
×
  • Create New...