| Time |
Nick |
Message |
| 01:07 |
|
calcul0n joined #minetest-dev |
| 04:02 |
|
Taoki joined #minetest-dev |
| 08:38 |
|
ShadowNinja joined #minetest-dev |
| 08:42 |
|
fluxflux_ joined #minetest-dev |
| 09:42 |
|
Beton joined #minetest-dev |
| 09:42 |
|
df458 joined #minetest-dev |
| 10:21 |
|
erlehmann joined #minetest-dev |
| 10:36 |
|
proller joined #minetest-dev |
| 10:49 |
|
Fixer joined #minetest-dev |
| 12:37 |
|
calcul0n joined #minetest-dev |
| 13:17 |
|
nepugia joined #minetest-dev |
| 14:24 |
|
absurb joined #minetest-dev |
| 14:44 |
|
Andrey01 joined #minetest-dev |
| 14:46 |
|
erlehmann joined #minetest-dev |
| 15:19 |
|
nepugia joined #minetest-dev |
| 15:40 |
|
fluxflux_ joined #minetest-dev |
| 16:31 |
|
proller joined #minetest-dev |
| 16:59 |
|
calcul0n_ joined #minetest-dev |
| 17:23 |
|
proller joined #minetest-dev |
| 17:27 |
|
DS-minetest joined #minetest-dev |
| 18:16 |
|
DS-minetest joined #minetest-dev |
| 18:20 |
|
calcul0n__ joined #minetest-dev |
| 18:36 |
|
Wuzzy joined #minetest-dev |
| 19:19 |
|
calcul0n joined #minetest-dev |
| 19:40 |
Krock |
rubenwardy: easy fix #9392 |
| 19:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/9392 -- guiHyperText: Fix blinky cursor on link hover by SmallJoker |
| 19:41 |
|
calcul0n joined #minetest-dev |
| 19:42 |
Krock |
#9458 looks dangerous to me. Mods that don't check for it, or user input for unknown nodes could result in a server shutdown |
| 19:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/9458 -- minetest.get_content_id: error on unknown node by HybridDog |
| 19:45 |
Krock |
hmm.. but that's still better than the old side-effects where fire spawned on invalid nodes |
| 19:56 |
Krock |
plantlife modpack, mg and ethereal work. No problem then. |
| 19:56 |
|
sys4 joined #minetest-dev |
| 20:03 |
Krock |
Wuzzy: https://github.com/minetest/minetest/issues/9481#issuecomment-596716008 ??? |
| 20:04 |
Wuzzy |
!!! |
| 20:04 |
Krock |
the bug is clearly gone if you revert that commit |
| 20:04 |
Wuzzy |
wait, what? |
| 20:04 |
Wuzzy |
ohhhhhh, its not in the repo yet?! loool |
| 20:05 |
Krock |
no? it would be nonsense, especially because the PR author is active |
| 20:05 |
Wuzzy |
i didn't follow the bug too closely tbh... |
| 20:06 |
Wuzzy |
ok if you already worked out a solution, great ^^ |
| 20:06 |
Wuzzy |
oh this reminds me |
| 20:07 |
Wuzzy |
in MCL2 the creative tabs look different and uglier in -dev now. not reported so far... |
| 20:07 |
Krock |
probably due to the style changes |
| 20:08 |
rubenwardy |
please report with a screenshot :) |
| 20:08 |
Krock |
take the opportunity to style[]-fix them entirely |
| 20:09 |
Wuzzy |
compiling takes so long when you start from 0... |
| 20:09 |
Krock |
Wuzzy: 30 minutes on a Celeron D 346 |
| 20:10 |
Wuzzy |
ooofff |
| 20:10 |
Wuzzy |
ok its not THAT bad on my side at least |
| 20:11 |
Wuzzy |
Krock: well i shouldnt be required to make any changes to formspec, really. its still a regression, technically |
| 20:11 |
Wuzzy |
but on the other hand, formspecs are still in flux, sooooooo... |
| 20:11 |
rubenwardy |
mlc2 also crashes in latest dev because of use of get_connected_players |
| 20:11 |
Krock |
up to you. luck-based whether someone will fix it |
| 20:12 |
Wuzzy |
lol so you're ok with releasing with regressions? ? ... dont worry, bug report will arrive eventually |
| 20:12 |
Wuzzy |
what's wrong with get_connected_players? |
| 20:12 |
rubenwardy |
it can no longer be called during load time |
| 20:12 |
rubenwardy |
well, it can, but it returns nil |
| 20:13 |
Krock |
a quick fix would probably to return an empty table there |
| 20:13 |
Wuzzy |
ah, i see, so you are working hard on version 6 then, ? as its clearly a breaking release ? |
| 20:13 |
rubenwardy |
I don't like that change in behaviour |
| 20:13 |
Krock |
which would be compatible, but wrong |
| 20:13 |
Wuzzy |
btw what is the rule for bumping the 5 in "5.1.1"? |
| 20:14 |
rubenwardy |
breaking changes |
| 20:14 |
Wuzzy |
6.0.0 confirmed!!! ? |
| 20:14 |
rubenwardy |
undocumented and undefined behaviour doesn't count |
| 20:14 |
rubenwardy |
get_connected_players during load time is undefined |
| 20:14 |
rubenwardy |
apparently |
| 20:14 |
rubenwardy |
I don't like the player/object/entity API, it sucks |
| 20:14 |
Wuzzy |
why was get_connected_players changed anyway? whats the reason? |
| 20:14 |
rubenwardy |
a player should be separate to an object imo |
| 20:15 |
rubenwardy |
bug fixes |
| 20:15 |
rubenwardy |
sfan5 ^ |
| 20:15 |
rubenwardy |
<rubenwardy> a player should be separate to an object imo // as in, player:get_object() |
| 20:15 |
Wuzzy |
i don't understand |
| 20:15 |
sfan5 |
it was needed for something I planned to do and left in because it's generally a good idea |
| 20:15 |
sfan5 |
but you could revert it today and things would also work |
| 20:16 |
Wuzzy |
as i understand, its like this: the general thing is "object". and players and luaentities basically "inherit" from object (OOP-style). correct? |
| 20:16 |
rubenwardy |
an object is a moving thing in the world |
| 20:16 |
Wuzzy |
yes |
| 20:16 |
rubenwardy |
imo, a player should have an object but not be an object |
| 20:16 |
rubenwardy |
but this can't be changed |
| 20:17 |
Wuzzy |
why should it not be an object? o_O players are moving creatures |
| 20:17 |
Krock |
Players and Lua Entities share the common ObjectRef functions, and are inheritance-like |
| 20:17 |
DS-minetest |
but objects are abstract; player objects can't be moved arbitrarily |
| 20:17 |
Wuzzy |
yeah this really sucks indeed |
| 20:17 |
rubenwardy |
composition over inheritence, a player should have an object but the player itself (and associated methods like hud_add) should be a separate object |
| 20:18 |
rubenwardy |
the relevance of this is that the rationale for get_connected_players returning nil is because there is no environment at that time |
| 20:18 |
Wuzzy |
sounds like something for the wiki. "List of breaking changes" or whatever |
| 20:18 |
Wuzzy |
i doubt MCL2 is the only victim... |
| 20:18 |
rubenwardy |
it's not a breaking change formally |
| 20:19 |
rubenwardy |
but it does break things |
| 20:19 |
Wuzzy |
> * `minetest.get_connected_players()`: returns list of `ObjectRefs` |
| 20:19 |
rubenwardy |
and I disagree with the above rationale |
| 20:19 |
rubenwardy |
get_connected_players() returning an empty list does make sense, there are no players connected |
| 20:19 |
rubenwardy |
get_node() returning nil makes sense because there is no world |
| 20:19 |
DS-minetest |
suggestion: make get_connected_players() return {} on load time but also print a warning |
| 20:19 |
Wuzzy |
so just return an empty list then? |
| 20:20 |
rubenwardy |
https://rwdy.uk/G15EV.png |
| 20:20 |
Wuzzy |
thank you |
| 20:20 |
rubenwardy |
it's rendering with a border when it shouldn't be |
| 20:20 |
rubenwardy |
I wonder if the button element itself asks for a border? |
| 20:20 |
Wuzzy |
its not just the border... its the whole gray button thing |
| 20:20 |
rubenwardy |
the gray button is called a border |
| 20:20 |
rubenwardy |
it's a stupid irrlicht term |
| 20:20 |
DS-minetest |
if done correctly, get_node and co. should raise an error on load time, like register_* errors in runtime |
| 20:20 |
Wuzzy |
... |
| 20:21 |
rubenwardy |
which also appears in the API |
| 20:21 |
Wuzzy |
rubenwardy: so previously, these image buttons were just the icons, the rest was transparent |
| 20:21 |
Wuzzy |
rubenwardy: I also got a lot of MCL2 crashing due to set_sky changes ? |
| 20:22 |
sfan5 |
report a bug |
| 20:22 |
rubenwardy |
report two bugs |
| 20:22 |
Wuzzy |
... dont worry |
| 20:22 |
Wuzzy |
... later |
| 20:23 |
rubenwardy |
later sounds like forget |
| 20:23 |
rubenwardy |
:D |
| 20:23 |
Wuzzy |
anyway i am most happy with the new sky stuff |
| 20:24 |
Wuzzy |
finally sun and moon are *actually* texturable |
| 20:24 |
Wuzzy |
not just in texture pack ? |
| 20:25 |
rubenwardy |
I think the get_connected_players() change should be counted as a breaking change, as the method is documented in a "misc" section with no mention about not being available at load time |
| 20:25 |
Wuzzy |
i still dont understand. why not just return {}? thats a perfectly valid and logical return value (as no players are, in fact, connected? |
| 20:25 |
rubenwardy |
<rubenwardy> the rationale for get_connected_players returning nil is because there is no environment at that time |
| 20:26 |
|
df458 joined #minetest-dev |
| 20:26 |
Wuzzy |
well i disagree with the rationale |
| 20:26 |
Wuzzy |
this is just one more annoying special value we need to check then |
| 20:26 |
rubenwardy |
df458: <rubenwardy> https://rwdy.uk/G15EV.png |
| 20:26 |
sfan5 |
there's still opportunity to change it you know |
| 20:26 |
Wuzzy |
{} for implicity |
| 20:27 |
Wuzzy |
yes but I'm afraid everyone is opposed |
| 20:27 |
Wuzzy |
simplicity* |
| 20:27 |
Wuzzy |
rubenwardy: fun fact: I still did not use formspec_version 3 to this day... |
| 20:27 |
rubenwardy |
:'( |
| 20:28 |
Wuzzy |
transforming the coordinates from old to new is a herculean task |
| 20:28 |
Wuzzy |
the "fun" part of the fact is because i was one of the strongest proponents of consistent coords... |
| 20:28 |
rubenwardy |
I think you can do `formspec_version[3]size[1,1]real_coordinates[false]` |
| 20:28 |
rubenwardy |
I didn't say that |
| 20:28 |
Krock |
you also don't need formspec_version 3 unless there are changes in the parameter count of elements and you want to keep it backwards compatible |
| 20:29 |
Wuzzy |
in fact, i never asked for the coord system to be *compleely* reworked. i only wanted that all formspec elements use the same system |
| 20:29 |
Wuzzy |
i find it MUCH harder to build formspecs in version 3 tbh |
| 20:29 |
rubenwardy |
I find it much easier |
| 20:29 |
Krock |
> i only wanted that all formspec elements use the same system |
| 20:29 |
Krock |
that's the same thing |
| 20:30 |
Wuzzy |
not exactly |
| 20:30 |
Krock |
without a rework this would not be possible |
| 20:30 |
Wuzzy |
one of the existing systems could have been kepts |
| 20:30 |
Wuzzy |
but all old systems were thrown away, so theres 0 compability |
| 20:30 |
Wuzzy |
which means i have 100% of the work :X |
| 20:30 |
Krock |
some were roughly kept, like inventory lists and button x/y positions IIRC |
| 20:31 |
Wuzzy |
new coord system isnt based on inventory slot sizes. |
| 20:31 |
Krock |
everything else just had any scaling factor |
| 20:31 |
rubenwardy |
the new coordinate system uses inventory slot sizes but not the padding or spacing |
| 20:31 |
Wuzzy |
what i like about version 1 is that i get the inventory slot offsets "for free". in version 3 i get nothing for free anymore, i have to start from 0 ? |
| 20:31 |
DS-minetest |
parseItemImageButton should probably just do e_btn->setDrawBorder(false); |
| 20:32 |
rubenwardy |
I plan to add elements to do padding automatically |
| 20:32 |
Wuzzy |
rubenwardy: btw is the distance between inventory slots a fixed number? |
| 20:32 |
Krock |
item image buttons don't have borders - do they? |
| 20:32 |
rubenwardy |
DS-minetest: it should use the correct default when there is no style |
| 20:32 |
rubenwardy |
Wuzzy: spacing=0.25xY padding=0.375x0.375 |
| 20:32 |
rubenwardy |
where Y is some value |
| 20:32 |
Wuzzy |
constant value? |
| 20:33 |
rubenwardy |
yeah |
| 20:33 |
Wuzzy |
k so this is hardcoded? |
| 20:33 |
rubenwardy |
padding=typically inset from formspec window edge, spacing=between elements |
| 20:33 |
Krock |
nvm, they do have borders |
| 20:33 |
rubenwardy |
yes, in formspec_version 1 |
| 20:33 |
Wuzzy |
no you dont understand |
| 20:33 |
Wuzzy |
i mean the distance between 2 inventory slots in the same inventory list |
| 20:33 |
Wuzzy |
i believe this can't be changed, right? |
| 20:33 |
rubenwardy |
it cannot |
| 20:34 |
Wuzzy |
ah |
| 20:34 |
rubenwardy |
there's a few PRs that need to be reworked to use styles |
| 20:34 |
Krock |
one inventory slot equals one grid unit |
| 20:34 |
Wuzzy |
but if i want to implement those v1 offsets, i have to manually hardcode this formula back into my formspec? :((((( |
| 20:34 |
Krock |
remove real_coordinates or convert your code |
| 20:34 |
rubenwardy |
yes |
| 20:35 |
rubenwardy |
however, the padding and spacing it gives you in formspec v1 isn't that helpful really |
| 20:35 |
Wuzzy |
well v1 sucks even more, i definitely WANT to have consistent coordinates |
| 20:35 |
Wuzzy |
but maybe i just didnt try hard enough so far |
| 20:35 |
rubenwardy |
I plan to have containers that handle padding and layouting |
| 20:35 |
Wuzzy |
what I probably need is is a script to convert v1 to v3 (at least the coords) |
| 20:36 |
Wuzzy |
doing that by hand is really painful... |
| 20:36 |
Wuzzy |
i tried. and almost became mad |
| 20:36 |
rubenwardy |
place buttons side-by-side with equal dimensions: stack[0,0;3,3;horizontal] button[0,0;0,0;one;One] button[0,0;0,0;two;two] stack_end[] |
| 20:36 |
DS-minetest |
other gui systems have many different kinds of containers |
| 20:36 |
rubenwardy |
yeah |
| 20:37 |
Wuzzy |
real games use a GUI library instead of rolling their own ... |
| 20:37 |
Krock |
rubenwardy: container[] |
| 20:37 |
Wuzzy |
Krock: i dont think thats the same |
| 20:37 |
rubenwardy |
naming things like stack_container[] gets verbose, but can be done |
| 20:38 |
DS-minetest |
container[] just moves; to have spacing like in invlists, you'd have to stretch everything i guess |
| 20:38 |
Krock |
oh, I get the point |
| 20:38 |
Wuzzy |
formspec_version[number] should be aliased to v[number] |
| 20:38 |
rubenwardy |
A stack layouter places its children in a stack - one after another in some directly, with optional padding. |
| 20:38 |
rubenwardy |
*direction |
| 20:38 |
Wuzzy |
formspec_version is a mouthful |
| 20:39 |
rubenwardy |
unfortunately, we can't rename it because otherwise older clients won't like it |
| 20:39 |
Wuzzy |
argh! |
| 20:39 |
Wuzzy |
yes, thats right |
| 20:39 |
DS-minetest |
you only have to write formspec_version once |
| 20:39 |
Krock |
luckily it already existed, otherwise this were a pure mess to implement |
| 20:40 |
Wuzzy |
what you mean? |
| 20:40 |
Wuzzy |
its not like we had formspec_version[] since the start. |
| 20:40 |
rubenwardy |
we did |
| 20:40 |
Krock |
we did |
| 20:40 |
Wuzzy |
?????? |
| 20:40 |
rubenwardy |
we've had that since formspecs were added |
| 20:40 |
DS-minetest |
it was just added automatically |
| 20:40 |
Krock |
it was just not exposed |
| 20:40 |
rubenwardy |
it was never incremented from 1 |
| 20:40 |
Krock |
:3 |
| 20:40 |
Wuzzy |
....... |
| 20:40 |
Wuzzy |
omg |
| 20:40 |
rubenwardy |
and also had bugs which made it impossible to use |
| 20:41 |
rubenwardy |
luckily those bugs are server-side |
| 20:41 |
rubenwardy |
other types of layouts include: frames (sets all children to equal the frame's position/size), grids (makes a table-like thing) wraps (wraps elements based on available space), constraint (super complicated equations) |
| 20:41 |
Wuzzy |
i see. so it was not exposed for good reason ? |
| 20:43 |
rubenwardy |
these layouters should probably wait until after #9358 |
| 20:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/9358 -- Formspec Refactor |
| 20:44 |
rubenwardy |
all of these also mean that I should probably finish #9189 |
| 20:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/9189 -- WIP: Add formspec rendering tests by rubenwardy |
| 20:56 |
Wuzzy |
hmm i just found this old "High Priority" security-vuln fixing PR: #8059... |
| 20:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/8059 -- Add fatal error on missing dependency by rubenwardy |
| 20:57 |
rubenwardy |
it's not really a security vulnerability and could break things |
| 21:01 |
Wuzzy |
you literally said "caused a security vulnerability on my server" |
| 21:01 |
rubenwardy |
doesn't mean it's a security vulnerability |
| 21:02 |
Wuzzy |
i dont understand how things could break by refusing to start with bad dependencies... |
| 21:03 |
Wuzzy |
so what about "High Priority"? is this wrong, too? ? |
| 21:04 |
rubenwardy |
I don't think it's high priority |
| 21:05 |
Wuzzy |
minetest has too many zombie PRs |
| 21:05 |
Wuzzy |
i.e. PRs that are kept alive for years but aren't going anywhere |
| 21:05 |
|
calcul0n_ joined #minetest-dev |
| 21:12 |
DS-minetest |
+ |
| 21:13 |
DS-minetest |
dev should not be kept stable |
| 21:33 |
|
GreenDimond joined #minetest-dev |
| 21:44 |
|
mizux joined #minetest-dev |
| 22:14 |
|
kilbith joined #minetest-dev |
| 22:14 |
kilbith |
I'd have renamed container[] to move[]; and scroll_container[] to container[] |
| 22:15 |
rubenwardy |
perhaps |
| 22:15 |
DS-minetest |
renaming would break backwards compatibility |
| 22:15 |
rubenwardy |
yeah |
| 22:16 |
rubenwardy |
I was planning on making `container[]` accept a size at some point, to do clipping and make it a real IGUIElement |
| 22:16 |
DS-minetest |
the weird thing with containers is that they dont clip |
| 22:16 |
rubenwardy |
which will clean up the offset code in GUIFormspecMenu |
| 22:16 |
rubenwardy |
snap |
| 22:16 |
rubenwardy |
with that change, you'd have a std::stack<IGUIElement*> |
| 22:16 |
rubenwardy |
and then not have any offset code when parsing - you'd just attach it to the current parent |
| 22:17 |
DS-minetest |
hm, but guielements still need their rect when they're drawn |
| 22:18 |
rubenwardy |
that comes from absolute rect stuff though right? |
| 22:18 |
DS-minetest |
it might be better if they just used their parents' relative rect |
| 22:18 |
rubenwardy |
it'll be the same as scroll containers, but without the scrolling |
| 22:29 |
sfan5 |
2020-03-09 23:29:32: ERROR[Main]: ...netest/bin/../mods/hunger_ng/system/interoperability.lua:26: attempt to call global 'file_exists' (a nil value) |
| 22:29 |
sfan5 |
^ Wuzzy I found one! |
| 22:30 |
Wuzzy |
ugh. why do people depend on undocumented features? ? |
| 22:31 |
Wuzzy |
remove file_exists anyway. make them suffer for their heresy ? |
| 22:34 |
rubenwardy |
lol |
| 22:41 |
sfan5 |
#9492 sounds like relying on buggy/implmentation-defined behaviour to me, so not worth fixing |
| 22:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/9492 -- Regression of image_button appearance |
| 22:51 |
rubenwardy |
how do I run my server in gdb such that I can automatically get backtraces? |
| 22:52 |
rubenwardy |
preferably sent to a bash command (I have a bash function to send me an email) |
| 22:52 |
rubenwardy |
related because I'm attempting to debug a few seg faults and std::bad_allocs on cTF |
| 23:03 |
sfan5 |
i had a script for that once five years ago |
| 23:03 |
rubenwardy |
yeah, I recall |
| 23:03 |
sfan5 |
probably something like gdb -x script.txt minetestserver |
| 23:04 |
sfan5 |
where script.txt does run --args --here and bt full and quit |
| 23:04 |
sfan5 |
and put that whole thing in a loop in bash |
| 23:04 |
rubenwardy |
ohh, that's what -x does |
| 23:04 |
rubenwardy |
https://serverfault.com/questions/61659/can-you-get-any-program-in-linux-to-print-a-stack-trace-if-it-segfaults |
| 23:16 |
rubenwardy |
it seems to be running all of the commands at once |
| 23:17 |
sfan5 |
at once? |
| 23:17 |
|
Sokomine joined #minetest-dev |
| 23:18 |
rubenwardy |
aha |
| 23:18 |
rubenwardy |
got it |
| 23:30 |
Wuzzy |
ugh |
| 23:30 |
Wuzzy |
the "border" style argument ought to be renamed. dont use stupid irrlich terminology, please |
| 23:31 |
Wuzzy |
renaming is still possible, i think. "border" was never in a stable release so far |
| 23:32 |
rubenwardy |
it has been in Minetest since 0.4.16 at least |
| 23:32 |
rubenwardy |
in the documentation at least |
| 23:32 |
rubenwardy |
and in the code since 5.1.0 |
| 23:33 |
rubenwardy |
s/code/api |
| 23:33 |
rubenwardy |
I've been meaning to rename it, it's possible to do so without breaking mods, but I'm not sure on a name |
| 23:34 |
Wuzzy |
style[] is new |
| 23:35 |
Wuzzy |
i mean "border" in style[] only |
| 23:35 |
rubenwardy |
style is in 5.1.0 |
| 23:35 |
Wuzzy |
thats "new" by minetest standards |
| 23:35 |
rubenwardy |
it is, but it's still a stable release |
| 23:35 |
rubenwardy |
but it's not that hard to fix |
| 23:36 |
Wuzzy |
oops |
| 23:36 |
rubenwardy |
I just couldn't decide on an apt name |
| 23:36 |
Wuzzy |
i see it now. border is not new ..... |
| 23:36 |
Wuzzy |
nvm |
| 23:36 |
Wuzzy |
i mostly ignored 5.1.0 style because it was incomplete |
| 23:36 |
rubenwardy |
it's WIP |
| 23:36 |
rubenwardy |
development is incremental |
| 23:37 |
Wuzzy |
in -dev it looks in a MUCH more useful state tho |
| 23:37 |
rubenwardy |
5.2.0-dev has had it massively extended, with the required GUI refactors necessary |
| 23:37 |
rubenwardy |
yeah |
| 23:37 |
rubenwardy |
the new buttons are awesome |
| 23:37 |
Wuzzy |
more stuff can be colorized thats a big one |
| 23:37 |
rubenwardy |
<3 9 slice buttons |
| 23:37 |
Wuzzy |
i am trying to make those work in MCL2 now |
| 23:37 |
Wuzzy |
buttons in mcl2 look just wrong atm ? |
| 23:38 |
Wuzzy |
9-slice buttons was one of Kenney's feature requests btw |
| 23:38 |
rubenwardy |
I know |
| 23:38 |
Wuzzy |
not that it matters anymore ... haha |
| 23:38 |
rubenwardy |
I implemented the feature because of him |
| 23:39 |
rubenwardy |
(the feature = 9 slice rendering, I didn't add it to buttons) |
| 23:39 |
rubenwardy |
(that was the button wiz) |
| 23:39 |
Wuzzy |
but its also a sensible feature to have, after all |
| 23:39 |
Wuzzy |
the idea is not new |
| 23:39 |
rubenwardy |
no, it's a common technique |
| 23:39 |
|
calcul0n joined #minetest-dev |
| 23:40 |
Wuzzy |
single-image buttons really don't scale well unless they are uber simple |
| 23:42 |
Wuzzy |
one thing that constantly annoys me about formspecs is that you must hand-draw the inv slots into the background if you want to use custom imgs... |
| 23:42 |
Wuzzy |
Pixture found a nice workaround for this, tho |
| 23:42 |
|
calcul0n joined #minetest-dev |
| 23:42 |
rubenwardy |
why can't use use background[]? |
| 23:42 |
rubenwardy |
background[3,4;1,1;image;false] |
| 23:43 |
rubenwardy |
then I think you can use a transparent slot color |
| 23:43 |
rubenwardy |
not sure on that |
| 23:43 |
Wuzzy |
seems i dont understand background[] then |
| 23:44 |
rubenwardy |
background has two modes - in one, it acts exactly like an image (auto clip = false), in the other it stretches to cover the formspec (auto clip = true) |
| 23:44 |
rubenwardy |
in formspec v3, the former mode of background and image are identical |
| 23:44 |
Wuzzy |
but i still need to draw ALL inventory slots by hand? |
| 23:44 |
Wuzzy |
instead of just a single one, which is repeated |
| 23:44 |
rubenwardy |
like, the former mode is only needed because formspec v1 and v2 don't support custom layers |
| 23:44 |
rubenwardy |
you can draw a single one, and use a for loop to copy it |
| 23:44 |
rubenwardy |
like how hotbar slots are done |
| 23:45 |
Wuzzy |
yeah thats the workaround i was talking about ? |
| 23:45 |
rubenwardy |
it's not a workaround really, it's composition |
| 23:45 |
Wuzzy |
baking all the slots into a single background is a really bad idea imo |
| 23:45 |
rubenwardy |
you don't need to |
| 23:45 |
Wuzzy |
which is what MCL2 does ... |
| 23:45 |
Wuzzy |
*oops* |
| 23:45 |
rubenwardy |
you can reuse the background multiple times |
| 23:46 |
rubenwardy |
MTG get_hotbar_bg uses image[] apparently: https://github.com/minetest/minetest_game/blob/master/mods/default/init.lua#L35 |
| 23:46 |
|
kilbith joined #minetest-dev |
| 23:46 |
rubenwardy |
I guess because images draw behind items (eugh, this is that regression again) |
| 23:46 |
Wuzzy |
the hotbar image must also have the correct number of slots |
| 23:46 |
Wuzzy |
if you want to change the hotbar size, new img required ... |
| 23:47 |
rubenwardy |
don't get confused |
| 23:47 |
rubenwardy |
the hotbar in the hud requires the correct number of slots |
| 23:47 |
rubenwardy |
the hotbar image in the GUI is a single image |
| 23:48 |
rubenwardy |
here's the hotbar image for the GUI: https://github.com/minetest/minetest_game/blob/master/mods/default/textures/gui_hb_bg.png |
| 23:48 |
Wuzzy |
yes and if you want to switch to, lets say, 5 slots, the gui will break |
| 23:48 |
|
kilbith joined #minetest-dev |
| 23:48 |
rubenwardy |
no, the image will still work in the GUI |
| 23:48 |
Wuzzy |
unless you replace the image that has 5 slots |
| 23:48 |
rubenwardy |
because the image only has a single slot in it |
| 23:48 |
rubenwardy |
you'll need to change the code to only do 5 slots in that for loop rather than 8 |
| 23:48 |
Wuzzy |
ugh... |
| 23:49 |
rubenwardy |
> for i=0,7,1 do |
| 23:49 |
Wuzzy |
more boilerplate |
| 23:49 |
rubenwardy |
when we have inventory styling, this will probably be easier \o/ |
| 23:49 |
Wuzzy |
but i can almost understand why |
| 23:49 |
Wuzzy |
what is inventory styling? |
| 23:50 |
rubenwardy |
like `style_type[list.slot;bgimg=mycustomslot.png]` |
| 23:50 |
Wuzzy |
That's what I'm talking about! YES |
| 23:50 |
rubenwardy |
styling is powerful, but mostly unimplemented |
| 23:51 |
rubenwardy |
I created it because I was fed up of having tableoptions, listoptions, bgcolor, blah - having one way to do it is good |
| 23:51 |
Wuzzy |
hmmm i still can't style the Esc menu directly, can't I? |
| 23:51 |
rubenwardy |
not directly |
| 23:51 |
rubenwardy |
only via formspec prepends |
| 23:51 |
Wuzzy |
right |
| 23:52 |
Wuzzy |
so its not a solotion for mcl2 them |
| 23:52 |
Wuzzy |
i need the formspec_prepend for something different |
| 23:52 |
rubenwardy |
in games, you should probably be putting default styles in formspec prepends |
| 23:52 |
rubenwardy |
oh dear |
| 23:52 |
Wuzzy |
sure |
| 23:53 |
Wuzzy |
in mcl2, my formspec_prepend works nicely for my normal formspec but it makes the Esc menu look kind of ugly |
| 23:53 |
rubenwardy |
I'll TAL |
| 23:53 |
rubenwardy |
hmm, not sure if that's an actual acronym - take a look |
| 23:53 |
Wuzzy |
TAL? |
| 23:53 |
rubenwardy |
oh, found another crash. That's fun |
| 23:54 |
Wuzzy |
=) |
| 23:54 |
rubenwardy |
in set_sky in MCL2 |
| 23:54 |
Wuzzy |
its not my fault set_sky's compability suddenly broke ? |
| 23:54 |
rubenwardy |
I don't see any styling on the pause dialog |
| 23:54 |
Wuzzy |
yes |
| 23:55 |
Wuzzy |
i have removed most styling from formspec_prepend |
| 23:55 |
Wuzzy |
i havent figured out a nice way to use formspec_prepend for default styling without *also* screwing up the esc menu |
| 23:55 |
Wuzzy |
but maybe this will be easier now with the extended styling ... |
| 23:55 |
rubenwardy |
what does screwing the esc menu look like? |
| 23:56 |
Wuzzy |
hmm i don't remember exactly what it was |
| 23:56 |
Wuzzy |
probably i wanted to have a darker background fullscreen shade |
| 23:57 |
Wuzzy |
ideally, style/prepend can be set explicitly for those "special" menus |
| 23:57 |
Wuzzy |
much less of a headache, i suppose |
| 23:57 |
Wuzzy |
but maybe i will find a way now... |
