Difference between revisions of "User:Faust Vollmar"

From Second Life Wiki
Jump to: navigation, search
m (Don't mind me, fussing about my UserPage again.)
Line 10: Line 10:
 
The project sections sound like advertising; I didn't mean it that way but that's kinda how my attempts to jot down what I do turned out.
 
The project sections sound like advertising; I didn't mean it that way but that's kinda how my attempts to jot down what I do turned out.
  
===Nexus CS===
+
===[ Nexus CS ]===
 
* This is my pet project, an SLRPG framework, it taught me LSL as I've gone along since '08, <strike>and will teach me C# when we can use it in SL.</strike>
 
* This is my pet project, an SLRPG framework, it taught me LSL as I've gone along since '08, <strike>and will teach me C# when we can use it in SL.</strike>
*: The design intent was to be non-profit and only split webserver costs between World Owners, without commercializing any part of the system.
+
* Intended to be a non-profit system that only collects funds to pay its operating costs. (Such as splitting webserver costs between World Owners.)
*:: This has the disadvantage that it would not gain funds to commission needed content such as Animations, Sounds or Particle Effects.
+
*: Other Funding (for Animations, Sounds, Particle Effects, etc.) would likely be on a Donation basis.
 
+
====Design Basis====
====Features====
+
* A configurable Race/Class/Powers-based system in the vein of DCS2 and Osiris.
* A configurable Race/Class/Powers-based system in the vein of DCS2 and Osiris
+
 
* Worlds are independent from one another. Any number of Sims can be a part of the same World.
 
* Worlds are independent from one another. Any number of Sims can be a part of the same World.
* One Avatar can have up to 12 separate Characters per World, instead of only one. (An Experience Share mechanic would be a World Owner option.)
+
* An Avatar can have up to 12 separate Characters per World, instead of only one.
* There are no Character Levels, the stats you start with are the stats you always have, other than temp Buffs via Powers.
+
* Attempt to mitigate the gap between New and Old players that sometimes causes OOC drama in Level and/or Powers based systems.
*: I never liked the whole seniority issue that happened with Level-based systems, it was always a source of drama.
+
*: No Experience Levels, Character Stats are static, changed only temporarily by Buff Powers.
*: Experience is still present, only used for acquiring new Powers for the character, if the Sim Owner configures them.
+
*: Experience Points are only used for gaining new Powers, if they are enabled. The World Owner decides how strong Powers progression is.
* Weapons use an OpenAPI to register with the CS itself, allowing it to control fairness while allowing freedom.
+
* Attempt to design Weaponry to meet the needs of Free Use, Cheat Proofing, Versatility and Fairness.
*: Some statistics are creator-defined, (within reason) others are calculated by the system to create a balanced result.
+
*: An open Weapons API for weapons to register their statistics with the CS Unit, which controls attacks internally. [Free Use, Cheat Proofing]
*: All weapons by all creators are equal. There will not be an 'enhancement' model.
+
*:: Some statistics are weapon-defined (within reasonable values), the CS Unit calculates others to create a balanced result. [Versatility, Fairness]
 +
*:: All weapons by all creators are equal. There will not be an 'enhancement' model. [Commercial Fairness]
 
====Current Status====
 
====Current Status====
 
* Currently not available to the public, attributing to the Outstanding Issues below.
 
* Currently not available to the public, attributing to the Outstanding Issues below.
*: I sometimes make exceptions to this. Case-by-case thing.
+
*: I sometimes make exceptions to this. Case-by-case thing. Contact me if interested.
 
====Outstanding Issues====
 
====Outstanding Issues====
 
* The Web Control Panel is currently incomplete. Not enough time to learn enough PHP (or other language) for it.
 
* The Web Control Panel is currently incomplete. Not enough time to learn enough PHP (or other language) for it.
 
*: I have learned enough PHP to set up a basic Inworld-to-Database layer, but that's all.
 
*: I have learned enough PHP to set up a basic Inworld-to-Database layer, but that's all.
* Internal Bullets are too insecure due to only having 21 bits of an integer available for any validation mechanism.
+
* Internal Bullets have no effective validation mechanism, only 21 bits of an integer is available for that use.
*: This is a raw, unfortunate fact of features missing from LSL;
+
*: Current LSL scripting lacks the functions I'd like to have to secure the Bullets;
 
*:# Validate an object without requiring full perms. [http://jira.secondlife.com/browse/SVC-5345 llGetInventoryHash]
 
*:# Validate an object without requiring full perms. [http://jira.secondlife.com/browse/SVC-5345 llGetInventoryHash]
 
*:# Directly pass a string across Rez. [http://jira.secondlife.com/browse/SVC-5716 llGetDataParameter + Others]
 
*:# Directly pass a string across Rez. [http://jira.secondlife.com/browse/SVC-5716 llGetDataParameter + Others]
Line 40: Line 40:
 
* Intended design of allowing two weapons wielded at once would require an unintuitive control scheme.
 
* Intended design of allowing two weapons wielded at once would require an unintuitive control scheme.
 
*: Scripted access to CONTROL_ML_RBUTTON is the ideal solution I keep hoping for. [http://jira.secondlife.com/browse/SVC-2566 Add CONTROL_ML_RBUTTON to llTakeControls]
 
*: Scripted access to CONTROL_ML_RBUTTON is the ideal solution I keep hoping for. [http://jira.secondlife.com/browse/SVC-2566 Add CONTROL_ML_RBUTTON to llTakeControls]
* HMAC Keys are Static. Is this even an issue?
 
*: This is due to the previously mentioned bullets problem. If needed, dynamic generation will be added when that is resolved.
 
 
* Using a fake HMAC with the pads in Base64 form fed to the native utf-8 llSHA1String. (Database Server has a PHP function to match.)
 
* Using a fake HMAC with the pads in Base64 form fed to the native utf-8 llSHA1String. (Database Server has a PHP function to match.)
 
*: I don't know how to concatenate Base64, and if I did I would have to do serious speed testing on Strife's Base64_SHA1 compared to the current method.
 
*: I don't know how to concatenate Base64, and if I did I would have to do serious speed testing on Strife's Base64_SHA1 compared to the current method.
 
*: (Could not find an existing JIRA for a native HMAC function request.)
 
*: (Could not find an existing JIRA for a native HMAC function request.)
====Design Considerations====
+
====Design Feedback====
* Always thinking about new Power Casting Mode/Types. If you have ideas and want the current list, IM me in-world.
+
* Suggestions for new Power casting Modes or Types. If you need the current list, IM me in-world.
*: Someone to bump heads with regarding the Equipment spec and balance formulae would be nice, as well.
+
* So far only the Weapons API is complete. Specifications for other equipment such as Armor (if it should be used at all) have not been defined.
* Direct access to Attacks/Powers Comms Protocol for Sim Owners?
+
* Should World Owners have direct access to the Comms Protocol for Attacks/Powers etc, such as being able to set their HMAC key?
*: Allow Sim Owner to set their World's HMAC Key? (Or some other method.)
+
*: Or should the system stay with the tried-and-true method of closed-source scripts that check if their user/owner is a GM/Owner in the World?
* Capture RP Stuff?
+
* (Big Design Question) Should the system remain purely for managing Combat, or branch out into other aspects of RP such as Capture or Non-Combat Skills?
*: I am not an animator and will not be able to create animations for Powers let alone this, so there is very little to gain from it.
+
====** Comm Protocol Info====
 
+
===OpenSource Weapons Systems===
+
* This was a project born of wanting my own take on Melee weapon scripts that evolved over time into it's current state.
+
* Basically boils down to a project to make two base sets (One for Melee, one for all the Range) that can be used for whatever.
+
* Intended for SLRPG weapons rather than the Weapon HUDs often seen in free-for-all combat.
+
* Theres really not much to say here. It does what it's meant to do and sometimes I add/fix something.
+
====Melee Weapon Scriptset====
+
* Current Version: 2.3.7; updated 28.08.2010
+
* Free on [https://marketplace.secondlife.com/p/NI-Melee-Weapon-Scriptset/1274908 SL Marketplace] or just IM me in-world.
+
====Range Weapon Scriptset====
+
* No Release: A lack of time to work on this sub-project.
+
 
+
===Communication Protocol/Channel Ranges===
+
Listed here for lack of notability for the Protocol Exchange.
+
: Channel numbers prefixed with 'x,' are in the -1,409,xxx,xxx range.
+
====Nexus CS====
+
 
# [ User Input Channel ] : 9
 
# [ User Input Channel ] : 9
 
# [ Dialog Menu Channel ] : 99 (Positive to allow /99Menu to retrieve the Menu.)
 
# [ Dialog Menu Channel ] : 99 (Positive to allow /99Menu to retrieve the Menu.)
Line 80: Line 62:
 
#: ''Header;'' = "NCS"
 
#: ''Header;'' = "NCS"
 
#: ''Payload;'' = Double-Pipe ("||") delimited, with Single-Pipe ("|") delimited sub-sets.
 
#: ''Payload;'' = Double-Pipe ("||") delimited, with Single-Pipe ("|") delimited sub-sets.
====OpenSource Weapons Systems====
+
 
 +
===[ OpenSource Weapons Systems ]===
 +
* This was a project born of wanting my own take on the well-known LCK weapon scripts, but has since evolved over time into it's current state.
 +
* Basically boils down to a project to make two base sets (One for Melee, one for Range) that can be used for SLRPG weapons.
 +
* There's really not much to say here. It does what it's meant to do and sometimes I add/fix something.
 +
====Melee Weapon Scriptset====
 +
* Current Version: 2.3.7; updated 28.08.2010
 +
* Free on the [https://marketplace.secondlife.com/p/NI-Melee-Weapon-Scriptset/1427318 SL Marketplace] or just IM me in-world.
 +
====Range Weapon Scriptset====
 +
* No Release: A lack of time to work on this sub-project.
 +
====** Comm Protocol Info====
 
# [ User Input Channel ] : 4 (Default, configurable to use any Channel > 0)
 
# [ User Input Channel ] : 4 (Default, configurable to use any Channel > 0)
 
# [ Dialog Menu Channel ] : -99 (Default, configurable to use any Channel)
 
# [ Dialog Menu Channel ] : -99 (Default, configurable to use any Channel)
Line 87: Line 79:
 
#: ''Header;'' = "OWS"
 
#: ''Header;'' = "OWS"
 
#: ''Payload;'' = Single-Pipe ("|") delimited.
 
#: ''Payload;'' = Single-Pipe ("|") delimited.
#: NOTE: Versions 2.3.5 and earlier, MWS sub-project comms did not have a Header and used channels -851000000 to -851999999.
+
#: NOTE: Versions 2.3.5 and prior, MWS sub-project comms did not have a Header and used channels -851000000 to -851999999.

Revision as of 14:00, 29 October 2010

About

An LSL [and a minor bit of PHP] scripter with a particular interest in SLRPG frameworks and weaponry.
Not a whole lot else to add really, no history nor achievements to speak of.

View my JIRA Reports

Projects

I should probably create sub-pages for my projects with a bit more comprehensive information and less rambling, but that can come later.

Should I post Source code for the OpenSource projects? I'm not sure of complications the Contribution Agreement could have on managing them.

The project sections sound like advertising; I didn't mean it that way but that's kinda how my attempts to jot down what I do turned out.

[ Nexus CS ]

  • This is my pet project, an SLRPG framework, it taught me LSL as I've gone along since '08, and will teach me C# when we can use it in SL.
  • Intended to be a non-profit system that only collects funds to pay its operating costs. (Such as splitting webserver costs between World Owners.)
    Other Funding (for Animations, Sounds, Particle Effects, etc.) would likely be on a Donation basis.

Design Basis

  • A configurable Race/Class/Powers-based system in the vein of DCS2 and Osiris.
  • Worlds are independent from one another. Any number of Sims can be a part of the same World.
  • An Avatar can have up to 12 separate Characters per World, instead of only one.
  • Attempt to mitigate the gap between New and Old players that sometimes causes OOC drama in Level and/or Powers based systems.
    No Experience Levels, Character Stats are static, changed only temporarily by Buff Powers.
    Experience Points are only used for gaining new Powers, if they are enabled. The World Owner decides how strong Powers progression is.
  • Attempt to design Weaponry to meet the needs of Free Use, Cheat Proofing, Versatility and Fairness.
    An open Weapons API for weapons to register their statistics with the CS Unit, which controls attacks internally. [Free Use, Cheat Proofing]
    Some statistics are weapon-defined (within reasonable values), the CS Unit calculates others to create a balanced result. [Versatility, Fairness]
    All weapons by all creators are equal. There will not be an 'enhancement' model. [Commercial Fairness]

Current Status

  • Currently not available to the public, attributing to the Outstanding Issues below.
    I sometimes make exceptions to this. Case-by-case thing. Contact me if interested.

Outstanding Issues

  • The Web Control Panel is currently incomplete. Not enough time to learn enough PHP (or other language) for it.
    I have learned enough PHP to set up a basic Inworld-to-Database layer, but that's all.
  • Internal Bullets have no effective validation mechanism, only 21 bits of an integer is available for that use.
    Current LSL scripting lacks the functions I'd like to have to secure the Bullets;
    1. Validate an object without requiring full perms. llGetInventoryHash
    2. Directly pass a string across Rez. llGetDataParameter + Others
    Alternatively, Raycasting and the ability to cast a llSay to arbitrary locations (in reasonable distance) would also work.
    • Since there is a beta test of Raycasting in-progress (as of 04 Sept 2010), this is the more likely result.
    • (Could not find an existing JIRA for a llSayAt-type function request.)
  • Intended design of allowing two weapons wielded at once would require an unintuitive control scheme.
    Scripted access to CONTROL_ML_RBUTTON is the ideal solution I keep hoping for. Add CONTROL_ML_RBUTTON to llTakeControls
  • Using a fake HMAC with the pads in Base64 form fed to the native utf-8 llSHA1String. (Database Server has a PHP function to match.)
    I don't know how to concatenate Base64, and if I did I would have to do serious speed testing on Strife's Base64_SHA1 compared to the current method.
    (Could not find an existing JIRA for a native HMAC function request.)

Design Feedback

  • Suggestions for new Power casting Modes or Types. If you need the current list, IM me in-world.
  • So far only the Weapons API is complete. Specifications for other equipment such as Armor (if it should be used at all) have not been defined.
  • Should World Owners have direct access to the Comms Protocol for Attacks/Powers etc, such as being able to set their HMAC key?
    Or should the system stay with the tried-and-true method of closed-source scripts that check if their user/owner is a GM/Owner in the World?
  • (Big Design Question) Should the system remain purely for managing Combat, or branch out into other aspects of RP such as Capture or Non-Combat Skills?

** Comm Protocol Info

  1. [ User Input Channel ] : 9
  2. [ Dialog Menu Channel ] : 99 (Positive to allow /99Menu to retrieve the Menu.)
  3. [ Public Protocol ] : x,000,000 to x,004,999 - Usage will be documented if/when it becomes necessary.
    Channel; Weapon OpenAPI = -1409000000
    Channel; Status Display HUD = -1409000001 - (llAbs((integer)("0x"+llGetSubString((string)OwnerKey, 0, 7))) % 4998)
    Header; = "NCS"
    Payload; = Double-Pipe ("||") delimited, with Single-Pipe ("|") delimited sub-sets.
  4. [ Private Protocol ] : x,005,000 to x,009,999 - Not for Public Use; HMAC-Signed Data for Attacks or other System Comms.
    Channel; AoE Effects = -1409005000
    Channel; Target Effects = -1409005001 - (llAbs((integer)("0x"+llGetSubString((string)TargetKey, 0, 7))) % 4998)
    Header; = "NCS"
    Payload; = Double-Pipe ("||") delimited, with Single-Pipe ("|") delimited sub-sets.

[ OpenSource Weapons Systems ]

  • This was a project born of wanting my own take on the well-known LCK weapon scripts, but has since evolved over time into it's current state.
  • Basically boils down to a project to make two base sets (One for Melee, one for Range) that can be used for SLRPG weapons.
  • There's really not much to say here. It does what it's meant to do and sometimes I add/fix something.

Melee Weapon Scriptset

  • Current Version: 2.3.7; updated 28.08.2010
  • Free on the SL Marketplace or just IM me in-world.

Range Weapon Scriptset

  • No Release: A lack of time to work on this sub-project.

** Comm Protocol Info

  1. [ User Input Channel ] : 4 (Default, configurable to use any Channel > 0)
  2. [ Dialog Menu Channel ] : -99 (Default, configurable to use any Channel)
  3. [ Public Protocol ] : x,010,000 to x,010,999 - Protocol not likely to be used, however messages are documented in the Project's packages.
    Channel; = -1409010000 - (llAbs((integer)("0x"+llGetSubString((string)OwnerKey, 0, 7))) % 999)
    Header; = "OWS"
    Payload; = Single-Pipe ("|") delimited.
    NOTE: Versions 2.3.5 and prior, MWS sub-project comms did not have a Header and used channels -851000000 to -851999999.