I can't count the number of times I've been caught offguard by the fact that there's no "if-then-else" in the XML. Like trigger spell="haymaker" percent="30" else spell="uppercut" or something to that effect. This would open up an entire range of abilities that currently can't exist.
This, this so very much. But of course that's not proper xml. I could see something like any of the following Code: <effect type="trigger" spell="haymaker" percent="30"> <effect type="trigger" spell="uppercut"/> </effect> <!-- this one has the benefit of usability in things other than triggers, though it'd get confusing with things like spawnitemfromlist --> <effect type="trigger" spell="haymaker" percent="30" elsespell="uppercut"/> <!-- this is basically the above, is easy to read but has the least usefulness--> <random> <effect type="trigger" percent="30" spell="haymaker"/> <effect type="trigger" percent="70" spell="uppercut"/> </random> <!-- and this way has the most usefulness, is slightly more annoying to implement, but quite easily allows any number of selections, it'd also have to implement amounts over 100 somehow (I'd think something like 50 and 60 would mean there's a 50% chance to pick the first, if it does than there's a 10% chance to pick the second in addition to the first, otherwise the 50% the second only would be picked)-->
mmm, although I see where you're going with this, XML is not meant for programming purposes or anything that does logic at all. XML is purely meant for structuring data and defining attribute/value pairs. Nothing more, nothing less. Deciding what data is used at what time under which circumstances, is business logic work. Basically what Null suggests in his last solution, is the most elegant and scalable one IMHO. Consider a trap that will trigger a random spell or effect, chosen randomly from a pool of dozens of spells. Creating an (one-dimensional) array in markup is rather tedious (especially when you're talking about hundreds of spells and effects rather than dozens), but it's much more readable and maintainable than writing all of those possible spells in one attribute (comma separated, for instance) or even one attribute per spell. Since XML does support referencing to elements as well, one could easily write out the array once in the XML file and then use the array multiple times by just referencing it: Code: <!-- Declaration schemas go here --> <!-- Define the array of 20 spells and effects and call it "spellArr1" --> <spellarray id="spellArr1"> <effect type="trigger" percent="5" spell="haymaker" /> <effect type="trigger" percent="5" spell="uppercut" /> <effect type="trigger" percent="5" spell="poisoncloud" /> <!-- The list continues for 17 more elements --> </spellarray> <!-- Define a new effect that will trigger one of the 20 spells defined earlier --> <effect type="trigger"> <ref:spellarray ref="spellArr1" /> </effect> <!-- Define another effect that will do the same, except for haymaker --> <effect type="trigger" exceptions="haymaker"> <ref:spellarray ref="spellArr1" /> </effect>
