The beta in this post includes a few more things.
- 3hee's fixes -- use window.expand and remove margin-bottom from #topbar.
- Submit dropdowns on blur (in other words, if you change a dropdown, you don't have to press enter; doing something outside the dropdown will cause it to be updated to the currently selected value). I didn't want to do this because it tends to be more server-heavy, but some people didn't seem to realize that changes needed to be submitted after being made, and adding a submit button looks inelegant.
If these are all good, the only thing keeping this from release is the fact that the dropdowns for certain mafia types don't work, despite having the same code as other types which do work. I suspect it's due to a) special characters in the names, or 2) hitting some kind of memory limit for dynamically building dropdowns. Any help debugging this would be much appreciated.
Filtering familiars: looks like this is a go.
@Fluxxx: Understanding the way documentation is saved takes a bit of familiarity with some of the features I have created for scripters, most importantly the Map Manager (link in my sig). The documentation for settings is in a separate map from your vars file, saved locally in vars_documentation.txt. However, this is not exactly a private map, since it is loaded via load_current_map() -- a function which checks the Map Manager once daily, and if your version is outdated, it gets completely overwritten by the updated map. So if no one is updating the remote map, your local changes are safe (which is all that the WOSSMAN does -- it does not upload changes to the server). But when someone updates the remote map, your local changes will be overwritten. To avoid your changes getting overwritten, you need to upload your edited map to the Map Manager. This shares your setting names and documentation with the world, but users will only see documentation for the settings they actually have.
There's also a chance that you could be having a permissions issue, if mafia is unable to write to vars_documentation.txt. But in that case, it would seem likely that
none of the documentation would have loaded.
@Alhifar: You found the mysterious "verbosity 0" bug!! I award you 10,000 points! Even after you explained it, it took me a little while to figure it out. This should probably be updated quite soon.
@Theraze: This one uses has_goal() to figure out the
best location to get the specified item:
PHP:
alias goget => conditions clear; conditions add 1 %%; ashq import <zlib.ash> float bestrate; location bestloc; foreach l in $locations[] if (has_goal(l) > bestrate) { bestrate = has_goal(l); bestloc = l; } if (bestrate > 0) obtain(1, "%%", bestloc); else print("No monsters drop this item.");
@Alhifar AND Theraze: just
link them here!
@Doodle: I could only see a wait() for relay scripts causing a problem if the page is being printed as it's being made. If check_version happens in the middle of this, particularly if other server hits need to happen in there as well, there may be a chance that it could lead to a browser timeout or somesuch. I recommend instead building the page in a buffer and writing the entire buffer at the very end.
As for consult scripts, check_version() really should not be causing any problems.
