Feature - Implemented "modernize" item manager tables

[bordemstirs]

And if you see "bottle of vodka" listed on "creatables", I think it's a user error to assume that that means "directly purchase from ... somewhere" rather than "create from ... ingredients".

Yeah, I don't really know what I was thinking, this makes perfect sense to me now. Thanks for filling in the gaps in my current state of mind. It should have been clear to me that it wasn't considering the mall or -every- kol item would have been in the list (that is in the mall and I can afford, at any rate). So yeah, thanks.

 

[xKiv]

The sorter: it actually looks like a slightly modified mergesort. They are calling it "shuttle" because it "shuttles" the values between two arrays (it's not an in-place sort).

The comparators: I would extend the row objects with Integer attributes, precompute them, and sort by that. That way, your regexes will only be executed N times total for N rows, instead of N*log2(N).
The problem here is, of course, when to trigger the precomputation. You can do it whenever you set the value of the appropriate row/column (cell), or hook it on the sort trigger, or I don't know ...

 

[roippi]

Hitting the regexes once per row sure does sound good. But boy is that going to be tricky.

JXTables kind of work on this WYSIWYS (what you see is what you sort) system, meaning specifying an alternate set of objects to sort by is not (natively) possible. Otherwise I'd just sort by strings/integers that haven't had HTML and whatnot added to them. Maybe I'll see if I can figure out how to do that and avoid the regex comparators entirely.

 

[xKiv]

Have each cell with two values (one what was the entire object now, another the cached sort-value), then override toString() to show the first and use the second in the comaparator?
Assuming that JXTables uses toString() to decide what to display in the cell.

 

[roippi]

It uses TableModel.getValueAt( int rowIndex, int columnIndex ). It's not just strings, you can display anything that extends JComponent - comboboxes, buttons, etc.

Edit: ooh I have an idea, thanks. Hopefully I can whip something up in the next day or two.

 

[roippi]

11058 should massively improve performance. Again. I didn't really have time to profile it, but it should be way speedier in every regard on slower systems.

ETA: some performance differences.

11057

flush took 15556799
flush took 15531865
flush took 15486696
flush took 15394189
flush took 15339262
flush took 15501873
flush took 15300236
flush took 15485612
flush took 15476217
flush took 15350103

11059

flush took 536978
flush took 535893
flush took 551793
flush took 470487
flush took 433629
flush took 435436
flush took 437604
flush took 433629
flush took 432545
flush took 398216

Worst-case filtering performance, basically.

 

[Nifft]

If it is possible, and if you're so inclined, could you make the new style list boxes restore a behavior from the old ones where ... if your focus was sitting on an element in the list, you could start typing the name of an item, and the list would scroll towards it.

thanks!
~ Nifft

 

[roippi]

Yeah, like I mentioned to you, I didn't even know about this feature until you mentioned it. Haha.

I'll look into it. Kind of lower priority, I want to get performance dialed in before I start adding features.

 

[Ensiferum]

it should be way speedier in every regard on slower systems.

Got me really excited there for a moment, but in fact both 11058 and 11060 are feeling much slower than 11056 for me.

Maybe I should stop posting here before you track me down and lynch me.

 

[roippi]

Got me really excited there for a moment, but in fact both 11058 and 11060 are feeling much slower than 11056 for me.

Maybe I should stop posting here before you track me down and lynch me.

java -Xmx256m -jar "old shortcut string"

Please replace your shortcut target with that and see if that fixes performance.

 

[Ensiferum]

Well, that finally worked for heap size. Unfortunately no change in behavior.

Anyways - this only affects my pulls management at the start of a SC ascension on day 1, not much else. I'll just write a pull script for that or use an older build then switch after pulls are done.

Thanks for all the help, but the little goth kids deserve more attention than me right now.

 

[roippi]

To help me zoom in on where to optimize - how well does column sorting perform? Try various columns, both strings and integers.

 

[lostcalpolydude]

java -Xmx256m -jar "old shortcut string"

Please replace your shortcut target with that and see if that fixes performance.

Suggesting 256m might be pointless since that's the value I had (as a default somewhere, I guess?) when I was posting before. I haven't seen any issues since I boosted it to 1024m, but it was sporadic before.

 

[roippi]

Well, he was stuck on 128m. He only has 512m minus whatever the OS needs.

It seems that I need to be more sophisticated about a couple of things. Requiring 512m of heap space is not ideal. I actually do know where to go next, but I'm quickly entering unknown territory in terms of implementation. Oh well, that's why I'm a dev here - learning is fun.

Edit: first-pass analysis shows that my original idea: no good. My thought was to compile a vector of vectors that could serve as my TableModel. This would reduce rendering overhead by a lot- but unfortunately the cost to recompile everything whenever all listeners fire is way too high. It trades a reduced memory footprint for some truly awful filtering performance. Back to the drawing board.

 

[lostcalpolydude]

With 1024MB memory available, I ran into some slowdowns with filtering again. It only lasted for about 1 second instead of 5 or so like it was before. Also, emptying the filter box was instant, which was not the case before when typing something made things unresponsive to begin with.

 

[roippi]

hahahaha. Boy, was I looking in the wrong place. At least everything is super-optimized now.

Try 11068.

 

[Ensiferum]

Just in case noone has told you this by now - you rock!

 

[roippi]

All fixed for you then?

11069 should add the fill and adv/fill columns to most everywhere it'd be useful. Think that clears my higher-priority queue, on to the miscellaneous stuff.

 

[Ensiferum]

Yeah, everything is working with great speed now.

If there is any difference at all, it's down to miliseconds (compared to a farmer multi I run from a different folder with months old build). It's nothing worth crying for with all the new features.

Thanks a lot for releasing this build just in time for my new ascension!

 

[roippi]

Yeah, everything is working with great speed now.

If there is any difference at all, it's down to miliseconds (compared to a farmer multi I run from a different folder with months old build). It's nothing worth crying for with all the new features.

Thanks a lot for releasing this build just in time for my new ascension!

Cool, that's about what I'd expect with your system specs. P.S. you should really get a new system.

11075 saves column states to a global pref and loads them when you open item manager. I thought about implementing Serializable for a bit (i.e. doing it the "right way") but meh. I enjoy hacking it into a string.