Now that people are starting to try their hand at Sidekick creation using the Sidekick Tutorial, I feel a need to round them all up for inspection. Inspection isn't all bad, and I see this as more of stamping beef with a grade mark rather than pass/fail. So far, I have a bag of fairly good grades to hand out!
Just by entering in the userscripts.org search bar "Wall Manager Sidekick" you can find a handful of scripts out there that intend to attach to the WM main body. New heads are growing on this beast as we speak. Hail Hydra! Sorry, I couldn't help myself. Anyway, here is a list of some stuff you may see out there:
- Maple Story Adventures
- The Sims Social
- Adventure World
- Football Life
Needless to say, some of these are incomplete, however some are on the right track to being fully supported additions to the WM script family. Yay!
Among the scripts I viewed source for, I did however notice a possibly fatal flaw in their coding. This flaw was not mentioned very well on my part before coding began but I have since started mentioning it to specific script writers. When an accText or ret value is created, you should always have your alias in front of that value definition, like this: EAcoins, FVgold, CVgoods. The problem is this: when you save these options and ANY other installed sidekick uses that exact same return value, there will be a conflict. Two menu items can be linked together, or sidekick B can affect saved settings in sidekick A. This is a problem I am working on and I plan to change the code in the WM main body. However, I DID mention this was a problem on the Sidekick Tutorial (not the userscripts downloadable file), and also mentioned that script writers needed to make sure their game alias was in front of the return value as a prefix.
When this issue is cleared up in the WM main script, no alias prefix will be required in the sidekicks. Furthermore all options for each sidekick will be saved separately from other sidekicks. This will help preserve menu structures, history and saved options from sidekick to sidekick.
As things stand right now, let me give you an example of an error that can and probably will occur. Lets say you install the Sidekick for The Sims Social by Nokraden: his script does not use these alias prefixes, so his options definitions look like this: Simoleans, Help, Gift, Reward, SocialPoints, Goodwill, and Love. Now lets say I accidentally make a menu structure or option in my FrV sidekick that points to Help or redefines Reward having no FrV alias. Both of these options are saved in the same object under the same name and whichever sidekick stores that variable LAST will overwrite previous versions of that same variable. In effect, I can set his TSS options with accidents in my FrV script. This is no good and its why I asked that all returns and definitions include the alias in their name.
In the next week, I hope to clear up the root of this problem in the WM script, and maybe we can avoid having to get these newly birthed sidekicks to change their definitions. However, things happen and I may be delayed. In the meantime, I really suggest all sidekick defs please use an alias, preferably one you supplied in the alias variable in your sidekick.
I've sent out userscripts.org messages to many of the people working on viable sidekicks asking if they are ready for support and sponsorship. Hopefully we can start adding to the family right away. As soon as next week, you may see more admins on this site, including DDM from FVWM or some new friends that will be taking over the prototype for the AW sidekick. Until then, hang tight as we improve WM yet again.