Malinda Quartz

I'm here to also say my sales have dwindled quite a bit these fast few weeks for reasons unknown, other than thinking that the sl pond dried up for me. I've never relied on Second Life as a main income, but it's been a really good augmentation. I'm just a creator trying to sale what I create. For the past few years people have been buying my products but like chewing gum maybe my stuff simply lost it's flavor. I kinda knew this would happen eventually, just feels bad it happened now. Maybe If I'd got access to someone's storefront to put in some lucky chairs of what's mine could help their traffic and boost me back up in the zone so I could afford to pay them weekly rent. Otherwise I'll I can do is create more things in some public sandbox, upload them and see who bites.

sndbad Ghost wrote: hello friends i make sample script for change object color with TextBox i use this script vector message ="" ;integer gListener;default{ touch_start(integer total_number) { integer channel = -13572468; gListener = llListen( channel, "", "", ""); llTextBox(llDetectedKey(0), "Some info text for the top of the window...", channel); } listen(integer channel, string name, key id, string message) { llListenRemove(gListener); llSetColor(message, ALL_SIDES); }} its work fine . with master prim but i need it works with linked prim not master object . i hope you get what i mean thanks Will this do it? // 1 - Create two prims and link them.// 2 - Name the child prim CHILD_01integer GetPrimNum(string n) { integer i = llGetLinkNumber() != 0; integer x = llGetNumberOfPrims() + i; for (; i < x; ++i) if (llGetLinkName(i) == n) return i; return -1;}default{ touch_start(integer total_number) { llListen(-13572468, "", "NULL_KEY", ""); llTextBox(llGetOwner(), "Modified by Punkyboo ...", -13572468); } listen(integer channel, string name, key id, string message) { key r = llGetOwnerKey(id); // Because llTextBox is NOT the owner itself. key n = llGetOwner(); if (r != n) return; else { llSetLinkPrimitiveParamsFast(GetPrimNum("CHILD_01"), [PRIM_COLOR, -1, (vector)message, 1.0]); llListenRemove(-13572468); // Make something like this the last iteration, always. } }} EDIT: Oh maybe you wanted it open to the public lol, here ya go... // 1 - Create two prims and link them.// 2 - Name the child prim CHILD_01integer GetPrimNum(string n) { integer i = llGetLinkNumber() != 0; integer x = llGetNumberOfPrims() + i; for (; i < x; ++i) if (llGetLinkName(i) == n) return i; return -1;}default{ touch_start(integer total_number) { llListen(-13572468, "", llDetectedKey(0), ""); llTextBox(llDetectedKey(0), "Modified by Punkyboo ...", -13572468); } listen(integer channel, string name, key id, string message) { llSetLinkPrimitiveParamsFast(GetPrimNum("CHILD_01"), [PRIM_COLOR, -1, (vector)message, 1.0]); llListenRemove(-13572468); // Make something like this the last iteration, always. }}

I read this blog explaining why there's no EDIT option to contribute to the portal but that was from 2014. Was it decided that it's going to stay locked indefinitely? If so, where else then, can we upload our contributions besides the forum where they'd just eventually get burred? Not much explaination on what's going on with it. I logged on to the portal today, to whatever page I could click on, saw a bunch confusing clutter, tried to click here, click there, click somewhere, just got lost.. it's a mess! What can I do to help fix it and make it user friendly?

By declaring your bits in global like that, you're adding an additional 4 bytes each per bit, which defeats the purpose of saving space by manipulating bits all together. I wrote about it here. Doing it this way, you knock off 16 bytes: integer rmask;//integer REPEATED = 1;//integer MONTHLY = 2;//integer WEEKLY = 4;//integer YEARLY = 8;default{ state_entry() { rmask = rmask | 0x01; // Set Repeated, Comment this whole line to see it not repeated. rmask = rmask | 0x04; // Set the interval string text = "The event is "; if (rmask & 0x01) { text+="repeated "; if(rmask & 0x02) // MONTHLY = 0x02 { text+="monthly."; } if(rmask & 0x04) // WEEKLY = 0x04 { text+="weekly."; } if(rmask & 0x08) // YEARLY = 0x08 { text+="yearly."; } } else text+="not repeated"; llOwnerSay(text); }} I know that's marginal but 16 bytes of free space saved is better than 16 bytes of free space missed. Now of course if you have a long list of bits (like 20 - 31) that need titles for the sake of simplicity...rather than declaring them as global integers each (which would fill up fast) it's better practice to just macro them for the titles: Instead of integer YEARLY = 8; Macro define it like this #define YEARLY 0x08 no semi colon needed either. Your bits stay literal. Edit: Should've noted: A viewer that supports pre-processing (and lazy lists enabled) is needed otherwise #define is surly a no-go. #define REPEATED 0x01#define MONTHLY 0x02#define WEEKLY 0x04#define YEARLY 0x08integer rmask;default{ state_entry() { rmask = rmask | REPEATED; // Set Repeated, Comment this whole line to see it not repeated. rmask = rmask | WEEKLY; // Set the interval string text = "The event is "; if (rmask & REPEATED) { text+="repeated "; if(rmask & MONTHLY) { text+="monthly."; } if(rmask & WEEKLY) { text+="weekly."; } if(rmask & YEARLY) { text+="yearly."; } } else text+="not repeated"; llOwnerSay(text); }}

Hey hey now, that's cool; I don't want any trouble. I didn't mean to insult you or your circle of friends. I mean if you wanna turn down a 0.2% increase in available space. Hey, that's your right. I yeild.. I mean why the heck would I accept a trivial 10℄ hourly raise in my paycheck, right? I'm better than that., you know? In fact that'd piss me off! So much, I wouldn't care of the fact that crap would add up to lousy 80℄ a day. Heck why would I care if that 80℄ totaled out to a measally $4 pathetic dollars a week, or $20 a month! $240a year, eh? thats what I'm saying? You all can correct me on the math here but come on.. That's not the point. "sheeesh!" EDIT math booboo fixed

but given the test Melinda did on bit packing vs not, I'd still not do it. My apologies but that has got to be the most baffling thing I've ever read. You'd still "not" do it even though the benchmarks clearly showed bit-flagging > integer toggling? GOOD LORDEH! EDIT bit-"flagging" not "packing"

since you need some extra code to operate the bitfields. Yes and no; allow me to explain: Yes: When adding say.. bit "0x01" literally and directly into it's own conditional scope will add bytes but you're actually using less because, No: That as long as you DON'T declare "0x01" as an integer itself in global, the overall byte count will not exceed as compared to globally declaring it, would of course add an additional 10 bytes. In the long run you'd get a bloated byte count, defeating the purpose of saving space. Adding mulitple global variables as exclusive toggles (especially if they're 32 bit ints) are allot more heavier in bytes overall as compared to just one 32 bit global toggle being XOR'd against an array of literal bit entries. See the benchmarks I posted. If you look at my comparison, you will notice the difference in size that using bit-flags compared to global integers came out on top. This is why I love Firestorm and it's "Lazy List" feature because making lazy defines allow you to give your "literal value" a title as you would with a global but without it lingering in global memory. All "lazy listing" does is tell the compiler to replace the title with the macro defined value right where it belongs: directly in its scope saving byte space.. EDIT TL;DR: Rule of thumb is: In LSL you can declare a global integer but never declare it's bit globally.

It is absolutely valuable to know how to manipulate bits. There are circumstances where you can't avoid it (as Dora illustrated). But in situations where you are free to choose, you should step back and look at the big picture. There will be tradeoffs in size, speed, readability and reliability and the relative value of each. Just so everyone know's I'm strictly talking about toggling bits only. Err.. we are talking about toggling bits right? Madelaine is correct that the differences in size basically: does not constitute an alarm for all of us to recall our best selling products off the marketplace just to get a less than 10 percent reduction in size, but it does make sense to use this practice of bit-flagging in new projects to come. So now the argument that I present to everyone is: What's the best way of doing it? From what I've seen with LSL scripting, when it comes to toggling bits, there is no adverse tradeoff of speed, size or readability from the bits alone by either XOR or shifting. That would just depend of how the overall script itself is written. I mean, I already know that my basic snippet, with its ugly and redundant nested "else if" flow is not the most optimal way. Advanced coders (both soft and hard) would look at it and laugh. I didn't start this topic to try and "preach to the choir". There are tons of higly skilled coders here, but some of us just don't know bits and I believe that a basic understanding is needed for some of us amateur folk. So I thought I'd try to explain it as elementary as I could and I hope nobody took it as condescension either. If so? My apologies..

That's a very awesome contribution you shared, a bit advanced (EDIT: No pun intended) compared to my "basic script for intermediate and beginners" but nice and compact and it doesn't seem to have a limit and what numbers you can add in either. And that's the magic of tossing in a contribution: It just eventually comes back completely optimized by those willing to spend the time to do so, and I thank you for this. BTW your snippet returned a byte count of 6504. Much-much lower; I'm "jelly'fied!" integer glb_tog; MC()//Based on http://wiki.secondlife.com/wiki/LlSetMemoryLimit{ llSetText("Limited Memory " + (string)llGetMemoryLimit() + "\nUsed Memory " + (string)llGetUsedMemory() + "\nFree Memory " + (string)llGetFreeMemory(), <1,1,1>, 1);}MCI(){ llScriptProfiler(1); MC(); llScriptProfiler(0); llOwnerSay("This script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during Test."); }default{ state_entry() { llListen(2, "", llGetOwner(), ""); MCI(); } listen(integer c, string n, key i, string m) { glb_tog = glb_tog ^ (1 << (integer)m); llOwnerSay( "Bit-flag" + m + " is toggled " + llList2String(["OFF","ON"], (glb_tog >> (integer)m) & 0x1) ); }} I think that LL should add yours to the portal minus the bloated benchmark code I added..

I made a comparison: script1 (with one global integer toggling 5 bit-flags as booleans) vs script2 (with five global integers as booleans; no bit-flags).. Both scripts were compiled with memory checks. Script1 returned an average total of 7560 bytes while script2 returned an average of 7576 bytes. The difference is not substantial but it does show that bit-flagging (in Second Life) does indeed decrease memory payload rather than increase it. script1: Bit-flaggedx5 integer glb_tog; MC() //memcheck{ llSetText("Limited Memory " + (string)llGetMemoryLimit() + "\nUsed Memory " + (string)llGetUsedMemory() + "\nFree Memory " + (string)llGetFreeMemory(), <1,1,1>, 1);} MCI()// memcheck init{ llScriptProfiler(1); MC(); llScriptProfiler(0); llOwnerSay("This script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during Test."); } default{ state_entry() { llListen(22,"",NULL_KEY,""); MCI(); } listen(integer c, string n, key i, string m) { key r = llGetOwnerKey(i); key x = llGetOwner(); if (r != x) return; else { string t; if ("bit1" == m) { glb_tog = glb_tog ^ 0x01; if (glb_tog & 0x01) t = "Bit-flag1 is toggled ON"; else t = "Bit-flag1 is toggled OFF"; } else if ("bit2" == m) { glb_tog = glb_tog ^ 0x02; if (glb_tog & 0x02) t = "Bit-flag2 is toggled ON"; else t = "Bit-flag2 is toggled OFF"; } else if ("bit3" == m) { glb_tog = glb_tog ^ 0x04; if (glb_tog & 0x04) t = "Bit-flag3 is toggled ON"; else t = "Bit-flag3 is toggled OFF"; } else if ("bit4" == m) { glb_tog = glb_tog ^ 0x08; if (glb_tog & 0x08) t = "Bit-flag4 is toggled ON"; else t = "Bit-flag4 is toggled OFF"; } else if ("bit5" == m) { glb_tog = glb_tog ^ 0x10; if (glb_tog & 0x10) t = "Bit-flag5 is toggled ON"; else t = "Bit-flag5 is toggled OFF"; } llOwnerSay(t); t = ""; } }} script2: global integers x5: integer glb_tog1;integer glb_tog2;integer glb_tog3;integer glb_tog4;integer glb_tog5;MC()// memcheck{ llSetText("Limited Memory " + (string)llGetMemoryLimit() + "\nUsed Memory " + (string)llGetUsedMemory() + "\nFree Memory " + (string)llGetFreeMemory(), <1,1,1>, 1);} MCI()// memcheck init{ llScriptProfiler(1); MC(); llScriptProfiler(0); llOwnerSay("This script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during Test."); } default{ state_entry() { llListen(22,"",NULL_KEY,""); MCI(); } listen(integer c, string n, key i, string m) { key r = llGetOwnerKey(i); key x = llGetOwner(); if (r != x) return; else { string t; if ("bit1" == m) { glb_tog1 =! glb_tog1; if (glb_tog1) t = "Bit_flag1 is toggled ON"; else t = "Bit_flag1 is toggled OFF"; } else if ("bit2" == m) { glb_tog2 =! glb_tog2; if (glb_tog2) t = "Bit_flag2 is toggled ON"; else t = "Bit_flag2 is toggled OFF"; } else if ("bit3" == m) { glb_tog3 =! glb_tog3; if (glb_tog3) t = "Bit_flag3 is toggled ON"; else t = "Bit_flag3 is toggled OFF"; } else if ("bit4" == m) { glb_tog4 =! glb_tog4; if (glb_tog4) t = "Bit_flag4 is toggled ON"; else t = "Bit_flag4 is toggled OFF"; } else if ("bit5" == m) { glb_tog5 =! glb_tog5; if (glb_tog5) t = "Bit_flag5 is toggled ON"; else t = "Bit_flag5 is toggled OFF"; } llOwnerSay(t); t = ""; } }} EDIT: If you notice that script2 still shows the string literals with Bit-flags quoted, I left those alone because this test is not comparing string size but rather the integers vs the actual bit-flags, incase anyone's wondering.

This quote from learncpp.com has a good answer for that question ( I think ): Let’s take a look at a more concrete example. Imagine you're creating game where there are monsters for the player to fight. When a monster is created, it may be resistant to certain types of attacks (chosen at random). The different type of attacks in the game are: poison, lightning, fire, cold, theft, acid, paralysis, and blindness. In order to track which types of attacks the monster is resistant to, we can use one boolean value per resistance (per monster). that's 8 booleans per monster.With 100 monsters, that would take 800 boolean variables, using 800 bytes of memory.However, using bit flags:1 const unsigned char resistsPoison = 0x01;2 const unsigned char resistsLightning = 0x02;3 const unsigned char resistsFire = 0x04;4 const unsigned char resistsCold = 0x08;5 const unsigned char resistsTheft = 0x10;6 const unsigned char resistsAcid = 0x20;7 const unsigned char resistsParalysis = 0x40;8 const unsigned char resistsBlindness = 0x80;Using bit flags, we only need one byte to store the resistances for a single monster, plus a one-time setup fee of 8 bytes for the options. With 100 monsters, that would take 108 bytes total, or approximately 8 times less memory. For most programs, the amount of memory using bit flags saved is not worth the added complexity. But in programs where there are tens of thousands or even millions of similar objects, using bit flags can reduce memory use substantially. it's a useful optimization to have in your toolkit if you need it. This quote talks about single byte chars, not 32 bit LSL integers. So of course if there's only one toggle then only one integer needed, in LSL.

/*Test output: 00000000000000000000000000000000Test output: 00000000000000000000000000011001Test output: 10000000000000000000000000100001*/ integer MEGA_ZERO = 0; //Extrapolated: [0000 0000₁ | 0000 0000₂ | 0000 0000₃ | 0000 0000₄] If I'm correct, that's 4 bytes worth of binary zeros & ones mostly squandered (by ammature coders like myself) since typically 1 out of those 32 bits gets assigned as a boolean, becomes a substantial waste of bitspace even if you have a project that needs like four to eight or even ten togglers. And the reason why I don't dare petition the Linden-Labers to give us the ability to declare smaller vars like "char", or something like "integer8", "integer16" (for situations like this), is because that would be asking them to risk breakage on other parts of code functionality unless its on the preview grid. So this is kind of why its (IMO) better practice to use just "put in" one integer to globally toggle everything especially with a limited size of 64k per script, stuff can add up fast. After combing the LSL portal, I've noticed there's really not much info/talk about bit-flagging (unless I overlooked something) and I'm pleased that people are starting to support this as good practice for second life and I really think LL should get this wiki'd if its not already.

I'd prefer the term "Old School" rather than outdated but it's just a method that works, and saves the coder or "soft" coder unnecessary "memory tax" (if I can call it that) for things like multiple buttons extending/retracting multiple menus exclusively within a HUD-script that use only one global integer for all toggles. It's quite simple to understand: If you're just doing simple toggles, then the bit-masks bit-flags need to be certain even numbers that have only ONE binary "1" out of the all the "0"s within: I personally did not know this until last night. 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096 and so on..perfect for YES/NO togglingBinary.....Dec..Hex 00000001 = 1 ...(0x01)00000010 = 2 ...(0x02)00000100 = 4 ...(0x04)00001000 = 8 ...(0x08)00010000 = 16...(0x10)00100000 = 32...(0x20)01000000 = 64...(0x40)10000000 = 128..(0x80)and then double:0000000100000000 = 256 ..(0x100)0000001000000000 = 512 ..(0x200)0000010000000000 = 1024..(0x400)0000100000000000 = 2048..(0x800)So on...... All 1s you see here just happen to be out of each other's way. Any other numbers like 3 = 00000011 (odd number) is going to toggle it's self and others at the same time using the XOR ^ method (from what I get) and you don't want that for just simple exclusive true/false flipping. You can (however) toggle odd numbers by method of bit-shifting << or >> to basically "scoot" the 1s in or out of the way.. Assuming I'm correct hehe. I am personally thankful that LSL allows this.. EDIT: Not all even numbers contain single 1's: 6, 10, 12, 14 , 18, 22, etcetera'cetera.....

EDIT, Sep 17: I'm going to periodically edit this post so to try and make it look more presentable and easier to understand. I started this topic because after searching both the forums and the lsl portal, I'd noticed there's not much discussion or any tutorials emphasizing on bit-flags or any bit manipulation for that matter. So someone once said "If you truly want something done? Gotta do it yourself." So here I am. My hope is that this will benefit new-comers and students learning to code who are not so familiar with the rundowns. Hi everyone. Just thought I'd toss in a contribution: Why use multiple global integers when you can just use one to toggle multiple bit-flags each exclusively via XOR? Bit-flags are used to prevent an unnecessary stack of 32 bit integers that would be used to toggle things. How do we visualize bits within an LSL integer: Take a look at this; integer glb_tog = 0; //32 bit glb_tog looks like [00000000 00000000 00000000 00000000] That's a big row of binary zeros. Count those zeros, that's 32 or 32 bits. The green bits are going to be manipulated (within the snippet below) and we'll leave red one's alone. Let's extrapolate the big row some more: Hexadecimals to "address" the bits. 0x01 = 00000001 0x02 = 00000010 0x04 = 00000100 0x08 = 00001000 0x10 = 00010000 The positioning: [00000000 00000000 00000000 0001₁₀ 1₀₈ 1₀₄ 1₀₂ 1₀₁] All bit-flags in position. These selected hexadecimal numbers are chosen because they share one thing in common, they are all single 1 binary digits. That's important to know when xoring any integer against it's bits without the use of bit-shifting as opposed to non-single binary digits such as "0x03 = 00000011". So whenever we toggle a single bit with the xor operator ^: glb_tog = glb_tog ^ 0x04; // Hit! We get this outcome: [00000000 00000000 00000000 00000100] bit-flag in position 3 is switched on. glb_tog = glb_tog ^ 0x04; // Hit again! Outcome: [00000000 00000000 00000000 00000000] bit-flag in position 3 is switched off. So without further adieu: Example Snippet (imperative style) for basic and intermediate levels: // Using only one global integer to control five toggles for the purpose // of better memory optimization - By the owner of Second Life Avatar: // Malinda Quartz (Sat Sep 17, 2016) Updated. // This script is....GPL licensed. Why not.. // Okay so basically: Why use five global integers // when you can just have one toggling five bit-flags // each exclusively? You can control up to 32 toggles // into one SL integer but for this example we'll just do five. // Instructions: ctrl-c & v this script into a prim within Second Life // and save. Type in public chat using channel 22: either // "bit1" or "bit2" or "bit3" or "bit4" or "bit5" without quotes // and watch them toggle ON/OFF. Example "/22 bit4" without quotes. // Lazy Lists: // In LSL never declare a "bit" globally or locally for that matter. // If you need to put titles on your bits, macro define them with a // compiler that supports pre-processing so to avoid doubling your // byte cost on each one. // If you have a viewer that doesn't support pre-proccessing then // add your bit digits directly into their scopes. You can add them as // hexadecimal or decimal but I prefer hex. #define lzy_bit1 0x01 // "00000001" = "1" #define lzy_bit2 0x02 // "00000010" = "2" #define lzy_bit3 0x04 // "00000100" = "4" #define lzy_bit4 0x08 // "00001000" = "8" #define lzy_bit5 0x10 // "00010000" = "16" // Just one integer 32 bit [00000000 00000000 00000000 00000000].. integer glb_tog; default { state_entry() { llListen(22,"",NULL_KEY,""); } listen(integer c, string n, key i, string m) { key r = llGetOwnerKey(i); key x = llGetOwner(); if (r != x) return; else { string t; // Why can't we just do "glb_tog ^= bit-flag"? (C++) It's // more succinct but it just won't compile that way. So // "glb_tog = glb_tog ^ bit-flag" (old school) will // have to do instead. Anyway, toggle using XOR.. if ("bit1" == m) { glb_tog = glb_tog ^ lzy_bit1;// ON/OFF if (glb_tog & lzy_bit1) t = "Bit-flag1 is toggled ON"; else t = "Bit-flag1 is toggled OFF"; } else if ("bit2" == m) { glb_tog = glb_tog ^ lzy_bit2; if (glb_tog & lzy_bit2) t = "Bit-flag2 is toggled ON"; else t = "Bit-flag2 is toggled OFF"; } else if ("bit3" == m) { glb_tog = glb_tog ^ lzy_bit3; if (glb_tog & lzy_bit3) t = "Bit-flag3 is toggled ON"; else t = "Bit-flag3 is toggled OFF"; } else if ("bit4" == m) { glb_tog = glb_tog ^ lzy_bit4; if (glb_tog & lzy_bit4) t = "Bit-flag4 is toggled ON"; else t = "Bit-flag4 is toggled OFF"; } else if ("bit5" == m) { glb_tog = glb_tog ^ lzy_bit5; if (glb_tog & lzy_bit5) t = "Bit-flag5 is toggled ON"; else t = "Bit-flag5 is toggled OFF"; } llOwnerSay(t); t = ""; } } }EDIT: This page has some good info on bit-flags and masks Example Snippet (optimized logic style) for intermediate & advanced levels - Credits go to wherorangi for sharing this: integer glb_tog; default { state_entry() { llListen(2, "", llGetOwner(), ""); } listen(integer c, string n, key i, string m) { // expects m to be in the range "0".."4" glb_tog = glb_tog ^ (1 << (integer)m); llOwnerSay( "Bit-flag" + m + " is toggled " + llList2String(["OFF","ON"], (glb_tog >> (integer)m) & 0x1) ); } }EDIT: Add this script to a prim and type in chat "/2 4" or any number without quotes.

As a merchant (myself) who's sales have dwindled down to a 10th of what used to be around 9 - 14 sales per day for many years. I'm getting pretty hungry and rent isn't getting any cheaper and its taking a toll on my sanity. Ya see? In RL, I'm not all there in the head if you know what I mean and I apologize to the people here on the forums over that, but I'm good at scripting/building things. Second Life has been my financial savior for quite some time. Fact: that I can't do the 9 to 5 thing in RL. If not for SL, I'd be homeless and smelling like the trash I'd have to eat No thank you with that! For the past few months I've been under the assumption that my low sales have been the result of dated products like chewing gum, just eventually loses its flavor and no longer worthy of interest and because of that, I've been at it these past few weeks trying to come up with "fresh flavored" products for the marketplace, but even still! They don't seem to be getting the clicks. I really think every merchant including the big time sellers and veteran designers should all call Linden Lab via phone and email and get them to hear our say even if they give us the run-around talk, it'll let them know how serious this is to us. Let them know this could put allot of us in danger of bankruptcy ( and that's no hyperbole) of course at least that's how I feel. It's been around awhile already, this new search system and I just don't see LL making any attempts at rectifying the situation. Maybe they don't agree its broken, who knows. I agree that it is in fact broken. Second Life's life blood is the very merchants (suffering from this bogus search system) trying to build/update/re-sale items on a botched marketplace. We're merchants, not 'hackers' trying to game a system. We're just trying to eat! So to Linden Lab: I see a vision, a meme: Ashton Kutcher as Steve Jobs yelling "SO FIX IT!!!!" Thank you and my apologies for my (future) nuttiness.

My apologies again, that was my "friend/lover" I was afk. We share the same computer and yes were both here together. So therefore I appologies on Devan Miami's behalf. He's upset over something that happened to me in one of the sims a few days ago. It was kind of uncalled for but I've conviced him to relax now but he thinks that the two of you or a few of you are behind it. That if you guys are trully them? Lets talk in private shall we?

Oh btw I see what happened, He left the computer, the room, I walked in, logged him off, so I could log myself in, then had to afk, he came back thinking he was still logged in and just started typing away on my account. My apologes but that wasn't me. Sorry about the confusion. Bad lover..

I can do whatever I want too. Who's to say more than one person don't share the same computer, in the same house with the same bed.. hmmmmm? Much appologies for my lover's behavior but I kinda have to agree with him though. cherio Edit but then agin I could say.. kick him out if he gets bad in the future but we'll see.

...

Seems like some LindeX congestion going at the moment. Is it the end, or just a bump in an already seismic line?