Search results

Sure. > test xpath charpane.html //tr[td[a[@class="familiarpick"]]]/text() 1: Tron, the 35 pound Rogue Program > test xpath charpane-fambelow.html //tr[td[a[@class="familiarpick"]]]/text() 1: Tron, the 35 pound Rogue Program

p.s. just to convince people that xpath is cool > test xpath charpane.html //span[@class="black"]/text() 1: 760 / 809 2: 718 / 1168 3: 21,756,038 4: 194 My HP, MP, meat, and adv. > test xpath charpane.html //center[3]//td[@valign="center"]/text() 1: The Sonata of Sneakiness (2) 2: Smooth...

Well for the charpane specifically we actually only load it during relay adventuring. But a lot of my points were meant in a general sense. I'm not terribly interested in profiling performance improvements exhaustively here. If we can cut our processing time by an order of magnitude, I...

That's one thing I haven't looked into. I know that HTMLCleaner works by creating a valid XML tree out of arbitrary HTML, in a fault-tolerant way like browsers do. I know that it provides some *Serializer helper classes but I haven't seen if you can serialize back to HTML equivalent to its...

I've considered it, yes :) It's something that should happen, in some form or other. Recreating the full API in ASH is a bit much, but we should be able to do something with xpath. The only question is how far down the rabbithole to go, heh.

Also also, I won't be committing anything on this before the upcoming point release.

Heh. I recently did some comparison shopping too, and I agree - you chose well. I love that it supports XPath queries. I might update it, though - it's still well-maintained and our version is from 2007 :)

tl;dr: I'm going to refactor the charpane to do its parsing using a dedicated HTML parser. It would be cool if other developers took note of this and used an HTML parser in the future when grabbing specific things from the DOM of other pages.

- Motivation There is a *lot* of code in mafia. Mafia just does a lot of stuff. But if one were to characterize what mafia spends all of its processor time doing, you would find that the lion's share is spent processing text. Searching for stuff in strings, really - that's what we spend our...

So, I'm on to the next thing that catches my whimsy, and this one's a doozy. But unlike many other Roippi Projects™, this one I can't do alone - I'm asking for a cultural shift amongst fellow developers, as much as anything else. Executive summary Instead of parsing HTML with regex, we should...

Yes, I know. That's intentional - and probably more correct than the old behavior, anyway. People are welcome to discuss, of course, but the whole point of the continuationState change was to segregate relay behavior from main interface behavior. This is consistent with that.

I was never questioning whether you were making it up. There's some sort of race condition that happens on slower systems that I just don't want to think about debugging. Try r14760?

Yup. r14757, untested (rather, r14758, now that I've remembered how to boolean logic)

Oh, I know how I messed this up. I'll take this.

Well, I can't reproduce, sorry. I guess you can open up a DEBUG log and run a combat in your vanilla copy, see if there's anything noteworthy in there.

continuationState and displayState are actually distinct things, yes - and really it's just the latter that's being messed up here. Still, relay threads shouldn't be able to interact with displayState either so there's presumably something to fix.

Download a vanilla copy of mafia to a folder somewhere and see if you can reproduce it there.

Update your mafia.

Do you have a before/between/after battle (adventure) script? fight.ash relay override?

Do you have a before/between/after battle (adventure) script?