Derma Buttons - Too Slow!

I’ve started to create an inventory system… which has been nothing but problems.

Firstly, there’s no NetworkedArray that I can use, so I need to use a NetworkedInt for every single inventory slot. That’s annoying, plus… probably not efficient.

Secondly, displaying the inventory is problematic. Basically it consists of 42 buttons arranged in a grid. The problem here… is when I load my derma menu, it takes a good second to actually draw all the buttons. This can’t happen if the player is to open the menu often.
for i=0,41 do
for j=0, 5 do
for k =0, 6 do
local invButton = vgui.Create(“DButton”, tab2)
invButton:SetSize(30, 30)
invButton:SetPos (5+35k, 20+35j)

Is there a faster way than buttons? I know I could use labels, but the player needs to be able to interact with them. Maybe a dynamic DermaMenu? Not really what I had in mind… really like the grid setup.

How about a way to keep the derma menu loaded, even though it’s not visible? So the player would have to wait an extra second the first time it loads up, but it would stay in the memory…

Oh fuck, another guy who does not understand how for loops work.

You are creating 42x7x6 buttons here, which is a nice bunch of 1764 buttons to allocate and render. The first for loop is completely redundant, basically, what it means is “create a 7x6 grid of buttons, and repeat this 42 times”.

Ah… well… ya got me there. At much as I’d like to contest my knowledge of loops, this sure does show otherwise. I’ve changed this code around several times, it had started off with a multi dimensional array. I’m also on some severe pain meds which I fear may be interfering with my ability to comprehend simple problems.

Thanks for the help, no thanks for the manner in which it was presented.

Well I’ve already seen someone do the exact same mistake before, and I still can’t see how such a logic can possibly make sense in any way. That’s sure irritating when you see someone else do the exact same mistake and not even notice it.

Also, you can use datastreams to send a whole table from the server to the client, although I wouldn’t recommend that if the inventory is frequently updated. If it is frequently updated, you can send the whole table once, and then update it on the client via usermessages.

I had it going through the inventory one by one before, hence the “for i, 41 do” loop. It would do “Msg(GetItemName(i))” in the console for each item. I wanted to see if the system worked at all before I started putting it in a menu. After a few changes, I decided not to loop through each item like that but didn’t take out the first loop. I haven’t touched datastreams yet, but I guess now’s the time to try.