Strilanc
Veteran Scripter
- Reaction score
- 42
You stated that there would be more overhead from cleaning up when a unit is removed instead of when units enter the map. But almost every unit that is removed must have entered the map, so you have the same overhead in both cases.
You mentioned spells, I think you're getting at 'clean it when they cast it' vs 'clean it when they die' and noticing that if lots of units are dying you do more work. That's a valid point, but in that case you should just NOT USE THE CALLBACK. You can still clean the data normally!
Providing the callback allows you to not use a 'pivot array'. The pivot array is bad because it requires a ton more knowledge about how handles work to be sprinkled throughout the code. The callback abstracts all the 'units can be other units' problems away.
PUI stops you from using unit custom data, can't detect outsides changes to that custom data, has default settings that are set too high, contains testing code that belongs outside the library (a text command to show the index of selected units? seriously? that doesn't belong inside the library), and doesn't tell you when it throws away an index.
Are those major problems? No. But they show PUI isn't perfect. Calling something perfect doesn't make it perfect (perfect things don't have versions, either).
You mentioned spells, I think you're getting at 'clean it when they cast it' vs 'clean it when they die' and noticing that if lots of units are dying you do more work. That's a valid point, but in that case you should just NOT USE THE CALLBACK. You can still clean the data normally!
Providing the callback allows you to not use a 'pivot array'. The pivot array is bad because it requires a ton more knowledge about how handles work to be sprinkled throughout the code. The callback abstracts all the 'units can be other units' problems away.
I was thinking wrong about this one, you're right that you can't hold indexes. HAIL can't have this problem either, because it holds a copy of the handle.Only if you use HAIL, PUI does not have that problem. (because PUI depends on it's own custom indexes and not on unit handle)
You can't possibly be missing the hypocrisy here. You're claiming PUI is perfect, right after I showed you a system which has features PUI doesn't have. That's pretty hard in the head.PUI cannot be improved, it is perfect unit indexing.
[...]
You seem to be a little hard in the head and like to answer before you think.
(which is also obvious from our PM discussion)
I am tired of always saying same thing three times so you can finally get it right.
PUI stops you from using unit custom data, can't detect outsides changes to that custom data, has default settings that are set too high, contains testing code that belongs outside the library (a text command to show the index of selected units? seriously? that doesn't belong inside the library), and doesn't tell you when it throws away an index.
Are those major problems? No. But they show PUI isn't perfect. Calling something perfect doesn't make it perfect (perfect things don't have versions, either).