Search results

Unsticking this, as script manager is pretty mature/stable now. New feature requests can go in bug reports forum.

There's a reasonable chance it's the JVM's fault. Not that there's anything we can do about that, either.

I see, I was mistaken about this particular report being a threading issue. Thanks for being persistent.

Only if this report was from a relay script. Of course, I have no idea how to reproduce this. The snippet in the OP is not something I can independently run. Bug reports that depend on some code to reproduce should be SSCCE. In fact this report is sufficiently difficult to reproduce that I...

No, that commit only affects relay scripts. This is about the CLI queue. What sort of CLI command ignores world peace being declared (aka continuationState)? I see a bunch of hand-wavy reports of various things in this thread, but nothing concrete. Give me an actual CLI command or ASH script...

Moving out of bug reports.

Good idea. Try r14779?

Hm, that's intentional but.. unfortunate. Not sure what to do there.

1) r14760 did not touch parsing. Parsing was broken by 14772. 2) I just demonstrated that -if- autocrafting is to fire during auto adventuring, it will work as it always has. Therefore autocrafting simply never happened for you (because of broken parsing, which is now fixed again), and your...

I suspect you are wrong. Auto adventuring does not use the relay combat thread. Or any thread other than the one that processing is done in: case ItemPool.MCCLUSKY_FILE_PAGE5: ResultProcessor.autoCreate( ItemPool.MCCLUSKY_FILE ); break; public static void autoCreate( final int...

Just reverting the htmlcleaner changes, this is way more than I have time to tackle right now. r14775

Yuck. There's a lot of stuff broken. Looking into it, might just roll back if I can't figure out a quick solution.

That's rather unfortunate if simply upgrading HTMLCleaner affected its parsing behavior. Sigh. We'll need a session log and HTML dump of a nun fight, please.

Yes. Presumably we should protect you from that, but... I'd need to think about how we can do that. Hm. I'm not sure this is a regression from the continuationState changes; I feel like previous behavior was just to forceContinue our way through the autoCrafting and arrive at the same place...

I'm far more interested in making the relay browser experience correct - i.e. diagnostic information on why things broke should go to, y'know, the relay browser. And simultaneously to the gCLI, which is still the case. So no surprise, I agree with veracity. I know that peoples' brains get...

Not sure, really. I had this thought that I would eventually be clever and fetch the pre-parsed tree (since I'm going to use parsers as part of many requests, might as well reuse them) but... I don't know, I'm unable to brain tonight, it's obviously better if you can feed it arbitrary html...

I'm sure I'll make changes to it, but you can play around with the xpath( str ) function I just added. Only works in relay scripts after you've invoked visit_url(). (or, well, you will be able to eventually, once I sort out build.xml)

Huh. I was previously thinking of adding a new type to ASH (blah) but I think I like this option way more. Just always return strings; convert TagNode objects to their innerHTML equivalent when necessary. Yeah, that can work. Well, I'm not averse to adding provisional new ASH functions...

Well, you can. But that's the thing I haven't figured out how port to ash yet. Normally, an xpath query returns an array of node objects. (TagNode objects, in HtmlCleaner, that have all the methods of the root object, including xpath evaluation) But when you apply the text() function, you're...

(missed this post on previous page) Oh. Yeah. I could possibly construct an xpath that would work for both compact/expanded... but it would be quite the hack. Comparing the HTML from both, the DOM looks completely different. (this is why you should do styling in CSS, people!)