Search results

Hm. This may be a non-starter. BasicScope.java: Iterator it = this.getCommands(); while ( it.hasNext() ) { ParseTreeNode current = (ParseTreeNode) it.next(); result = current.execute( interpreter ); // Abort processing now if command failed if (...

I don't think we need a "thread-global" abort state for interpreters off in their own thread. If there's a problem, that will shut the interpreter down just fine - and since we're not doing anything else in that thread, there's no need to have some sort of continuationState to stop other stuff...

To expand the discussion (and de-jargon some things): continuationState is "the color of the sidebar." Red == ABORT, gray == PENDING, etc. You can hit buttons to put mafia into an ABORT state - and since we frequently "check in" on continuationState during most operations, that has the net...

Split from the hedge maze thread.

Can we reexamine this (perhaps in a new thread (haha))? I feel that ideologically, relay scripts should not be able to interact with KoLMafia.continuationState in any way - whether it's setting things from "okay" to "abort", or vice versa. There is of course a huge gap between ideology and...

Nice! I pride myself on being one of the best rubber ducks in the industry :-) Yes, it's unfortunate we have to support two protocols at once. If my time were free and I had the motivation to do it, I could see hacking the javascript of lchat to submit/request things in JSON format, then...

Hum. That implementation... well, I do understand why you did it like this, since we seemingly have to support two different chat protocols. Devil's advocate (if I'm reading the diff right): if someone says something terse like "yeah" in browser chat, then says "yeah" again some time in the...

yeah, you should switch to papyrus

Preferences are small enough that we just store them all in-memory in a big hashmap. Occasionally we serialize it to the preferences file - how often we do that depends on your settings. We should probably do that write operation in a background thread but it doesn't look like we do - I don't...

Slick.

Blocking bad searches is a feature. If you want to force an exact search - even for an item that mafia doesn't know about - put quotes around it.

Well it's no different from any other new feature in that regard - other than it being the last one you need to be hesitant about, of course ;-) Marking implemented.

I suspect it's just the update-all method (whatever I named it) naively thinking every file in svn/ is a working copy folder. That was supposed to be the contract enforced by svnmanager but I didn't think of users (and their OS) adding files in there. Won't personally be able to fix for a day...

r14659 Things I did: handling for both version/revisions Things I didn't: optional error message field after the revision argument. I'm not philosophically opposed to adding it, really, but the API seems cleanest without. I don't think that users should in general be told to downgrade...

I should have mentioned that feature request too. I never got around to implementing it because in the end it was only going to amount to a warning message that occured after you svn-updated. That still might be worth doing but I think this idea is better overall (I prefer a fail-fast useful...

Pretty straightforward idea. A lot of neophytes have this as their first post on the forums: They of course simply need to update their mafia (and perhaps to be told that there are releases other than point releases). I propose that we add some ability to specify a directive near the top...

Oh I see, ChatPoller.handleNewChat is only invoked by RelayRequest. Yup. I think between the two threads we (ok mostly you) have cleared up a lot of the "black magic" inherent in the chat system. It sounds doable - though yes a lot of work - to make the two play nicely together. After the...

Do we actually respond to being put into "away mode"? In the mchat source I see that it sets its repeat interval by responding to the "delay" attribute that it gets with every response: var gotChat = function (res) { if (!res || res == null) return; delay = parseInt(res.delay); //...

Yep. Make it the default.

I suspect that some areas where we display HTML probably scale differently (if at all) compared to natively rendered java text. Doubt there's a clean way to address it. Certainly not without a dev being able to reproduce, at least.