Time Nick Message 08:54 Wuzzy I really dislike the new policy tho ... 08:55 Wuzzy So basically, what you're saying is, when a PR was ignored for 1 week, it is closed. No review, no justification, not even concept rejection, just kill it blindly. 08:56 Wuzzy that sounds like a really bad idea to me. closing PRs just because policy dictates you to, without even taking a glimpse at the subject matter ... yeah, if you apply this policy consistently, you are going to kill a lot of PRs regardless of quality 08:58 sfan5 I understand the sentiment and *if* no coredev has looked at in the one week period that's a problem 08:59 Wuzzy thank you 08:59 sfan5 but in principle it's working correctly: If you write the code ahead of time you have to be very sure that a coredev will approve your PR or you might see it go to waste 09:00 Wuzzy yesterday, 4 of my PRs were closed by rubenwardy in row with this exact reasoning 09:00 Wuzzy but 3 of them were already re-opened... LOL 09:01 Wuzzy sure, i have no problem if a PR is rejected for concrete reasons. but i have a problem if my work is just flat out rejected for formal reasons and nobody even took a glimpse at it. This is frustrating 09:03 sfan5 well if I look at PRs I won't be writing a comment saying "This approach didn't sound too useful / catch my interest enough." when I don't concept-approve it 09:03 pgimeno I think it encourages submissions of issues instead of pull requests, allowing to determine if a subsequent pull request would be merged 09:03 sfan5 so you can take that as implicit reasoning 09:03 sfan5 only issue is uncertaincy whether someone even looked at it, as you mentioned 09:03 sfan5 pgimeno: yeah 09:04 sfan5 it's also advantageous to discuss the implemention ahead of time instead of having the submitter code it out and then coredevs want it done totally differently 09:04 Wuzzy just throwing out PRs with no feedback whatsoever isn't nice to your contributors tho. Please don't mass-close PRs just because of the 1 week rule 09:05 Wuzzy 1 sentence feedback would already be nice, like "No, Boost will NOT be added, we decided that years ago." ? 09:05 Wuzzy anyway, it seems i am so far the only 1 affected by the 1 week rule 09:07 Wuzzy But yes, I am fully aware if I post a PR ahead of time, I am always in risk of rejection. That's life ... But fun fact: Most of my PRs weren't rejected like that 09:08 Wuzzy I think after >100 successful PRs I think I have somewhat of an impression what goes, and what goes not. ? 09:08 sfan5 it's cool that "leave it lying for months and eventually someone picks it up" worked for you but we do not want to leave PRs lying around anymore 09:09 Wuzzy what do you mean "someone picks it up"? 09:09 Wuzzy like, review? Or do you mean incomplete PRs? 09:09 sfan5 = "a coredev takes interest in it" 09:09 Wuzzy sounds great, so will there be more reviews in future then? 09:10 Wuzzy do we have newly added core devs? 09:10 sfan5 yes 09:11 Wuzzy awesome. yeah, having >130 open PRs is mind-boggling, i get why you want to get this number down to 0 09:11 Wuzzy hey i have an idea 09:11 Wuzzy how about an "anti-roadmap"? 09:11 Wuzzy like the roadmap, but a list of things that are definite no-goes in minetest, so dont bother trying 09:12 sfan5 not even that though, if PRs nobody is interested in are closed reviewing can happen focused on the PRs that have real chances to get in 09:12 sfan5 and you mean PRs that are neither on the roadmap or the anti-roadmap then get left open? 09:13 pgimeno Hm, "list the things that won't ever be accepted". Should "Space shooters" be in the list? What about "Converting Minetest into an ERP"? 09:13 Wuzzy I understand you want to get the PR count down. I want that too. But if you close PRs purely based on the fact that nobody reacted to it, that seems like a great way to maximize contributor frustration 09:14 Wuzzy the idea of the anti-roadmap will make it easier to reject PRs for contrete reasons tho ? 09:14 sfan5 not really 09:14 sfan5 you cannot have an exhaustive list of what we don't want 09:14 pgimeno that was my point :) 09:14 Wuzzy I think one important thing to figure out is the question: "Belongs this feature in the engine, or does it belong to games/mods?" 09:15 sfan5 also you didn't answer my question, if we leave everything uncertain open we have a state just as bad as before 09:15 Wuzzy Well, you are dancing around the main issue: Many PRs are simply not decided on because nobody took the time to give even minimal feedback 09:16 Wuzzy Oh, I don't think the anti-roadmap must be exhaustive. it could be limited to ideas that frequently come up. basically based on experience 09:18 sfan5 the main thing is 09:19 sfan5 "post code first, ask questions later" is not compatible with our new model. it should be "questions first, code later" 09:19 Wuzzy make a forum thread about it ? I was completely unaware of the new policy btw 09:19 sfan5 if you build an escape hatch that forces us to provide feedback plus rejection reasons PRs WILL keep piling up 09:20 Wuzzy yeah ok, for new PRs from now on this seems fair enough, but then at least spread this new policy widely or else there will be frustration as well 09:20 Wuzzy i dont know how many contributors are aware of this... probably not many 09:21 sfan5 the PR text template refers to this but it's not super clear 09:21 Wuzzy feedback could be minimal tho, like "this PR is insta-rejected because it is on the anti-roadmap" and the anti-roadmap already explains everything so you don't have to write entire novels again and again 09:23 Wuzzy Do you have other strategies to reduce the open PR count? 09:23 sfan5 not that I'm aware 09:24 sfan5 we can go closing old PRs without activity but that's not formalized anywhere I think 09:25 Wuzzy well what if the lack of activity is because reviewers/coredevs, not because of the author? Like they didn't react while the author did everything that was requested from them in the past? Maybe at least give them bump or so if you're requesting something 09:25 sfan5 sure 09:26 sfan5 that wasn't meant to be an exhaustive description of conditions for closing 09:26 Wuzzy i feel like if you want to close old PRs, you can kill >100 PRs instantly right now lol. I'm not sure the contributors will like it ? 09:27 Wuzzy Here'S an idea: "rebase needed" + no reaction from author for $TIME = auto-close 09:27 Wuzzy because then it's the author's fault for failing to follow up 09:28 Wuzzy also: "changes requeted" + no reaction from author for $TIME = auto-close 09:33 Wuzzy May I suggest an addition to the roadmap? 09:34 Wuzzy I suggest to add "stuff that helps with debugging, eliminating entire classes of bugs in game development, improved error reporting, etc.". 09:34 Wuzzy That way, PRs like #11429 don't get auto-closed. 09:34 ShadowBot https://github.com/minetest/minetest/issues/11429 -- Add no_texture.png as fallback for unspecified textures by Wuzzy2 09:34 sfan5 that's "Maintenance" 09:34 sfan5 and uh no 09:34 sfan5 well I guess it's not all Maintenance 09:35 Wuzzy its a mix somewhat because its also about game development 09:35 Wuzzy so... good idea or not? 09:36 Wuzzy #11429 is somewhat of a weird mix of feature, "maintenance" and bugfix btw 09:36 ShadowBot https://github.com/minetest/minetest/issues/11429 -- Add no_texture.png as fallback for unspecified textures by Wuzzy2 09:36 sfan5 first, I don't think that PR should be exempt from concept approval 09:37 Wuzzy i never said the opposite 09:37 Wuzzy so i agree 09:37 sfan5 you said it's so it wouldn't get auto-closed 09:37 Wuzzy to be clear: my future prs will come AFTER issues, unless those prs are very simple 09:38 sfan5 which is only possible if it's a bugfix or the goal is on the roadmap == exempt from concept approval 09:38 Wuzzy i thought the auto-close rule doesnt apply if the concept is on the roadmap 09:38 sfan5 correct 09:39 Wuzzy do you think #11429 is technically on the roadmap? 09:39 ShadowBot https://github.com/minetest/minetest/issues/11429 -- Add no_texture.png as fallback for unspecified textures by Wuzzy2 09:39 Wuzzy (just curious) 09:39 sfan5 no 09:39 sfan5 we have a whole four points on the roadmap so not surprising 09:41 Wuzzy five, if you count the "long-term" goals which aren't explicitly listed 09:43 Wuzzy i am surprised that not even something like "improve error reporting" is part of the roadmap ? so technically, a change like this needs concept approval first, lol 09:45 sfan5 it's definitely missing one thing: maintenance PRs are okay too 09:45 sfan5 it only mentiones bugfixes 09:46 pgimeno I'd say it's important for the core devs to first agree with the submitter on what "improve" means 09:49 Wuzzy I feel like a frequent topic of argument is whether feature X "belongs in the engine" or would better be suited in mod/game. I think this should be formalized somehow. 09:49 Wuzzy Any ideas where to put the cut-off point between "engine feature" and "game/mod feature"? 09:50 Wuzzy One obvious case would be "this idea can alredy fully and reasonably implemented in $GAME, so not an engine feature" 09:51 Wuzzy note the "reasonable". if it could only be done by complex workaround or by huge performance tradeoffs, that's not really reasonably doable ? 09:55 Wuzzy btw: Note how "documentation fixes/improvements" is also awkwardly missing from the 1-week rule exception ? 09:59 Wuzzy My PR plug of the day: #11128 09:59 ShadowBot https://github.com/minetest/minetest/issues/11128 -- Improve documentation of tools by Wuzzy2 13:07 MTDiscord Re: the auto-close after 1 week policy, the 1 week time period would maybe make sense if we were professional full-time core-devs, but some of us may have to be away from MT for weeks at a time. Something like 1 month might be more reasonable. This also effectively means that someone may have to comb through a bunch of closed PRs after a longer absence to make sure nothing they want to champion needs to be resurrected. A longer 13:07 MTDiscord wait period would allow closure to be more likely to actually be final. 13:09 MTDiscord Also I've looked at a lot of Wuzzy's PRs and thought "I like the general sound of this, but surely there must be somebody else who has a better idea about this than me." Like with those drawtype PRs, any individual one seems like an improvement, but looking at them en masse, it suggests some sort of overall plan to expand drawtypes, and do we have a vision for a "complete" set of drawtypes, or are we just adding new ones as 13:09 MTDiscord inspiration strikes? 13:11 MTDiscord As a result, I was on the cusp of supporting any of them, but it seemed like I might have to support all of them to be consistent, and I didn't feel like I understood the overall vision for drawtypes well enough for that. 13:12 Wuzzy there is no overall vision for drawtypes 13:12 MTDiscord I suspected as much, but it makes me wonder if there should be... 13:13 Wuzzy there are some drawtype prs which should be safe tho.. 13:13 Wuzzy like the one that adds support for static nodeboxes in leveled nodes 13:14 Wuzzy thats like a missing feature 13:14 Wuzzy also, you dont have to support all or nothing to be consistent 13:14 Wuzzy that doesnt make sense 13:15 Wuzzy approving one drawtype pr doesnt mean you approve every drawtype PR in existence ? 13:15 MTDiscord If I don't support a PR it doesn't necessarily mean that I disagree with it, it may just mean that I think that supporting a PR comes with a certain level of responsibility to see it through, and I don't want to overcommit all at the same time. 13:15 Wuzzy slippery slope fallacy 13:16 Wuzzy i dont think concept approval is the same as full approval. full approval means you tested it. but better to ask what hte others think ... 13:16 Wuzzy anyway, what should i do in your opinion? 13:17 Wuzzy FYI All of my drawtype PRs are mostly born out of pragmatism 13:17 MTDiscord I can't tell you what you need to do to get core dev approvals in general, but in order to get approval from me, I think it's mostly just a matter of getting my attention and then giving me time. I'm also a new core dev so I need to find my own pace in the role yet. 13:18 Wuzzy well ok. if you feel like testing something today, try this bugfix: #11110 13:18 ShadowBot https://github.com/minetest/minetest/issues/11110 -- Fix number of tool uses being off by 1..32767 by Wuzzy2 13:19 Wuzzy but congrats for making it to core devs status!! not many people have this 13:21 MTDiscord Thanks 13:24 MTDiscord It seems like there must be a Wuzzy Minetest Roadmap out there somewhere that ties together and prioritizes all the various pending issues/PRs :-) 13:24 MTDiscord Or perhaps it's for a specific project, like the way I have an "engine" section of the wishlist for NodEcore 13:28 MTDiscord I've been trying to get #11378 to just cross the finish line, but I'm not sure what rubenwardy meant about the fix being in the wrong place. It seemed to work, and so I don't know whether it's just a code organization issue, or one of those things where it causes distant consequences that I don't know where to look for. 13:28 ShadowBot https://github.com/minetest/minetest/issues/11378 -- Add disable_settings to game.conf to get rid of "Enable Damage"/"Creative Mode"/"Host Server" checkbox by Wuzzy2 13:34 Wuzzy Suggestion to add a new thing to the roadmap: "Un-hardcode stuff". That is, to make features that are annoyingly hardcoded in Minetest no longer hardcoded but customizable by game/mod/conf. See also: https://dev.minetest.net/List_of_hardcoded_features 13:35 Wuzzy Up to a reasonable limit, of course. Not everything that's hardcoded must be un-hardcoded 13:37 Wuzzy As I understand it, Minetest wants to be flexible for games, and hardcoded stuff (like the death screen) is a limitation 13:40 MTDiscord Make a issue for it 13:40 MTDiscord As for the death screen there is a pr for that already 13:40 MTDiscord Personally, for NodeCore, I've taken a "nothing is sacred" approach to things that engine/builtin dictate and I rip them out as violently as necessary. I've completely redefined the builtin entities, rewritten inventory:add_item, and am frankly considering completely redoing the falling_node checks. Having a less fragile way to do this would be nice, though it's not currently a high priority for me... 13:43 MTDiscord I noticed that in one of your PRs, Wuzzy, you were reworking how attached_node works in the falling check code, and I was tempted to suggest just adding a check_falling callback to the node def for that instead of just replacing builtin-hardcoded with more builtin-hardcode ... but I wasn't sure if it was a good idea to scope-creep the existing PR. 13:50 Wuzzy well, facedir nodes have a defined "direction", so it makes sense to add attached support for them... 13:51 Wuzzy on the other hand, there are probably a billion ways to define "node is attached", sooooo 13:51 Wuzzy my rationale was is that facedir is a core paramtype2 13:51 MTDiscord Yeah, in my case though I want full customizability. I want to be able to have things that hang from a ceiling, or things that won't fall if they're supported above OR below OR from at least 2 sides or something. 13:52 MTDiscord The idea would be that instead of having builtin do all the falling check stuff internally, it'd defer to the fall_check CB on a node def, and we'd have a "standard fall check" that's loaded as the default CB on node defs but could be easily overridden. 13:52 Wuzzy overriding falling nodes is kind of tricky btw. there are now so many checks to get the rotation right its not funny anymore ? 13:52 MTDiscord Could be a good separate PR 13:53 Wuzzy all those checks could be eliminated if entities had a 'node' visual (render entity like a node) 13:53 MTDiscord I think I can probably override what I need by just monkey-patching builtin as things are now, but it'd be nice to not have to :-) 13:53 MTDiscord OIC, you mean like how to display the actual falling node ent? 13:53 MTDiscord yeah, I was just thinking about the "should I fall or not" decision so far. 13:53 Wuzzy yes. entity visual = "node" 13:54 Wuzzy i am confused why u would wnat to override inventory:add_item o_O 13:54 MTDiscord I did a search for is:open author:Wuzzy2 in the GH issues/PRs and there are 6 pages of them. You've got a LOT of irons in the fire :-) 13:54 Wuzzy what is wrong with that? 13:54 Wuzzy what is wrong with add_item? 13:54 MTDiscord The inventory:add_item override is because players in NodeCore need a way to split stacks, pick them up, and keep them split. 13:55 Wuzzy NodeCore is very hard. 13:55 MTDiscord The MTG default is search the inventory from the far left and put items in the first slots they fit into. The NodeCore default is to scan right from the currently selected slot, and then scan left from it if there are still items remaining after reaching the end. 13:56 Wuzzy ohhh 13:56 Wuzzy well in MCL2 i added my fair share of helper functions as well 13:56 MTDiscord Speaking of our respective games, you need better screenshots on CDB :-) 13:56 Wuzzy item entities had to be overriden because of physics. 13:57 MTDiscord The thumbnail for Hades Revisited I don't think really shows the depth and diversity of the game well. 13:58 Wuzzy hahaha "depth" 13:58 Wuzzy this game has no real depth so far 13:58 Wuzzy unless you mean "dig down to -31k to hit bedrock and get bored" lol 13:58 Wuzzy anyway, i do plan to add lots of things to the game 13:58 MTDiscord I meant like the fact that you could establish a farm in the middle of that hellscape. I've seen screenshots that show that, I think they were for HR and not just the original Hades at least? 13:59 Wuzzy i am still in the planning phase 13:59 MTDiscord conceptual depth, not physical 13:59 Wuzzy i know 13:59 Wuzzy well after a few hours you have basically explored all the interesting stuff, so depth is limited 13:59 Wuzzy progress is slower than usual tho 14:00 Wuzzy i still need to change so many things, its not an accident its in alpha 14:00 Wuzzy this is getting off-topic lol 14:00 MTDiscord Yeah, slowing down a player's progress by placing obstacles in their path seems to be a helpful way to stretch limited content, so long as you make the challenges interesting and not just annoying. That was a lot of what went into early NodeCore... 14:01 MTDiscord Hmm, yeah, it's hard sometimes to talk about engine dev and game dev separately since they're so intertwined. That's probably one of the reasons c55 decided to make a couple of game devs into new core devs; in theory it's game devs who are actually the target audience of the engine. 14:03 Wuzzy boy, we REALLY need to get that main menu reworked someday. its so horrible 14:03 Wuzzy but nobody can agree on anything, its a stalemate 14:03 MTDiscord I'd love to see ruben's vision for a game-neutral experience come about. 14:03 Wuzzy perfect bikeshedding 14:04 Wuzzy thats the same vision as celeron55's, roughly, and also mine 14:04 Wuzzy game-neutralness is totally reasonable 14:04 Wuzzy but IMO that doesnt mean the default design can be ugly or bland ? 14:04 MTDiscord I mean, c55 is still the ultimate tiebreaker as I understand it; he can put the Benevolent Dictator hat on whenever necessary to break through roadblocks. 14:05 Wuzzy so IMO the main problems with the main menu are: 14:05 Wuzzy 1) really really ugly 14:05 MTDiscord Also game-dev core-devs could essentially form a voting bloc since we all have common stake. I mean, in theory, there shouldn't really be such a thing as an engine dev that's purely an engine dev... 14:06 Wuzzy 2) poor usability (game settings are hidden DEEP in the settings tree) 14:06 Wuzzy 3) can't really decide if its for one game or multiple. its a weird confusing mix 14:06 Wuzzy 4) violates every usability rule in the book lol 14:06 MTDiscord I think improving the flow of the main menu, and de-default-ifying MTG, are more important to me than prettying it up, but I don't see why we can't eventually do them all. 14:07 MTDiscord I don't want to do a big monolithic main menu redesign AND facelift as one big project though if it's going to lead to more bikeshedding and more delays. With a task this big, I just wanna take an axe and chop it up into little bite-sized chunks and pipeline them all through, so we can keep progress going. 14:07 MTDiscord Or in this case, maybe, start it. 14:08 Wuzzy well, it looks more like a pre-alpha test version of some ancient broken management software than a game lol 14:08 pgimeno what do you mean by de-default-ifying it? 14:08 Wuzzy Dethrone MTG from its default status (MTG is still shipped by default) 14:08 MTDiscord I think the assumption is that the MT engine doesn't behave properly in the absence of any installed game, so MTG is included with it. 14:09 MTDiscord Instead MT should detect when no games are installed and direct the user to shop for one. 14:09 Wuzzy in other words, hiding a bug ? 14:09 Wuzzy but in my tests, MT seems to work with no game installed 14:09 Wuzzy not sure tho 14:09 MTDiscord It's not a simple bug though, it's a fundamental design flaw (which arguably wasn't a flaw at the time but now context has changed) 14:09 MTDiscord I suppose MT does ship with DevTest, so technically there IS a game installed, isn't there? 14:10 MTDiscord but then there's the risk that users assume that's meant to be the default experience. 14:10 Wuzzy yes in my vision the whole concept of how MT deals with game needs to be rethought 14:11 Wuzzy its pretty obvious its just a test, i cant remember a single complaint 14:11 Wuzzy It's literally called "Development Test" and there is also a start-up message that this is just a test 14:11 MTDiscord As far as I'm concerned, MT's sort of odd place as a game creation system that includes a game distribution system sort of works, and there's some convenience to it, and I wouldn't dramatically change it, but I would make the way it presents itself match the way it actually functions, at least. 14:11 Wuzzy However, I can recall numerious complaints about MTG being too "bland" or "unfinished" or "boring". happens all the time 14:12 Wuzzy > but I would make the way it presents itself match the way it actually functions, at least. 14:12 MTDiscord MTG is not a game, it's a build-your-own-game starter kit. 14:12 Wuzzy I fully agree! 14:12 Wuzzy and not even a very good one lol. its OK for server operators who know what they're doing tho 14:13 MTDiscord NodeCore or MineClone are games, they can be played. MTG is not really a game per se; you're expected to mod it. 14:13 MTDiscord Yeah, as far as a game starter kit goes, MTG is arguably so basic that it may make sense to design mods for MTG-derivatives instead... 14:14 MTDiscord It's good to have games that occupy all levels of basic-ness (ideal for derivative game creators) and fullness (ideal for players) but probably the initial experience of MT should be player-centric rather than dev-centric. 14:15 MTDiscord I don't think there's any real risk that a project like MT is ever going to bury the dev tools deep enough that it's a problem for devs, so we should feel confident in making all the default behaviors cater to players. 14:21 Wuzzy So, in my opinion, there should be no default game (let's ignore the special case of DevTest for now...) and MT just starts with presenting a list of games to start with ... or the server list 14:21 Wuzzy for this to work, there needs to be some basic curation 14:21 Wuzzy you cant just dump the ContentDB games list unmoderated, there are a lot of alpha-stage games there 14:22 Wuzzy I recently had a player who installed Hades Revisited as their first game (after MTG, ofc) and they are annoyed by its bugs ... ? 14:26 MTDiscord There is basic community-driven curation on CDB already via the reviews/score system. I think ruben had planned a more focused curation, e.g. like an "Editor's Picks" recommended game list to be presented to new users. If the main menu rework gets any momentum then I'm pretty confident that support from the CDB side for this will be easy. 14:31 MTDiscord On the other hand, I do want to find ways of using the leverage of the CDB system to actually drive exposure for more obscure titles, and prevent an enclave of elite packages from starving others of attention. Players often miss out on really great unique experiences simply because they don't know to go looking for them. 19:04 Krock will merge #11379 in 15 minute 19:04 Krock s 19:04 ShadowBot https://github.com/minetest/minetest/issues/11379 -- Add wallmounted support for plantlike and plantlike_rooted nodes by Wuzzy2 19:19 Krock merging 19:52 twoelk most casuall players don't want to go and look for unique experiences - they want to be presented them and in modern quick pacing and always spot on and the next adventure always more exciting than the last and ........ place more ranting here 19:56 MTDiscord Yeah, people with crap attention spans who are just looking for "give me free dopamine" are not really the audience I want to cater to. As an open source project, we don't get revenue or anything from just plain empty eyeballs. Only players who are eventually going to actually engage with the project in some way are really meaningful. Popularity only gets us so far in that regard. 21:29 sfan5 reminder #11287 21:29 ShadowBot https://github.com/minetest/minetest/issues/11287 -- Take advantage of IrrlichtMt target by JosiahWI 21:51 MTDiscord There must not be a lot of devs who are hyped about reviewing build system stuff. XD 22:45 MTDiscord Tested it on Android yet? Or M1 Mac? 23:09 MTDiscord I think it's a good idea to test it on multiple OSs, because there are arch specific libraries that are now handled by Irrlicht instead of Minetest. As much as I highly doubt there's an arch specific issue, it wouldn't be good to assume that and run smack into it later. 23:14 MTDiscord on mac it's preferred you compile against an .so rather than installation 23:14 MTDiscord because all mac apps are portable 23:15 MTDiscord as long as it's an executable .app it's portable 23:16 MTDiscord most importantly .app are the only way you're allowed to create context windows on the system 23:21 MTDiscord the way modern binaries are built they're directly built into minetest.app/Contents/MacOS/minetest 23:22 MTDiscord Maybe you could teach me the build process for Mac sometime; I'm a little confused. :) 23:22 MTDiscord it's no different to Linux 23:22 MTDiscord it's identical 23:23 MTDiscord Ok. I'm just wondering whether you're saying there's something I need to fix or not. 23:23 MTDiscord since i built all the dependancies from source using cmake 23:23 MTDiscord i have to manually specify locations on disk 23:24 MTDiscord however, i wrote a build script that will automatically handle all that for me