| 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 |
