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)
and then using the 'development' version of it to clean out each system instantaneously
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,
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.
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.
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...
but I call this 'proof of concept',
^ . .^ A helpful feature that could be added to all Itemlists, bout shouldn't.