


|
Comparison of LE vs XL
Major Differences
The ACP LE is a total re-write of the system, with a few bits of code taken from the old ACP XL. Many lessons were learned from writing XL and in the time since it was first released, so a decision was made to write a brand new system that would take advantage of all these fresh new ideas. The result was the ACP LE, and what follows are the major differences between it and the ACP XL.
- There is now an explicit difference between anti-illusion mode and open (or basic) mode. This is useful for when you're sparring a serpent and want full anti-illusion versus when you're sparring a knight and have no need of all the extra checks. Sets of class folders for each subsystem are toggled when switching modes, so you only ever have one of these two sets of scripts active at a time. That is, each subsystem has a basic version with no extra illusion checks for faster execution speeds and an anti-illusion version with many extra failsafes built in (and a small risk of missing a few afflictions or defenses here and there due to the strictness of the failsafes, though our best efforts have been made to keep that from happening).
- Many triggers are broken down into their respective skill folders and there are aliases and buttons to toggle class types of your opponents. This is another anti-illusion method to keep serpents from hitting you with Aeon illusions and such, but is also just a general speed thing to turn off many of the triggers when you're not fighting that class (or anyone at all).
- There are actually fewer aliases now because of the use of command input triggers wherever possible. The command input triggers are used to capture (but not exactly override) your game commands for things such as waking, standing, and other basic things. This allows the ACP to efficiently track your actions without you needing to call special aliases as hooks any more.
- Pipe tracking is a little more intelligent and tries to go by the number of puffs left in each pipe. When you smoke the last one, it refills it ahead of your next smoke. It doesn't try to fill all your pipes when you turn on the pipe smoking, so long as they have puffs remaining. There are failsafes (and pipelist, of course) to try and catch faults in the tracking and keep things synchronized.
- The 'todo' functionality is a little more sophisticated, with the addition of a few aliases that allow you to add only one command to the list of things to do and avoid duplicates (
acp_todo1 ), and queue up actions that require/take no balances at all to be executed all at once when you are able to act again (great for picking up stuff when someone drops things).
- All triggers are now regular expressions. This makes them load faster and execute more efficiently. Duplicate patterns are eliminated and similar patterns have been combined to cut down the total number of triggers by using more precise matches.
- Most settings options have been combined into a single data record variable called
Settings and the keys have default values defined, so you can look at your settings (acp_settings or the editor) and change the values associated with each key to tweak the performance of the ACP.
- There are aliases to print pretty messages on various events, such as defenses going up/down, afflictions received/cured, and balances lost/gained. These messages are toggleable using the custom settings options, so if they create more problems than they solve, you're able to easily turn them off.
- Curing has been broken down into the various balances, rather than handled all inside one giant alias. For example, you can now execute the herb curing without the extra overhead of also executing all the code for other healing methods. When you regain herb balance, only the herb curing is checked for possible cures. There is still a single healing alias that executes when afflictions are received, but it has been greatly simplified and made into a more modular piece of code.
- Methods of curing afflictions have been optimized to iterate over the list of afflictions rather than the list of all possible afflictions that can be healed. What this means is if you have stupidity and recklessness, the herb curing alias will not check for all other possible afflictions. It will only check to see if stupidity and/or reckless should be cured using herbs. This means you get only a few iterations in the loop to check for afflictions to be healed and fewer expressions are evaluated. (Yes, this method should even surpass the simple if-else method of checking for all afflictions, and is also much more flexible in terms of priorities and what methods are used to cure specific afflictions.)
- Customizing which afflictions are cured by certain specific queues is very easy now. You can simply delete the affliction name from the appropriate list and it will no longer be cured. The knowledge of how to cure that affliction via this method is not erased, however, so you can easily just add the affliction back to that list and it will be cured once again. For example, if you don't want to use goldenseal to cure stupidity, you can remove stupidity from
HerbAfflictions because the HerbCures variable is the one that knows stupidity should be cured by goldenseal. Only the afflictions listed in HerbAfflictions will be cured using herbs, and they will be cured using the mapping laid out in the HerbCures variable.
- Prioritizing the order in which afflictions are cured is also much easier than in the XL module. The order in which affliction names appear in the various "affliction" list variables is the order in which they are prioritized. For example, if you have the variable
HerbAfflictions configured such that paralysis is first and recklessness is second, you will cure paralysis before recklessness when you have both at the same time and the herb queue is executed.
- All curing and defense stuff is executed on the prompt now, to take care of things such as multiple affliction attacks and anti-illusion failsafes. Not all code is executed on every prompt, however, to keep the system from getting extremely bogged down. The
heal or def flag needs to be set to execute the main queues, and they are toggled on key events such as a new affliction or a cured affliction.
- The toolbars have been completely redesigned to eliminate synchronization bugs and stray variables. They are now flat, single state, buttons and the color is changed via the aliases that turn systems on and off. This ensures that if you use the alias from the command line, the button will be appropriately updated. The fact that the buttons are no longer controlled through variables means that importing scripts, especially newer versions of the ACP, no longer messes with the button states or causes them to get out of sync. Also, there are buttons to toggle all systems or classes with a single click, for convenience.
- Installation and upgrade of the scripts themselves is cleaner. The script first removes the ACP folders, so you don't accidentally update and get duplicates of everything. This means that any changes you make to the core system will be lost (which was always the case anyway), so you should have a way to backup and redo any changes you make, taking into account bug fixes and upgrades (i.e., don't overwrite aliases and things that have been changed from an upgrade).
|
---|