Hey, more ways to handle itemsets: ---- 9. ItemSetDB.xml; HTML: //itemsetDB.xml <itemsetDB> <itemset name='Bronze Bonanza' id='0' amount='3'> //do buffs and stuff </itemset> <itemset name='Bronze Baron' id='0' amount='4'> //do buffs and stuff </itemset> <itemset name='Bronze Berserker' id='0' amount='5'> //do buffs and stuff </itemset> </itemsetDB> //itemDB.xml <item name='Bronze Cuirass' convert='1'> <itemset id='0' amount='1'/> </item> <item name='Bronze Greaves' convert='1'> <itemset id='0' amount='1'/> </item> //etc etc etc This means adding a new "variable" itemset(id, amount), which handles items that count towards a specific itemset. In itemsetDB you can choose what the *id* itemsets do on *amount* items. I'd even add some kind of notification when you've reached a certain itemset, or add itemset information in the item's description (when it's actually in an itemset). That way you'd also need some <itemsetgroup> or so; HTML: <itemsetDB> <itemsetgroup name='Bronze Armourset' id='0'> <description text='Gear up, soldier!'/> //this will be under the name of the itemset maybe? </itemsetgroup> <itemset name='Bronze Bonanza' group='Bronze Armourset' amount='3'> //buffs and stuff </itemset> </itemsetDB> Which'd make item tags like this: [item name] -stars- [item type name] [normal description] "This is part of an itemset!" [itemset name] [itemset description] -X Bronze Cuirass -./ Bronze Greaves (1/2)
I support everything Alistaire said. Also more flexibility on polymorph. People love polymorph. Something like allowing different skills to be used while in polymorph without having to change the core files. Probably a reverse condition, excluding some skills and allowing everything else. And a way to make you float without polymorph.
I would like this. As sometimes I don't have teleports or polymorph that allows floating and I can get trapped somewhere because of this.
I haven't finished any mods for this and I could be wrong. I think though everyone here would be willing to have their mods broken for sometime, to have all these awesome new additional features. If the update comes in beta form, the mod developers would have time to update or port their mods if need be. I guess I'm saying please break stuff, we'll pardon the dust i'm sure, am I wrong people?
Well, he means in terms of having a sensible way to do things which don't exist yet - the technology isn't there yet, man, IT ISN'T THERE.
The most general implementation of this should reflect something like... data ItemSet = SingleItem Item | DisjunctItemSet [ItemSet] | ConjunctItemSet [ItemSet] with two <itemSet name="foo" ... /> with the same name being interpreted as either disjunct or conjunct item sets. I'd go with disjunct, so that modders who add items who want to have their items fulfill a particular requirement can add a top level statement that their item fits a particular niche. IE: Code: <itemSetBuff name="Bronze Armor"> <secondaryBuff id="10" amount="2"/> </itemSetBuff> <itemSet name="Bronze Armor"> <conjunct> <itemSetRef name="Bronze Shield"/> <item name="Bronze Greaves"/> </conjunct> </itemSet> <itemSet name="Bronze Shield"> <item name="Rough Bronze Aspis" /> <item name="Bronze Aspis" /> <item name="Heroic Bronze Aspis" /> </itemSet> .... then in the mod that adds the item Bronze Buckler Code: <itemSet name="Bronze Shield"> <item name="Bronze Buckler"/> <itemSet>
It isn't about "breaking mods" but rather about breaking the whole game. Making changes which are too drastic would require rewriting not only data files from mods but all the data files of the core game and this is something the Gaslamp Games team, working on Clockwork Empires now, has not time for - sure, it is possible for them to release the data to a chosen group of people (the ones proven to be trustworthy and responsible enough here) with the new code and ask them if they were willing to spend time refitting the code so that the patch could be released for everyone else, but there is a certain stigma against such a thing happening (and I hope you know why). Not to mention that any major changes to the code would have to be extensively play-tested to make sure that nothing which was not supposed to break, broke. You might not be aware of it, but from what I know about it (based on Sir Nicholas' comments on this forum), the code for Dungeons of Dredmor, when it comes to its clarity and ease of making major changes to it, it like a mangled pasta on which someone poured instant glue. Meaning that if you force them to make any major changes, you will be given a brick for your next birthday instead of a proper gift. The above comment aside, now that I've gotten around to actually being able to think about it and having enough time to post, there are the things I'd like to see being added. I tried to keep those things small (or at least small-ish), albeit I have not seen the code for DoD but only heard of its general shape so some of those might be a little more time-consuming to add than I envisioned them to be. - - - - - 1. A way to make buffs invisible to the player Explanation: A 'hiddenBuff="[value]"' tag, with possible values of "0" and "1" and the default value being "0", added to the definition of a buff, which would stop it from showing on the part of the screen where all the buff icons are located, either outside of debug mode or simply at all (the latter one being easier). Reason: Right now, there are a few things which can be made to work via dummy buff juggling and some "funny" code, but many of those look really ugly due to the fact that they leave dummy buffs on the screen and thus confuse the player. Likewise, it is possible to make "should only work once after taking a particular skill" bonuses which leave similarly confusing dummy buffs now but would be unnoticeable if the change was introduced. It would also make it possible for spells to work differently (due to the possibility of using 'requirebuffontrigger' to detect the hidden buffs) based on the skills we have without cluttering the whole screen with the dummy buffs in question. The alternative to that is making it possible for us to define and set (and check the values of) our own variables, which would undoubtedly be a more time-consuming task; that combined with the fact that the buff checking procedure and even all the buffs by themselves aren't all that taxing on neither CPU nor memory means allowing us to hide buffs would be a good way to give us something similar to defining our own variables, without actually having to write that in. Shortened reason: Would make it possible to freely use solutions which are too inelegant and ugly for them to be used now. - - - - - 2. A way to check the percentage of health/mana as a requirement for triggering Explanation: A set of four pairs of tags: 'requireHealthBelowOnTrigger="[value]"', 'requireHealthAboveOnTrigger="[value]"', 'requireManaBelowOnTrigger="[value]"', and 'requireManaAboveOnTrigger="[value]", with possible values of "0" and "1" and the defafult value being "0"; and their paired tags 'requireHealthBelowOnTriggerValue="[value]"', 'requireHealthAboveOnTriggerValue="[value]"', 'requireManaBelowOnTriggerValue="[value]"', and 'requireManaAboveOnTriggerValue="[value]"', with available values ranging from 0 to 100 (percentage-based, thus these are the only values which ought to be possible). The sets being exclusive in the same way "requirebuffontrigger" and "requirebuffonnottrigger" are now. Reason: These four sets will make it possible to create spells the effects of which will vary depending on whether the player is fully healed or close to death, with full mana or running on fumes, making it possible to make skill trees which rely on the condition the player is in. Admittedly something which doesn't appear to be easy to add, it only requires adding hooks for two values (current health and current mana) and comparing them with maximum health/mana for which hooks are already present in the game, with the resulting tag being similar to "requirebuffontrigger" in its usage. Shortened reason: Would make it more possible to make "conditional" skills and spells. - - - - - 3. A way to tie a trigger effect to a buff instance Explanation: A 'tieTriggerToBuff="[value]"' tag, with possible values being "0" and "1" and the default value being "0", which would stop the effect from triggering at all if the buff triggered from the spell effect of which houses this tag was taken down in any way, and either do the same if no buff was triggered or ignore the tag then. Alternatively, the ability to put the triggering effect in the buff itself and tying it to its remaining turns, via a 'triggerOnBuffTime="[value]"' tag with possible values of anything above 1 and the default value being 1. Either option would be welcome, albeit the first one has more potential for being useful due to all buffs having fixed durations (and thus them doing virtually the same thing, spare for the first one also working on buffs without timers); not to mention the latter likely taking more time to implement. Reason: Right now it is possible to create something close to it via use of "requirebuffontrigger" tag. However, it is not perfect - if the required buff is taken away but triggered back before the spell which checks for it is triggered, then it will still work the same way it would if the buff was never taken down. Shortened reason: Would make abilities with cyclic/random changes via buff shifting viable. - - - - - 4. A way to make an equipped item which triggered an effect disappear Explanation: A pair of tags: 'destroyOnSpellTrigger="[value]"' tag, with possible values of "0" and "1" and the default value being "0", and 'destroyOnSpellTriggerName="[value]"' tag, with possible values being any names of spells existing in any "spellDB.xml" file, added as a parameter to "playerHitEffectBuff" and "targetHitEffectBuff". The tags, if set to "1" and a name of an existing spell, would cause the item to be destroyed if it triggered an effect and the spell with the given name was triggered as an effect of that. Reason: With such an effect it would be possible to make items which would, given correct conditions, apply additional effects and then get destroyed. Amulets which heal the player under certain conditions (and here I point back to my second point), "vegan" swords which hurt you and disappear the moment you kill an animal with them, armour pieces which fall apart when hit too many turns in a row, these would all become possible if this was implemented. Of course, out of every single thing I asked for this one is the most time-consuming (or at least close behind the third point) to add, even if only because it is doubtful that the game keeps track on which spells exactly were triggered, which means the whole thing would have likely have to be coded in almost from scratch. Still, I am hopeful you'll be able to add it. Shortened reason: Making condition-based "usable" weapon, armour, and amulet/ring equips.
Add all of the Suggestions, and make sure you REMEMBER to update the Dredmod Wiki as well as the Online XML Validator. You don't have to do it right away, you can do it when you have time for it. I'm willing to adapt to new mod mechanics as long as I have tutorial references that come soon after.
More suggestions! 10. Ways to make something trigger only on a certain dungeon/player level, or with certain stats (or even with certain items, which'd even be better cause it wouldn't only give us actual _itemset_ code, but it would work with _anything_ involving items..). HTML: <spell name='foo' type='self'> <trigger name='shoo' requireItemOnTrigger='1' requireItemOnTriggerName='Bronze Greaves'/> </spell> <spell name='shoo' type='self'> <trigger name='hoo' requireDungeonLevelOnTrigger='1' ----------etcccc </spell> <spell -------- <trigger name='goo' requireStatOnTrigger='7' requireStatOnTriggerLevel='100' </spell> <spell -------- <trigger name='boo' requirePlayerLevelOnTrigger='1' ----------------etccccc </spell>
I'd pay for expanded modding. There's a lot of stuff that I'd really like to be able to do: -Create room objects that act like levers bit don't look like them -Designate blockers that are passable by flying creatures but not by walking creatures -Call for a type of object rather than a specific object in room scripts (ie. ANY Rune of Pillars, rather than THIS Rune of Pillars) -Dedicated symbols in rooms.xml for vending machines, bbqs, fridges, and fountains -Ability to add things like counterBuffs, blockBuffs and thrownBuffs, crossbowShotBuffs, targetHitEffectBuff, (etc.) with encrusts rather than (or in addition to) the currently supported special powers of ambiguous activation method. -ability to make spells that create actual, non-temporary dungeon walls that match the current level's decor -ability to use <palette tint> on items -more operations on the coloration of monsters other than <palette tint>, in particular the ability to invert the color scheme, and the ability to do what is referred to in GIMP as Colorifying
