Jump to content

Acheron Gloom

Resident
  • Posts

    124
  • Joined

  • Last visited

Everything posted by Acheron Gloom

  1. /me wonders why there is no llGetMemoryLimit and no OBJECT_SCRIPT_TIME.
  2. Great work, its good to see someone actually working toward optimization for prim-count and the like! And yet it still manages to look good. I think thats what one of the main benefits of mesh is personally.
  3. Its been said that its pretty much the same exact behavior as before when an object overflowers the limit/the object itself is returned and nothing else is affected. Also Andrew, I think, said that they were looking into making it so you couldn't do operations that would cause the object to go over the limit. I have yet to have an issue with something turning super high PE from a link, unless it was like a torus with 4 revolutions and 720 twist, etc. I've actually linked meshes to prims and had the overall PE go /down/ quite a bit.
  4. Jo Yardley wrote: But aren't they still figuring out the prim count? Yes if I can save prims, I'm very interested. But I'll wait a little longer to see how it all changes and how the prim count get sorted. Whatever gets me more prims is good. Costs won't be raised, only lowered, though I don't think they'll lower too too much at this point. If you have a link-set of unscripted/non-physical boxs you can link them together and use convex hull physics to get half of the PE cost. Same with cylinders that have a normal radius or spheres that have a normal radius. For types other than those you won't always have less than the standard PE, so it won't be useful, but its still a good tool for the cases you can use it. If you use a physics type of none you can get even higher, actually and the prim-type/size makes less of a difference.
  5. Kascha Matova wrote: ZOMG! You so crazy Val! LOL! :matte-motes-big-grin-squint: Oh ya. The question...I still don't really get what it's supposed to do for us or the extent to which it's going to change things, and furthermore, am far too lazy to read up on it. Would that be the same as "no"? Yes, I do believe that willful ignorance is the same as not caring.
  6. I agree with York Jessop. I'm interested in it, and all of the other new changes its bringing, too. New physics parameters (friction, density, restitution, gravity, and density), physics types (none, prim, and convex hull), mesh itself, havok 2k10, 64m^3 prims, and so on. I'm also really looking forward to more v2 viewers, as I do believe v2 itself is a superior code base almost all around. The thing I don't like about v2 is the radically different UI, but Firestorm is already making some good strides in that regard, and I hope they continue to focus on V2 rather than working on a now deprecated V1.
  7. This should work quickly/efficiently to return itself: llSetLinkPrimitiveParamsFast(LINK_SET,[PRIM_PHYSICS, FALSE, PRIM_POSITION, <1.304382E+19, 1.304382E+19, 0.0>, PRIM_POSITION, <128.0,128.0,5000.0>,PRIM_PHYSICS,TRUE]); Attaching and detaching would go to the objects folder, but it needs to request permissions to attach first, and it needs to be in the same sim as the owner.
  8. You can also attach it, set scripts to not running, reset scripts, and drop it unless the owner was clever and did: llDie(); llRequestPermissions(llGetOwner(), PERMISSION_ATTACH); llDetachFromAvatar();
  9. WADE1 Jya wrote: yes maniac, its a big issue indeed! yikes i hope we see this patched before full grid rollout of mesh. a simple tris limit per attachment could do the trick, maybe cap it off at 256 prim equivelency? I like this idea. It would match the old system pretty well. Who needs to wear 256 PE worth of mesh on a single attachment point anyway?
  10. I believe its llSetAngularVelocity. Thats what it was when I was testing it on the beta grid.
  11. Cerise Sorbet wrote: I guess it will get more clear when we can play with them, but what will we get with llSetVelocity vs. llSetForce and llSetRotationalVelocity vs. llSetTorque? It instantly sets the object's velocity or rotational velocity (if thats the correct term) to that speed. You don't have to work with llGetMass or get the current velocity. Example, you have an object at 150 m/s that you want to be at 100 m/s. You can just do llSetVelocity(<100.0, 0.0, 0.0>, 1); Instead of doing llApplyImpulse((<100.0, 0.0, 0.0>*llGetRot() - llGetVel()) * llGetMass(), 0);
  12. Void Singer wrote: Oskar Linden wrote: Fix to prevent LSL scripts from using non-finite numbers in physical functions. please tell me that means no more goofy nan/inf casts, and not breaking posJump... pretty please Oh gosh, this this this. I assumed it meant things like llRezObject(objectName, pos, infiniteVel, rotation, rezparam); Which when done in Mono can break some LSL scripts that detect the rezzed object's velocity. If it breaks posJump I'll be very upset.
  13. Perhaps it was an accident, but llGetObjectDetails' new constant OBJECT_SCRIPT_TIME and the function llGetMemoryLimit aren't included in the release notes for Magnum. Are we not seeing those this week or something? I was really looking forward to OBJECT_SCRIPT_TIME.
  14. ValidusEquis LittleBoots wrote: Yes I tried Phoenix got nasty virus had computer cleaned of sed virus. I will never try to install that viewer again. I guarantee that you didn't get the virus from Phoenix, unless you didn't install it from the official phoenix website. Phoenix is the most used TPV on the grid, and either comes close to or exceeds the usage of official LL Viewers. I don't have statistics for the latter however, so I'm not entirely sure.
  15. Its not as easy as just deciding to roll out an individual piece of an entire project.
  16. The specific throttle is 25 requests per 25 seconds. You could do, for example, 25 requests in a second but then you would have to wait another 24 seconds. Or you could do 1 per second for the 25 seconds. The throttle is per-object, so no it wouldn't be a very easy fix. You can either: A. Just make sure there aren't too many requests, and if so throttle it yourself. B. Redo the way your system works. C. Use some sort of rezzed proxy.
  17. They're using it simply so that an over-sized value won't corrupt the other compressed values. So they mask out all the other bits that would do the aforementioned corruption.
  18. My uploading issue is fixed now. Something I might suggest is going back, changing your answers to a wrong answer, waiting a second, and then changing them back to a correct answer.
  19. Yoki Enoch wrote: The only big deal I see so far about mesh is that its full incorportation into SL will probably force me to find another virtual world. I did not come to SL spend a fortune on computers and/or computer upgrades to be awed by more bells and whistles. Doubt that'll happen to the degree you make it seem like it will, considering I use an x1600 for my graphics card and I haven't had any issues stemming from mesh. x1600s were considered mid-range in 2005. Efficient, professional use of Mesh is much much better than sculpties in terms of client-side rendering, as far as I am aware.
  20. I still can't upload.
  21. Rolig Loon wrote: Step One: Familiarize yourself with the LSL wiki, so that you know where to look for information about the syntax and usage of LSL functions Step Two: Spend a little time doing the basic tutorials at http://wiki.secondlife.com/wiki/LSL_Tutorial or consider taking a course or two in world at Builder's Brewery. Step Three (the real step): Get a mess of freebie full perm scripts and start taking them apart and modifying them to understand how they work. Keep breaking them and adding bells and whistles to make them yours. If you have any prior experience with writing scripts in any language, you should be up and running in no time. If you are a raw beginner, .... well, it depends on how much time you have to focus on it and how smart you are. Scripting is basically logic. The language is the easy part. I'd do this, except it may also be helpful to think of something you want to do, and then just do it. And then add more to it. And then improve it, and so on. Thats basically how I started.
  22. It depends on where you go. Most of the places I go are probably about 85% real-life males. In turn most of the places you go there are apparently more females. Statistically I might see its pretty even. In the fourth quarter of 2008 there were more males than females (58.72% versus 41.28%) http://static-secondlife-com.s3.amazonaws.com/economy/stats_200811.xls
  23. Thinka Little wrote: And I have a green background for paymentinfo and a "red" one for the tutorial, which i completed with 10/10 right, resulting in no upload-button (and yes I'm in one of the meshsandboxes). Shouldn't it be green too in the tutorial then? this page gives no real clue what to do. Tried with different alts, which have no payment info, resolving tutorial don't change it's status. So please make the page show whats the problem. Yep, same here.
  24. The SL website tells me both are fine and I got an 11 / 11 on my test... and yet I can't upload in-world. Sim name is 'Titan' and its on the main grid. Other people can upload, but I can't. I also even boujght 550 lindens specifically to see if that fixed it :l
×
×
  • Create New...