LepreKhaun

Your sixteen nails might better be done within the texture instead of being modeled. This is generally true of all nails, brads, rivets and any other small embellishments along these lines. As it is, you're not only unnecessarily upping your final LI with this unneeded geometric complication but the nails are eating up a huge amount of space of your texture. A normal map might be used if you wanted to further the illusion of protrusion drawn onto the texture, but I'd skip that on such small details.

The lettering is called text overlaying and if you Google "text overlay tutorial" and "text overlay effects" you'll find thousands. In fact it may help to also include the name of your graphics program as well, just to narrow it down. Basically you're just adding a layer to your image with the text on it, sizing and placing it and from that point on it starts getting fancy! Borders are simply called borders and, if you lack the time to devote to them, you can Google "picture border clip art" for a large number of royalty-free examples, which are then added to your image the same as text, on a new layer. Always read the fine print of the licensing of any elements you use in your work to ensure it's within bounds. That said, graphic design in advertising is a "voodoo science" that takes years to master. Carefully screen your efforts with friends and relatives before going "live" with them and, if their (honest) reaction is lukewarm, consider hiring someone to do this for you. That image is your first impression with a potential customer, you don't want it to be the last as well. /me grabs one of Rolig's comfy cushions, sits down and sips some of Maddy's root beer...

Please stop frustrating yourself. Learn as you go and do what you're able to to do at that point. Attempts to take shortcuts will only end up having taken a longer path. http://community.secondlife.com/t5/Mesh/Avatars-Meshes-Blender-Help-please/m-p/2483363

revochen Mayne wrote: Another way to achieve an alpha fade in or out is by using a texture grid and the llSetTextureAnim function. This might be the less lag way, especially as llSetTextureAnim is client side. Looks good on paper, have you ever attempted this approach?

Innula Zenovka wrote: See http://community.secondlife.com/t5/Tools-and-Technology/Changes-to-Our-JIRA-Implementation/ba-p/2519371 Thank you, Ebbe Altman. woot woot! Thank you for bringing this to our attention. Transparency in dealing with the issues we all face can only bring about resolution of those issues. Whether that resolution by LL is appropriate or not is on them, at least we now have a means to track their actions in response to our reports.

Matu wrote: It can be done with a bot, however i never heard of a bot that does this. A bot, which is a scripted agent (an avatar controlled by a software program), can do many things. However, it would be no more capable of organizing the OP's inventory than either you or I would be.

Rolig Loon wrote: ... Take a look at the function llSetAlpha, which will control your object's transparency... Errr, I just realized that's prim specific. For an object (which may or may not be a link set) one needs to use llSetLinkAlpha(LINK_SET, alphaFloatVar, ALL_SIDES); where alphaFloatVar is, of course, the decrementing transparency control. See http://wiki.secondlife.com/wiki/LlSetLinkAlpha , for details, which also has a fade in/out script that the OP could easily mod to their specs.

Tenaar Feiri wrote: ... The script saves the data periodically, but I don't want to accidentally lose any of the information it's currently processing if a restart unexpectedly happens in the middle of its workflow. I know scripts generally just 'pause' when the server's down & resume again afterwards but I don't trust LL's servers to reliably retain my script data. ... I feel you're overlooking the fact that you're trusting the server to pause and resume script execution up to 45 times a second any time the server is going. A script gets a very thin slice of a server frame. And between those slices, they're rolled up like a rug and stashed in a corner. And let's not even get into the hand off that occurs when teleporting to another sim, when you may have to be trusting not only two different servers, but they may be running differing channels of the software...

Exactly- when the specifications begin changing, then one just goes with the wheel that's already been invented. Otherwise, we may end having to explore multiplication next. No harm in that except any possible string manipulation is going to prove inferior to the list and integer manipulations given in BigNum, especially the effect working with long strings under Mono has on heap memory usage.

Shay McAuley wrote: I have looked through the forum, but could not find a related topic, so very sorry if I have missed it anywhere and I`ll be happy if I just get a link to it, if there is one already. ... http://community.secondlife.com/t5/Mesh/I-NEED-HELP-Trying-to-add-link-add-on-objects-to-Mesh/m-p/2169219/highlight/true#M23209

Indigo Mertel wrote: @LepreKhaun, planar mapping doesn't work with curved faces and when faces are tilted, but in this specific case it's a piece of cake. Faces don't even need to be on the same plan, I often use it to map textures on perpendicular faces, as is often the case with a room. And, as you noted yourself, prims do not need to be linked. As for your suggestion, it's another way to do it but I don't see how your way can be easier/faster than the few clicks required by using planar mapping. That was simply to show an alternative workflow, no recommendation made over any other. If you feel a need for making a comparison you feel a reader isn't capable of, that's fine.

Follow Qie's advice; irihapeti's approach doesn't take into account the signs of the addends and, if one of them is negative, you are doing a subtraction and may end up with a negative number. Though BigNum has a lot more features than you think you require, a study of it will show exactly what you need to extract out of it to implement what you need. The list and integer manipulations there will be far better than anything cobbled together using strings.

Welcome to the forums! Everything Rolig said with the addition of adding the option of doing the fade within a loop (possibly having a llSleep(0.01); in it) in your timer event handler (requiring only a local variable for the current transparency) as opposed to using the timer from that point on (which would require a global variable). Only caveat to that approach would be having event messages queued until the loop finished. Benefit would be finer control of the effect and one less global variable.

Planar mapping may not always work as expected and, in the case of unlinked prims, won't even be doable [Edited to strike mistaken part of statement, I see as how it is doable after all]. Here's my work flow for these cases. If you separate the texture sizing, then do the vertical adjustment and finally the horizontal tweaking, this will go a lot easier/faster. Also, your final texturing will never be better than the build itself, if there's seams between the prims, there'll be seams no matter how you texture it. So tighten up the build first if needed. Your wall consists of 4 prim boxes, the one to the far left extends from floor to ceiling, has no cuts and isn't hollowed. This naturally makes it your Base Prim, which you'll start with and use to derive the other texture placements. Start with this Base Prim (the one all the way to the left), in Edit Mode with "Edit linked" checked if the wall is linked together. Also, make sure "Stretch textures" and "Stretch both sides" are NOT checked throughout this. Make note (using copy and paste into Notepad) of the <X, Y, Z> coordinates of its Position and also its Size vector in the Object Tab of your Edit Floater. You'll also need these measurements for the other three prims as well when you work your way across, so I usually copy all this information down before I even start. Move this Base Prim into the room a bit, in "front" of the rest of the wall but maintain its Z Position. Change the width of this prim to match its height by pasting its largest Size into the middle Size (figuring the wall thickness is going to be the smallest Size within this vector and X, Y and Z may unexpectedly differ according to how the original builder had oriented things). This gives you a square to apply your texture to. Move this prim to the "right" so its completely within the room. Check "Select face" and click on the wall, open the Texture Tab and apply your wall texture with scales at 1.0 and offsets at 0.0. Rotate it in 90 degree increments if needed. The top and bottom of the texture should now be correctly aligned at this point but it may appear "scrunched" or "stretched" horizontally. If it's scrunched, you need to halve the horizontal scale. If it's stretched, you need to double it. This adjustment has to do with the ratio of height to width of the texture, which may not be square. Make note of the final configuration, ensuring your offsets are still at 0.0. This finishes sizing the texture correctly Uncheck "Select face" at this point. Now it's simply a matter of replacing the Base Prim back into its original Position and Size. Copy and paste that info back in while in the Object Tab of your Edit Floater. Once it's back in place and resized as it was originally, you're done with it, no more adjustments of any sort will be made to it from this point on and everything else builds out to the right from it. Next you have a choice of which of the two prims to the right of that to work with next. Doesn't matter which, whether it's the "stringer" across the top or the prim with the hollow (the "window" prim) first, they're both handled the same. Move one of them a bit into the room, in "front" of the rest of the wall. First step is to size the texture to match the Base Prim. To do this, you need that square again you had initially. Copy the height of the Base Prim and apply it to the height and width of the prim you're working with. NOTE, height and width may not match X, Y or Z from prim to prim, depending on how they may have been rotated originally. If you apply it to a thickness, don't worry about, hit CNTRL-Z to undo or simply paste in the correct wall thickness later. What's needed is that square area of the same size we had on the Base Prim when we apply the texture. Once you have that, Select face click on the wall area you're working on and apply the texture, with the rotation and scaling exactly as used before. Your texture is now correctly sized on this prim, we won't touch scale again. Now, Select Move and paste back the prim's original Size and Position. Recheck Select face Do the vertical alignment first using the Vertical offset in tenths, then hundredths and finally thousandths. Then do the horizontal alignment to match the Base Prim. A trick for this is to find a distinctive part of the pattern near the edge of the Base Prim and bring it into view on your working prim. Then move that into the Base Prim's pattern. A final tweaking may be needed on the vertical to get this seamless. However, don't touch any settings on the Base Prim, once you're there, you're done with it, move on to the next and don't touch it again! That's basically it, size the texture correctly onto the prim, replace the prim's Size and Position vectors, align it vertically, then horizontally (with, possibly, a vertical tweaking at the end) and then leave it alone! The final prim, with the "doorway" (as pointed out by GreggStar in the second message) requires one additional thing. Immediately after applying the texture to the square area of this prim, you'll want to double the vertical scale to 2.0 to account for half of it being cut off. Otherwise, same procedure.

Whatever gave you the idea that learning LSL was easy for any of us? One never learned to walk by asking to be carried.

Aluviel Nakamura wrote: I am a business woman and I just knew that you were going to rip my texture into photo shop the minute You asked for it! You didnt NOT have permission to do this!!!!!!!!YOU should have asked before doing so!!!!!!! I AM EXtremely angry............Dont you have any respect or common sense? I dont care if you thought you were helping or not........You major stepped over the line by doing what you did. That reminds me of a story me Uncle Mick once told. Seems he was sitting in a pub in the wee hours when a gentleman came limping and stumbling in, moaning and groaning about the pain of his poor feet. Plopping down near Mick, he went on and on how dreadfully hurting his feet were and loudly prayed out for someone to please help him. So me Uncle Mick, being the kind and generous soul he was, bid his friends pardon as he turned to attend to this distressed stranger. "Place your feet up where I can see them, wouldya'. I know a wee bit 'bout boots and all and mayhaps might be of service." So the gentleman swung his feet up onto the stool 'twixt the two of them and Mick bent down to study. Took notes and measurements and generally went over every last inch of the pair. After a good while of this, he nodded and then proceeded to unlace the boots, took them off and replaced them right to left and vicee versee. "There you have it! You'd simply put them on the wrong feet earlier is all" Mickie said as he finished lacing up and tying off with a better knot than what the stranger had worn in. But Uncle Mick's warm glow of a job well done turned quickly to astonishment when the other fellow suddenly sprang up and began beating all around with his walking stick, in a frenzy like. "You dastardly scallywag! I knew you were up to no good as soon as you asked to see me boots! I'm mortified that you'd dare to touch them with nary a 'by your leave' nor even a 'may I, please' first!" And as he flounced out (with no limp, one might add) he continued ranting of the outlandish abuse he had suffered in the place. After the telling of this tale, I had to ask me Uncle Mick how this had affected him. He paused in thought for a moment and then replied, "Well, me Nephew... In a pub, in the wee hours, one can only forgive a fool drunk. But truth be told, if he ever comes back to get those boots resoled, that gent might best be passing me by."

Wow, it's amazing what I find myself learning while watching over the shoulder of a good student. Excellent thread!

arton Rotaru wrote: Well, the reason why it's a bug is simple. It has been aknowleged as a bug by Linden Lab, and it's not marked as expected behavior. Only because of there are easy workarounds, doesn't mean that It's not a bug. Seriously, the behavior would be the most stupid intentional behavior I have ever seen. About changed behavior to touch_start can be read here. https://jira.secondlife.com/browse/SVC-3017 Most interesting reading, thank you for the enlightenment. Of course, now that I'm aware of this, you'll be the blame for my next month of lost sleep. Seriously though, the issue raised there is a much more serious issue than that of an unexpected "prim grab", is most definitely a bug and, since it has never been resolved in the six years it was first reported, underscores the advice to never use a state transition within a touch_start() event handler. Thank you again for sharing this!

Dora Gustafson wrote: Well done! I'm impressed. You have demonstrated that a touch in a state without handler makes a prim sick when a new state is entered during the touch. You even don't need any touch event handlers to do it Default{ state_entry(){ llOwnerSay("In default."); // Click and hold at this point llMinEventDelay(0.25); llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, <0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]); llSetTimerEvent(5.0); } timer(){ llOwnerSay("default timer."); state test; }}state test{ state_entry(){ llOwnerSay("In test."); // Prepare to get sea sick! }} That is valuable knowledge The explanation about why and what goes on is still guesswork and hypothetical Obviously something not intended is happening to the prim property because the non physical prim can still be grabbed and moved, even after the script is deleted :smileysurprised: :smileyvery-happy: Edit: My last comment is not valid: A prim can be grabbed and moved as default Mmmm, without the touch* events within state test, I wouldn't have proved that what originated as a click in default, stayed a click after the state transition. However, in my first script what originates as a touch, remains a touch through the transit. In other words, whether a touch or a click is happening in the second state, is determined solely by how the sustained mouseDown was perceived in default. Perhaps this shows it better, using a timer to transition from default both times, just uncomment the three lines in the default state to see what is happening... default{ state_entry(){ llOwnerSay("In default."); // start touching and hold now llSetTimerEvent(5.0); llMinEventDelay(0.25); llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, <0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]); } // Uncomment this event handler to see difference between // Click and Touch being transferred between states.// touch_end(integer total_number){// llOwnerSay("default touch_end.");// } timer(){ state test; }}state test{ state_entry(){ llOwnerSay("In test."); // Still holding mouseDown, move your mouse after this } touch_start(integer total_number){ llOwnerSay("test touch_start."); state test; } touch(integer total_number){ llOwnerSay("touched!"); llLookAt(llGetPos() + llDetectedGrab(0), 1.0, 1.0); } touch_end(integer total_number){ llOwnerSay("test touch_end."); state default; }}

Congratulations, you're off to a great start! The specifications of a program is sometimes the most difficult to work out. Learning LSL should be a breeze for you. A good community to do that within is the Builders Brewery.

Dora Gustafson wrote: It makes sense but is nothing more than a claim or hypotheses that have not been confirmed Neither are reliable references given Only with access to LL's server code a proof could be given of what actually happens Unless we have an undercover Linden contributing in this thread I think that nobody here has this access :smileysurprised::smileyvery-happy: Oh, but I can prove my theory. Observe the touch being transfered over the state change on a long mouseDown: default{ state_entry(){ llOwnerSay("In default."); llMinEventDelay(0.25); llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, <0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]); } touch_start(integer total_number){ llOwnerSay("default touch_start."); state test; }}state test{ state_entry(){ llOwnerSay("In test."); } touch_start(integer total_number){ llOwnerSay("test touch_start."); state test; } touch(integer total_number){ llOwnerSay("touched!"); llLookAt(llGetPos() + llDetectedGrab(0), 1.0, 1.0); } touch_end(integer total_number){ llOwnerSay("Touch_end."); state default; }} But, if I transit from a default which has no touch* event handler to begin with, observe what happens to a long click as it makes the transition. default{ state_entry(){ llOwnerSay("In default."); // Click and hold at this point llMinEventDelay(0.25); llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, PRIM_HOLE_DEFAULT, <0.0, 1.0, 0.0>, 0.0, ZERO_VECTOR, ZERO_VECTOR, ZERO_VECTOR]); llSetTimerEvent(5.0); } timer(){ llOwnerSay("default timer."); state test; }}state test{ state_entry(){ llOwnerSay("In test."); // Prepare to get sea sick! } touch_start(integer total_number){ llOwnerSay("test touch_start."); state test; } touch(integer total_number){ llOwnerSay("touched!"); llLookAt(llGetPos() + llDetectedGrab(0), 1.0, 1.0); } touch_end(integer total_number){ llOwnerSay("Touch_end."); state default; }} And, no, one doesn't have to be a Linden to figure this out, just me.

Gregory McLeod wrote: Thanks to you both for insights innto solving the problem. Question along the same lines you mention the arrangement of global variables and constants. Is there any point in arranging the different types of variables/constants together? Integers/floats/vectors/keys/rotations/lists/strings or some other order. I do not know how the Mono compiler orders these things in memory. Can space be saved? That sounds like a wonderful experiment! And it should be easy to set up and test. Why don't you try this and get back with us with the results?

Rolig Loon wrote: OK...... For what it's worth, I just had a scripting client report exactly this same odd behavior. A one-prim object that I had scripted for him was behaving as if it was physical, even though the edit window clearly said that is was not. If he left-clicked on it, he got the hand cursor icon and could drag the thing . It killed that behavior by adding two lines to the script: llSetStatus(STATUS_PHYSICS, FALSE);llSetStatus(STATUS_BLOCK_GRAB_OBJECT, TRUE); The second line should not be necesssary if the first one is there, but I was not taking any chances. That addition stopped the wierd behavior. I'm wondering if we don't have an undocumented server bug here. Correct, it does seem to be odd behavior until one looks at what constitutes a "touch" as opposed to a simple "click" on an object. Though all touches are clicks, not all clicks are touches. The difference in what constitutes a click as opposed to what may be interpreted as a touch is contextual, entirely dependent on the initiation of the mouse_down event within the viewer, to which the server will respond. The following is Windows specific, though there are parallels within other OS. Right Click on any object will result in a menu of choices, drop down or pie menu, same difference. Left Click on an object with no scripts or a script w/o a touch* event handler is simply a click, do it twice and your avatar will want to walk towards that point. ANY Left Click on an object with an active touch* event handler and the click is processed as a touch, according to whatever is coded within the event handler that is triggered. Left Click + CNTL on an object with no scripts or a script w/o a touch* event handler is a "grab and move". Left Click + CNTL + SHIFT on an object with no scripts or a script w/o a touch* event handler is a "grab and rotate". CNTL + 2 brings up the "Grab Menu", which is also available from the Edit Menu by choosing the Grab Icon. Within the Grab Menu, one has three options on controlling the prim, which differ considerably from the Edit Menu One can also enter the Grab Mode as the OP script does, which is the main caveat regarding making a state change within the touch_start() event handler, as this behavior may be unexpected. Dora almost had it right, in that once a click is initiated, it is either a click or a touch. The unexpected behavior arises when transitioning states within touch_start() (when a click is being interpreted as a touch) to a state that has no touch* event handler at all. In that state, it must either be reinterpreted as merely a click or, as it happens, remain a touch and, as it happens, it's taken to be a touch grab and move, since no other behavior has been defined. In other words, you're simply observing the default prim behavior to be expected under those conditions, all of which can be overridden within LSL And, as I stated before, the grab touch does leave a bit to be desired in its implementation. However, that is the default touch event behavior, for whatever that's worth.

Gregory McLeod wrote: How do you solve stack/heap collisions? I was just adding the last little bit to my HUD and BANG. How do you go about it I have already split the two scripts into 3. I do have a lot of verbiage llOwnerSay 's but is there a good methodology for fixing them? Your llOwnerSay() calls are using more memory space than you might realize, the strings getting passed are copied and exist in memory twice, the same as a string being passed to a user defined function. Limiting these calls to (at most) 2 or 3 well-placed occurrences is always recommended. Having them sprinkled throughout your code results in larger code size, more memory usage during run time as well as harder to decipher messages (the last especially applies when you are trying to get 3 scripts to coordinate their work). In general: Having a llOwnerSay ((string)llGetFreeMemory()); in an often-entered code point should be used as a script is being developed to show how memory use is going as you add more to the script. Its use will be insightful to how memory is being affected by use of user defined functions, global vs local variables, lists and strings- the usual suspects for the stack-heap error. Move code from user defined functions if called less than 3 times from within a script. User defined functions involve memory overhead that is usually not offset by removal of the code from its inline placement otherwise. Try to combine smaller functions into a larger one. Having a Math function with an extra "operation" parameter rather than separate Add, Subtract, Multiply and Divide functions will result in smaller overall code size. Avoid changing long strings unnecessarily. Strings are primarily heap objects, which result in two existing copies on the heap when a change is made. If there isn't currently room on the heap for the new copy (which requires contiguous bytes the length of the new copy) the heap is expanded. These expansions are permanent, the heap never gets smaller. Global and local variables affect memory differently and, depending on their usage within the program, should be set properly. Though a globally declared variable requires more memory than a local one, it is not subject to copying within user defined functions (unless it is mistakenly being passed as an argument, something to look out for!) Avoid small optimizations that destroy readability, saving 10 bytes at the cost of maintainability is no savings at all. Basic design changes to the underlying algorithm can sometimes save kilobytes and should be attempted.

arton Rotaru wrote: It's still a bug though. They broke existing content with the changed behavior to touch_start already. Sorry for my limited knowledge. Perhaps if you could supply a few links to this changed behavior breaking existing content at the time would enlighten me...