Helium Loon

I think it's your re-use of the variable name 'channel'. Since you use that as the prototype for your listen, the compiler thinks within that scope it would 'mask' the global variable of the same name..... Try changing it in the prototype of the listen.

I don't see any matching JIRA entries that describe this bug.....you should create one! Create a JIRA

Stefani Joubert wrote: Is there any way to keep a dialog menu up after a user selects menu item? I'm working on a show/hide for a prim, and I want to use a menu, as the "hide" will go full alpha and make the prim completely invisible. Also, any way to make the dialog menu open on rez? I'm just a script hacker, and I can't find exactly what I need in the forums. Thanks in advance for any suggestions~ 1) Sort of. Simply re-display the menu to the same id after you get one of the selections in your listen. 2) Yes. Simply call llDialog() from in the on_rez() event. However, the only user keys you'll have are the owner and creator. (And any you hard-code in, of course.)

Not true at all. Use the llSetLinkColor() and llSetLinkAlpha() functions. These will set the parameters independently. ETA: Also, if you want/need to use llSetLinkPrimitiveParamsFast(), you CAN 'get' each parameter you don't want to change and pass that in as the 'new' one. So if you wanted to just set the alpha, you could do: llSetLinkPrimitiveParamsFast(linknum, [ PRIM_COLOR, ALL_SIDES, llList2Vector(llGetLinkPrimitiveParams([PRIM_COLOR, ALL_SIDES]),0), new_alpha_value); and something similar to just set color and leave alpha unchanged.

Something like this (may not be perfect, doing it off the top of my head) list parts1 = [];list parts2 = [];list parts3 = [];// more as needed for various colors/etc.integer listen_id;list getPartsByPartialName(string partname){ integer i; list retval = []; for(i = llGetNumberOfPrims(); i > 0; --i) { if(llSubStringIndex(llGetLinkName(i),partname) != -1) retval += [i]; } return retval;}SetListColors(list partnums, vector color, integer face){ integer i; for(i = llGetListLength(partnums); i > 0; --i) llSetLinkColor(llList2Integer(partnums,i), color, face);}SetListSizes(list partnums, vector size){ integer i; for(i = llGetListLength(partnums); i > 0; --i) llLinkSetPrimitiveParams(llList2Integer(partnums,i), [ PRIM_SIZE, size] );}SetListTexture(list partnums, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians){ integer i; for(i = llGetListLength(partnums); i > 0; --i) llLinkSetPrimitiveParams(llList2Integer(partnums,i), [ PRIM_TEXTURE, face, texture, repeats, offsets, rotation_in_radians ] );}// now, in your object you need the various 'parts' that will have these operations// performed on them to have names which share a common sub-string....// for example, all the parts that need to change color have names like:// colorablePart1, colorablePart2, colorableTop, etc.default{ state_entry() { parts1 = getPartsByPartialName("colorable"); // this gets the 'colorable' prim numbers parts2 = getPartsByPartialName("textureable"); // get all the ones with 'texturable' in them parts3 = getPartsByPartialName("sizable"); // you get the idea.... listen_id = llListen(2, "", NULL_STRING, ""); } listen(integer channel, string name, key id, string msg) { string prefix = llGetSubString(msg, 0, 0); list params = llParseString2List(llGetSubString(msg,2,-1), ["|"], []); if(prefix == "C") { SetListColors(parts1, llList2Vector(params,0), llList2Integer(params,1)); } else if(prefix == "T") { SetListTexture(parts2, llList2Integer(params,0), llList2String(params,1), llList2Vector(params,2), llList2Vector(params,3), llList2Float(params,4)); } else if(prefix == "S") { SetListSizes(parts3, llList2Vector(params,0)); } else { llInstantMessage(id, "Invalid command!"); } }} This is hardly a full script, but would allow commands typed correctly to channel 2 to alter all the above qualities. ETA: the commands would look something like this: /2 C <0.8,0.5,0.3>|-1 /2 S <1.4, 2.0, 1.0> /2 T -1|textureToSwitchTo2|<1.0,1.0,0.0>|<0.0,0.0,0.0>|0.0 Obviously, there is a lot more you can do, but this is the general idea....

While there are functions that can control the camera position and target (along with some other parameters) in LSL, the big issue here is that regardless of those controls, the draw distance that is set in the users client program will limit the distance that things can be seen from. So if the draw distance of your client is set to 512m, if the rocket is farther than that from any objects, they won't see anything. And above a certain height, the ground won't even render, IIRC. Most clients default to a draw distance of 128 or 256 meters. So it would have to be a pretty low-flying 'satellite' to work. If that is what you were considering, then look at the wiki on the function llSetCameraParams() and all the related functions.

There is a fourth option, used heavily already in SL, which is the multi-prim single-letter on a face, mapped font image way. It uses a font image (a texture with every letter in the font on it, regularly spaced) and then the sign has lots of rectangular thin blocks across it (which all use the previous texture on their facing face.) The texture repeats and offsets are adjusted so each 'block' shows only the letter on the image it needs to. These are used heavily for scoreboards and such already. And a script could easily convert what was found in a notecard into offsets for each block prim on the object. Prim-heavy, yes. But allows lots of color, font, and size options. Complicated scripting too. But it IS an option.....

Considering the apps you want to run (possibly concurrently), the quad-core is going to be a better solution, processor wise. However, your biggest slowdown at the moment is going to be your memory. 4GB would be better, 8GB would be best. Will your current motherboard support 8GB of DDR2? The best you could do would be to go to an Phenom II x4, a new motherboard (that supports DDR3 SDRAM, and at least 8GB), the memory, and maybe an nVidia graphics card (say a 560GTX Ti). CPU would be $90-140, Motherboard $50-120, and 2x4GB of DDR3 1333 for around $50. The video card would be around $250, though. A nVidia 550GTX TI would be around $150. And you could re-use your current ATI card until you could upgrade that. So, without the GPU, a good re-build (CPU/Motherboard/Memory) would be $190 - $310. (prices taken from newegg.) Intel HD3000 will NOT do well for SL. You could run Low settings and get 5-15 fps typically. i3 is dual core (not quad) so it wouldn't be much of an upgrade from where you are now. Core i5 would be good, but is a lot more money.

Yes, they matter. And yes, those are VERY high triangle counts for a bed. Remember, you only need a lot of triangles in areas of tight curvature. Large flat areas can be modelled with only a few triangles. You'll either need to use a triangle reduction plugin of some sort (like decimate in blender).....or generate your parts with fewer sections. Cylinders don't need multiple cross-sections except for additional UVs for the most part.....and 8-10 faces around. Look for the sections that could be modelled with just a few larger polys without much change in shape. Unless it is a brass bed style (lots of curved pipes), the total poly count shouldn't be more than 2k to 4k. Even a brass bed style one could be done in under 10k easily.

You've got a few problems in there..... First, you have an infinite loop in your state_entry() event. It never exits. Second, you are missing the ';' endings for quite a few lines. Third, alpha values run from 0.0 to 1.0.....setting it to 2.0 will just set it to 1.0 (the maximum.) Try something more along these lines: string TEXT = "╔════════╗\n║DJ Ninja║\n╚════════╝ ";float TEXT_ALPHA = 1.0; // fully opaquedefault{ state_entry() { llSetTimerEvent(2.0); } on_rez(integer start_param) { llResetScript(); } timer() { vector c; c.x = llFrand(1.0); c.y = llFrand(1.0); c.z = llFrand(1.0); llSetText(TEXT, c, TEXT_ALPHA); }} That will change the color every 2 seconds. Smaller timer intervals will change the color faster, but will put a heavier load on the server.

Most of those HUDs and devices have a 'scan' option. That is what initially populates the list. It may also do it periodically on its own. Once the object HAS that list, it can request data on those agents/objects regardless of how far up they might be. And if they leave the sim, then (after a short while) the requests will start returning null or other signal values, so the script knows they've left the area. During a 'scan', it may rez a temp object at various heights/positions. Such a scanning object could be very simple. It rezzes, runs a scan, saves what it finds, moves up ~150m, repeats. Does this as needed (say, to a max of 4096m height), including going DOWN if the start position it rezzes at is greater than llGround() by at least half the sensor range. Then once it finishes it's run (which won't take long, unless the sim is VERY crowded) it sends the results to the main object via a llRegionSay() (now we can use llRegionSayTo() to be more efficient) and then deletes itself. Done once every 5-10 seconds would be easily doable......one could be more efficient by having several kinds of scanner objects to rez, and rezzing those that scan FAR away only every 30 seconds or more, and rezzing ones that only scan to 1024m every 10 seconds........and the HUD object itself can run a sensor on the nearest 96m itself every 5 seconds. Still a bit much, but wouldn't be TOO excessive.....

All it takes is someone who knows a little about using 'decimate' in blender, and suddenly those high-poly models can be reduced down to levels that can work in SL. And for attachments, many of the high-poly models will work just fine.....if a bit laggy on the client (and asset servers). So I'd still expect to see a lot of ripped content. And many will claim that by using a poly-reduction mechanism, that it isn't the same model, and therefore it isn't an infraction........oy, the arguments that will ensue!

The problem is probably the extents of the bounding box......the long diagonal of the bounding box on the dimensions you list would 319m.......meaning that if you rotated the tree the wrong way, you could have it pointing outside BOTH sides of a single sim. You'd probably be much better off re-designing the tree to not have such a large singular dimension. Break it into two or more linked parts. I might mention that the PE of such a mesh is going to be huge at those dimensions as well, and by breaking it into smaller segments will reduce the PE as well.

Well, according to the postings at Phoenix's own website, they are still commited to maintaining and releasing updates to the phoenix viewer. If the other v1 style TPVs integrate mesh (and publish the patch diffs, hopefully), then integrating it into Phoenix will be simple enough they would be foolish not to......and I suspect they will integrate such patches once they are available. Firestorm, since it is based off the SnowStorm code, will include mesh as soon as the Phoenix/Firestorm team gets caught up on the SnowStorm merges. Since they're still on 2.6, this may be a month or three......

Just a couple of notes/additions: To set the 'GetPrimsByNameString' function to work by prefixes or suffixes only requires changing the -1 in the test. For prefixes, compare with 0 instead. For suffixes, compare to (-llStringLength(str)). You could even pass a parameter into the function to specify that. Say, list GetPrimsByNameString(string str, int position) { ... } and pass in either 0, -1, or -llStringLength(str) for position to tell it (and possibly predefine int values for the common ones.) You can also save the lists returned (assuming the linkset won't be changing while running) so you don't have to run the loop each time. Just set a global list variable for each set you need to keep and do it during the state_entry() of the default state.

Absolutely! I used a function like this: list GetPrimsByNameString(string str){ integer i; listofprims = []; for(i=1; i <= llGetNumberOfPrims(); ++i) { if(llSubStringIndex(llGetLinkName(i), str) != -1) { listofprims += [ i ]; } } return listofprims;} So if the pattern str is found anywhere in the name of the prim in the linkset, that prim index is added to the list to be returned. Call it whenever you need a list of whatever prims you need. Write other functions that do a specific action on a list of prims....say, setting color and alpha, like so: SetLinkedColorAndAlpha(list primlist, vector color, float alpha){ integer i; if(llGetListLength(primlist)==0) return; for(i=0; i < llGetListLength(primlist); ++i) { llSetLinkAlpha(llList2Integer(primlist,i), alpha, ALL_SIDES); llSetLinkColor(llList2Integer(primlist,i), color, ALL_SIDES); }} Now, in your code you can simply call them..... .... // Set all prims with "foo" in their name to 50% transparent black. SetLinkedColorAndAlpha(GetPrimsByNameString("foo"), <0.0,0.0,0.0>, 0.5);... Doing it with the description field is a little more difficult, but not much. Just use llGetLinkPrimitiveParams() to get the description fields to test in the first function, instead of using llGetLinkName().

The problem of mesh 'lag' is not the geometry....it's the physics. Anything but the simplest of shapes is going to create a complex physics hull (especially if it isn't optimized!) This puts a big load on the server calculating the physics simulations. The scale affecting the PE is a bit excessive. I know it is based on the fact that the larger an object is, the shift between LODs happens at a longer distance.....hence, it shifts to lower LODs much further away. If an mesh gets large enough, the highest LOD is the only one ever seen, meaning that it's PE at that size would best be represented by the PE of the same object with ALL LODs set to the the same top level LOD mesh. However, the argument breaks down, since that isn't exactly how they calculate it. A simple 4-triangle mesh, scaled up, will easily go way beyond the cost of the top-level LOD cost at a smaller level. Why? It makes no sense, since the rendering cost would never change anyway......it is either rendered or not, no LOD changes affect it. This is how the PE should be calculated for scaled objects.

Ceera Murakami wrote: Well, what I mean by "it doesn't work" is that proper multithreading would assign one instance of SL to one core, a second instance to a different core, and maybe my web browser to a third one. Or it would spread the load evenly across all cores. SL doesn't do that. With V1, it only saw one core, period. With V2, including Firestorm, it spams all the cores available, but the window that has focus gets the vast majority of the CPU cycles, and a much higher frame rate than any other concurrently running SL instances.. If it worked right, two instances of SL running on a 2 to 4 core computer would each get the same frame rate. But on most computers, the bottleneck isn't CPU power - it's graphics card power. And most computers only have one graphics card in use. A really well-done multi-threaded application would be able to overcome that. I think some people here don't fully grasp what 'multi-threaded' really means. The example about one instance being assigned to one core, and such.....that isn't a threading issue. It's a processor affinity setting. Start your instance of SL, bring up the task manager, right-click on the SL process, and select the processor affinity. Repeat as needed. You'll need to run it single-threaded for this to hold up, though. Threads are started by processes. A process is what you are calling an 'instance' of in this case (though in actuality, there are several processes started when SL starts up....like the SL plugin host.) Threads are simplified execution sets that run timesliced on a given core (though they can run on other cores than the initiating process.) In order to avoid hideous lag within a given thread, the task the thread works on needs to be as independant as possible from the other threads of that process (so it can continue to do what it does without waiting on the other threads.) In a highly graphically oriented application like SL, multi-threading will keep things from 'freezing' and improve performance in many areas. But by the nature of what each thread does, and how often or how fast it accomplishes it, as well as the thread's priority, it will NOT take the same amount of CPU time as other threads. Balancing threads is not usually a concern.....unless the application is likely to peg ALL or most of the cores available, then it becomes an issue. Typically, in an application like SL (or a 3D game) the majority of the CPU is consumed by the rendering thread.....mostly due to handling the setup, changes, and other things that feed the GPU. Another thread may be handling Network communications, another handling sound, another synchronizing things, etc. Those are not nearly as time-critical as the rendering thread. ALL threads yield time and allow other threads in the same core to execute. This means that no thread can starve all the others. But one or two threads can still dominate the CPU usage on a given core. This is expected. And since 3D rendering usually happens as fast as possible (i.e., no frame-rate target caps.....just get as much as possible) the core that the rendering thread runs in will typically peg (sometimes only to 50%, if hyperthreading is involved). While it would be nice to have dynamic multi-processing auto-balanced across cores in a CPU, applications and operating systems can't yet, and the overhead in hardware in the CPU itself would be excessive. Hardware and the OS depend on the software to distribute things as evenly as it can across threads, but that is limited by the nature of the application.....not all apps balance well. MIMD parallelism is tough to work with. Take it from someone who's written code for SIMD, MISD, and MIMD parallel processor machines. Threading makes it simpler to program, and efficient enough as long as the threads are created with proper priorities by the host process. Now as to getting the same framerate on two simultaneous SL processes running on a single CPU.....No, not the way it works. Several issues with that. First is bus contention (that PCI-E bus can only have one master at a time.) So even if one process has finished with it, the next may not get it immediately. There is also overhead with task switching, and unless the processes are viewing the exact same scene at the same resolution and settings, it is NOT going to be the same. There is also contention in resources (network usage, for example) that will cause additional delays. Let's not even talk about cache and disk access issues. But, even assuming two GPUs, two network cards, separate hard drives and separate controllers, separate monitors......the OS is still doing other things in the background, and some of it may be executing on some of those cores. Which can cause additional imbalances in load and other contentions with resources. As for the bottleneck being GPU power, that's not really the issue. The issue is the way the GPU pipeline works, and what has to be done to prepare a scene. If a single GPU is being used, then each process has to get access to it, and ALL the currently cached rendering setup is invalidated, and has to be redone from scratch. Some textures may remain cached, but there are no guarantees. The transforms, shaders, camera properties....everything about how it renders a frame....has to be re-configured for the next process. And this happens pretty much every frame or two (as the PCI-E bus yeilds control from one SL process to the other.) In other words, a significant slowdown just trying to run two simultaneous SL processes. No amount of programming skill or technique really overcomes the limitations inherent in the hardware designs. We can try to minimize the impact, but in the end, we software engineers are limited in just how much we can do in that regard.

Need a few more details to even begin this..... 1) Are you wanting the texture uploaded, or simply displayed on the prim containing the script? Clarify what you mean by "brought into SL somehow..." 2) How do the three parameters passed to the script arrange to form the URL? Need to know this to make a script that works. 3) How are you wanting to pass the parameters? I'm assuming chat on a specific channel, but there are a lot of ways to communicate with a script.... 4) Are you wanting Media on a Prim, or setting the texture? If MoaP is okay, the script is easy.....the other....not doable without some kind of scripted agent bot and some significant non-scripting work.

Technically, no. An external site CAN connect to a webserver object in SL, which has the notecard, and have it 'give' it to a given recipient. But I have a feeling that isn't what you are looking for. The external site can pass in a user name, key, and other data so the SL object knows who to send it to, and which one (out of its inventory of notecards) to send. But this is how a lot of update servers work already.....just with objects , instead of notecards.

I've been using various 3D packages for many years.....I've tried just about all of them (haven't tried Maya yet, though.) Of all of them....the most intuitive, quick, and flexible? (at least, in my opinion?) Lightwave 3D. Blender's interface feels a lot more clunky to me. 2.5x improved on it, but still not up to where LW is. 3DSMax.....the whole modelling paradigm just seemed off with the whole 'stack-based' thing. truSpace....free, now that microsoft bought it and it's been shelved. Decent, but no new features or fixes.... The best software is the one you feel comfortable with, and can produce content with quickly and efficiently.....I would normally model in LightWave, rig in 3DSMax, and render with a renderman appliance (if only I could afford time on the render farms!) Texture work I used to use 3D Painter, but its no longer around.....and won't run under win7. Now I mostly just use Photoshop.

Mesh doesn't really put any additional strain on the GPU/CPU. Every current prim/sculpt you see in SL technically IS a mesh.....just one that is 'built-in' to the viewer, so all the info on it is fixed and available locally.....it doesn't have to be downloaded from the asset servers.

Sora, That isn't going to run SL worth anything.....ONLY due to the GPU. An Intel GMA X4500 isn't going to be able to run it beyond low graphics settings at an acceptable framerate.

You can't do that with an avatar.....using llGetOwner() or such in that call won't work. ( the OBJECT_GROUP parameter specificaly notes that if the key specified is an avatar, it will return the NULL_KEY.) The only thing you can check is the ACTIVE group an avatar has with the llSameGroup(key agent) function. Which will also return true if the object isn't group owned! So any object you used in this way would have to be owned by that group first. Then you could use the above function to determine if a given avatar had that group as their active group.

<snark> Then instead of complaining and wanting someone else to fix the problem, do it yourself! You say the problem is all the junky freebies? Then put out some high-quality freebies, and circulate them! I'm sure a bunch of high-quality, top-notch freebies would be heavily used, once they were found and shared......Oh, wait. That would mean GIVING something away to better SL. You don't have a problem with that, do you? I mean, if it's going to benefit SL, and get a lot more retention (and thus future customers), then you and all us other merchants should make a few top quality freebies and put them into circulation. Sure, it's a hit to our profits, but it'll make SL better in the long run! </snark> The reason some may leave SL shortly after signup is all the immature behavior and actions being perpetrated in many of the starting areas. Some may leave when they can't get the hang of the controls, and don't feel like spending the time trying. Some may leave when they come for HAWTSEKS and find out they can't even get to certain areas without age-verifying. The number who leave based solely on the appearance of the world and the avatars in it? Probably a small fraction. I don't have any numbers, nor am I claiming to know.....just making educated guesses. So I don't say these ARE the reasons.....I say they MAY be. You are stating 'as fact' something you have no evidence for. Might want to try stating your claims a little differently......and maybe suggesting some solutions too?