Miles Doge

The way i worded my sentence in the OP, was definitely meant to convey needing a combination of the two things here to cause the condition. While the drift is specific to the projected light itself, it can only happen with the help of llTargetOmega rotating the prim emitting that light. All in all though, i do agree it should be bug reported! I don't particularly recall where/how to go about doing that again (its been a while), but if it adds any helps at all for demonstrating the process, i did try to throw together a quick video demonstrating the "drifting" itself the other night.😅

Apologies for the delayed response. Quickly testing this on a simple rezzed wooden prim reveals that the projected light itself does indeed still "drift" It doesn't seem to be something specific to the reflection at all. (shown with the first two images) I probably forgot to say this in the original post also, but: If i were to unlink one of the spinning projected-light prims from the linkset of this trinket, the point-light that's emitting from that unlinked prim no longer shares this drift issue, but the rest of the spinning point lights do. This can be seen with the last two images; While the red colored point light remains stationary. The outer surrounding point lights are slowly drifting downwards (the central "triangle" point-light should also be seen as unaffected as it does not spin at all).

Thus far, i've only tested this at ground level, but not any higher elevations. I must apologize when i say, I'm not sure what difference elevation would make for the drift to occur or not but its worth a shot in testing!

As weird as the title is, this is the best way i can label my little predicament here....I was hoping someone here may have a solution or idea of what's going on here, but to give some detailed context: The item: A friend of mine recently created an "illusionary" attachment for themselves, which contains a link-set of multiple projected light primitives, and a cylindrical prim. Each point-light prim is set to plainly spin using llTargetOmega(), while their lights are pointed directly at the cylinder primitive. The cylinder primitive has a specular gloss of 255, and an environment of 125 applied to it. Now for those who aren't aware of what exactly this does...When projected-light are pointed towards a primitive with gloss & environment like this, it can actually create some rather cool "reflective/mirror-like" effects, that can make for creating some neato false scenery or seemingly 3D portals; and that is precisely what we're dealing with here! The issue: After completing this little light trinket of theirs, said friend eventually reached out to me with an issue, noting that their point lights had some form of "drift" that would occur after a considerable amount of time has passed (usually about 2 minutes or more, but the "drift" becomes even more noticeable if you wait even longer). Now, initially, my first assumption towards this "drift" issue, was that they might've just been calling llTargetOmega() before having the projector-light prims properly rotated & aligned a full 90 degrees, so that their (obvious client-side) rotation would rotate consistently throughout. Test: To test that this issue wasn't just a matter of improper prim alignment (and to freshly test this overall), I completely recreated their trinket completely from scratch, including rewriting the EXTREMELY SIMPLE llTargetOmega() scripts that were involved with the trinket. I found that when these point light prims *weren't linked* at all, the aforementioned "point-light drift" was not an issue at all, nor did it ever occur as far as i could tell. However if they *WERE* linked, the "drift" would inevitably start to occur overtime. I tried a few different attempts at writing the llTargetOmega call differently with the linked point lights, and found still, that the issue persists. I even tested to see if this problem happens with some of my own projected-light illusion contraptions that utilize a similar layout, and again, i found that all of them in some way or another, had this inevitable "drift" issue; despite the prim itself showing no signs of being "misaligned" whatsoever...I'm at a loss for what's the cause of this, but i can only assume its some strange unavoidable sight effect with spinning linked projected lights with llTargetOmega. Visual: To better show the problem I'm referring to, i've attached a gif to this post. If you pay CLOSE attention to the bottom of the outer ring, you will see that the projected-light slowly (but surely) drifts closer and closer towards the (unlinked) wooden "plane" seen just below the point-light effect. Right clicking the object seems to reset this issue as if nothing occurred, which (again) leads me to believe this is some kind of side-effect caused from calling llTargetOmega on a linked prim utilizing projected-lights. I'm certain there's some other method of constant rotation i could go about to avoid this problem altogether, but i first wanted to see if anyone else had ever encountered this issue before.

Honestly forgot about the oh so fun "Taking damage from scooting across a prim floor too fast" bit with LL damage & It would be an nice addition if we could have some kind of "intangibility" toggle to prevent this sort of thing, just to avoid the need to have a script [ever so slightly] lift the avatar above the ground for fast moving mechanics or sprinting.

As someone with a personal idea in mind to put together a seemingly harmless little drone (containing equally as lethal "combat modes" to fit & adapt to various situations), i VEEERY MUCH like how much this LSL could seamlessly fit into that idea!

Another very good question, and something i was hoping would be prompted to have others here input what they want to see, because depending on the weapon & person, one MAY WANT to continuously stack more chip damage... but at the same time, maybe someone else would like to have the option to not allow this from the receiving end or so forth. Though personally, I'm on board for it functioning the way a friend proposed as an example, below:

This was something that did cross my mind amid writing out the idea, but i wasn't entirely sure how it might be handled functionality side. All in all though, i don't see any reason not to allow healing bullets to function the same for being able to gradually drop their heal effectiveness! Heck It could even be kinda funny to encounter a gun who's bullet could damage you one moment at a certain distance, and then suddenly adjust its numbers into a defined (negative) max_falloff, to heal someone the next.

I was told to drop my face into this thread to share an stretch of an idea i had swirling in my mind, which would allow for creating variation in how bullet behave with their defined damage amounts. I don't really know what it would take to have something like this done, but on paper, it sounds like it could be a great addition to many gun-slingers across the grid, and even bring about some additional suggestions to be added to the overall concept! Before that though, let me start off by saying, the events & functions that have already been discussed thus far are QUITE exciting to read, and i do hope to see them in action!! I also do apologize if this is a suggestion that was already brought to mind previously in some way, as i (admittedly) did kind of excitedly read through the pages at the discovery of this thread. But without further ado, the idea in question: Using llSetDamage() just as a basis of reference for the concept being presented here...what if we could define a list of BULLET_PARAMETERS that adjusts how a users bullets adjust its damage? Some very basic examples i can think of for this would be: llSetDamage(float damage, list params); BULLET_DEFAULT //keep it at default! no fancy effects needed for the bullet. BULLET_FALLOFF, float falloff_distance, float falloff_amount_per_meter(??) float max_fall_off "float falloff_distance" would refer to how far the bullet needs to travel from its initial on_rez before beginning to take away from "float damage", using the defined "float falloff_amount". "float max_falloff" is the threshold the bullet is allowed to adjust its damage down to. BULLET_CHIP_DAMAGE, float chip_amount, float chip_per_second(???), float chip_linger_time(???) "float chip_per_second lets u define how quickly to chip health off the affected target using the "float chip_amount". "float linger_time" would refer to how long the chip damage takes from your health before stopping. As an additional fun note to BULLET_CHIP_DAMAGE, bullets that "heal" a target could also be used to immediately "extinguish" the lingering chip damage effect. (A SLIGHT edit here for the sake of consistency with the presented example: "float chip_amount" would probably just use "float damage" instead if it were actually implemented under llSetDamage. I defined float chip_amount as its own separate thing, because i wrote this idea out under the assumption that the parameter would be under an entirely separate lsl function from that of llSetDamage) These are just a few basic ideas i thought of off hand, but I'd love to see what further input it brings about!

Will do. Thanks for the tip!

A friend of mine recently noticed from the Secondlife Release Notes "Disable Selected" and "Disable All" buttons in Top Scripts were recently removed as a feature from the region estate tools, and neither of us are sure as to why this may have been done... It proved to be a useful feature for said friend, for not only preventing against certain grief items, but also stopping certain terribly made scripts that are unnecessary to be running.. Any ideas for this removal at all?