Post Sat Mar 27, 2010 12:57 pm

Set step and Virtual keys

My goal:

I am attempting to create a setup in LOTRO where I can adjust character roles and set certain character specific actions for my team dynamically while playing. I have created a set of icons to use on "Click Bar" buttons to indicate which state a given character is in and by right clicking on the click bar button, the state will toggle (currently between 3 states). There are a total of 6 separate single button click bars, one for each character (the reason for using separate click bars as opposed to a single 6 button bar is related to positioning of the button over the on screen profile for the character in game). I am then wanting to synchronize this icon state for the click bar(s) across all 6 of my characters in the character set such that each will see the indication for the state of a given character. In LOTRO this can be a bit of a challenge since you cannot refer to characters by name only by generic function keys and which are tied to the order that fellowship members show on screen and tied to the order in which they were invited to the fellowship. While it is consistent assuming a fixed invite order, it is not immediately obvious what the pattern would finally be. So, while player A will see player B as the second player profile on screen, player C will see player B as the 3rd profile on screen. So, if I change the state of a click bar button (icon changes to reflect state) positioned over my second player profile on player A, this will need to change the click bar over player profile 3 on player C and player profile 1 on player B. This gets much more complex as more characters are added to the fellowship.

Once I have this click bar mechanic in place (I currently have a working prototype, missing only the needed functionality discussed in the "My challenge" section), I will be able to control which member(s) of the team participate in DPS and which in healing as well as which member of the team a healer should focus on. I also will be able to split the team and control who follows / assists whom. One of the classes that I am currently playing has the ability to DPS or heal, but not both at the same time. To transition between healing and fighting requires some effort and specific skill use. If I have a single dedicated healer and that character goes down, I want to be able to move another character into healing mode on the fly.

Using the same click bar mechanic, I will also be able to implement a "click to heal" interface using a single click to do what currently requires selecting a given character in need of healing and then cast the heals and finally returning to previous target and continuing normal operation.

My challenge:

Using virtual keys to make the configuration flexible and scalable to multiple characters participating in multiple character sets requires the use of 2 tiered virtualization, where a character virtualizes a generic mapped key (or keys) and then the character set virtualizes the character specific mapped key to a character / character set specific mapped key. In this latter mapped key is the knowledge of the order of the fellowship from the perspective of this character. With this setup, it is known which function key will select which fellowship member.

Since a fellowship can have 6 characters and each character must know the mapping for the function keys to the specific character there are a total of 36 mapped keys needed at each tier of virtualization for a total of 72 for a single 6 toon character set. This is for a single team and grows with each new character set configuration and as more characters are added to the mix.

In order to minimize this configuration, I came up with a single 6 step mapped key that is virtualized by each character and then by the character set for each character for a total of 12 (as compared to 72 in the previous example). The key to making this 6 step mapped key work is the ability to be able to use the "set step" action to specifically set the step of a key so that it will execute that step on the next activation. In order to keep the configuration flexible, this "set step" needs to be performed on the generic mapped key which has been virtualized by the character and then further by the character set.

So, consider the following example:

Mapped key A is generic and virtualized to mapped key B at the character level
Mapped key B is virtualized to mapped key C at the character set level
My generic setup does not know (or ideally need to know) about the virtualization and needs to be able to set the step for A and have that ultimately set the step for C

Conclusion:

The beauty of being able to use this method is in being able to reduce the total number of mapped keys in general where many of them are not actually used, but need to be created as place holders. Also, in creating / adding new characters the number of virtual keys that need to be created is reduced thus keeping the character as well as the character set configuration much simpler and much less tedious. By reducing the steps needed to add new character sets, the chances for making errors is further reduced and if / when there is a need to re-factor the configuration, then there is hopefully much less that will need to be changed.

Additionally, the use of "set step" allows for the passing of knowledge to other mapped keys. There are times when you are able to "know" certain things at a specific point. But, since there is no mechanism for setting / passing variables the use of this knowledge by subsequent mapped keys is not easy to implement. However, through the use of multi step mapped keys and the "set step" functionality you can effectively pass information to subsequent mapped keys. This general feature is of course available at present, but not for virtualized keys unless you set the step of the final target which some what defeats the purpose of virtual keys.

*NOTE: The most current version of ISBoxer now has the ability to use "set step" on virtualized keys. Thanks Lax!

Cheers,

creo