add 1.20 armor trims #3784
No reviewers
Labels
No Label
#P1 CRITICAL
#P2: HIGH
#P3: elevated
#P4 priority: medium
#P6: low
#Review
annoying
API
bug
code quality
combat
commands
compatibility
configurability
contribution inside
controls
core feature
creative mode
delayed for engine release
documentation
duplicate
enhancement
environment
feature request
gameplay
graphics
ground content conflict
GUI/HUD
help wanted
incomplete feature
invalid / won't fix
items
looking for contributor
mapgen
meta
mineclone2+
Minecraft >= 1.13
Minecraft >= 1.17
missing feature
mobile
mobs
mod support
model needed
multiplayer
Needs adoption
needs discussion
needs engine change
needs more information
needs research
nodes
non-mob entities
performance
player
possible close
redstone
release notes
schematics
Skyblock
sounds
Testing / Retest
tools
translation
unconfirmed
mcl5
mcla
Media missing
No Milestone
No project
No Assignees
9 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: VoxeLibre/VoxeLibre#3784
Loading…
Reference in New Issue
No description provided.
Delete Branch "armor_trims"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This pull request adds the Minecraft 1.20 armor trims to mineclone
Note
This pull request changes A LOT of files, however, most of them are textures (59), as well as one line changes in loot tables etc
To be done
Only apply to one piece of armor
add templates
add template "duplication" recipie
alter smithing table
add color support
add inventory image
remove from creative inventory
fix itemstring of enchanted itemsset enchanted variant to trimmedmove mcl_armor_trims into mcl_armor
resolve merge conflicts
Testing
Thanks to @cora for providing the texture of the "trim shadow" used in the smithing table
WIP: add 1.20 armor trimsto add 1.20 armor trimsI just started testing this, and I noticed the following images can be optimized for a lower file size.
For everyone else testing, some extra info:
done :)
Thanks for raising the PR. Added a few items of feedback.
@ -0,0 +2,4 @@
local S = minetest.get_translator(modname)
for _, template_name in pairs(mcl_armor_trims.overlays) do
minetest.register_craftitem(modname .. ":" .. template_name, {
This string append is done 3 times: modname .. ":" .. template_name
It might be better to append in a local variable, and use that. Makes it easier to debug too.
I think you've done this in other places, but not here in this for loop. In the for loop there are 3 references, so that is logically where a local variable could be used for that.
@ -7,3 +7,3 @@
-- Function to upgrade diamond tool/armor to netherite tool/armor
function mcl_smithing_table.upgrade_item(itemstack)
function mcl_smithing_table.upgrade_item_netherite(itemstack)
Why are you renaming a public function? If a mod is using upgrades, it could break it, and I think there is one that does upgrade items.
While I didnt change the name back (due to it being misleading now), I've added a function with the old name for legacy mods... It just calls the new one
That works, and is clear. Good call.
@ -54,0 +59,4 @@
if(string.find(material_name,"mesecons:")) then
material_name = "redstone"
else
material_name = material_name:gsub("_ingot","")
I see what you're doing here, and it may work now, but if for example, an item moves from it's current mod to a new mod, it would break this in a way that may be quite tricky to diagnose. It may be better to use a map to map the name to the to expected string and that way, when something gets renamed (like mesecons could to a mcl specific mod), it will be easier to find in search.
Maybe look at how I redid the smithing table upgrading here https://codeberg.org/PrairieWind/mcl_upgraded_smithing_table/src/branch/master/smithing_table.lua and here https://codeberg.org/PrairieWind/mcl_upgraded_smithing_table/src/branch/master/items.lua.
At first I wanted to do it similar to string.split...
When I read your comment, I was thinking about using string.gmatch to get a substring after the first ':' character, but now, I've just used the array
@ -54,0 +77,4 @@
end
local function is_smithing_mineral(itemname)
if itemname == "mcl_nether:netherite_ingot"
Based on the above comment, if this is a table, you can simply check this is a value in there, and return true if it is.
Where did the image assets come from? What's the license on them?
Edit: Answer via Discord. PP and altered to match our models
I just noticed that the
optipng
command we recommend preserves the metadata, which we actually want out of our textures. :P So I added "-strip all" for a better optimization, and updatedTEXTURES.md
in PR #3806.Example:
That's quite a significant change - I should've tested this earlier. :)
P.S. I attached the optimized textures.
0bf9b691bb
toa159717f18
a159717f18
to9d1840f4ca
Sorry for force-pushing 2 times in a row, what I just did altered some files that it wasn't supposed to, others were reduces in filesize (like intended), and some even increased, thats why I went back to that commit
ae0a14b102
tod346aa07ee
I think it would be better to implement the armor trims without registering new items. We can already use functions in item defs to dynamically determine the player armor textures (I asked @LizzyFleckenstein03 for it with this kind of stuff in mind).
We will be able to update the item image with its metadata in 5.8, so I think we should build a
tt
like way of updating item images using callbacks like we do for complex tooltips already.IMO even the
*_enchanted
items should go away in favor of a similar approach (allowing to enchant any item like mc with commands)if we break compatibility with old worlds completely, maybe for Minetest next breaking release?
https://github.com/minetest/minetest/pull/12614
Armor trims are a feature I like and I hope to see them soon :)
Exemple of using mcl2 functions to update player armor with functions: https://github.com/minetest-palamod/palamod/blob/master/pala_grade/paladium_skin.lua
I personally disagree with breaking world compatibility! There are tons of worlds and servers that are actively played since like the project's inception, and there just HAS to be a way for those to go on...
Regarding the itemmeta thing, yes, i know thats possible in minetest 5.8, but I don't think it's time to drop support for 5.7 yet either! Also, again if you want that sort of style everywhere, have fun with all the alliases, which also need to set metadata properly in order for the item to work
IMO what should be done is implement armor trims the same way as banners (without really matching inventory icons) and then implement these icons using Minetest 5.8 API later.
What I meant by "breaking world compatibility" is Minetest making a breaking release making old worlds no longer load at all without using a converting script (no realistic possible in-game conversion code).
I don't think is on Minetest, it is on us, and we try to support old worlds as much as possible. We support the last 2 releases, so wouldn't use 5.8 code until 5.9 is out, so this is far in the future.
I don't know the inner workings of banners, but we have an existing PR, and there was a few issues flagging with either the item string or description that make me somewhat hesitant to be confident in this design.
I think chmodsayshello's solution is the best solution we have for now, and from a code perspective, I will approve it once we've validated assets. If this gets reworked next year after 5.9, I'm happy for us to discuss it then.
Added media missing beacuse ALL the textures (except the ones ending with
smithing_template.png
) need a replacement under a compatible licenseJust checked Minetest API documentation and its actually much easier than delaying the support.
Changing the inventory icon of an item just use a specific metadata field, so its completely "backward compatible" for both the server and the clients. Clients will need upcomming 5.8 to get the fancy inventory icon, clients with 5.6/5.7 will still have the tooltip description to rely on, and server can be 5.6/5.7/5.8.
5.8 release will land in less than a month so we will quickly get one of our two officially supported version able to support this feature.
https://github.com/minetest/minetest/blob/master/doc/lua_api.md#item-metadata
@AFCMS if so, does that apply to archaeology as well? I'll quote wsor here:
I might get it implemented and merged faster if that's true :D
https://git.minetest.land/MineClone2/MineClone2/src/branch/archaeology
I don't really know since the inventory images for the pots are 3D, not flat file images.
Can you document the following for the assets:
Ideally anyone should be able to find this information in the future. I've struggled to find assets that weren't fully documented. Mod readme is probably the best place for this.
In the past I would've agreed, however, due to textures no longer being contained inside mods themselves, I'd prefer the central credits document
add 1.20 armor trimsto WIP: add 1.20 armor trims@ -0,0 +15,4 @@
_mcl_armor_texture = function(obj, itemstack)
local overlay = itemstack:get_meta():get_string("mcl_armor_trims:trim_overlay")
local old_armor_texture = mcl_armor_trims.old_textures[itemstack:get_name()]
if type(old_armor_texture) == "function" then
i am aware that this condition is never true, I'll change that when "merging" the mod with mcl_armor
WIP: add 1.20 armor trimsto add 1.20 armor trimsCool
maybe you should add a remark that an item is trimmed in the item meta description field so you can see it in inv
but otherwise looks like it works
I really like this feature, thanks for implementing it 👍
BLOCKERS:
Armor trims doesn't handle enchantments at this point.
I tried enchanting a trimmed armor chestplate with a book in an anvil. The item didn't have any shiny overlay, and keep crashing when you equip the armor.
More explanation in the review.
COULD HAVE:
Currently, nothing indicate which armor trim is present on an armor item in its tooltip. It can be implemented using
tt.register_snippet()
like enchantments.The overlay on the inventory images is the same for all armor trims. I don't think its mandatory to have a different image for each armor trim since it represent a good amount of additional textures to do but it would be nice to have.
@ -85,6 +85,22 @@ function mcl_armor.equip_on_use(itemstack, player, pointed_thing)
return mcl_armor.equip(itemstack, player)
end
local function get_armor_texture(textures, name, modname, itemname, itemstring)
The function have to handle the enchantment overlay on the player.
Like this:
fc5079258c/pala_grade/paladium_skin.lua (L37-L59)
@ -88,0 +91,4 @@
mcl_armor.trims.core_textures[itemstring] = core_texture
local func = function(obj, itemstack)
local overlay = itemstack:get_meta():get_string("mcl_armor:trim_overlay")
local core_armor_texture = mcl_armor.trims.core_textures[itemstack:get_name()]
core_armor_texture
is undefined for enchanted items itemstrings.Should check if the item is enchanted and take the unenchanted version of the itemstring if needed.
@ -260,0 +306,4 @@
meta:set_string("inventory_image", def.inventory_image .. inv_overlay) -- dont use reload_inv_image as it's a one liner in this enviorment
end
function mcl_armor.reload_trim_inv_image(itemstack)
Inventory image doesn't handle enchantment overlay.
It should check if the itemstack is enchanted and reapply it (since enchanted items have separate itemstrings, their overlays are hardcoded in the item def, so this function override them completly)
@ -0,0 +1,46 @@
local mod_registername = minetest.get_current_modname() .. ":"
local S = minetest.get_translator(modname)
modname
is undeclaredsnippets only provide the itemstring, while this is a meta dependent story, gonna try
_mcl_generate_description
b66a16f819
to49bd28e109
can confirm the enchanting crash is fixed and enchanting trimmed armor and trimming enchanted armor works
On top of the license problems, one of the trims (sentry) resembles the MC texture too closely IMHO.
Either you contact the pack author and ask for publication of an explicit Creative Commons license, or we have to make our own textures... even I could make some stuff tbh.
Also, I'd like to see prismarine and glowstone trims, too. And golden trim should be darker.
@ -44,1 +44,4 @@
Armor trim models were created by Aeonix_Aeon
Source: <https://www.curseforge.com/minecraft/texture-packs/ozocraft-remix>
License: [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
The license is certainly not CC-BY. It's a pinky promise license, that can at most be interpreted as CC-BY-NC, which gets flagged on CDB. However, it's not even that.
All the stuff from the checklist works, can confirm.
It seems there are two licenses, the CC-BY is indeed there and is valid.
Considering other problematic textures and stuff, the sentry texture is not that big of a problem.
Comment from Discord:
"John Smith Legacy and Faithful 32 textures are used to fill in blanks"
https://www.curseforge.com/minecraft/texture-packs/faithful-32x has a custom licence
no idea what license this is: https://texture-packs.com/resourcepack/john-smith-legacy/
do we know where these textures originated?
the author won't have permission to relicense art, so the cc license will just be for their creations
License clarification needed
@chmodsayshello ItemStack is passed as the third parameter.
b4c693bb20/mods/HELP/tt/init.lua (L26)
https://github.com/minetest-palamod/palamod/blob/master/pala_legendary/endium_gauntlet.lua#L41-L61
New commits pushed, approval review dismissed automatically according to repository settings
cb196c5076
tod5522111c7
force pushed to remove the "b" I added by accidient while resolving the merge conflict
It is CC, the textures used in mcl2 have all been made Aeonix_Aeon
3cd98a0c1e
to8936313fb3
Force pushed as there were still some issues related to the cherry pick, made cora's change myself at
4046a68fbf
in MineClone2 historyWorks, good job 👍
The tooltip indications for the applied trim could be a different color from the base green one so it can be a bit easier to notice, but thats a minor problem IMO.
Thanks for the PR, chmodsayshello. Thanks for reviewing, @AFCMS