1) Adjusted set creation and analysis framework. It now supports using
separate equipment search "intensities" for a single set and for a
full analysis of 200 sets. This should give you the best possible
results for a single set while keeping the time to do a full analysis
more manageable. Also, the resolution of a full analysis is fairly
rough to begin with because it is dependent on stat bonus estimates.
It doesn't make sense to try to squeeze every possible fraction of
a fraction of a percent out of the analysis when the original stat
assumptions could be off by 10% or more.
1) Updated refresh documentation to reflect the current status (automatic
refreshes are disabled by default)
2) Updated refresh code so that your first successful refresh after loading the
plugin will be a full refresh. We need this so that we properly handle items
that are orphaned (e.g., a no-save key disappears) and so that we can re-sync
items that may have been moved or modified outside of this client/plugin.
3) Fixed incorrect return value check in plugin update code. The previous code
could send an incorrect (nil) return value in some error cases.
2) Updated stat comparison display to give aveDam and offhandDam 4 columns
each. This lets us handle things like a "-500" change to offhandDam if
one set has a second weapon and another set has a shield.
3) Added support to detect if a quit command is cancelled. The previous
code essentially halted all activity in the plugin if someone entered
"quit" even if the quit was cancelled for some reason (e.g., they were
holding a no-save key.)
4) Removed "dinv update confirm" mode
5) Added "dinv version [check | update] <confirm>" mode
6) Plugin auto-updates now support both old (r1825) and new-ish (r1937)
MUSHclient builds. If the new async functions aren't available we
fallback to the original raw request functions.
7) Added new "version mismatch" return value code
2) Added new "dinv debug" interface for testing new features
3) Changed default # of automatic backups from 4 down to 3 and updated the verbage
in "dinv help backup" to make things more clear
4) Added dbot.shell() framework to execute shell commands in the background without
pulling up a command prompt window. The previous method of using os.execute()
was functionally correct, but on Windows (but not wine?!?) using os.execute()
could briefly display a command prompt window before automatically closing it.
5) Added routines to detect if files/directories exist and to spin until a specified
file or directory is created or deleted. You can spin in either a sleep loop
(more efficient but requires a co-routine) or in a busy loop (less efficient but
can be used anywhere.)
6) Replaced all os.execute() calls with equivalent dbot.shell() calls. The os.execute
code runs everything in the foreground and stalls until the command completes. In
contrast, dbot.shell() runs in the background and does not block the user from
doing other things. In places where we need to block (e.g., you don't want the
user changing saved state in the middle of a backup) the plugin will explicitly
block now.
7) Fixed an assert that could potentially trigger while opening a state file
2) Removed temporary debugging code for portals
3) Updated release notes to warn uses to rebuild their inventory table if they
ever get the portal wish
2) Fixed a bug that prevented equipment sets from exploring what happens if overmaxed
stats are reduced. This could result in non-optimal sets.
3) Temporarily added debugging code for using portals in equipment sets
2) Fixed broken paths on Win7 and Win10. The previous code didn't handle it properly
if there was a space in the absolute path to your saved state.
3) Changed the backup code to use "rename" instead of "move". Win10 couldn't handle
long pathnames with "move" but it does with "rename". Go figure.
2) Temporarily commented out the status bonus thread since it appears to have caused a conflict
for a user. I need to investigate that further.
3) Temporarily commented out the auto refresh at login since it was causing a lot of spam for
new users. I'll look into a better way of handling that.
We don't want a "note write" command to be pending at the same time
that we send a fench message to the mud because the fence could
interfere with the "to" or "subject" fields of the note.
Durel