I hooked into twx proxy and started to try and run to see how it did. this is just after setting it up and the script started. I got a indexoutofbounds error. now it could be something from twx.

I had lexer turned on. but it didn't spit anything out. maybe it would have if it was the only program hooked up.



489676 [Network-3] INFO krum.weaponm.network.NetworkThread - network thread started
499770 [Network-3] INFO krum.weaponm.database.DataParser - entered correct game
547134 [Network-3] ERROR krum.weaponm.network.NetworkThread - unspecified error
java.lang.IndexOutOfBoundsException
at java.nio.HeapCharBuffer.subSequence(HeapCharBuffer.java:574)
at java.nio.HeapCharBuffer.subSequence(HeapCharBuffer.java:42)
at krum.weaponm.database.DataParser.mkeyWarpTarget(DataParser.java:1421)
at krum.weaponm.database.lexer.DataLexer.dispatch(DataLexer.java:348)
at krum.weaponm.database.lexer.DataLexer.lex(DataLexer.java:697)
at krum.weaponm.database.DataParser.parse(DataParser.java:82)
at krum.weaponm.network.NetworkThread.run(NetworkThread.java:98)
547135 [Network-3] INFO krum.weaponm.network.NetworkThread - network thread exiting

it would be nice if it ignored what it couldn't parse. I can't use weaponm in a real game right now because it doesn't parse everything and i don't have teh script written yet. however i'd gladly let it tag along on twx proxy if it would work ok with it.

that way it could parse as i went along. and i could play with it and have it do things with the data it collects. i'd be testing it the same time i'd be playing a game with twx proxy.

Making it more toleratant shouldn't be too bad. What has me really worried, though, is how the UI hits a wall after a few minutes and becomes sluggish. With the CPU usage staying low and no memory leak, I'm not sure how to approach that one.

yeah, that one worries me.

it starts out fast. haven't heard much from mongoose on how that is coming.

neato. i was able to open up the jar in a text editor and view the source. i get a idea how things are put together.

one thing i'm not sure of is how to add more parsing. i know mongoose uses a lexer. and from what i understand, he has to compile it separate from the application?? thats probably what those automation files are .gz or something.

i'm not going to jump right in though messing with the app right now. i liked how the telnet negotiation was just one command he sent to satisfy twgs. i was looking in to see if he implemented the whole thing and how he worked with it. haha cause i was working on a client at one point and was playing with telnet negotiations. sending and receiving responses.

Yeah, he totally cheated on the telnet code Now that the build is automated, with maven 3 installed, just run:


This will process the lexer files, compile the code, and build the single jar binary. To run it, type:

Alternatively, you can run the WeaponM class from your IDE, which is handy to run in debug mode to use breakpoints.

Ok, good news - I'm making some progress. I'm writing out my findings to help me think it through:
- There is a thread that is forcing a full screen redraw every 750 milliseconds for blink handling
- There is another paint request when any character in the current viewport changes
- After 10000 lines, the limit of the buffer, repaint requests on character changes stop working. Scrolling up then down triggers a full redraw so you can see the state
- After 10000 lines, the only reason we see any content is the 750 ms blink redraws, hence it feel sluggish
- Even if I fix the 10k line problem, I still notice the redraws take progressively longer, especially around the 8k mark

Even better news - I fixed it. Turned out to just need a simple adjustment in how it calculated the position of the character to update as well as a full redraw on buffer sizing. The blink is still doing a full redraw every 750 ms, which certainly could be optimized so for now, I decreased the default buffer size to 5000 lines, though you'll only get this improvement if you either modify or clear out your preferences. Patch for Display.java in JTX is here:

If you are using the installers, you should get the new version automatically on next restart.

cool. i'll get into a test game to mess with it again

was there a reason you had to decrease to 5k since you changed how it calculated stuff? never mind, i re read it. you did it to work with the blinking text repainting everything every 750ms. since it can still use some optimization.

Another Error I noticed is that it does not parse the player info screen in twgs v1. but that could be on purpose right now since you are working on it with v2.

(deleted double post)

Sorry I haven't been able to spend much time on this lately. I've been working long hours at a new job.

Tweety: it looks like the line numbers in your stack trace are a little off from my version. It's probably this line:



It's likely that the +/-24 is are wrong, at least in some situations, e.g., different game versions.



I think that's a good solution with little to be gained from complex optimization. Repainting is extremely fast, as you can see if you grab the scroll bar knob and jerk it around. If the screen is scrolling, the whole thing needs repainted anyway. And if not, it's idle and can spare the CPU cycles. Swing repaints are asynchronous and automatically combined, so if repaint() is called twice before the screen actually repaints, it will only repaint once. And only the visible area is painted; the buffer size doesn't matter.



It should only repaint the region that contains the change.

I knew there was some weirdness at the very top of the display when it's full, but I haven't encountered the sluggishness you're describing. What happens when you run the speed test demo from JTX? The longer it runs, the higher the thread scheduler seems to prioritize the thread writing to the character buffer, at the expense of the thread repainting the screen.

The blink repaint seems to be repainting the whole component, which includes the large buffer. Wouldn't it be better to tell the blink to only paint the visible portion?



The problem was the repaint for the characters stopped working after the buffer was full. It was trying to tell the terminal to paint outside the region of the component, so nothing happened. The only reason you saw anything at all is the blink repaint was repainting the whole component every 750ms, and updates only every 750ms seems pretty sluggish. The patch I attached fixed it.

While I'm at at, what do you use for lexer debugging? My Intellij console is eating most of the characters, and even when I run it from the linux terminal there are characters eaten.

Calling repaint() with no params dirties the whole component. It's up to the Swing repaint manager to calculate the visible portion, because it might change between the calls to repaint() and paintComponent(). If there's any doubt, we can examine the clip rectangle of the Graphics object passed to paintComponent().



Ah... that's bad. Thanks for the fix.



You mean the lexer log messages? They display reasonably well in the Eclipse console.

Ah, yes, you are correct. Good, I feel a little better about that then. When I was starting, one of the first things I did was remove the blink repaint() and it seemed to go faster, but perhaps it was my imagination.



You mean the lexer log messages? They display reasonably well in the Eclipse console.[/quote]

Hmm...I may have to try Eclipse *shudder* Also while I have you, could you give me commit access to your github repos and I'll get those projects set up?