If you wanted them to be separate from ordinary chest pieces, you would need to create new item type in items/types.txt. You would then need to update the inventory menu so that there's a place to equip them. Finally, if you wanted player animations for the new item slot, you would need to update engine/hero_layers.txt to define where in the draw order the new layer sits for each of the 8 directions.
I would consider this out-of-scope for Flare. I don't think the difficulty of implementing it is worth the payoff. Challenges I see are:
On the art side, a new "swing" animation would need to be created for each piece of equipment. This would also need to be done for all parts of the player character, not just the weapons + arms as you might think. We also don't have anyone that could be dedicated to such a workload of new art.
On the engine side, items are currently restricted to a single slot type. A lot is based off this assumption, such as how we manage draw order for the player's body parts. So this restriction is not easily bypassed.
On the game data side, while it is possible to create "combo" attacks that switch up the animations with each consecutive attack, it's a bit convoluted and adds some complexity to the power definitions. I guess this is the smallest of the potential problems.
There's also the issue of balance. We'd need a way for modders to define stat modifications for when the player is dual wielding.
Yes, that is certainly a concern. The numbers we'd be dealing with a quite small (most are less than 2^8), so I think we'd have the precision we need. We could do fixed point math if we super strict about accuracy here, but I don't think it would be necessary.
Flare's mod files are meant to be human-readable, so in the places we do use floats, they are in decimal format. This is mostly a one-way street, since I think the only place the engine writes floats to a file is when saving the player's X/Y position.
@WithinAmnesia
I'd start with everything that's represented as a percentage, so speed would be included.
Noted. We added support for fractional percentages for loot drop rates, so it would makes sense to do the same wherever we use percentages.
More broadly speaking, I think it would be beneficial to use floating point numbers for all stats where possible. This would help us avoid cases where we need a second internal variable to track the "real" value of a stat versus its integer display value.
I think an approach that might work is to have the summoned creature cast a constant AOE power to apply the debuff to the player for a short period per "hit". An example of such an AOE power would be the "minotaur force field hazard" from the empyrean_campaign's enemy powers.
If you wanted them to be separate from ordinary chest pieces, you would need to create new item type in items/types.txt. You would then need to update the inventory menu so that there's a place to equip them. Finally, if you wanted player animations for the new item slot, you would need to update engine/hero_layers.txt to define where in the draw order the new layer sits for each of the 8 directions.
I would consider this out-of-scope for Flare. I don't think the difficulty of implementing it is worth the payoff. Challenges I see are:
This is definitely a hole in the mod API.
Both EnemyGroup and NPC map objects should have the same requirement properties as Events, which includes:
Consider it added to the TODO list.
@skeletonzombie
Yes, that is certainly a concern. The numbers we'd be dealing with a quite small (most are less than 2^8), so I think we'd have the precision we need. We could do fixed point math if we super strict about accuracy here, but I don't think it would be necessary.
Flare's mod files are meant to be human-readable, so in the places we do use floats, they are in decimal format. This is mostly a one-way street, since I think the only place the engine writes floats to a file is when saving the player's X/Y position.
@WithinAmnesia
I'd start with everything that's represented as a percentage, so speed would be included.
Noted. We added support for fractional percentages for loot drop rates, so it would makes sense to do the same wherever we use percentages.
More broadly speaking, I think it would be beneficial to use floating point numbers for all stats where possible. This would help us avoid cases where we need a second internal variable to track the "real" value of a stat versus its integer display value.
Sounds like a reasonable request. There's actually some bugs with negative regen right now, so this would be a good opportunity to fix them.
Have you looked at the For Modders section of the wiki yet? A good place to start is Creating an Empty Mod, followed by Creating a Map in Tiled.
I've made an example mod that adds a Goblin npc to Perdition Harbor that you can have follow you:
https://drive.google.com/file/d/10eDae1JO_O4p6pXM2QhEt1F9OTOETpSd/view?u...
But I noticed a glaring bug: enemies will never target NPC followers, so NPC followers roam around uncontested.
I think an approach that might work is to have the summoned creature cast a constant AOE power to apply the debuff to the player for a short period per "hit". An example of such an AOE power would be the "minotaur force field hazard" from the empyrean_campaign's enemy powers.
For the Empyrean campaign specifically, each item type has a base price, which is then multiplied by the item's level. The base prices I used can be seen here: https://github.com/flareteam/empyrean_itemdef/blob/master/itemdef_prices.py
Pages