:) this is my first real contribution (and post) to Transcendence.
Obligatory longwinded ranting:
;) After having created a 'quick loot' script that caused the Mule to 'scavenge' all vessels (matching given parameters)
:unsure: and then using the 'development' version of it to clean out each system instantaneously
:blink: I faced an incredible itemlist that in combination with me 'fix and enhance' filter was thoroughly impenetratable;
:( and some scripts that crash without their inventory,
:ph43r: and 100 GT mule that would plow me out ot the solarsystem
:) The solution seemed simple: implement the iventory in such a manner that this massive pile becomes a number of smaller ones.
More ranting:This lead to very bulky and nearly identical modified Loot Screens with different 'filters'. discovering that the scrSetListFilter did not have a meaningful effect as an action, and not wanting to create a hundred loot screens, I had an idea.
:D Noting that the gPrevScreen and gPrevPane varibles were not reset, then any window wouldnot require a riteration/push of the value were they meant to go 'home'. and that scrSetListFilter is set in <litstoptions> by gItemListFilter, I decided to see what would happen if I were to call the same Loot scrren from a pane within the lootscreen and set a filter.
:angry: I know that had I just used a table and lambda, I only would have needed one pane to set the filter,
<_< had a relly cool (dynmic) rolling list, have reduced the code size to one quarter what it is...
:P but I call this 'proof of concept',
^ . .^ A helpful feature that could be added to all Itemlists, bout shouldn't.