Jump to content

Rider Linden

Lindens
  • Posts

    221
  • Joined

Everything posted by Rider Linden

  1. A Combat2 Update! There is a new version of the Combat2 simulator. By my calculations, this is somewhere around the 1/2 way point. There is certainly enough there for people to start playing with it and building interesting things! Functions: llAdjustDamage llDamage llDetectedDamage llDetectedRezzer llGetHealth Events: on_damage on_death Function documentation is already in the wiki and I'll be updating this page (https://wiki.secondlife.com/wiki/Category:LSL_Combat2) early next week with suggestions on how these pieces can be put together. Consider that page the "central clearing house" for combat status. There are two regions on the beta grid open and available for testing: Thermopylae: secondlife://Aditi/secondlife/Thermopylae/235/124/27 Gallipoli: secondlife://Aditi/secondlife/Gallipoli/18/142/27 I'll be looking for feedback at next Thursday's Rooty Tooty Shooty Committee meeting.
  2. The fix should go out with next week's RCs. We had rolled that simulator back just before the holidays so that everyone could enjoy SL without additional "bonks". We put the version without the fix back onto the Magnum channels last week so that we could spot any other issues that we might have missed.
  3. That function is part of the Fall Colors simulator release. We are planning on rolling that to all RC channels this Wednesday. (Dec 13th)
  4. Interesting, I think I'd want to handle something like this through llSetPrimParams and llRezParams, but I like the concept. The projectile would need to be able to track how far it had traveled from its rez point... but I believe it is doable. I think a healing limit could be added as well. I'd do it as a region/parcel parameter.
  5. I have created a new topic in the forum for discussing the damage system proposal.
  6. A few ground rules before diving in. First: I'm presenting this as a draft strawman design. The design I'm suggesting is not set in stone, no code has been written yet, and the design may change significantly as people give me feedback. Second: This proposal deals only with a new damage system for Second Life. That is the only elephant that I'm putting on my plate for this discussion. There are numerous other things that have been put on the roadmap for development, such as being able to adjust avatar hitboxes, additional options for sitting, and several others. Let's address those in other threads. Third: This proposal is not meant to be a complete combat system on its own. I am convinced that you guys can build a better combat system than I can, and so, my goal is to provide the tools that allow you to do that. (In other words the final product will have a big label that reads: "Batteries not included, some assembly required") And with all that out of the way. --------------------------- In Second Life there are a host of combat communities scattered across the grid. These communities use a wide variety of combat systems, HUDs and weapon systems. Some are completely custom, relying on scripts to arbitrate health and damage, while others are based on the Linden Lab Combat System(LLCS). The goal of the Linden Damage & Combat2 project is to provide a coherent set of tools and systems that allow the residents to create complex and compelling combat systems using a common and easy to use framework. Linden Damage 1.0, LLCS (Will Remain Unchanged, but give a short TL;DR for it here) Second Life wiki combat documentation: Combat Combat/Systems Weapons in Second Life Linden Damage & Combat 2.0 (LLD&C2) For backwards compatibility, LLD&C2 will not be enabled on regions by default. It must be enabled by the region owner. New Concepts in LLD&C2 LLD&C2 introduces a couple of new concepts. Damage Types, Damage Limits, Regeneration Speed, Death Consequences, “Remote”(non-collision) Damage, and Damage Events. Damage Limits A damage Limits is the maximum amount of damage that may be delivered by any single hit on an avatar or prim. If the total damage delivered in a single hit exceeds this value, the actual damage delivered will be reduced to this amount. If the Damage Limit is set to 0 then damage is disabled. Damage Events Rather than a hit directly applying damage to an object or avatar in world, if a damage event (see on_damage() below.) is present in any script attached to an agent, this event will be called instead. The event may modify the actual amount of damage being applied before it is applied to the avatar. Damage Types Damage Types are information passed along with a successful hit on an avatar or object. The intent is to allow combat systems to assign categories to the damage applied. In order to facilitate interoperability between combat systems Linden Lab provides a list of suggested combat types. Death Consequences LLD&C2 provides more options when an agent’s health drops to 0. The region owner may select from a number of options. 1 Teleport Home send the avatar to their home location. This is the same behavior as the old LLCS. 2 Teleport to Telehub. When an agent’s health falls to 0, they are immediately sent to the region’s Telehub. 3 Teleport to Land Point. Similar to being sent to a Telehub, the agent may be sent to the parcel’s landing point. 4 No action. The region will not attempt to reposition an agent reduced to 0 health. The region owner may also set a brief period of invulnerability for avatars that are reduced to 0 health. During this time the agent may neither deal nor receive damage. In any event, upon death the agent’s health is returned to 100%. Griefer Protection To protect against hostile land owners, if an agent is kill more than 5 times 30 seconds they will be offered the option of teleporting home, overriding any region settings. Regeneration Speed The region or parcel owner may specify the rate at which health is regenerated. The default is 1% per second. Setting this value to 0 will disable regeneration. Remote Damage Damage may be applied directly to an object or avatar without a collision with a damage enabled object (see llDamage() below.) Damage inflicted this way will only be applied if the target has a script with an on_damage() event in it. LLD&C2 Features Combat Event Log Regions maintain a Combat Event Log that records all damaging events, damage adjustments and kills. [details TBD] Region & Parcel Additions In damage enable regions & parcels a number of new options are available. The region owner may set the Damage Limit for the land and the overall Regeneration Speed on the region. They may also specify the action the simulator is to take when an agent reaches 0 health (see Death Consequences.) The region may also toggle whether damage adjustments are allowed (see the llAdjustDamage function.) The Damage Limit and Regeneration Speed may both be overridden on a parcel level. Additionally, an agent’s current health is maintained during region crossings. Script and Event Additions and Changes New Events on_damage on_damage(integer count) The on_damage event is fired in a script when an object receives damage from an outside source. Either damage delivered through a collision or through a call to llDamage() from a script. This event intercepts any damage about to be applied giving the script a chance to modify it. Once all scripts in a linkset have finished processing their on_damage events the damage is either applied to the attached avatar or distributed through the vehicle to all seated avatars. There may be up to 1632 damage events. The following functions from the llDetected* family are available in the on_damage event. llDetectedGroup - TRUE if the damage was delivered by an object in the same group. llDetectedKey - The key for the root object delivering the damage. This object may have derezzed, especially in the case that the damage was delivered through a projectile. llDetectedLinkNumber - If the damage was delivered through a collision this is the link number that collided. llDetectedName - The name of the object delivering the damage. llDetectedOwner - The owner of the object delivering the damage. llDetectedPos - The last coordinates of the object delivering the damage. (In the case of a projectile the object will have derezzed.) llDetectedRot - The last rotation of the object delivering the damage. (In the case of a projectile the object will have derezzed.) llDetectedType - The type of the object delivering the damage. llDetectedVel - The last velocity for the object delivering the damage. (In the case of a projectile the object may have already derezzed.) llDetectedDamage - see new functions. on_death on_death() on_death() is triggered when an agent’s health reaches 0. This can be used to trigger custom actions on death, such as a death animation or in conjunction with an experience to teleport the agent to a custom team respawn point. This event is only triggered from an attachment. New Functions llDamage llDamage(key target, float damage, integer type) llDamage sends a damage event to the indicated object or avatar, triggering the on_damage() event. Target is the avatar or agent to damage, damage is the amount of damage being done and type is the type of damage that is to be applied. As with collision damage, negative values are treated as healing. llApplyDamage llApplyDamage(float damage, integer type) If called from a vehicle or other prim with sitting avatars, this function transfers the damage to all seated avatars. If called from an attachment it will immediately apply the damage to the avatar bypassing any further on_damage events. llGetHealth float llGetHealth() Returns the current health of the agent. This must be called from an attachment. llDetectedDamage list llDetectedDamage(integer number) llDetectedDamage is only available inside an on_damage event. This function returns a list with the following information describing the damage. [float damage, integer type, key deliverer, key owner, key rezzer, float original, integer modified] damage - The amount of damage delivered in the event. type - The type of damage delivered in the event. deliverer - The key for the object delivering the damage. This value is the same as the key returned by llDetectedKey() owner - The owner of the object delivering the damage. This value is the same as the key returned by llDetectedOwner() rezzer - The key for the object that rezzed the object delivering damage. If the object was rezzed by an agent this value is NULL_KEY. (should we add a llDetectedRezzer() function? It might be useful in general collisions) original - The original amount of damage that was delivered. modified - This will be TRUE if the damage amount was modified by llAdjustDamageAmount. llAdjustDamageAmount llAdjustDamageAmount(integer number, float new_value) The llAdjustDamageAmount function is only available inside the on_damage event. This function allows the script to alter the amount of damage that will be applied. Any scripts that process their on_damage events after this script will get the new value. If the region has disallowed damage adjustments this function has no effect. Additions llGetEnv Several new values values are added to llGetEnv. "damage_limit" - The region wide damage limit. "regen_rate" - The speed of regeneration on the region "on_death" - The consequences of reaching 0 health. llRezObjectWithParams A new constant for setting damage type on a projectile. REZ_DAMAGE_TYPE - The type of damage delivered on a collision.
  7. I believe the default sound for falling leaves is "Aaaaawwwwwwwwwwwwww...SPLAT" 😉
  8. There was a change that I introduced in 2023-11-20.6935786551 to support llRezObjectWithParams. That change moved collision damage and collision sounds out of script properties and made them object properties. It appears that I missed an edge case. It should work correctly when rezzing an object or moving from the current release simulator(2023-11-07.6790647783) to the Fall Colors simulator (2023-11-20.6935786551). It looks like I may have missed going in the other direction. The problem should disappear as Fall Colors spreads across the grid over the next two weeks.
  9. The build number does increase with each build. It does not do so in a predictable manner... or at least in a manner that wouldn't drive someone insane attempting to figure out. My advice is to read nothing into it beyond "Higher number, later build". We are in the process of migrating our build system to Github and in the process there was a change in the numbering scheme. There was some confusion when these larger numbers first showed up on the simulator a month or two back.
  10. Unfortunately not directly at this time. I considered adding a way to set the collision sprite, but decided against it since they have been broken on the viewer for quite some time. (See VWR-322) I would like to see that fixed at some point. In the meantime it requires a script on the object that handles the collision event.
  11. That might be better tackled as part of @Leviathan Linden's game controller project. I know that he's looking at a number of changes to the way controls are handled.
  12. Actually that did get lost... even when I quoted it. REZ_POS does not take the rezzer's rotation into account. However REZ_ROT does. To orient a rezzed object relative to the rezzing object use: REZ_ROT, ZERO_ROTATION, TRUE
  13. I have turned damage on on Leafeon (just south of Jigglypuff) Whatever you do, don't stand on the glowing red ❌ and touch the red or green boxes...
  14. Fall Colors is now live on the beta grid. Server version is 2023-10-13.6514087432 (I may update again later today.) Jigglypuff, Leafeon, Mauve, and Cloud Sandbox 1 & 2 are all on the new version.
  15. The wiki page is online. I'll try and get some regions on Aditi up tomorrow so people can try it out. https://wiki.secondlife.com/wiki/LlRezObjectWithParams
  16. Some quick edits. I've removed inherit and impulse from REZ_ACCEL. It doesn't make much sense to inherit your parent's acceleration... impulse is redundant with REZ_VEL. I've also removed REZ_FLAG_DIE_ON_COLIDE since objects that deliver damage already die after their first collision.
  17. The llRez commands will continue to be async. The ID returned will just be the eventual ID for the object rezzed. A script can not be reasonably assured that the object exists in the world until it receives an object_rez() event. No. We can not change the signature on an existing function to return a value. The key passed into an object_rez_fail event will be NULL_KEY if llRezObject or llRezAtRoot fails.
  18. I would like to add that change and I think I can sneak it in.
  19. I agree. It is a major pain, and when I have to do something like update scripts in my objects as a version update I usually spend a couple hours muttering curses under my breath while I do it.... HOWEVER There needs to be some way of assuring the providence of an object rezzed by a script and the easiest way to do that is by requiring that it be object to be rezzed is in the inventory of the rezzer. (I just finished a pulp spy 🕵️‍♂️ novel where the bad guys were international art thieves... so I've added the term "providence" to my vocabulary 😀)
  20. This function would allow that on the caller's side, BUT you run into an issue with the on_rez event. It can only accept an integer and we can not change that. Let me kick the idea of how we could do something like that around in my head for a bit.
  21. A quick follow up. I'm posting this separately because I want to make sure that this point is not missed. This will necessitate a subtle change in the way damage is handled. Currently damage is a property of a script, this change means that damage will be changed to a property of the object.
  22. Well. As the warning said, I've taken a moment, considered it and I'm going to bump this thread, darn it! As I teased today in SLUG I'm looking at the llRezObject function. Here is a sketch of the function and event that I'm proposing: key llRezObjectWithParams(string inventory, list params) Rez an object from inventory and apply the listed parameters immediately. (See below for the initial set of parameters.) llRezObjectParams will return a key, this key will be the UUID of the root prim rezzed by this function in the event of a successful rez. If the rez is unsuccessful the key is passed to object_rez_failure in the id parameter. And the new event: object_rez_failure(key id, integer parameter, integer reason_code) In the event that llRezObjectParams fails to rez the object in world this event will fire with the key being identical to the key returned by llRezObjectParams and the parameter value equal to the value specified by REZ_PARAM parameter. If triggered by llRezObject or llRezAtRoot id will the NULLGUID and parameter will be the value passed as param to the original call. The initial set of parameters that I intend to implement are: Parameter Name Values Description LSL Function REZ_PARAM integer param On a successful rez, this value is passed to the on_rez() event in the new object. llRezObject llRezAtRoot REZ_FLAGS integer flags Flags applied to the object. See table below REZ_POS vector pos, integer rel The absolute position in world to rez the new object. This must be within 10m of the object attempting to rez. If the second parameter is TRUE the position vector is relative to the object doing the rezzing. If the rezzer is an attachment then the velocity is relative to the avatar. llSetPos REZ_ROT quaternion rot, integer rel The initial rotation of the object when rezzed. If the second parameter is true, the rotation is relative to the object doing the rezzing. If the rezzer is an attachment then the velocity is relative to the avatar. llSetRot REZ_VEL vector vel, integer loc, integer inherit The absolute velocity of the object after it is rezzed in world. If the second parameter is TRUE the velocity is relative, if it is FALSE it is global. If the third parameter is TRUE the object inherits the rezzer’s velocity. llSetVelocity REZ_ACCEL vector accel, integer loc The Force(Acceleration) applied to the object. If the second parameter is TRUE the force vector is relative to the object being rezzed, if it is FALSE the vector is global. llSetForce REZ_OMEGA vector axis, integer loc, float spin, float gain Initial angular velocity of this object. If the second parameter is TRUE then the angular velocity uses the prims local axes. FALSE uses the world axes. REZ_DAMAGE float dmg Damage applied to an avatar on collision with this object. llSetDamage REZ_SOUND string sound, float volume, integer loop The name of a sound in the rezzer’s inventory or a UUID identifying a sound. The second parameter is the volume to play the sound at. If the third parameter is TRUE the sound will loop. llPlaySound llLoopSound REZ_SOUND_COLLIDE string sound, float volume Sound to play on object collision. The second parameter is the volume to play the sound. llCollisionSound Flags that may be passed for the REZ_FLAGS parameter. Name Description REZ_FLAG_TEMP Object is temporary (TEMP_ON_REZ). REZ_FLAG_PHYSICAL Object is Physical. REZ_FLAG_PHANTOM Object is Phantom. REZ_FLAG_DIE_ON_NOENTRY Object will llDie if it can not enter a parcel REZ_FLAG_NO_COLLIDE_OWNER Object will not collide with its owner. REZ_FLAG_NO_COLLIDE_FAMILY Object will not collide with other prims rezzed by the same parent. This is an initial set of parameters and flags. In the future we will be able to expand it as need arises. But on this pass I want to make sure I get the infrastructure to support this function into the simulator first.
×
×
  • Create New...