Well, the present struct changes broke the build on more than one occasion. That is clearly nothing new. That's why I make changes in a branch, and wait until they are complete before merging them.
If you give ffcs memory management, and their UIDs for each of them is stored in a vector, then adding to a pool > 32 should not be too hard. At least, I would not think it to be hard. That meaning, a user creating an ffc should work well with that system.
It does not need to be valid at present to try loading it. LoadFFC(120) actually flipping permits loading junk data, and writing to goodness knows what memory area. I have in fact known users who have done this to try to create temporary scratch vars, and I have scolded them for it. The LoadFFC block, or soemewhere in the pipe, we need a routine that clamps the range to whatever is valid. I don;t ultimately care how this looks, but if we allow user-created ffcs, just like any other pointer, then a validity check will be needed for them, just as with any of the other objects connected to a screen.Surely "isValid(ffcref)" is like the most horrible last-resort anti-solution for the problem, isn't it? I mean it has to be valid for it to run in the first place, right?