Random Ramblings of Lauren Mandelbrot

Login.Mine ar tougher. Mine not only do not need to be reset after being sat upon, they keep flying around even with passengers.I figured that, my Queen, but with me it helps if you`re a bit more explicit, because I can never be quite sure otherwise. My apologiesLots of other interesting information is available, too, but I didn`t notice as any of it would be useful in this context. Methinks I`ll have to be giving the detected functions another look when I update the bugbrain. Oops! Entirely too true.Right. I agree, not that it ever occurred to me.Since I`m working with bugs, though, and not fish, the "colection of individuals orbiting an arbitrary centre" actually seems appropriate to me.Now that makes perfect sense, except I don`t see any need to re-scan, and don`t see why the false result would be a significant issue anyway, especially since I`m already deliberately miscalculating the center anyway. Am I missing something?Update: I just noted that I forgot to post that the initial Health of the bugs has changed from 65535 seconds to 48 hours. This is implied by an earlier post, but I forgot to mention it explicitly.
Toodle-oo! Logout.

That would be true for moths around a lamp, but a swarm of bees following their queen would move as one.

llSensor() can only scan for one object name at once, my fish can subdivide into 8 "breeds" where the name changes to reflect the breed. While shoaling attraction only requires a search for other fish of the same breed, the repultion, or collision avoidance, requires multiple scans to include other fish.

Also, multiple predators require multiple scans to detect them, all the scans being done in quick succesion and the data stored for later processing.

If you use a Queen bug and worker bugs and need them to swarm together, you'll have to do multiple scans also.

Hugz

Login.My bugs currently are called "Fireflies" and "Butterflies", and don`t really need much of a flocking instinct --just something to keep them from wandering away and getting lost-- but the species you mention do have stricter requirements.Hmm. Interesting. I`m not using the repulsion for collision avoidance at all. I`m using it strictly for anti-clumping. I don`t CARE if my bugs collide.Interesting. Is the sensor limit per object, per prim, or per script? I have not yet needed multiple sensor scans, but I had been wondering how I was going to deal with the need when the need DID arise. I still don`t see why the information needs to be concurrent, however. I figured that asynchronous processing of various behaviors would be sufficient. Am I missing somethng?Good point, but I`m not doing that. I currently have two classes of bugs of each species: regular and HerdMaster. I won`t detail the differences here, as there are no changes there since last time I posted about them, but the distinction does not require me to use multiple sensors.

My Queen, your experiments are far and away much more advanced than my humble beginnings. I as yet have no need for some of your advanced techniques, but I eagarly learn from them, against the day when I will have need. I would love to meet you in-world someday. Feel free to IM me.Toodle-oo! Logoff.

llSensor() does not accept wild card entries in the object name, so if you have predator1 and predator2 you must do two scans, llSensor(predator*....) will not work.

It is also important to store the results for concurrent processing as it greatly affects the outcome.

Example,
Bug in centre, predator1 coming from the right, predator2 coming from the left. Escape paths are forwards, backwards, up or down. NOT left or right.

The above escape paths look obvious, but only if you know there are two predators. If you do a single scan, see predator1 and then act on that info imediately, the calculated escape path would be to move left, away from predator1 but straight into the path of predator2...

You must have all the info before you start processing. This is equally valid for shoaling/swarming/flocking, seeking food, object avoidance etc, thus you perform several scans, storing the data each time, then process all the data at once.

Logon.Of course. No disagreements here. The only wildcards are "match EVERYTHING" and "match this EXACTLY".This is the part where I start getting confused.Correct.Definitely an "eep!" move.Here we seem to disagree. I`d say before we start ACTING, not PROCESSING. ...and I still fail to understsand why a small failure of concurrancy on the data is such a big deal. Further explanations from an advanced ALife scripter would of course be welcome.Agreed. ...but again, does the data for any one behavior need to be synchronous/contemporary with the data for any one other behavior?....thus I understand you better, but am still confused.

...and you never did answer my question about the sensor limits, despite quoting the question. "Per script" would be most convenient, but "per prim" seems most likely.



I`ve had several bugs get returned to my inventory yesteday, at least one from as far as a whole sim away from where it sould have been. I`ve had a few similar returns from time to time since the update a couple weeks ago. Something may need to be done about this.
Toodle-oo! Logout.

I'm sorry, I thought I had... There is no llSensor limit based on script, object or prim. You can run as many as you like.

The Limit is in what llSensor can scan for, either Everything or just one object name.
So if you have a swarm of bugs containing 10 of bug1 and 5 of bug2 You can't llSensor(bug*...) to see all of them, you must do two seperate scans, one for each bug type.

This is where storing the data for later processing comes in. You run two scans, one for each bug type, storing the data. You end up with a list of all the data as if you'd run llSensor(bug*...) Like taking a snapshot of the swarm at that time. While you have the data stored you can process it as much as you like for swarming, repultion, leader following, etc. and all the calculations you do are relevant to each other as they all use the same data.

If you do a scan, then process the data, then another scan, then process then data, then act on the results, the seperate scans will be at significatly different times and the objects from the first scan may have moved (or you may have moved) making their data out of date. Doing multiple scans first, storing the data as you scan, then processing it all together ensures the data is collected at the same time (or near enough).


I realise it's not important for what you're doing just now, but if you're to progress you need to understand why it is important. I just not very good at explaining why... sorry.

Login.My apologies; I was not clear enough, obviously. I was refering ro CONCURRENT scans in particular, and llSensorRepeat() in general....so what happens if you

{llSensor(...);llSensor(...);};

Do BOTH scans trigger? If they do, they would of course trigger seperate sensor() events.Exactly. This much I fully understand.This makes sense, too; what I still don`t understand is why it is important for the predator-avoidance data to be fresh at the same time as the swarm-position data, or the food-position data.I agree! This is why I keep asking questions, and explaining where I fail to understand your answers.BTDT. I`m not the world`s best explainerizer either, in either world.

By the way, I note that you`ve stopped commenting on my "average-position distortion-method" of swarm control. Has it stopped being interesting? This sensor stuff is also interesting for another reason: I`m also working on a custom security system. I`ve already been paid two seperate L$1000 retainers for it too [both by the same resident] even though it still needs work.

Toodle-oo! Logoff.

You scan for predators, see one (or more) calculate escape path, runaway... great
You then scan for food, see food, calculate path to food, apply impulse towards food straight into the path of the predator... Bad
You need to scan for predators, then scan for food, then decide which is more important. If the path to the food takes you closer to the predator is it worth the risk???


No no, I think it's a great way of adding repulsion to the swarm calcs.

Login.Ah! I see why you need both to be available at the same time --I was pretty sure I was missing something-- but I still don`t see why you can`t do something like this:

1. Scan for food, updating stored data. Call Move().
   
2. Scan for predators, updating stored data. Call Move().
   
3. Scan for friends, updating stored data. Call Move().
   
4. Scan for left-handed monkey-wrenches, updating stored data. Call Move().
   
5. etc.
   
6. Wash, rinse, repeat.
   

where Move uses stored data from ALL scans to calculate desired motion.That`s for survival of the fittest to determine.Ok.


I haven`t had an opportunity to verify the sensor questions. Am I correct that you have no answers, either?









During 1.11.0.9 and the immediately preceeding releases, I seem to have had some difficulties with bugs flying off on their own and getting lost, or even returned from sometimes distant parcels. I do not yet recall making note of similar problems with 1.11.0.11.



I`m planning on adding feeding behavior next, but I need to work a few things out first. For example, how close should I require the bug to get to the food before it can eat? The way my gardens are deployed, colision may not be practical. For example, how much shrinkage of the Patch of Grass [reduction in health] provides how much additional health [seconds of life] to a bug? For example, how to encode the exchange of data that represents the transaction?


Toodle-oo! Logout.

Login.

Sometime over the last weekend, the entire Garden of Life #3 got returned to my Lost and Found, apparently by accident or program error. The landowner, who had nearly all of his stuff on the same parcel returned also, has expressed interest in a replanting, but has yet to authorize it.

Late Tuesday or early Wednesday, what was left of Garden #2 after several bugs wandered off and got lost was returned to my Lost
and Found deliberately, pending some semi-major landscaping.

Mid-Wednesday, I planted Gardens #5 & 6, but had to leave before finishing #6.

When I returned late Thursday, Garden #6 was quite simply not there, and I have as yet been unable to contact the landowner.

Toodle-oo! Logout.

Login.

As of yesterday, Garden of Life #6, which had vanished before I could finish planting it, has been replanted, in full, on a different location on the same parcel. I now have three active gardens again.


Toodle-oo! Logout.

Login.

During the first part of this month, some weird things have been happening.

1. Garden #3 got replanted, returned, replanted again, and returned again. I am currently awaiting word on the stability of owership of the parcen it was planted on, and on the posibility of replanting it at another location.
   
2. The sim that one of my Gardens is located in seems to have been crashing frequently of late, and my Firefly script was implicated in one of the crashes. The Garden in question was suspended, the Firefly scripts disabled, pending resolution of the issue.
   1. Please be reassured that the problems CANNOT be the direct physics effects of the Fireflies, as the fireflies generally do NOT collide, and there were no complaints when they collided continously.
      
   2. Also, I have been very careful to ensure that there is nothing in the script itself capable of taking down a healthy sim.
      
   3. Further, the fact that one script was reported to have been involved in the sim crash does not necessarily mean that it caused that crash, much less the other crashes.
      1. It remains possible that the crash itself caused weirdness in the script.
         
      2. It is also possible that there are bugs in the sim that my script innocently triggers.
         
      3. Further, the sim seems to be crashing once every three to four days, and these scripts run continously.
         
      
      
   4. I have several Lindens looking into this for me.
      
   
   
3. Also during this period, I learned how to keep the physics engine from stalling the Fireflies and Butterflies, so they remain in continous motion. It is doubtful that this enhancement has anything to do with the crashes, as they apparently were already a problem before I made this upgrade.
   

Toodle-oo! Logout.

Yesterday I planted a new garden, but forgot to make note of WHERE.

Today I re-activated the original Garden.

LOL. It's in my lot in Eup. But Llauren and I have talked since then.

Login....and i`ve been back, and MADE A NOTE OF WHERE IT IS. Thanks, Thistle.

Today I`ve installed Garden of Life #8.

Toodle-oo! Logout.

1. Bibi's Water [1g, 10f, 3b] Open Bibi Book
   
2. Private home [1g, 3f, 4b] Open Anonymous
   
3. Private home [0g, 0f, 0b] Closed [temporarily?]
   
4. Private home [0g, 0f, 0b] Closed permanently
   
5. home [1g, 5f, 0b] Open Jeanette Pegler and robbyg Bling
   
6. Private home [1g, 6f, 4b] Closed [Land sold], awaiting contact with former landowner
   
7. River View [1g, 5f, 0b] Open Thistle Decatur
   
8. Real Slut Tea House [1g, 8f, 6b] Open Lila Luan
   
9. Clan Tangle [2g, 10f, 4b] Open Tangletwigs Fairymeadow and Junette Jamberoo
   
10. !* Various Vendors *! Main Store Happy Shopping !!! [1g, 0f, 4b] Closed [Land sold] Ben Baphomet, awaiting contact with former landowner
    

Garden #4 is the one whose Patch of Grass was evicted by the hostess`s landlord. The hostess has since moved, and I have no contact with her.

Login.

Yesterday, I created a new breed of Firefly, and released it on Thistle`s land, in place of the regular Fireflies.

The new breed makes no distinction between "HerdMaster" and "regular" bugs, although the code that impliments that distinction is still present and functional.

Instead, all Fireflies in this breed now memorize the location of the nearest Patch of Grass when the script resets, then treat this memorized location like just another Firefly when they process the swarming code. This has consequences:

1. Bad: If the Patch of Grass gets moved, the Fireflies will not notice until the script gets reset again [which is how they currently get "fed": I reset the script].
   
2. Good: Unless they actually cross a sim border, Fireflies can no longer get lost by getting "out of range" of the Patch of Grass: They will always remember where they saw it, and always be drawn to it.
   

Unfortunately, this does make crossing sim borders more of an issue than it used to be:

1. The old breed could pretty much ignore sim border crossings, except that sensors seem to be less reliable across sim borders than within a single sim, making runaway Fireflies more likely with sim-border-crossing Fireflies than with stay-at-home Fireflies. Still, sensors DO work across sim borders, however unreliably, so this was rarely an issue, even with Fireflies that were in constant risk of crossing sim borders.
   
2. The new breed stores the Patch of Grass location as a sim-local vector, which is invalidated by sim border crossings. This would tend to collect wayward Fireflies at the right part of the wrong sim.
   

I clearly need to Do Something to address the negative issues of this new breed. The position of the Patch of Grass needs to be recalculated relative to the new sim. Having given this thought overnight, I have ideas for using the sim-border-crossing detector that they already have for something besides explicitly ignoring the event, as was needed in the earlier breeds.

Toodle-oo! Logout.

I'm having the same problem, which I haven't gone back to address because I've been building my cave. Building is strangely exhausting. But will get back to it soon.

The critters have to be able to both swarm and look for food, but I haven't been able to get the two nicely integrated yet. They swarm until they get hungry then they forget about the swarm and go off to eat. My swarming alorithm is a bit off too. The critters stay close together, but they don't synchronize velocity.

Anyway, I've been able to get away with really simple code so far, but to integrate several possible actions requires a leap in complexity.

Login.

I`m still continuing to work on the new breed of Firefly. It now remembers the location of its favorite Patch of Grass in grid-global coordinates, although it processes everything in sim-local coordinates.

Also, about a week ago, I added another Garden, hosted by Tangletwigs Fairymeadow. The location is noted in my list of gardens, two posts back, updated. This Garden is unusual, in that it has TWO Patches of Grass, and has both old and new breed Fireflies. Thistle`s place in Eau is where I`m doing my primary development, currently.

The grid attack yesterday caused a few hiccups with my Gardens, mostly relating to the no-script and slow-script times allowing the bugs to wander away beyond sensor range of their Patches of Grass. The new breed is being designed to handle this issue. It is something that I`ve pretty much always had a little of, especially when scripts are lagging a little, but it is much more likely to happen when scripts are turned off entirely. Yes, I was working on this before the attack. The attack just made the issue more pronounced.

Toodle-oo! Logout.

New Garden installed today. See Garden # 10 above.

Hi Llauren,have had much pleasures going through your random ramblings from start to the lastest post. Yes it started out as random mumblings steep in staccato, colloqial tone of a lost and confused soul. But once the bearing is set on a LSL based experimental garden, you have finally found your purpose /calling in SL universe,with all the help and encouragements from many friendly residents. I do envy your good fortune.

Being a newbie in SL world and in particular in scripting, I am still trying to absorb and grasp the technical aspects of the discussions particularly the syntax /structure of the language. Hope to pick up speed in time with your beautiful Fireflies.

Welcome back...Merry Christmas and festive greetings. Good to hear from you again after your long hiatus. Hope that you have resolved your RL issues.
I look forward to more of your lucid and eloquent contributions to these Forum pages and in particular scriptings related to Artificial Life. May your beautiful fireflies soar to greater heights.