Combat 2.0

I think there is a trick missing here to be able to limit Combat2 to Experiences. This would take in the form of a region setting, similar to "allow_damage_adjust" and "restrict_combat_log", but instead of allow/deny having a third option of being able to restrict to scripts with an allowed land-scoped experience. Combat 2.0 is quite exciting but people might be put into a tough place to either restrict scripts or allow them without distinction. Experiences provide an excellent in-between where the trust can be managed by the experience owner or game developers managing damage adjustment themselves for players in their game. Like myself where I am wanting to adjust damage for a dedicated combat game region of my players, compared to the SLMC where you would find two groups pitted against eachother. I might not always be around for moderation of the combat logs or have to be forced to monitor to constantly to prevent other third-party non-game scripts from adjusting damage unfairly. I think the integer boolean environment variables "allow_damage_adjust" and "restrict_combat_log" can be extended into integer constants so that for example "2" would be meant that for restriction to allowed/key experiences. Alternatively adding separate variables such as "experience_damage_adjust" and "experience_combat_log" if not extending the current ones.

At the moment, llDamage is throttled to 10 instances of damage over 30 seconds when directed at the same target. Some weapon effects linger and repeatedly cause relatively small amounts of damage to avatars until they take some action like moving away from the damage source. Here are some cases where non-environmental (e.g. not from a land owner) damage over time may hit the throttle if it uses llDamage : Fire (direct contact or being ignited) Poison (from being hit by a dart) Toxic gas clouds Acid or electrified puddles There should be multiple ways to end it. The damage should be able to be modified or stopped by: The script that started it (the target moved away from the fire) A script worn by the recipient (the target is wearing a fireproof suit, or stops to put out the flame) Other scripts (a fire extinguisher puts out the flame) By dying Being able to stop damage over time implies that there would a way to detect it, apart from the individual instances of damage. Should the damage be continuous (like negative health regeneration), or should it occur on a script-defined interval (e.g. every 1-5 seconds)? The llDamage throttle can be avoided by rezzing multiple damage sender objects, or sending higher damage at longer intervals > 3 seconds. The latter workaround may limit creativity for weapons that split their damage between two or more damage types.

Under the current Combat2 testing version, COMBAT_CHANNEL can get very spammy, especially when there are multiple sources of damage over time present in a busy combat sim. An excess of messages can cause scripts to drop events off the end of the queue. Most residents/scripts will most likely be interested in only a few events: Damage my objects (or my specific object) caused that were modified by the recipient Damage my objects caused that resulted in a death What damage source resulted in my death Therefore I propose a dedicated "combat_log" event that functions similar to listen using whitelist filters. The three types of events I have observed are "MODIFY", "DEATH", and "DAMAGE", typically occurring in that order as applicable, but there seems to be at least one more event, where scripts can send a message on COMBAT_CHANNEL to be added to the log (we could still listen on COMBAT_CHANNEL to pick up that). The fields the first three have in common are "event", "owner", "rezzer", "source", "target", and "type". The event signature could look something like one of these: combat_log ( integer handle, string data_json ); combat_log ( string event, key owner, key rezzer, key source, key target, integer type, list params ); Params could vary with the event type, but for any and all of the other fields, there should be a way to set filters to avoid firing the event too often and slowing/blocking other events. The option to enable multiple filters would be ideal with a signature looking something like this, where the function returns an integer containing the filter's handle (like llListen): integer llCombatLogListen ( list rules ); llCombatLogListenRemove ( integer handle ); Some examples of rules that could be used to filter for desired events (from the top of this post): [ COMBATLOG_EVENT, "MODIFY", COMBATLOG_OWNER, llGetOwner() ] - damage my objects caused that was modified [ COMBATLOG_EVENT, "MODIFY", COMBATLOG_SOURCE, llGetKey() ] - damage this object caused that was modified [ COMBATLOG_EVENT, "DEATH", COMBATLOG_OWNER, llGetOwner() ] - my objects resulted in a death [ COMBATLOG_EVENT, "DEATH", COMBATLOG_TARGET, llGetOwner() ] - someone's damage resulted in my death [ COMBATLOG_EVENT, "MODIFY" ] - for region/estate owners to monitor for undesired damage adjustments, i.e. cheating [ ] - accept all Unlike listen, an empty string or NULL_KEY should not be treated as a wildcard, since parameters can be omitted.

It would be helpful to replicate the behavior of llCollisionFilter as a parameter to llRezObjectWithParams so that objects can take advantage of that collision filter behavior without requiring a script. A typical use case here is dual guns. Both rez the same bullet object with the same name, and these bullets all occupy the same space in front of the user when fired, typically with some randomized rotation added (a.k.a. spread), so collisions between bullets fired by separate guns can happen. However, these guns are two different objects, so the flag REZ_FLAG_NO_COLLIDE_FAMILY doesn't help. This is not an issue for old-style scripted bullets, which can use llCollisionFilter("bullet", NULL_KEY, FALSE) to avoid colliding with bullets from the other gun. However, having to use scripted bullets to regain this capability defeats the purpose that llRezObjectWithParams was designed for. All types of collision modifications would operate independently from each other. That is, setting REZ_FLAGS, REZ_FLAG_NO_COLLIDE_OWNER | REZ_FLAG_NO_COLLIDE_FAMILY, REZ_COLLISION_FILTER, "bullet", NULL_KEY, FALSE would result is preventing collision with the owner, any other object rezzed by that object, and also any object named "bullet". I thought it would be most flexible to replicate all the parameters to llCollisionFilter, although filtering by a specified UUID isn't particularly useful for the specific use case I described. Simplified example use: list rez_params = [REZ_FLAGS, REZ_FLAG_NO_COLLIDE_OWNER | REZ_FLAG_NO_COLLIDE_FAMILY, REZ_COLLISION_FILTER, "bullet", NULL_KEY, FALSE]; llRezObjectWithParams("bullet", rez_params);