| Time |
Nick |
Message |
| 00:06 |
|
paramat joined #minetest-dev |
| 00:35 |
|
fluxflux joined #minetest-dev |
| 00:37 |
|
ANAND joined #minetest-dev |
| 03:38 |
|
paramat joined #minetest-dev |
| 04:00 |
|
fluxflux joined #minetest-dev |
| 04:01 |
|
Taoki joined #minetest-dev |
| 04:09 |
|
fluxflux joined #minetest-dev |
| 07:57 |
|
YuGiOhJCJ joined #minetest-dev |
| 08:39 |
|
ShadowNinja joined #minetest-dev |
| 08:49 |
|
calcul0n joined #minetest-dev |
| 09:04 |
|
Beton joined #minetest-dev |
| 10:24 |
|
troller joined #minetest-dev |
| 11:19 |
|
deltasquared joined #minetest-dev |
| 11:20 |
|
df458 joined #minetest-dev |
| 11:43 |
|
Unarelith joined #minetest-dev |
| 11:56 |
|
Fixer joined #minetest-dev |
| 12:22 |
|
YuGiOhJCJ joined #minetest-dev |
| 12:35 |
|
proller joined #minetest-dev |
| 13:14 |
|
tomraceror joined #minetest-dev |
| 14:38 |
|
ensonic joined #minetest-dev |
| 15:39 |
|
MayeulC_backup left #minetest-dev |
| 16:22 |
|
Taoki joined #minetest-dev |
| 16:31 |
|
Lone_Wolf joined #minetest-dev |
| 17:10 |
|
Unarelith joined #minetest-dev |
| 17:46 |
|
Krock joined #minetest-dev |
| 17:47 |
|
fluxflux joined #minetest-dev |
| 17:58 |
|
ANAND_ joined #minetest-dev |
| 17:59 |
|
ANAND_ joined #minetest-dev |
| 18:02 |
|
indiana joined #minetest-dev |
| 18:10 |
|
ANAND_ joined #minetest-dev |
| 18:11 |
|
DS-minetest joined #minetest-dev |
| 18:30 |
DS-minetest |
Uh, always that PRs where the description is longer than the code diff... New simple bugfix PR: #9266 |
| 18:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/9266 -- Formspec: set rect_mode tooltip and inventorylist elements invisible to allow clicking the elements beneath by DS-Minetest |
| 18:37 |
|
df458 joined #minetest-dev |
| 18:43 |
Krock |
DS-minetest: better now? |
| 18:45 |
DS-minetest |
Yes, probably. |
| 18:45 |
DS-minetest |
Thanks. ^^ |
| 18:45 |
Krock |
ObjectProperties::dump()'s output is getting out of control |
| 18:45 |
Krock |
oh man this is an enormous long dump |
| 18:50 |
Unarelith |
yay thanks for the approval Krock |
| 18:50 |
Krock |
easy stuff |
| 18:52 |
Unarelith |
well it's a small step but I really want to get this merged, I think it can help making mobs mods better |
| 18:53 |
Krock |
weird. applying diff does not work any more |
| 18:53 |
Krock |
it might be irritating though at first glance |
| 18:53 |
Krock |
people expect that there's a selection box |
| 18:53 |
Unarelith |
well MT is the first place where I've seen a selection box around mobs |
| 18:54 |
Unarelith |
for other kind of entities I'd agree, but for mobs it's weird |
| 18:54 |
Krock |
for Player vs Mob it's usually helpful to see when you're out of range |
| 18:54 |
Krock |
doesn't look great but it very practical |
| 18:55 |
Unarelith |
I understand what you mean, and that's the reason why people will still be able to show the box using debug mode |
| 18:55 |
Unarelith |
but I think that there should be another way to show this, for example using an info mod (like witt, but for mobs) |
| 18:56 |
Unarelith |
and this solution would also allow seeing the remaining life of the mob so it's a win/win |
| 18:57 |
Unarelith |
and that's how it works in a lot of games btw, you see the life of the enemy you're targeting when you're at range |
| 18:57 |
Krock |
indeed |
| 18:57 |
Unarelith |
anyway, people will do whatever they want with this feature, but at least it will exist |
| 18:58 |
Unarelith |
btw Krock, since you're here I wanted to ask you, what do you think about my refactorings? |
| 19:00 |
Krock |
Mainly the content_sao split, I presume? |
| 19:02 |
Krock |
the only thing that I dislike about it is that it'll surely cause merge conflicts in quite many PRs |
| 19:02 |
Unarelith |
not only, yes #7903 is the only one that's still open but there's also #7908 (game.cpp) and the most important is #7970 (formspecs) |
| 19:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/7903 -- File 'content_sao' splitted into folder 'src/server/object'. by Unarelith |
| 19:02 |
Krock |
but that's unavoidable with such PRs |
| 19:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/7908 -- File 'client/game' splitted into new folder by Unarelith |
| 19:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/7970 -- Formspec refactor proposal by Unarelith |
| 19:02 |
Unarelith |
yeah I agree that's unavoidable |
| 19:03 |
Krock |
for content_sao it totally makes sense. LuaEntitySAO is not useful in the same file as PlayerSAO |
| 19:03 |
DS-minetest |
Those merge conflicts are not too hard to solve, however. |
| 19:03 |
Unarelith |
+1 DS-minetest |
| 19:04 |
Unarelith |
because it's just moving changes to the new files |
| 19:04 |
Krock |
I wonder why "serverobject.h" was included in "player_hp_change_reason.h", even though a forward-declaration would be enough |
| 19:04 |
Krock |
different story |
| 19:05 |
Unarelith |
but I think the most important is the one about formspecs |
| 19:05 |
Unarelith |
there's so much issues around them, each people trying to change something have to work on the same two files, which slows the development a loooot |
| 19:07 |
Krock |
#7908 splits it way too much. Sometimes there's barely more code than license text |
| 19:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/7908 -- File 'client/game' splitted into new folder by Unarelith |
| 19:07 |
Unarelith |
Well the three of them are proposals, they're not a final thing either way |
| 19:07 |
Unarelith |
Because this kind of change is impossible to rebase |
| 19:07 |
Krock |
most of the code can stay together because it kinda belongs together and is rarely touched |
| 19:08 |
Unarelith |
then for this stuff you'll have to tell me what is better to split and what is better to stay in the same file |
| 19:09 |
Unarelith |
when I'll do it, if I ever do it |
| 19:09 |
Krock |
FormSpecData is a good idea to bundle the render information, but passing it to each parse function is not elegant at all |
| 19:10 |
Krock |
if even, bundle more into that struct (or class) so that everything that's needed for adding an element is together in one argument |
| 19:11 |
Unarelith |
what you say is the kind of information that would be useful as comments on the PRs actually |
| 19:11 |
Krock |
right |
| 19:13 |
Krock |
or even pass a FormSpecGui pointer to a constructor of the widget class. It could access the required data from there |
| 19:14 |
Unarelith |
ok noted |
| 19:14 |
Krock |
FormSpecGui would then kinda be an internal API for formspec elements which is exactly what we want |
| 19:14 |
Unarelith |
yep |
| 19:14 |
Unarelith |
btw there's not the 5.0.0 to release anymore so I just hope that I will be able to do these refactorings during next month, otherwise it'll probably wait one year |
| 19:15 |
Krock |
it would be best to do it like the proposal - one element for demonstration purposes |
| 19:15 |
Krock |
in later PRs this can be extended if it proves to be seamless |
| 19:16 |
Unarelith |
well I can do that, like I did in 7970 |
| 19:16 |
Krock |
nobody is happy to review >1000 LOC changes unless it was moved (unmodified) from one file to another |
| 19:16 |
Unarelith |
yeah sure |
| 19:17 |
Unarelith |
ok so I'll try to open a new version of #7970 with what you suggested in mind |
| 19:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/7970 -- Formspec refactor proposal by Unarelith |
| 19:18 |
Krock |
great :D thanks for your efforts |
| 19:23 |
Unarelith |
you're welcome Krock, I just hope that it will get more interest this time |
| 19:25 |
Krock |
the dev team has definitely seen more activity in the past years than there is currently |
| 19:25 |
Unarelith |
yeah I agree, doesn't seem very active right now |
| 19:25 |
Krock |
I'd still like to get someone into the team who's already some time into Minetest programming |
| 19:26 |
Unarelith |
I think there's already some contributors that knows enough MT code to get in the team |
| 19:31 |
Unarelith |
hmm Krock, I'm reading the code of 7970 and I'm wondering why you said that passing FormSpecData to each parse function is not elegant |
| 19:32 |
Unarelith |
I don't see the problem with that approach |
| 19:34 |
Unarelith |
another thing, FormSpec data is needed for the separation into widget classes, but it makes a lot of changes so the "one element for demonstration purposes" will actually be big like 7970 was |
| 19:34 |
Unarelith |
is that ok? |
| 19:34 |
Krock |
hmm |
| 19:37 |
|
Malivaso joined #minetest-dev |
| 19:37 |
|
Lone_Wolf joined #minetest-dev |
| 19:39 |
Krock |
thing is, parserData and FormSpecData are closely related. both are used for parsing & adding elements |
| 19:40 |
Krock |
although FormSpecData is persistent for common functions in GUIFormSpecMenu after parsing |
| 19:40 |
Malivaso |
hello |
| 19:42 |
|
Wuzzy joined #minetest-dev |
| 19:43 |
p_gimeno |
Wuzzy: please when pointing out issues, say #nnnn instead of the link, and let the bot tell us the URL and title |
| 19:45 |
Krock |
no, it's not a good idea to unify both. I'm now rather thinking to somehow get rid of the "widgets" argument |
| 19:45 |
Unarelith |
Krock, they could be in FormSpecData then |
| 19:45 |
Krock |
with formspec element priority sorting these could be thrown into one large widget pot (Widget*) |
| 19:52 |
Krock |
parse() which calls a function to add a new Widget to std::vector<Widget *> in GUIFormSpecMenu. Afterwards it would just be a matter of iterating and calling widget->draw(args) which will call the corresponding inherited class' funcion |
| 19:53 |
Krock |
just thinking loud |
| 19:53 |
DS-minetest |
but that does already sort-of happen |
| 19:54 |
DS-minetest |
it's just the irrlicht element* linked list instead of the widget* vector |
| 19:54 |
Wuzzy |
#9254 |
| 19:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/9254 -- Add mapgen settings in world creation dialog by Wuzzy2 |
| 19:54 |
Wuzzy |
p_gimeno: why not teaching the bot how to URL? ? |
| 19:54 |
DS-minetest |
!title |
| 19:54 |
ShadowBot |
xkcd: XKCD Stack |
| 19:55 |
Krock |
DS-minetest: Widgets would be used to parse and add the element to irrlicht's element* linked list in GUIFormSpecMenu |
| 19:55 |
p_gimeno |
Wuzzy: it knows how to URL but only on demand as DS-minetest demonstrated |
| 19:55 |
Wuzzy |
i dont get it |
| 19:56 |
Wuzzy |
also, that doesnt really answer my question anyway |
| 19:56 |
p_gimeno |
http://www.formauri.es/personal/pgimeno/ |
| 19:56 |
DS-minetest |
but why not add parse member functions to the element classes? |
| 19:56 |
p_gimeno |
!title |
| 19:56 |
ShadowBot |
Pedro Gimeno's Main Page |
| 19:56 |
Krock |
or add them directly to the linked list as element which is directly called by Irrlicht |
| 19:56 |
Wuzzy |
or is the bot set in stone and cannot be changed? |
| 19:56 |
Unarelith |
actually Krock I'm realizing some work has been done on formspecs architecture since I opened 7970 |
| 19:57 |
DS-minetest |
(the adding to the linked list happens in the element constructor) |
| 19:57 |
Wuzzy |
GitHub issue links are predictable. maybe only react on those? ? |
| 19:57 |
Krock |
to convert each element into an Irrlicht GUI element with unified render calls |
| 19:57 |
Unarelith |
there is now guiBox, guiBackgroundImage etc |
| 19:57 |
Krock |
DS-minetest: ikr, Widget would be a layer in between, thus thinking of making the layer thinner or redundant |
| 19:58 |
p_gimeno |
Wuzzy: it could be taught to do that but what's the point, if there's already the other mechanism? anyway it runs on one of VanessaE's servers and it's in Python, and I think she's the only one who can modify it |
| 19:58 |
Unarelith |
DS-minetest, as you suggested, I think it could be better to add the parse function in already defined widgets |
| 19:59 |
Wuzzy |
ok i try again... |
| 19:59 |
Wuzzy |
#9254 |
| 19:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/9254 -- Add mapgen settings in world creation dialog by Wuzzy2 |
| 19:59 |
Wuzzy |
unless that's off topic here |
| 20:06 |
|
ensonic joined #minetest-dev |
| 20:07 |
Unarelith |
what is wrong with these lines https://github.com/minetest/minetest/blob/master/src/gui/guiFormSpecMenu.cpp#L2091-L2108 |
| 20:07 |
Unarelith |
Why is a FieldSpec created here? @Krock @rubenwardy |
| 20:08 |
Unarelith |
I tried to search but I really don't understand its purpose |
| 20:08 |
Unarelith |
it wasn't here before and that's the only thing preventing me from moving parseBox to guiBox |
| 20:09 |
Krock |
FieldSpec is used to link elements with tooltips for example |
| 20:09 |
DS-minetest |
Well, every element has its FieldSpec. |
| 20:10 |
Krock |
now it's there to get the priority sorting right |
| 20:10 |
Unarelith |
wtf |
| 20:10 |
Krock |
in formspec_version 3 (new formspec_version[x] element) elements are drawn in order they're defined |
| 20:10 |
DS-minetest |
And for giving every element its own id. |
| 20:10 |
Krock |
so that you can overly one on another |
| 20:11 |
* DS-minetest |
always wondered what the magic number there is btw. (258) |
| 20:11 |
Krock |
DS-minetest: offset for special elements |
| 20:11 |
Krock |
taken from the pause menu or so |
| 20:11 |
Krock |
258 + x are Lua-provided |
| 20:11 |
Unarelith |
seems so hacky |
| 20:11 |
Krock |
because it IS hacky |
| 20:11 |
Unarelith |
._. |
| 20:12 |
DS-minetest |
ahh |
| 20:12 |
Unarelith |
well... -_- |
| 20:12 |
DS-minetest |
can we at least make a makro? |
| 20:12 |
Krock |
after real_coordinates there were so many changes that it got kinda outof hand |
| 20:12 |
Krock |
DS-minetest: *macro. yes, that would be an appropriate fix for the magic number |
| 20:12 |
DS-minetest |
btw. would it make sense to implement key change menu, pause menu and co. with formspecs? |
| 20:13 |
rubenwardy |
Unarelith: all the GUI elements are now GUI elements |
| 20:13 |
Krock |
the dead screen was already exposed to Lua API, but removed afterwards for some reason I cannot remember |
| 20:13 |
rubenwardy |
well, most of them |
| 20:13 |
DS-minetest |
*or bound to gui elements |
| 20:13 |
Unarelith |
rubenwardy, I only asked about the FieldSpec |
| 20:13 |
rubenwardy |
I'm still reading down the chat log |
| 20:14 |
Unarelith |
I already noticed that now most GUI elements are using IGUIElement from Irrlicht |
| 20:14 |
Unarelith |
it's still a good step forward compared to what it was before |
| 20:14 |
Krock |
FieldSpec serves the purpose to assign tooltips and send the formspec fields to the server |
| 20:14 |
rubenwardy |
IGUIElement and should should eventually be moved into the MT source code, but that can be done after the main refactor |
| 20:14 |
Krock |
mainly it's a container for the element names |
| 20:14 |
rubenwardy |
guiFormspecMenu needs to go |
| 20:15 |
Unarelith |
"IGUIElement and should should eventually be moved into the MT source code" <= sorry what did you mean by that? |
| 20:15 |
DS-minetest |
the hidden "should" class |
| 20:15 |
rubenwardy |
the Irrlicht GUI code should be moved into our code and improved |
| 20:16 |
rubenwardy |
that's a later task |
| 20:16 |
rubenwardy |
that would close #9360 |
| 20:16 |
ShadowBot |
rubenwardy: Error: Delimiter not found in "HTTP Error 404: Not Found" |
| 20:16 |
rubenwardy |
hmm |
| 20:16 |
Unarelith |
moved? don't you think it would be better to actually write a good GUI system from scratch and finally get rid of that bloated Irrlicht one? |
| 20:16 |
rubenwardy |
#6527 |
| 20:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/6527 -- Formspec replacement |
| 20:17 |
rubenwardy |
that's an alternative, but not compatible |
| 20:17 |
Unarelith |
yep |
| 20:18 |
Unarelith |
that's exactly what I meant |
| 20:18 |
rubenwardy |
there are options here |
| 20:19 |
rubenwardy |
given all the improvements to our GUI code recently, it would be good to share GUI elements |
| 20:20 |
* Krock |
wonders why it's called "noclip" rather than "clip". Inverting names doesn't turn out well |
| 20:22 |
DS-minetest |
"share GUI elements"? what does that mean? keep the old elements? |
| 20:22 |
* DS-minetest |
is against replacing noclip with clip. not falling through the floor shouldn't be a privilege |
| 20:23 |
rubenwardy |
as in, share GUI elements between the current formspec format and any future system |
| 20:24 |
DS-minetest |
ah, i see |
| 20:24 |
DS-minetest |
that would be needed anyway to keep mod compatibility |
| 20:24 |
rubenwardy |
the alternative is to have 2 different systems side-by-side |
| 20:25 |
Unarelith |
2 different systems side by side seems better given how hacky the formspec code is |
| 20:26 |
rubenwardy |
the GUI code isn't hacky |
| 20:26 |
rubenwardy |
the formspec code is |
| 20:27 |
rubenwardy |
if the irrlicht GUI code is to be replaced, then we should pause all work on it |
| 20:29 |
Krock |
(the situation that is most unlikely to happen) |
| 20:29 |
rubenwardy |
yeah |
| 20:36 |
Wuzzy |
what's the difference between formspec version 2 and 3? |
| 20:38 |
DS-minetest |
look into networkprotocol.h |
| 20:38 |
rubenwardy |
Formspec elements are drawn in the order of definition |
| 20:38 |
rubenwardy |
bgcolor[]: use 3 parameters (bgcolor, formspec (now an enum), fbgcolor) |
| 20:38 |
Krock |
inb4 issue about formspec_version not being documented |
| 20:38 |
rubenwardy |
this should be in lua_api |
| 20:40 |
Unarelith |
btw rubenwardy, can you take a look at #9240 when you have the time please? btw Wuzzy, this one can interest you |
| 20:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/9240 -- FormSpec: Support custom size and spacing for slots in list (#7971) rebased by Unarelith |
| 20:42 |
Wuzzy |
i htink drawing order is a little broken |
| 20:42 |
Wuzzy |
just click on all the dropdown lists in minimal test formspec |
| 20:42 |
Wuzzy |
open dropdrown renders behind item slots, the last time i checked |
| 20:43 |
DS-minetest |
inventorylists are still rendered last |
| 20:43 |
DS-minetest |
that's a TODO |
| 20:43 |
DS-minetest |
btw. could we go ahead in the fs priority list? https://github.com/minetest/minetest/projects/6 (mine is next and is ready) |
| 20:43 |
DS-minetest |
!title |
| 20:43 |
ShadowBot |
Formspec Priority List · GitHub |
| 21:08 |
|
fluxflux joined #minetest-dev |
| 23:23 |
|
Malivaso joined #minetest-dev |
| 23:51 |
|
fluxflux joined #minetest-dev |
