I have no idea how it works, to be honest. How is it calculated? Can I, as a modder, control/tweak punchwear in any way? Haven't found anything in lua_api.txt yet.
Search for punch_attack_uses in the documentation.
Linuxdirk wrote:Yes. The coordinates are now different, but not necessarily better/cleaner if you have complex formspecs. I recently converted all mTimer formspecs to version 2 coordinates and it was just replacing one mess with another mess.
But, it's consistent. No more guess-and-check. That's the real reason I made it. I considered adding automatic padding, but the PR was taking forever as it was and I decided that you can use containers for that.
Linuxdirk wrote:Yeah :( Still no scrollable inventories or button lists. Only super weird scrollbars no-one understands.
So I can simply add, let’s say, a 20*70 large inventory in a 4*6 large container and get automatically scrollbars so players can scroll around this absurdly large inventory I just made up for the example?
Linuxdirk wrote:So I can simply add, let’s say, a 20*70 large inventory in a 4*6 large container and get automatically scrollbars so players can scroll around this absurdly large inventory I just made up for the example?
It's so you can have a 5*70 inventory in a 5*6 inventory. Having two axes of scrolling is a terrible idea, this would be more for creating custom list-like elements. I plan to use it in my menu redesign to list games with screenshots and such
rubenwardy wrote:It's so you can have a 5*70 inventory in a 5*6 inventory. Having two axes of scrolling is a terrible idea,
Of course it is. Except 2-axis scrolling being a terrible idea: would it – in theory – possible? Or in other words: Are we limited to up-down scrolling or are interfaces with left-right scrolling are possible, too?
rubenwardy wrote:this would be more for creating custom list-like elements. I plan to use it in my menu redesign to list games with screenshots and such
Almost everything benefits from this. All craftguides would greatly improve if they do not have to re-implement pagination all the time. All inventory lists would benefit from it for the same reason. Even Minetest Game creative inventory would benefit from it.
Both horizontal and vertical are possible at the same time. If I remember correctly, you have to place one scroll_container within another and bind it to two scrollbars, but it might be possible with only one.
And as for guess-and-check, I meant you know that a button at (1,1), a field at (1,1), or a dropdown at (1,1), etc., it will be in the exact same place, as well as things like normal buttons, tab bars, and dropdowns having changeable heights. So no guess-and-check basically means that you don't have to guess and add and subtract weird coeffiecients and use multiplication just to get your button in line with your field.
v-rob wrote:So no guess-and-check basically means that you don't have to guess and add and subtract weird coeffiecients and use multiplication just to get your button in line with your field.
This is exactly what I had to do. Just with different coordinates like before.
Linuxdirk wrote:
This is exactly what I had to do. Just with different coordinates like before.
This isn't true, the coordinates are all exactly the same on different elements meaning that using the exact same cooridinates will place a button inline with a field.
I would like to add containers which automatically do padding and stacking for you, as manually adding 0.375 padding and 0.25 spacing isn't very fun. But the new system is a great improvement on the old
Forgive the noob question, but is the copy of minetest provided in the 1st post's links using LuaJIT with the GC64 variant? I don't know how to check this myself...
v-rob wrote:They most definitely have consistent coordinates now.
I never said they have not, but you had a look at my code, right? It’s better overall with the coordinates, but still messy. At least I was able to eleminate all 3 digit decimals.
ShallowDweller wrote:Forgive the noob question, but is the copy of minetest provided in the 1st post's links using LuaJIT with the GC64 variant? I don't know how to check this myself...
Yes, since 5.0 the official builds come with gc64-enabled LuaJIT.
What kinds of mods got broken with this new version? And how long do we have before depends.txt is no longer accepted by the engine? Thanks in advance (so I won't get paranoid about not having posted a reply to just say "thanks" without adding anything to the discussion)
sfan5 wrote:
ShallowDweller wrote:Forgive the noob question, but is the copy of minetest provided in the 1st post's links using LuaJIT with the GC64 variant? I don't know how to check this myself...
Yes, since 5.0 the official builds come with gc64-enabled LuaJIT.
ShallowDweller wrote:What kinds of mods got broken with this new version? And how long do we have before depends.txt is no longer accepted by the engine? Thanks in advance (so I won't get paranoid about not having posted a reply to just say "thanks" without adding anything to the discussion)
No mods were intentionally broken as this isn't a breaking release. The next breaking release will be called 6.0.0, if it happens. Note that the exception to this are experimental APIs, such as client-side modding, which aren't officially supported yet so can be broken at anytime
Depends.txt will be supported for a very long time, and can't be removed before 6.0.0 anyway as it is a breaking change
ShallowDweller wrote:What kinds of mods got broken with this new version? And how long do we have before depends.txt is no longer accepted by the engine? Thanks in advance (so I won't get paranoid about not having posted a reply to just say "thanks" without adding anything to the discussion)
No mods were intentionally broken as this isn't a breaking release. The next breaking release will be called 6.0.0, if it happens. Note that the exception to this are experimental APIs, such as client-side modding, which aren't officially supported yet so can be broken at anytime
Depends.txt will be supported for a very long time, and can't be removed before 6.0.0 anyway as it is a breaking change
I see... good to know. Thanks!
Aaand good luck to the CSM developers.
I suppose there are major changes made concerning depth where different ores appear.
Iron cannot be found over ca. -100. I could not find any diamond and mese though I dig currently at -350.
I chose the valleys mapgen. Maybe it's because of this, or is the depth the same in all mapgen? This is what I thought so far.
Can anyone tell me the current depths since when the different ores occur?
Nordal wrote:I suppose there are major changes made concerning depth where different ores appear.
[...]
Can anyone tell me the current depths since when the different ores occur?
Ah, cool, thanks, Hamlet. Exactly the infos I was looking for!
I like the idea of an EDIT: in-game /EDIT ore_info. A really inventiv mod. At first brief insight the data seems to be not in any case 100% corresponding to the mapgen list's data. Minor mistakes, if at all.
Last edited by Nordal on Wed Dec 11, 2019 07:09, edited 1 time in total.
Nordal,
In all mapgens except V6, many ores are deeper, many are twice as deep. The depths were also rationalised in several ways and are now in order of ore value.
Depths do not depend on what biome you are in. However, there are no ores in desert stone and sandstone, which extend to roughly y = -256.
Mapgen V6 has unchanged ore depths.
In that mapgen.lua file of MTGame, keep in mind there are 2 ore registration sections, one is for mapgen V6.
Thank you, paramat, for your infos. It just makes more sense to have indications where to search ores. And I definitely realized now that V6 is a special case. :)