Conversation
plugins/civmodcore-paper/src/main/java/vg/civcraft/mc/civmodcore/config/ConfigHelper.java
Show resolved
Hide resolved
| version: ${version} | ||
| depend: [ CivModCore ] | ||
| softdepend: [ CivMenu, NameLayer, Citadel, Heliodor ] | ||
| softdepend: [ CivMenu, NameLayer, Citadel, Heliodor, EssenceGlue, Bastion, HiddenOre ] |
There was a problem hiding this comment.
I guess this is more of a future issue, should items be registered by plugins or should we register them in CMC? FM will get chaotic with soft depends
There was a problem hiding this comment.
I'd love to move it all to CMC, same with the migration stuff, I just didn't want to rock the boat any more then I already am with this pr
There was a problem hiding this comment.
Agree, I guess the other alternative would be maybe a CustomItems plugins that plugins can depend on but depends on thoughts @okx-code
There was a problem hiding this comment.
Only issue here, is it possible to make the custom item config driven
There was a problem hiding this comment.
I think so, but it would only get us so far. For very basic items like bastions and essence, which purely are just 'cosmetic' custom items, yea. For stuff like heliodor, I have no idea how you could even apply the block rules for example from a config without it getting messy fast. IMO, having it in the code is better, especially because these are supposed to be registered before any config loading is done since they can technically be used anywhere in the config.
plugins/factorymod-paper/src/main/java/com/github/igotyou/FactoryMod/FactoryMod.java
Outdated
Show resolved
Hide resolved
Diet-Cola
left a comment
Diet-Cola
left a comment
There was a problem hiding this comment.
Overall solid, downside is losing config driven custom items however this allows us to go further down the line. More worried about dependency stuff down the line if we stay with this approach however as mentioned in the comment
| ((loc.getBlockX() - location.getX()) * (float) (loc.getBlockX() - location.getX()) + | ||
| (loc.getBlockZ() - location.getZ()) * (float) (loc.getBlockZ() - location.getZ()) >= type.getRadiusSquared())) | ||
| ); | ||
| (type.isSquare() && (Math.abs(loc.getBlockX() - location.getBlockX()) > type.getEffectRadius() || Math.abs(loc.getBlockZ() - location.getBlockZ()) > type.getEffectRadius())) || (!type.isSquare() && ((loc.getBlockX() - location.getX()) * (float) (loc.getBlockX() - location.getX()) + (loc.getBlockZ() - location.getZ()) * (float) (loc.getBlockZ() - location.getZ()) >= type.getRadiusSquared()))); |
There was a problem hiding this comment.
why remove the formatting that made this readable?
There was a problem hiding this comment.
Yea your right, auto formatting error. I'll try and force the formatter to ignore.
|
It might be worth adding an item-tagging system while you're at it which would add an easy means to tag an item as compacted or as wordbanked. It could be as easy as storing a set of strings, that way testing for wordbank is just checking for the presence of |
|
A tag system probably is a better idea, I'm just not sure how too effectively handle the custom model data for example any differently. My current idea for it is to just add strings to a pdc. Would work great for wordbank stuff, but for compacted items, you just need to hope people use the compacted item method instead of checking the pdc manually. |
4 participants
Reworks the custom item interface as well as adds support for custom textures. Additionally, it migrates more custom items to proper custom items, for better fm config usability, plus removing the need to match items purely based on lore.
Fixes #737