Jump to content

Vixie Darkfury

Resident
  • Posts

    12
  • Joined

  • Last visited

Reputation

0 Neutral

Recent Profile Visitors

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

  1. Well, I'm not having a problem dealing with it, I just think it's kind of dumb. But thanks anyhow. Vixie
  2. I just got bit by this same problem. Fortunately I hit upon the solution quickly. What I'd like to know is, why is this considered correct behavior? I generally expect the llList2whatever functions to make a whatever as needed, am I wrong to expect this? I will grant that the bug is well documented, but it seems to me it's still a bug and should be fixed. Casting the wrong type to the right one has adverse side effects, as explained in the docs. Vixie
  3. OK, thank you for the explanation. I had no clue how it worked, sorry for the hubbub. Vixie
  4. I read that long ago but it never made sense to me. I guess it's more efficient to check a long list of prims for a listen on a channel than it is to compute the distances and sort.
  5. It's like this: when you or an object shouts, the shouts propagate through space (or whatever you want to call it on a sim) such that every other object within 100m that has a listen has to be checked to see if the listen applies. This creates lag. Normal speech propagates 20m, and so creates less lag. Since it propagates through a 3-d volume of space, and 100 is 5 times 20, it's going to propagate through a volume 125 (= 5^3) times as large as a normal llSay(). A 50m yell, if it existed, would propagate through a volume only 15.625 (= 2.5^3) times that of a normal llSay(). Thus, it would be only one-eighth as laggy, as far as the lag due to volume might be concerned. I hope that explains it for you; I don't know how else to explain it. Vixie
  6. Well, I knew about llRegionSay() but it seems even worse than shouting. I can't RegionSayTo cuz I'm talking to unknowns and in some cases multiple objects. So, it seemed to me a chat mode with an intermediate range was the solution. Vixie
  7. Hey all, I am having a problem with a building I'm working on. Some of the components are out of normal chat range of the controller, so I'm having to make all the relevant components "shout" so as to be heard by each other. This seems needlessly laggy to me. Shouts carry 100m, which is like 125 times the volume of space for a normal chat. It seems to me, a fourth chat mode that carried, say 50m, would come in very handy in these situations. Call it llYell(), for the sake of argument. A mode that carried 50m would only carry through about 15 times the volume of a normal chat. It seems to me the potential difference in lag would make it worth the effort to code. Vixie
  8. Hmmmm. Thanks to all who replied, but the situation is still about as clear as mud. It seems a bit of testing might be in order. In quick, limited testing, I found out the following: In Mono, global variables containing strings cost 2 bytes per character, plus some overhead for the variable. Mono optimizes out functions that are not called; the regular compiler does not. Minimal over head for a Mono program is over 3k, for the regular compiler, about 200 bytes. Both Mono and the regular compiler get rid of the symbol table in the final executable. Good on 'em. Obviously more testing is needed. Vixie
  9. I have a question and a comment about LSL. The question is, does the length of symbols used (variable and function names) affect the compiled size of LSL scripts? The comment is, the following documentation seems wrong: http://wiki.secondlife.com/wiki/LlSay It states that the chat limit is 1023 bytes, which doesn't make sense to me. It's an odd number, but a double-byte character system appears to be in use. Quick testing confirms that 1023 characters can be chatted. Should this be changed? Thanks, Vixie
  10. Uh, it's good to know the word got out, lol. Vixie "English? Why study that? I'm never going to England!" Homer Simpson
  11. I've had intermittent trouble with preview pics on the marketplace, and I finally figured out why. If your preview pic has a pound sign (#) in the file name, it will not show up correctly on the website. There may be other toxic characters as well, but the pound sign is a definite problem. I'm not sure this is a bug, at least in the case of the pound sign. It has significance within HTML URLs and hrefs and an image tag contains an href element. So, there may be no way to fix this. But, I wanted to get the word out since I'd finally figured out what was wrong. Hopefully others can avoid the problem. Thanks, Vixie :)
×
×
  • Create New...