Time  Nick          Message
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: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: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: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: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