On 29.01.2017 00:05, Michael T. Pope wrote: > On Sat, 28 Jan 2017 17:26:46 +0100 > "Enrico Weigelt, metux IT consult" <enrico.weig...@gr13.net> wrote: >> I've seen that modifiers are sometimes collected in lists, sometimes in >> sets. Is there a special reason behind that ? > > Historical accident/inconsistency between developers.
Ok. Seems that Set is used more often (especially in FeatureContainer), therefore duplicate modifiers (incl. all attributes eg. source) are not allowed. Digging a bit further, it really seems the whole duplicity problem (perhaps even the need for the source attribute) comes from the fact that at some places modifiers of sub-/related objects (eg. buildings and building types within colonies) are aggregated here and removed there. Just have a look at Building::setType(). Looks like a good place for subtle and hard to find bugs (which actually hit me in a completely different area). >> Are there cases where duplicate modifiers need to be filtered out, >> or could we just use lists anywhere ? >> (eg. Unit::getMissionaryTradeModifiers()) > > I doubt anyone knows. Meanwhile I've found out that it's required for the modifier inheritance caching. But this, in many places, doesn't seem to be the proper way to go (eg. building type modifiers propagated up into individual colonies), and it makes the whole thing very fragile. (for things like derived spec objects, like building or unit types, it might make sense, in contrast to usual game objects) > Sorting is now only required at the point the modifier is applied or for > display purposes. Modifier application used to involve some very brittle > special case code until we made a sustained effort to define a sorting > order, allowing the current sort+apply-incrementally algorithm. Matches my observation. Should we then get rid of all sorting outside the GUI ? > You will need a mechanism to recalculate the compound modifier when one > of the underlying modifiers changes, which is asking for bugs due to > forgetting one or more special cases ... basicly the problem the current modifier caching has ... :o Actually, there won't be any need for recalculation, as there wouldn't be any need for any caches (outside the operators themselves), which need to be maintained. Let's take a little example: a colony's warehouse capacity. (see Colony::getGoodsCapacity(). It's influenced by Buildings (mainly various depot/warehouse types). So, for a calculation, we just ask the buildings how much storage capacity they provide to the colony. (note that's yet global to all goods types, so eg. buildings w/ storage capacity of goods they produce or consume, isn't supported yet - maybe a nice future feature ?) Assuming we dont just go the easy way of adding some getGoodsCapacity() method to Building (which IMHO makes it a lot easier to understand), but rather have very generic approach, the buildings could be asked for an modifier operator with Id warehouse. This operator would just act on the modifiers coming from the building's type. We can even easily cache that operator (actually, it could even directly come from the building type), or even do a partial solving at load time. If the buildings change (eg. new warehouse being built) we dont need any further action here, because the colony now asks a different set of buildings. > Also the individual modifiers will still be needed for display purposes > so you will not be saving memory. Do we really need the individual modifiers, or just groups of them ? --mtx ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
