Search results

For some reason I thought the IOException was being thrown by getInputStream which would throw an IOException if the outputStream hadn't been closed yet in a POST request. I might've misinterpreted the stack trace somewhere and got confused, it wasn't happening for me so I was throwing ideas out...

I assume this means it's happening a lot to you, try this patch and see if it makes any difference at all. I'm only guessing it's a synchronization error. If I am right about it, then I can only guess it has started happening recently due to perhaps architecture changes in KoL servers leading...

I'm not able to reproduce this on my system, but it looks like a possible race condition causing synchronization errors. The inputStream of a POST request can't be read until the outputStream has closed. Synchronizing execute() might fix the issue, but it'll make things pretty slow by blocking...

Your choiceAdventure595 property needs to be set to "1" for this to work. Can you confirm that?

I am still confused as to why you wouldn't serve the .json files as application/json types from a web server with gzip enabled, but good luck :)

If you're talking about whether or not you should enable gzip encoding on your web server, the answer is yes, you should. You should be serving the JSON data over HTTP, I'm not sure where 7zip comes into the equation. Let the webserver handle it for you using it's own implementation of gzip...

That's usually an error that appears if you have out of date rt files, but you said you've tried to update the rt files, so I'm not sure. My suggestion is that you delete the rt folder completely and unzip it from the latest rt.7z. Also make sure your path is correct to where KoLmafia.exe is, so...

It's possible that whatever method Rinn is using to access the files is not following HTTP redirects. In any case, the /*checkout* sections of the links could be safely removed.

Thanks, I'll look into it :) Probably won't be fixed for the next 10 hours, as I'm not at home. Edit: I think it's fixed...

Looks like the project file destinations haven't changed, I just needed to relocate to the new SVN and the Excelsior builds are back on track :)

Well this was done for eatables, drinkables and spleenables, I remember because I provided the patch. CSA campfires were on the "do it later" list, here's the thread. I wasn't even doing PVP at the time I wrote the original patch and I had a lot more time back then. Maybe someone who actually...

Don't forget: General -> Preferences -> Extra Debugging -> Verboseley log communication between KoLmafia and browser So we can see if there's any HTML that's not being parsed properly.

That's the one I was thinking of. It was marked as not a bug quite early on, Morgoth was clearly still having trouble with it. He posted how to reproduce the issue but I never got a chance to test it (I think I did ascend to a DB run though).

I feel like there is an unresolved case floating around already. Might be an idea to merge the threads, if somebody feels like finding it.

I don't think the callstack should be empty in the first place, so you're kinda patching the symptoms instead of the cause. Perhaps I am mistaken, though. If your changes to the test script worked than that would be a bug in itself, particularly this line int c= call void myFunc("funcC"); as...

From memory, I think the call logic is in FunctionCall.java? Most ASH functions tend to have their own class in parsetree. I remember looking at this briefly and I don't think the problem is in FunctionCall.java but it might be. I might look at it later but I have a lot on my plate atm.

This is partially normal behaviour, but it shouldn't be happening when the window isn't active, so there will probably be a fix for that when somebody has the time.

The JTextComponents being referred to here are enabled, or else you wouldn't be able to interact with them. What you might be thinking of is that they are not editable. They are certainly handled differently, a component that is not enabled won't fire certain events. The problem is related to...

If any selected JList item is being copied into your clipboad then it sounds like something potentially strange is configured in your X server or possibly with your JVM. Make sure they're up to date. Does it happen with other frames? eg. open the inventory frame, click " - Fine Tuning" and...

There's a lot of noise in the example, can be condensed to: void funcB(string myFunc) { call void myFunc("funcC"); } void funcC(string i) {} void main() { funcB("funcB"); }