Time Nick Message 00:58 rubenwardy coming soon: https://rwdy.uk/9NDfU.png 01:00 rubenwardy why does CLion suck so bad 01:06 rubenwardy better pic: https://rwdy.uk/wcM09.png 01:09 rubenwardy I think I may make it have a simple were it just shows you what CDB has found, and then you can click [Cancel] [Edit] [Install] 01:09 rubenwardy edit would then go to that screenshot 01:09 rubenwardy that would only work if CDB finds everything that is required 01:10 rubenwardy I may also disable the [Edit] to begin with, and only allow installed the preselected choices 01:10 rubenwardy which is fine for 99.999% of mods 01:29 rubenwardy here's a mock simple mode: https://rwdy.uk/J33Zi.png 01:30 rubenwardy this will display if there are no problems with the selection that ContentDB choose 01:30 rubenwardy ie: contentdb is able to find all hard dependencies 01:31 rubenwardy actually, maybe it should always show. Advanced isn't going to be that useful if it can't find the dep 06:08 BuckarooBanzai rubenwardy: oh, that looks good :) 06:09 BuckarooBanzai rubenwardy: isn't that painful to implement in formspecs? :/ 09:29 p_gimeno rubenwardy: I've been thinking of implementing something similar but in the mod selection dialog. The main hurdle is that with my idea, I would need something like a modal dialog containing a list, on top of another formspec. Is there any way to do something similar? 09:31 ANAND p_gimeno: Check out builtin/fstk 09:31 ANAND It's a Lua API created by sapier, that builds on top of the existing formspec API 09:32 p_gimeno ANAND: interesting, what do you mean "builds on top"? as in, can show two formspecs simultaneously? 09:32 ANAND Not sure about that 09:32 ANAND See also, https://github.com/minetest/minetest/blob/master/doc/fst_api.txt 09:34 p_gimeno hm, my understanding is that that's simply a structured way of creating the formspec string, it's not adding functionality to it 09:35 p_gimeno what I need is one modal formspec on top of another (visually) 09:35 ANAND There are show and hide methods, but I doubt they allow displaying two formspecs at once 09:35 p_gimeno yeah 09:44 p_gimeno or, well, some other way to convey the info (a list of mods) and to offer options (buttons) 09:44 p_gimeno maybe it can be done by temporarily replacing elements in the existing formspec 09:47 p_gimeno my initial idea was: when you activate a mod in the form and it depends on others that are installed but not active, to show a modal dialog with a list of the mods that are needed, and choose between activating them as well, or deactivate the one you've selected 09:48 p_gimeno and if it depends on at least one mod that is not installed, to show a modal dialog with an error explaining what mods are missing, and only the option to deactivate it again 09:49 p_gimeno similarly, when deactivating a mod that others depend on, to show a modal dialog offering between deactivating the others as well, or re-enabling that one 09:50 p_gimeno in other words, to keep the mod list consistent at all times when manipulating mods, instead of being able to leave it in a state where there are inactive dependent mods 09:50 nepugia p_gimeno, you can't show two formspecs simultaniously, but you can probably fake your way to victory 09:51 nepugia by only adding a backgroun behind elements that need it and having a gap between both sections 09:54 p_gimeno nepugia: I don't get what you mean, do you think you can show an example? 09:54 nepugia Well, i mean with displaying two formspecs you mean to show two side by side? 09:55 p_gimeno one on top of the other, a modal dialog 09:55 p_gimeno i.e. one partially hiding the other 09:56 nepugia You can achieve that in an upper api indeed 09:56 nepugia by modifying the "lower" formspec to cut elements to a specific size to allow the upper formspec some room 09:57 p_gimeno can you have overlapping elements in a formspec? 10:02 p_gimeno anyway, it's going to be big, and if it's hard to get big PRs merged, it's even harder when I'm not in GitHub 10:42 nepugia p_gimeno, yes you can 10:42 nepugia but it doesnt look pretty :) 10:43 nepugia i dont think there is any need to merge something like this, if a mod wants somethign like that they can just depend on the mod that provides it 10:44 p_gimeno nepugia: this idea is not for mods, it's for the mod selection menu when configuring the world 10:44 p_gimeno the dependencies that it would read are the dependencies stated in the mod 10:44 nepugia why do you need overlapping formspecs there? 10:44 p_gimeno to show a modal dialog 10:45 nepugia for what? :) 10:46 nepugia the easiest way would be to just dismiss the underlying formspec, and bring it back once the dialog would be closed 10:47 p_gimeno say you activate mesecons_luacontroller but you don't activate mesecons; the modal dialog would immediately show saying "To activate mesecons_luacontroller the following mods need to be enabled: mesecons [Activate all] [Deactivate mesecons_luacontroller]" 10:47 nepugia why? just activate the dependencies 10:47 p_gimeno silently? 10:47 nepugia yes 10:48 p_gimeno I don't like to do things behinds the user's back 10:48 nepugia the users intention is to use mesecons_luacontroller 10:48 nepugia dependency management is too complicated for end users, and shouldnt be shown to them normally 10:48 p_gimeno this is a simple example, but in other mods the dependency chain could be larger, and they may be activating something they don't want 10:49 p_gimeno (e.g. a mobs mod with unwanted mobs) 10:49 nepugia then when a mod is selected show a list to the right of it with dependencies that will be activated too 10:49 nepugia p_gimeno, that is moot, because you cant not activate them 10:50 p_gimeno you can choose to not activate that one... take into account that once they are activate, you need to go one by one to disable them 10:50 p_gimeno active* 10:50 nepugia nah, you can track which ones were dependencies and immidiently deactivate them 10:50 p_gimeno and maybe disable one that was enabled and you wanted... 10:51 nepugia How should a user know that it is enabled if they did not enable it themselves? 10:51 nepugia users dont read modal dialogs 10:52 nepugia also, the assumption is that all listed dependencies are absolutely required, and if the user expresses intent to use a mod then the dependencies have to be activated 10:53 nepugia its like, in an office programm, you could prompt for each keypress whether it was correct, after all a user may have mistyped which could lead to more correct text, but it heavily degrades the ui 10:53 p_gimeno say a mod A depends on B, C and D, and you voluntarily have C active, because you want it. Now you enable A, and automatically get B and D enabled. Now you regret that B was enabled, and go through the dependencies of A and disable B, C and D. You end up disabling a mod you wanted active. 10:54 p_gimeno actually what I'm proposing is something I've seen used in the Windows service manager 10:55 nepugia You mean like, a tool used by administrators that users wont touch? 10:56 p_gimeno if the user expresses intent to enable a mod, but that forces them to enable another mod they didn't want, they need a chance to regret the decision 10:57 nepugia After they have enabled it 10:57 nepugia There is no point in questioning each and every action the user takes 10:58 p_gimeno but that may have unwanted consequences, many mods may become automatically enabled and they may not like that 10:58 p_gimeno perhaps colour codes for the dependency list could be a substitutive 10:58 p_gimeno one colour for "when you enable this mod, all these other mods will be automatically enabled" 10:59 nepugia indicating what consequence their action has is fine 10:59 p_gimeno another colour for "this mod depends on mod X which is not installed" 10:59 nepugia questioning their actions is not 11:00 p_gimeno that doesn't solve disabling, though, because for disabling, the list that should be shown is the list of mods that depend on the selected one, not the list of mods that the selected one depends on 11:04 p_gimeno what you call questioning the actions of the user, I call giving them information they may not have thought of, before making their decision final 11:10 nepugia You are supposed to provide the information beforehand 11:10 nepugia not after they already made a decision 11:10 nepugia it's like asking someone to buy a watch and after they agree to buy them price you tell them "oh by the way, this watch is highly radioctive, are you really sure you want to buy it?" 11:11 nepugia the list of "activated" mods doesnt need to show the ones that are enabled as dependencies, their state is irrelevant to the user 11:12 nepugia if they choose to disable a mod you should then list all the mods that that will disable, which includes and mods that depend on this mod, and any that are activated only because of this mod 11:17 ANAND p_gimeno: Why modal tho? 11:20 p_gimeno ANAND: if you enable a mod, popping up a modal window that allows you to confirm seems like the right thing to do. Kinda like the confirmation dialog you get in a save dialog when going to overwrite a file. 11:22 nepugia but you /arent/ overwriting a file 11:22 p_gimeno nepugia: "any that are activated only because of this mod" needs tracking which ones were activated by hand and which ones were manually enabled, kinda like the Debian package manager. That needs tracking extra info (manual vs automatic), complicating things a lot more, even for the user. 11:22 nepugia and most save dialogs that overwrite files do not have one 11:22 nepugia no, its just a list of automatic activations 11:22 nepugia it isnt that complicated 11:22 nepugia you dont need to track by whom they have been activated 11:23 p_gimeno sorry, I meant "and which ones were automatically enabled" 11:24 ANAND p_gimeno: That doesn't strictly require the parent formspec to be visible though :) 11:24 ANAND Take for example the change setting dialog 11:24 nepugia p_gimeno, same response 11:25 ANAND When you double-click on a setting, the adv. settings window will disappear, and you'll be shown a simple dialog box 11:25 nepugia it makes it easier on the user, not more compilcated 11:25 nepugia dealing with modal dialogs sucks 11:25 ANAND Yea 11:25 ANAND It might look cool, but... why? 11:26 p_gimeno ANAND: yeah I see, but isn't the formspec recreated that way? 11:26 nepugia you can "recreate" formspecs all the time 11:27 p_gimeno in the mod selection dialog there's some state, it would need to be remembered and recreated later 11:28 p_gimeno I've noticed that the settings modal dialog doesn't respect the scrollbar position, it always scrolls down the selected item to the bottom of the window 11:30 p_gimeno in fact, it also collapses the other options I had open; that's bad 11:30 nepugia if you emulate a new formspec to get a modal dialog you will "recreate" the formspec too 11:31 nepugia so if any state is lost it will happen either way 11:54 rubenwardy p_gimeno: with that formspec order pr, you could use boxes to simulate the affect 11:57 p_gimeno nice 12:04 p_gimeno rubenwardy: #8740 ? 12:04 ShadowBot https://github.com/minetest/minetest/issues/8740 -- Make formspec elements real elements for draw order and clipping by DS-Minetest 12:06 rubenwardy Yeah 12:07 p_gimeno I might develop a PoC of the idea in LOVE instead of MT 12:08 rubenwardy BuckarooBanzai: it's a real formspec, just no code to fetch and resolve dependencies yet 12:36 kilbith celeron55: may I ask why you didn't use occlusion queries from the beginning in MT? 12:38 kilbith I have an (almost) working prototype, but I wonder whether it fits to MT due to its architecture 12:48 celeron55 i don't remember 12:48 celeron55 possibly because on a slow gpu everything takes away from fps 12:49 celeron55 i'm pretty sure nobody is using an i945 these days anymore though 12:49 celeron55 it was old 8 years ago 12:49 kilbith hardware occlusion is likely faster now 13:02 celeron55 as long as it helps everyone it's good 13:03 kilbith so here is the problem exposed: https://github.com/minetest/minetest/issues/8894 16:35 BuckarooBanzai celeron55: while you are here: thanks for starting the minetest project :) 18:15 sfan5 merging #8895 18:15 ShadowBot https://github.com/minetest/minetest/issues/8895 -- Fix Inventory::moveItemSomewhere() by sfan5