Author Topic: Brick menu adjustments for tabbing.  (Read 3256 times)


That still doesn't answer my question: how does the game prioritize conflicting brick packs? For example, if two brick packs tries to use the non-default category 'Zombie', for example, but uses different icons, how does the game choose which one to use? If two servers use either of the packs exclusively, i.e. pack 1 but not pack 2 and vice versa, the players would see different icons depending on which server they visit which would be confusing as hell.
Also, substituting properly descriptive icons with randomly chosen brick icons is a terrible idea, because 1) the icon is most likely not designed to represent the contents of the entire brick pack, and 2) the icon chosen would be different depending on which brick packs you have loaded. Even worse is the way brick packs with no icons would be handled; in this case, the 'Zombie' tab would either have a single 'Z', which could mean anything from 'Zit' to 'Zebra', or have the entire category name written on it, which would make it wider than all of the tabs that have icons, and that would look awful.
The point is, your system is very poorly designed and causes unneccessary complication for add-on makers and end users alike. It's just not worth what little (subjective) gains there is for the UI design.

The very question that you're asking is found in what I said. The add-on makers would not make the icons for the brick pack. The client-sided "icon-view" would be the one to do so.

Outside of that, having the first icon is the last thing that could be done to display a icon, if even that does not exist/fail, then just leave in Z.
Be it means Z for Zebra or anything else, it's not a hard thing to figure out once you click it and you see zombies.

yes this thing is glorious
I should make a topic where I have all the helpful add-ons I made in one place

The very question that you're asking is found in what I said. The add-on makers would not make the icons for the brick pack. The client-sided "icon-view" would be the one to do so.

Outside of that, having the first icon is the last thing that could be done to display a icon, if even that does not exist/fail, then just leave in Z.
Be it means Z for Zebra or anything else, it's not a hard thing to figure out once you click it and you see zombies.
And how exactly would your "icon-view" "make" the brick icons if the add-on creators can't? Would they even have control over what their category icons looks like?

And how exactly would your "icon-view" "make" the brick icons if the add-on creators can't? Would they even have control over what their category icons looks like?

Since not every add-on maker will be obliged to give a stuff about this, no. But there's room for interpretation. Since rarely 2 add-ons use the same category, add-on makers that care more could make their own icons for their categories. And if someone makes such a category as well, in general sense, it would either be a extension of that category (in which case, it would require the original pack, in which case, it would not require the user to input in a special icon), and otherwise, it could simply be a different category if they both have icons. I'm saying simply because I am maybe trusting too much on how would reworking the tabs work.
Whoever makes the add-on would loving make the loving icons for the loving indexed bricks (putting emphasis on loving because I repeated this for the third loving time now).