Geldsbard Freck

The one thing you didn't include in your System Spec. is the graphics board you are using. To find out (if you are not sure) in Windows 7 or before open the Start window (round Window's logo button in bottom left corner of your screen) and type in the search/run entry box "dxdiag" and hit [RETURN] This will start a DirectX Diagnostics program. Under the "Display" tab of that program you will find the name of the graphics board currently being used by Windows. Some of the less powerful graphics processors just can't display all the real time bump mapping, reflections, shadow casting lights, environment shaders, etc, even though the SL preferences will allow you to activate them. Your included images look to me like abandoned shadow or highlight renders which would mean you have too many graphic bells and whistles activated or your GPU is simply incapable of rendering all you have active in a "frame rate friendly" manor - so it doesn't! If this is an effect that has just started showing up, it could be a sign of a failing GPU (most likely due to over heating)

Varified! (@Dora) 100 point lights shining brightly! Lights and Shadows turned on in preferences. Forgot to test to see what happens if I turned Lights and Shadows off.

This is an educated guess because I know nothing about Wings 3D: Most "permission" conflicts come from Windows Vista or Windows 7. The folder where you are trying to install the plugin is most likely "protected" or limited access. If Wings or the plug-in is trying to either alter or create, say, an *.ini file, or any other file in that folder, Windows will not allow this with the above protection or security level setting. To correct this you can do one of two things. Decrease the overall security level for the entire computer in your System Settings in the Windows Control Panel - not really a good idea if you spend a lot of time on the Internet or download a lot of free, non-certified software. Find the folder where the plug-in resides and open the "properties" for that folder. Click on the "Security" tab and increase the permissions for that folder. Be sure that the "program", "user", and "administrator" can all write to that folder and all it's sub-folders. Nine times out of ten this will solve "permission" errors whether they are general Windows' error messages or as in your case - program specific.

Understand what a "sculpty" is. The sculpty image is actually called a "height map" in 3D modeling terms; the RGB values for each pixel are actually the X,Y,Z coordinates for each vertex in the wire mesh for the object relative to the objects center. When uploading any image to Second Life, Sl turns the image into a TGA ("Targa" ) image. This includes Scuplty maps. (If you are unsure this is the case, download ("save as") any image in your inventory and it will save as a TGA image file). TGA, like PNG, JPG, and many others have compression schemes that help to reduce the final file size. Sometimes these compression schemes will, among other things, merge two pixels by finding a visual medium - such as a blue pixel and a red pixel, side-by-side can be merged into a single purple pixel. To our eyes, this is visually acceptable, but when each pixel in the sculpty map is actually representative of the numerical position of a point in the mesh, this can begin to distort the object or even delete points. When DirectX or OpenGL (the graphics drivers in our computers that actually draw Second Life on our screens) performs a LOD function (Level Of Detail) on an object mesh, it "culls" (removes) vertex at specific intervals - sometimes every other, sometimes every third, sometimes every forth vertex, according to your graphics settings. If the height map (Sculpty map) has been compressed in the upload to SL, thereby distorting the mesh to begin with, the LOD function has a much more difficult time deciding which vertex to remove and can (and many times does) removes the wrong one creating an even more heavily distorted object. Many casual (?careless?) builders either do not know or don't care to check the "losses compression" box in the image upload dialog when they upload their maps to SL. You may not be able to detect any "smudging" with your eyes but an analisis of the numerical data would show missing vertex or out of place vertex as a result of even slight compression of the image. If this is the case with your purchased object, unfortunately, there isn't much you can do about a disappointing LOD reduction. If it is your own creation, simply re-upload the map and be sure "use lossless compression" is checked in the upload dialog.

Just a few things to consider before you throw your laptop through the window. Sometimes ... especially if you use a "drag select" to select your prims ... you can include one or more objects in your intended link that may not belong to you. If you try, you get a failed link message, Depending on where you are working, this could be an object (prim) underground, behind a wall, invisible, anywhere in the background in your view. - In your build options be sure to check "select only my prims" (what ever it says) this prevents selecting a non-owned object in the background in a drag-select. If you are only trying to link two objects, try selecting one object by clicking on it, then [sHIFT] + click to select the second object. Another possible reason: you are working in "edit linked" mode. This mode will not allow you to create new links, and a common oversight not to turn this off before attempting to link objects This may seem rather self evident, but I mention it just to help you sort out the problem from all aspects. If one of the objects was not your creation originally and has been marked "No Modify" you can not link it to anything else. Both objects must be modifiable.

Helium Loon: Excellent reading! “Fundamentals of Computer Graphics" I'm going to look that one up. This isn't my thread but thanks for your input. My own knowledge is based purely on self study and I will be the first to admit that not everything I "understand" is necessarily 100% correct. What I do know came from creating content for a little known simulation game from Germany. The distributor bought the software distribution rights but could tell me nothing about the display system it used (DirectX only) or even the particulars of the model format to import my contributions. Until that time my experience was only with trueSpace, creating stills and animations; I didn't really care how it worked! I began a very tangled learning journey into the different X formats, and how DirectX used the data, and what was available in DirectX in the way of capabilities that I could utilize in creating my models. To explain the length of this journey, when I began I was having to use DDS textures in power of two, square dimensions. I STILL tend to make textures in square dimensions. After being away from it for a while I find myself arguing over things that no longer apply, or at the very least are legacy functions. From the "intuitive" side I understand the excerpt you quoted from the book but I think a little more reading is necessary for me to fully wrap my head around the process. I think we probably all agree that SL's lack of true reflectivity on prim surfaces and limited control over specularity is one of the reasons metal surfaces are so difficult to create. I guess that's one thing that hasn't changed is that the most convincingly realistic surface is still created with a well made texture. But look how far the technology has come in ten years - wait a few more years and you will be able to render your grandmother's false teeth with a simple slider control adjustment.

Part of what gets my mind going in circles is trying to keep separate the two rendering operations that go on in a 3D package like trueSpace, which is a real-time render and then there is single fram render. The first is attempting to re-draw the screen as fast as it can to create animation or the dynamic aspect of the 3D environment - hopefully no less than 24 FPS. This is the type of rendering going on in SL Because of the speed required to draw that many screens in one second it sort of necessitates the use of simplified methods of displaying the 3D scene. DirectX has improved it's abilities over the years and anyone who has used MS Flight Simulator from the early days has witnessed these improvements in DirectX. MSFS 9 finally included ground shadows projectd from planes and scenery objects, and MSFS 10 has shadows being cast ON planes and scenery objects. This is all done in DirectX as MSFS uses no "interum" (for lack of a better term) rendering engine. In the case of trueSpace, DirectX (or OpenGL) is ONLY used for real time rendering. I'm not certain I remember correctly but LightWorks (i think) was actually created in partnership with Caligari as tS's single frame rendering engine. Until tS 7.6 LightWorks was part of the package - now it must be purchased as a stand alone or plug in rendering engine. I learned early on that SecondLife used LightWorks for it's display. Where my brain scrambles sometimes comes from not knowing exactly how or to what level LightWorks contributes to each frame image. I have had single frame renders with deep level reflections (mirror reflecting mirror reflecting mirror reflecting ....and on) that took several hours to draw one screen (or cell) and an entire week to finish a 20 second animation clip. Helium Loon, your explanation of a texture based reflection is what I suspect the water reflections are in SL (not including the specular shine that comes off the surface of the water) I'm still not convinced SL uses shadow mapping. I really have no evidence to prove my assumption one way or the other, but I would think that if shadow maps are being produced dynamically, as in the animated shadow cast by an avatar, then a form of raytrace or projection as you stated would seemingly be the best way to produce those maps. Again my question is where are the shadows coming from, DirectX (which is now capable of this) or LightWorks, and are their methods different for producing the effect. Back to topic: Mizana, ... face it ... (procedural) shiny metal in SL just plain sucks! Its the nature of the beast that makes it appear on your screen, and your best results will come from a well thought out and carefully produced texture.

This Hi there Chosen Few (Mr. Bones? ... maybe not) Let me explain. I realize there are many accomplished modelers, texture artist and animators in Second Life, but I am aware also that they have only learned the SL terminology and I hesitate (but do anyway) to deviate too far from those terms. It's true that without full explanations and definitions of standard terms used in CGI and 3D graphics and animation, it can be more confusing than if I were to just stick to the SL terms and I get tripped up trying to find a happy medium. So I apologize if I left anyone more confused than I needed to. You are correct and I misused the term "diffusion". This term describes how much an object's surface absorbs light. The less diffuse - the darker the apparent surface. This has nothing to do with that surface's shine or reflectivity and the overall effect is that an objects surface will be more, or less intense in color. This is not a setting you can adjust in SL but can simulate by using slightly darker hues of a given color or adding a gray level color behind (or to darken) a texture. I have to disagree with you that specularity is not employed in SL. I have approached this area of observation both as a 3D artist and game content creator and as a graphics programer. Ultimately it is either DirectX or OpenGL that is doing the rendering and both have the native capability to render specular shine. Neither have the ability to calculate reflections. In the case of SL this would be handled by LightWorks and uses an algorithm called "RayTracing" if it were used A simplified form of raytracing is used by DirectX to produce shadows in SL, an improvement that came in DirectX 9.0c, but it is not used for reflections because it is a time intensive calculation and frame rates would go down to several per minute instead of per second. The amount of specularity and the hue of that shine are an included part of a meshes material data that is sent to DirectX. There is no data template or software command to send to DirectX (or OpenGL) to turn on RayTracing - they do not posses the capability. It is the controlling software like LightWorks that tells DirectX where and how to apply reflections and this is only feezable for single cell rendering for recording animations or single renders. (taken from an x format mesh directly readable by DirectX. I don't know the format of data that SL uses and each set can be set individually through software commands, but this same set of data MUST be sent to DirectX for it to render the object) Material SelectionMaterial_0_26 { 0.000000; 0.094118; 0.541176; 1.000000;; /R.G.B.A. phong color and alpha The alpha here is set by the SL "transparency" control found in the object's "texture" tab in build or edit mode and has nothing to do with texture transparency masks. 0.000000; / Specular Shine amount 0.0 to 1.0 0.000000; 0.000000; 0.000000;; / R.G.B. hue of specular shine 0.000000; 0.000000; 0.000000;; / R.G.B. levels of lumanance 0.0 to 1.0 (as in full bright) By checking "Full Bright" these numbers change to 1.000000, 1.000000, 1.000000 TextureFilename { "C:\\rtr\\Scenes\\PDK\\stateFlag.dds"; / texture name and location associated with mesh } } this is the material data that DirectX reads for every object and then applys to that object when rendering. Examin and compare these two images - One is SL and the other is trueSpace. Both are set with a neutral gray color, and a mid level shine. The specularity in both images effects the size of the shine "halo" (if you will) - a less specular shine would cause a more defined red area and the less defined area of red (at the corner) is actually the red light, lighting and altering the color of the fully defuse material. Both of these show the inherent Phong shader effects of DirectX. Notice in the tS image a small box in the lower right corner of the control box to change the color of the specular shine, also a native rendering ability of DirectX Phong shader (third line of data in the material definition). What is missing in the tS image is the environmental map used in SL to represent reflectance. Had I applied a reflectance layer to the objects in tS it would have had no effect because there is nothing else in the scene for it to reflect! It is my observation that SL does indeed use DirectX's ability to render specular shine but it does this in combination with the environment map. The overall effect is that a low "shininess" presents a higher specularity and less defined environment map, while a higher "shininess" renders a lower specularity and very defined environment map. (even though the environment map itself is an extremely simplified light on top, dark on bottom image and a fuzzy, high-lite area between that represents a hazy horizon (I guess?) Adding Lumanance to an object to overcome diffusion and specular shine caused dimming/darkness. Yes, this is kind of a remnant legacy left over from the very early days of 3D, especially in real-time rendering when 3 lights was maximum. Surfaces that were highly reflective became much less diffuse and except for high-lites, became almost black silhouettes. it was necessary to add some luminance to the material to overcome this. Many "old-timers" still use this technique to create reflective metal surfaces like gold, silver, copper or brass. It gives the material a kind of "glow" if not overused, but not an option in SL. In trueSpace 3.2, DirectX 7. something or other, and a very early version of LightWorks, oh around 2000 or 2001, this luminance adjustment was very necessary to create a shiney metal material unless you built an entire enviroment into your scene. Even then the surface of the metal itself would appear dark. Actually, in the REALLY early days when DirectX was first purchased by Microsoft from SubLogic, there were no lights - directional or omnidirectional and the only way to vary the lighting was to adjust the (self) luminance for each face of the object. Take a look at the first version of Microsoft Flight Simulator, the reason MS purchased the graphics driver from SubLogic. (1987 If I remember) There was no "shading" at all, no textures - everything was phong, and all objects in the 3D enviroment were self illuminated. Chosen Few wrote: ... but I'd also add that the artist should carefully texture the objects, with baked-in (or painted-in) specular highlights, placed where they would most likely be under neutral lighting conditions, and from a neutral viewing angle. Apply a low or medium shine, and it can look pretty good. It will never look truly great, since, as you already mentioned, the baked highlights cannot behave dynamically, but this is the kind of thing we're all so used to seeing in SL that our brains do end up going "Oh, that's metal." Also, I highly recommend paying attention to the colors that tend to be incoprorated into the highlights (specular color) and shadowed areas (ambient color) in various metals. Gold, for example, tends to have bright yellow spec, and dark brown ambient. Copper tends to have pale salmon colored spec, and reddish brown ambient. Aluminum tends to have pale gray spec, and dull blue-gray ambient. Polished steel tends to have a bright gray, almost white spec, and very dark gray, almost black ambient. The list goes on and on. As with all things artistic, the first step to effective simulation is learning how to look. On these points we are in total agreement!:matte-motes-wink: (one last edit) I am not certain what is used for the complex water simulation in SL. It is not an accurate reflection as RayTracing would produce and to my knowledge RayTracing does not distinguish between types of objects as you can set in your preferences. RayTracing can render varying amounts of reflectivity but it is an "all or nothing" function in LightWorks. There may be a whole 'nother algorithm going on there. I suspect that this may be a post render effect (while the graphics page is not yet "flipped" into view) where a mirror image of the viewers angle of the scene is superimposed (with bump map distortions) and masked to the area of water in view. This method could be accomplished much faster tha RayTracing a reflection and could make decisions on which objects to include in the "reflection".

The fact that it leaves your inventory listing would indicate that it is a "no copy" object and is normal behavior for that permission type. If it didn't do this you would now have two copies - one on the ground and one in your inventory. There may be many reasons it is not showing up when rezzed but it would help to know what it is, what size it is, etc. If it's a "packed box" (containing other objects) I have seen some of these with a transparent texture - the box rezzed, you just can't see it (can't tell you why anyone would do that, but ... they're out there). Try this: rezz the object; go into build mode and drag a selection box (left click + drag) over the area you intended to rezz the object. If it rezzed invisible or transparent you will see a yellow outline of the object when your selection box includes the entire object. If this is the case and the object is modifiable; open the object's texture tab and remove the transparent texture. You will now be able to see the object. If the above is true and you "lost" the object, check in your "lost and found" folder - it was most likely returned to you.

The main problem with reflective metal (or any other reflective surface) in SL is that it only reflects the sky and active lights, and even those reflections are extremely diffuse. I realize that you didn't say anything about reflective metals but if you think about it nearly any metal surface you can think of in RL has a certain amount of reflectivity. In the 3D (and real) world, three things make up the look of a metal surface; grain (texture), shine (diffuse), and reflectivity. The diffuseness of both shine and reflectivity depend on the grain or tactile texture or roughness of the surface. Shine itself comes from environmental lighting and reflection comes from environmental lights and surroundings. The very best you can accomplish in SL is a poor representation because both DirectX and OpenGL do not do reflectivity. This must be done with texture. The reason the texture method is inadequate is that reflections on an object move as our vantage point moves around - a simulated reflection remains fixed regardless of the viewing angle. Whats worse is that if there are no active lights nearby, the "shinyness" settings merely seem to darken and haze the surface of the object. In most 3D applications the darkening effect is overcome by adding from 5 to 10% "luminance" (self light) but in SL our choice for this is 100% luminance (full bright) or none at all and 100% just looks plane silly. things to try: Create a "noisy" or fine grain surface texture that resembles the grain of the metal you are trying to represent and superimpose a reflection image (in an image editor). Think about how this reflection must be oriented on the object but generally speaking things reflect light sky tones on their top surfaces and darker earth tones on their lower surfaces.Add SL shine but do it sparingly. Full shine works very well for small, shiny brass and copper objects like door knobs if your colors are correct, but will wash out a steel surface.The realistic appearance of highly reflective surfaces like mirrors and chrome will largely depend on a well planned reflection texture. Take a moment to "study" the reflections coming from objects in your real world environment. Look at the color variations it causes in the surface of the object. There is a fairly decent "brushed steel" texture in the Library > Texture folder that's a good starting point. BUT generally speaking, metal surfaces are fairly disappointing in SL.. The good news is that the inhabatants of Second Life have the visual instinct to accept a dark and dull, fuzzy glowing surface as "shiny metal"!

Yes , correct, ... if the idea is to have a color variation also, say, dark blue at the bottom to light yellow at the top, well you will have to make the texture specifically for those colors.

If you run Windows Vist or later this is most likely caused by the folder permissions settings on your system. You will find that SL stores some profile info in a folder C:\User\(YourName)\App Data(hidden folder)\Local\SecondLife ... When you downloaded and installed SL the installer program was given permission (by you or system administrator) to create and install files to this folder, but in a Default Windows Vista or Windows 7 install or one where the security level is set very high, the SL viewer DOSE NOT have the permission to alter and save files to this folder even though it can read them. Since some of your profile status is kept in this hidden folder in key coded, binary files, it remains unchanged from a basic user as it is installed. Since this info is not being changed, every time you log in to SL the "status" info kept in these files is used to set your "in world profile" status which also will not change from it's default. This is different from your on line account info as this information is kept on the server side and does not depend on your system settings. The reason your "Preferences" remain consistant from one session to the next is because that info is kept in the folder where the viewer runs - Windows allows a program to write to it's own folder and sub-folders (just in case someone raises the question) You need to find this folder and change it's security level. If you don't know how to change the permissions for a specific folder and are not brave enough to "hunt and peck" your way through the process send me a PM and I'll write a step by step instruction. You can also find the instructions at the Microsoft Help Center (HomePage - select your system) and / or other Windows tips sites around the Internet. Windows XP and versions before Vista and 7 do not behave this way so if you are running earlier Windows .... ummmm ..... ?!?

I'm no expert when it comes to permissions but in my experience it not only depends on the permissions of the object you are trying to modify but also the permissions of the resource you are trying to add to the object. In some cases (in my experience) dragging a resource from a rezzed box to either an attachment or another object with restricted permissions will be unsuccessful. In the case of the Intan Dance Ball and a separately purchased "Intan Ready" animation. The instructions say to just drag the box's contents to the dance ball - but that doesn't work! In this case that operation would place a COPY of the animations into the ball and leave the original still in the box (and in your inventory), but the animations are protected with No Copy. In order to add these copy protected resources you MUST unpack the box to your inventory. This removes any no copy resource from the box and palaces it in your inventory. Now you can drag the animations to the ball but you will notice that they are removed from your inventory when you do. This behavior prevents you from taking your purchased animations and adding them every dance ball across the grid. It wasn't stated just how this script was being added to the tail but I would make sure the script was coming out of your inventory - not a box if that is the case, and I would go so far as to suggest that you select the tail while it is on your AV, right click it and select edit; check "edit linked"; find the root prim (if more than one prim); open the "contents" tab and drag your script directly into the contents listing. If you are waring the tail at the time, you do not need to save the tail (now with the script) It automatically becomes part of the object as an AV attachment. If you rezz the tail on the ground to add the script REMEMBER to save it - you will have two tails; one with the script and one without. If the script does not have copy permissions and you mess up, be sure to drag it back to your inventory before deleting anything or you will lose the script. This may not be the answer to your problem, but my main point is there are many ways to get a resource into an object's inventory. If one method doesn't work, try other ways. By-the-way; this method of draging resources directly from inventory to object contents tab (in build or edit mode) is a way to modify something on land that does not allow rezzing - as long as it is attached to your AV, you can edit it. You can also add resources to a HUD this same way - you can always edit a hud while waring it (if the HUD permissions allow) but you MUST be in build mode first.

... exactly what everyone here said except, make your gradient texture a grey scale rather than any particular color. Once applied to the prim you can now select the color from the prim color selector and it will display as you want with the gradation. The advantage is you only need one texture but have selection of any color.

I believe your problem may be in the saving of the image file rather than any way you have masked the image. It is indeed important to get your selection boundary as close as possible to the wanted image but even a perfect selection saved with the wrong transparency settings will create the "dithering" (cloud or halo effect) you describe. 1. Make sure your finished image has a transparency layer below the image layer - do not merge the layers. 2. When you save the image, select either .png or .tga as your file type (I prefer png) 3. In the "Save As" dialog box, click on "Options" (found just below the Save button) 4. in the options menu that pops up select "Run Optimizer" 5. In the Optimizer, click or open the "Transparency" tab; 6. select transparency (as opposed to "no Transparency") 7. select "existing transparency layer" If you use any other method of setting the transparency the save routines will "dither" selected pixels that are not fully transparent or opaque (happens when your tools have a "feather edge" setting) around the edge of the mask. This semi-transparent edge (like looking through a screen door) will show up as a halo. ALSO: make sure when you upload the image that the "use lossless method" is checked at the bottom of the upload dialog; unchecked means your image goes through a compression algorithm that will also blurr the transparency mask.

First of all - you, when in SL are the "agent" - more accurately, it's your computer. Everything you see (except particles) in Sl is an object, even the sky (known as a "sky box" - this may not actually be the case with SL but is normally true in most 3d virtual enviroments. DirectX has a function to display a "background" texture but it behaves differently than the SL sky so it's difficult to tell). What you see on your display is rendered by your computer - not SL; SL merely sends data to your computer. Object data is the data your computer needs to display an object as intended - it's shape, scale, rotation, translation, texture or phong shading , object features, etc. This is the object data DirectX or OpenGL on your system needs for every object that exists within your view to be able to display them for you. Animated objects have this data updated periodically even more so than static objects. The amount of time the server spends to update this data to your system is the calculated "agent time"

After re-reading your post I see that your question is more about a method to change the color rather than an explination of the light itself. in your touch_start state you could call another function that returns a random color vector or include the randome routine within the touch state itself. You could do as Rolig Loon suggests and present pre-set colors in a dialog You could link a touch pad to the light with a grid of different colors that when touched would message the light with the new color vector values. Use llDetectedTouchST() or llDetectedTouchUV() which ever works best for the selector texture and llMessageLinked() + link_message() for communication between prims.

To change the color of the light: SetPrimitiveParams(PRIM_POINT_LIGHT,integer bolean on/off, vector<color>, float intensity, float radius, float falloff) example: SetPrimitiveParams(PRIM_POINT_LIGHT,0, <1.0,0.1,0.0>, 0.75, 8.0, 0.57); or vector color = <0.0,0.0,1.0>; // pure blue ("colour" if you are British =D) list lights_on = [1,color,1.0,10.0,0.75]; SetPrimitiveParams(lights_on); To use PRIM_POINT_LIGHT all 5 fields must contain data. A named variable can be used for any data field You can use a predefined LIST for the data but to change any variable data the list must be re-defined; ie, list light_on = [1,color,intens,rad,falloff]; - but once defined, this list will not change even if the named variables do untill you redefine the list. You can change or replace one element in the list without redefining the entire list with llListReplaceList(). "radius" defines how far in meters the light will extend (effect objects) "fall off" usually discribes (in most 3D software) how far from the origin light the light will fall to half intensity. In Second Life, this is a percentage, 0 to 1, and seems to discribe the light intensity at the maximum set radius. A light with 20 meter radius and .5 (50%) falloff, the light intensity at 20 meters will appear 50% of the original intensity. This may not be what this number actually represents but it is the overall effect of this number. sugestion: be carefull with your effect radius and adjust it according to the type of light it's coming from if you want to be "realistic" A camp fire in RL has a lighting effect out to about 15 feet or 5 meters. If you set it to 20 meters with no fall off it will light up things too far away to be realistic. PS. I also learned on a C64, Basic and 6500 machine code.

Please forgive my ambiguity, I am guarding my idea as best I can because as far as my research can find, no one has tried this in SL yet. It will mean a limited number of sales since it's a highly specialized system. To answer some of the questions: It is all linked objects, the control panel itself being the parent or root object. llSetLinkedParamsFast() could be used to manipulate the controlled objects. My use of the term "external objects" simply means that although linked, their location is typically some distance away from the parent prim. These answers have been very helpful, thanks. I believe that I am going to build two systems - one in modular form that a client can build a system as large as they need without technical intervention and the other would be a (sort of) custom build. But either way, both systems will operate on a single script.

Hi all, This is my first post but I've been building and scripting in SL since '08. I also program in iBasic which is a compiled language with OOP structure and similar to C. .... bla bla bla bla end Intro Project Explination (limited info) My current project is a controller for linked objects. The controller "panel" has linked buttons and control sliders that control linked objects at a distance from the controller. It controls these objects attributes such as color, rotation, glow, etc. Originally I went with linked messaging: The panel itself receives messages from the buttons and sliders then sends messages to the external objects such as rotation values, color, on/off, etc according to the data received from the buttons and controls. The objects receive these messages and act accordingly. At this point I have 9 buttons and 12 slider controls, the controlling panel, and 23 controlled objects (some objects are "twins" and act on the same commands from the controller). This makes a total (so far) of 46 running scripts in a single (grouped) object! The whole system is expandable to the customer's requirements and could double or even triple the number of scripts. The largest script is the main controller in the panel. the buttons' scripts are small - 6 lines, but the sliders' script is a bit more complex with touch locating, texture manipulation and percentage calculations. I think I've already answered my own question, but for the purpose of reducing lag; I'm thinking that llSetLinkedParamsFast() could be used rather than linked messaging, removing the need to put scripts in the controlled objects. The buttons could be done the same way with a touch face location on the main panel and their display (on/off - green glow/dark green) could also be performed by the main panel with SetLinkedParamsFast(). If done this way, the whole thing will run on one script, but the script for the main panel will be necessarily huge ... BUT it will be idle 99% of the time, acting only when touched. (no timer states, no listening, ect) Is it less laggy to have 50 really tiny scripts at idle or one big huge script (mostly) at idle? I can code it either way so my concern here is to find the least resource hungry method to achieve my goal. If idle scripts have little impact on the sim or do they eat up resources reguardless of size. Any thoughts on the matter is appreciated - thanks.