Minetest logo

IRC log for #minetest-dev, 2021-07-15

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
01:07 v-rob joined #minetest-dev
02:59 specing_ joined #minetest-dev
05:22 Kimapr joined #minetest-dev
07:51 Wuzzy joined #minetest-dev
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
09:59 calcul0n_ joined #minetest-dev
10:32 YuGiOhJCJ joined #minetest-dev
10:33 entuland joined #minetest-dev
11:21 entuland joined #minetest-dev
11:34 ssieb joined #minetest-dev
11:48 twoelk joined #minetest-dev
11:58 twoelk joined #minetest-dev
12:35 m42uko joined #minetest-dev
13:07 MTDiscord <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 Kimapr9 joined #minetest-dev
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 <Warr1024> 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 <Warr1024> 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 <Warr1024> Thanks
13:24 MTDiscord <Warr1024> 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 <Warr1024> Or perhaps it's for a specific project, like the way I have an "engine" section of the wishlist for NodEcore
13:28 MTDiscord <Warr1024> 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 <Jonathon> Make a issue for it
13:40 MTDiscord <Jonathon> As for the death screen there is a pr for that already
13:40 MTDiscord <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> OIC, you mean like how to display the actual falling node ent?
13:53 MTDiscord <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> I suppose MT does ship with DevTest, so technically there IS a game installed, isn't there?
14:10 MTDiscord <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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 <Warr1024> 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.
15:00 specing_ joined #minetest-dev
15:07 Kimapr joined #minetest-dev
15:16 Fixer joined #minetest-dev
15:50 Extex joined #minetest-dev
16:11 entuland joined #minetest-dev
17:10 MTDiscord joined #minetest-dev
17:25 clavii joined #minetest-dev
17:33 MTDiscord joined #minetest-dev
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:37 Lone_Wolf joined #minetest-dev
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 <Warr1024> 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.
20:31 Extex joined #minetest-dev
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 <josiah_wi> There must not be a lot of devs who are hyped about reviewing build system stuff. XD
22:07 Lone_Wolf joined #minetest-dev
22:45 MTDiscord <Warr1024> Tested it on Android yet?  Or M1 Mac?
23:06 AliasAlreadyTake joined #minetest-dev
23:09 MTDiscord <josiah_wi> 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 <Jordach> on mac it's preferred you compile against an .so rather than installation
23:14 MTDiscord <Jordach> because all mac apps are portable
23:15 MTDiscord <Jordach> as long as it's an executable .app it's portable
23:16 MTDiscord <Jordach> most importantly .app are the only way you're allowed to create context windows on the system
23:21 MTDiscord <Jordach> the way modern binaries are built they're directly built into minetest.app/Contents/MacOS/minetest
23:22 MTDiscord <josiah_wi> Maybe you could teach me the build process for Mac sometime; I'm a little confused. :)
23:22 MTDiscord <Jordach> it's no different to Linux
23:22 MTDiscord <Jordach> it's identical
23:23 MTDiscord <josiah_wi> Ok. I'm just wondering whether you're saying there's something I need to fix or not.
23:23 MTDiscord <Jordach> since i built all the dependancies from source using cmake
23:23 MTDiscord <Jordach> i have to manually specify locations on disk
23:24 MTDiscord <Jordach> however, i wrote a build script that will automatically handle all that for me
23:35 Kimapr joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext