| Time |
Nick |
Message |
| 00:51 |
MTDiscord |
<paradust> well that did not go well. I built it using ClangCL, and the resulting executable is completely broken |
| 01:47 |
|
fluxionary joined #minetest-dev |
| 04:36 |
MTDiscord |
<paradust> I got it working. Took a while to fix it |
| 04:36 |
MTDiscord |
<paradust> (ClangCL build on windows) |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 08:10 |
|
calcul0n_ joined #minetest-dev |
| 10:18 |
sfan5 |
official build is mingw |
| 11:18 |
|
appguru joined #minetest-dev |
| 12:52 |
MTDiscord |
<mistere_123> sfan5, I'm not sure I know what I'm talking about so I will ask here instead of the issue thread, but, have you considered that only supporting specific official minetest releases and rejecting forks and dev builds for certian aspects of a game, might be considered a feature (as in, maybe that's basically why zughy needs it)? Also, for dev builds, won't you be able to tell that the version is greater than a certian version, such as |
| 12:52 |
MTDiscord |
that 5.9 dev is greater than 5.8, thus supposedly supports all 5.8's features? Just give the disclaimer with the api function. Also, we should not care about forks like multicraft which change the version number... we are developing for Minetest, not Multicraft... and modified clients can send a different version number, and can cheat anyways in other manners, but this issue is for law-abiding players, not cheaters, and it is about regular |
| 12:52 |
MTDiscord |
minetest users, not fork users. Also, exposing the version would allow mods to require a fork... which, for tech demos, is a great thing. |
| 12:53 |
MTDiscord |
<jordan4ibanez> I'm going to say what MisterE said but in my own way: Please give us that, please |
| 12:55 |
MTDiscord |
<jordan4ibanez> You can't imagine the issues this fixes when you're developing a game and you constantly have to ask "oh what version of minetest are you running?" |
| 12:56 |
MTDiscord |
<jordan4ibanez> This was 80% of the solution in Crafter: Oh you need 5.3.0-dev |
| 12:57 |
MTDiscord |
<jordan4ibanez> There were even users trying to run the game with 5.1.0 IIRC |
| 13:03 |
MTDiscord |
<luatic> You should be using the protocol version to distinguish those. |
| 13:04 |
MTDiscord |
<luatic> Rejecting dev builds doesn't seem very useful to me, but should also be possible using the protocol version, if we bump that as soon as we continue with the dev version. |
| 13:04 |
MTDiscord |
<jordan4ibanez> Of course, but where is that documented? Which one is 5.8.0 and which one is 5.9.0? |
| 13:04 |
MTDiscord |
<jordan4ibanez> All I see is "32" |
| 13:06 |
MTDiscord |
<luatic> well it's in the sources, but indeed we should probably document this |
| 13:06 |
ROllerozxa |
the code is the documentation, as usual |
| 13:06 |
MTDiscord |
<luatic> Still, I agree with sfan that we don't want to expose version strings when we already have other indicators that more accurately convey the technical capabilities. |
| 13:07 |
MTDiscord |
<jordan4ibanez> Does this change between version numbers? Can we have protocol 33.02 when we're working with dev builds so we can specify a specific commit? |
| 13:07 |
MTDiscord |
<jordan4ibanez> I'll be working with the dev build to get it ready for 5.9.0 release, I would like to have some fine grain control in that portion |
| 13:08 |
MTDiscord |
<luatic> I think it was established that the protocol version is incremented at least once per release. |
| 13:08 |
MTDiscord |
<mistere_123> That still leaves the issue of detecting low-effert cheaters, which is 80% of the battle |
| 13:08 |
MTDiscord |
<luatic> It doesn't |
| 13:09 |
MTDiscord |
<luatic> Dragonfire (and other "good faith") cheat clients identify themselves. That doesn't mean Minetest has to do the same. |
| 13:09 |
MTDiscord |
<luatic> Also note that cheaters would quickly figure out how to revert this commit. |
| 13:10 |
MTDiscord |
<luatic> We're not proprietary software, it doesn't really make sense for us to waste our time on hoops for cheaters to jump through. |
| 13:10 |
ROllerozxa |
luatic: fyi the server already knows the client version, it just doesn't want to tell mods that right now |
| 13:11 |
MTDiscord |
<luatic> ROllerozxa: That doesn't change my judgement tbh. |
| 13:11 |
MTDiscord |
<luatic> I agree with sfan that exposing this to modders will just lead to bugs. |
| 13:12 |
MTDiscord |
<mistere_123> Put the disclaimer, then who cares. |
| 13:12 |
MTDiscord |
<luatic> I care |
| 13:12 |
MTDiscord |
<mistere_123> Mods can do with it what they like |
| 13:12 |
MTDiscord |
<luatic> Broken / unusable APIs shouldn't be added in the first place |
| 13:12 |
MTDiscord |
<jordan4ibanez> We're going to have to remove the whole api then |
| 13:12 |
ROllerozxa |
should we remove retrieving player IPs because mods could display that publicly to every player on the server? |
| 13:12 |
MTDiscord |
<mistere_123> Please, keep it professional @Sr. Christmas Researcher (MD) |
| 13:13 |
MTDiscord |
<luatic> That's a false analogy |
| 13:13 |
MTDiscord |
<luatic> This is something that is 99% likely to be misused, 1% likely to be used properly for extremely specific usecases (which usually involve forks anyways) |
| 13:13 |
MTDiscord |
<jordan4ibanez> I whole heartedly agree with the opposition to this opinion. If a script kiddy is utilizing a hacked client, they probably literally have no idea how to even find the portion of the code in which the string identifier to change it to the latest stable to falsify that it's an unmodified client, let alone recompile the game |
| 13:13 |
ROllerozxa |
it's up to the modder to use the API functionality properly |
| 13:14 |
MTDiscord |
<luatic> vs. IPs which are.. I dunno, 50-50 misuse vs proper use? x) |
| 13:14 |
MTDiscord |
<luatic> (IP bans are questionable, esp. as they usually hit others on the same network as collaterals, and don't really work with dynamic IPs) |
| 13:15 |
MTDiscord |
<luatic> Even the example of "let's combat cheaters" is already flawed. |
| 13:15 |
MTDiscord |
<luatic> A "dirty" client does not at all equal a cheater, quite the opposite in our developer-centric community. |
| 13:15 |
MTDiscord |
<mistere_123> The disclaimer should detail the limitations, and give better alternatives (e.g. if you need to check for a specific feature, use protocol_version), and then its not a broken api, but a useful feature. |
| 13:15 |
ROllerozxa |
(personally I don't care about cheaters and that's not why I want the version digits to be exposed) |
| 13:16 |
MTDiscord |
<luatic> With all due respect, I still haven't seen a single proper use case mentioned besides use cases where you already have a custom client, and even then alternative solutions could be discussed. |
| 13:16 |
MTDiscord |
<luatic> custom client / server forks* |
| 13:17 |
MTDiscord |
<mistere_123> ... such as requiring 5.9 dev? For new feature tech demos? |
| 13:17 |
MTDiscord |
<luatic> That doesn't work, because 5.9-dev at the earliest commit is basically just 5.8 bumped. |
| 13:17 |
MTDiscord |
<jordan4ibanez> The argument "we are not proprietary software" does not yield any weight in the argument where an anti cheating implementation is .. implemented. A basic version check is worth it's weight in gold on the side of the content creator |
| 13:18 |
MTDiscord |
<jordan4ibanez> The integral nature, I assume i32 of the protocol does not yield in it's current state any use to people trying to prepare their software for the next release |
| 13:19 |
MTDiscord |
<mistere_123> luatic... duh, but soon (or maybe already with godrays) there will be such features, and as a rule, the dev version accumulates features that the release does not have... |
| 13:19 |
[MTMatrix] |
<Zughy> RE luatic: "I still haven't seen a single proper use case mentioned". Literally the first message of #14151 |
| 13:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/14151 -- Expose MT version to `get_player_information()` |
| 13:19 |
MTDiscord |
<luatic> yes, but if a client tells you "I'm 5.9-dev" you basically have to treat it as 5.8 |
| 13:19 |
MTDiscord |
<luatic> If anything, we could discuss a more fine-grained protocol version bumping policy. |
| 13:19 |
MTDiscord |
<jordan4ibanez> If this stance was taken on every version, the game would have literally not even gotten a lua modding api |
| 13:20 |
MTDiscord |
<luatic> Zughy: Can't you use protocol version for that? |
| 13:20 |
|
cranezhou joined #minetest-dev |
| 13:20 |
MTDiscord |
<luatic> If the opposing stance was taken, this came would have fallen apart like a house of cards within a month |
| 13:21 |
MTDiscord |
<luatic> game* |
| 13:21 |
MTDiscord |
<jordan4ibanez> It already has and has been fixed, partially |
| 13:21 |
MTDiscord |
<mistere_123> Off topic? |
| 13:21 |
[MTMatrix] |
<Zughy> Why modders are expected to know about what protocol version is equal to what MT version? Why should I maintain an internal conversion that might blow up at the first X.X.1 patch? |
| 13:21 |
ROllerozxa |
Zughy: arguing with luatic is like a brick wall, it's best to not bother trying |
| 13:21 |
MTDiscord |
<luatic> Zughy: I agree that we should probably document this. The reason is that it's the protocol version, not the version string, which conveys the technical capabilities of a client. |
| 13:21 |
[MTMatrix] |
<Zughy> I don't want to update my code every time a new version comes out. I want my code to simply work |
| 13:22 |
MTDiscord |
<mistere_123> How about a helper function minetest.get_equivalent_minetest_version(protocol_version) |
| 13:22 |
MTDiscord |
<luatic> You don't have to update your code every time a new version comes out. The protocol version is more reliable in that regard. |
| 13:22 |
MTDiscord |
<jordan4ibanez> Exactly, I want some min version I can let the end user know when they're trying to use my software that they are running a client that is too outdated to utilize the features in which I've crafted my software upon within the internal API |
| 13:22 |
MTDiscord |
<paradust> Maybe it would be better to have capability flags? Like a client can flag to signal whether fog is enabled and visible |
| 13:22 |
MTDiscord |
<luatic> Yes, and protocol version works for that. It's just slightly awkward for modders to use. |
| 13:23 |
[MTMatrix] |
<Zughy> Do we have a policy for that? If we roll out a 5.8.1, does the protocol increase? Also, in case I build an internal converter, how am I expected to know in advance if protocol version 33 is 5.8.1 or 5.9? |
| 13:24 |
MTDiscord |
<jordan4ibanez> Does it? Was it 33.0 before your bone regression fix and now it's 33.1 after it? |
| 13:24 |
MTDiscord |
<luatic> 5.8.1 would be a bugfix release; it wouldn't get a protocol bump (since it won't get any new features). 5.9 will get a protocol bump. |
| 13:25 |
[MTMatrix] |
<Zughy> If the bug messes with a minigame, I might need to know if people are using the bugged or not bugged release |
| 13:25 |
|
grorp joined #minetest-dev |
| 13:25 |
[MTMatrix] |
<Zughy> E.g. let's say people find a way to bypass the new fog system and this gets fixed in 5.8.1. Now what should I do? |
| 13:25 |
grorp |
merging #14145 in 10 min |
| 13:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/14145 -- TouchScreenGUI: Make server-sent overrides of button textures work by grorp |
| 13:26 |
[MTMatrix] |
<Zughy> Quite unlikely to see a bugfix release for that, but it might happen because of other reasons. And since the fog bugfix is a bugfix anyway, it'll be included |
| 13:26 |
[MTMatrix] |
<Zughy> (I guess) |
| 13:27 |
MTDiscord |
<mistere_123> To be clear, we are assuming that the hypothetical fog bypass is possible without client build modifications... we are not considering hacked clients |
| 13:27 |
[MTMatrix] |
<Zughy> of course |
| 13:29 |
MTDiscord |
<luatic> This does seem like a valid use case, though I'm not sure exposing the version string is the best way to go about it. |
| 13:29 |
[MTMatrix] |
<Zughy> You might think it's silly. But let's now say a tournament with real money is happening on that specific minigame that requires fog: now what you do? My server is already hosting tournaments with a money prize, so it might really happen in the future |
| 13:30 |
MTDiscord |
<luatic> I don't think it's silly to want control over client capabilities, but I was under the impression that for the most part, being able to detect which features a client has would suffice. You raise a good point that there may be game-breaking engine bugs, and that there should be a way to detect them. |
| 13:31 |
[MTMatrix] |
<Zughy> The only solution I have in this case is to compile the server myself, invalidating my mod feature |
| 13:32 |
[MTMatrix] |
<Zughy> (compile the server to remove the debug build only check) |
| 13:38 |
ROllerozxa |
Zughy: sounds like that's unfortunately going to be the only solution |
| 13:38 |
ROllerozxa |
a patch to remove the `#ifndef NDEBUG` preprocessor flag has been traded around pretty extensively between server admins for their own server builds, but I assume it will never get accepted upstream as the reactions from people seem to be |
| 13:39 |
[MTMatrix] |
<Zughy> I wouldn't be so pessimistic: maybe after these discussions things will change |
| 13:39 |
MTDiscord |
<jordan4ibanez> No no, I agree with ROller on this one, strong oppositions usually == nothing changes |
| 13:41 |
[MTMatrix] |
<Zughy> I've literally brought a case to the table about how knowing the exact version is the only solution |
| 13:41 |
MTDiscord |
<luatic> alright folks, you've convinced me: https://github.com/minetest/minetest/issues/14151#issuecomment-1868297167 |
| 13:43 |
MTDiscord |
<jordan4ibanez> :O |
| 13:50 |
pgimeno |
maybe relevant discussion: https://irc.minetest.net/minetest/2017-12-25#i_5178768 |
| 13:55 |
pgimeno |
the gist linked does not exist anymore, but this commit includes the idea: https://notabug.org/pgimeno/fishing/commit/9fee380e95e4633013de081e9cd1e1bebf676aa8 |
| 14:21 |
MTDiscord |
<mistere_123> Someone should link this (current) irc discussion in the issue |
| 14:31 |
|
imi joined #minetest-dev |
| 14:37 |
sfan5 |
"I've literally brought a case to the table about how knowing the exact version is the only solution" |
| 14:37 |
sfan5 |
if it's supposed to be in the issue then I don't see it |
| 14:41 |
MTDiscord |
<wsor4035> Dragonfire |
| 14:42 |
MTDiscord |
<wsor4035> Worst case servers will just keep removing the arbitrarily stupid limit and mte can pretend it doesn't happen |
| 14:43 |
sfan5 |
well there might be a compromise to at least let mods detect clients that scream "I am a cheat client!" at the server |
| 14:44 |
MTDiscord |
<wsor4035> The web space has had user agents forever, not sure why you want to stick your head in the sand over this |
| 14:45 |
sfan5 |
putting that aside for a moment: |
| 14:47 |
sfan5 |
if you want a minimum minetest version the solution of choice is protocol versions (see also #14054) |
| 14:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/14054 -- Manually configurable minimum protocol version by Warr1024 |
| 14:47 |
sfan5 |
people have reasonably complained that this is opaque and undocumented -> builtin lua could gain a helper for this |
| 14:50 |
sfan5 |
the need to tell apart e.g. 5.7.0 from 5.7.1 (due to bugfixes) is not solved by this but I'm not sure this can be solved well |
| 14:50 |
sfan5 |
(dev builds and non-linear development make this hairy) |
| 14:51 |
MTDiscord |
<wsor4035> You wonder why specifically server people don't bother reporting some stuff to mte, great example here+in the issue |
| 14:51 |
sfan5 |
meta question: please read your last message one more time. do you think it contributes to constructive discussion? |
| 14:53 |
MTDiscord |
<wsor4035> Meta question: do you think slapping possible close on something that has 7 thumbs up and counting is helpful? |
| 14:53 |
sfan5 |
okay |
| 14:53 |
sfan5 |
you are not trying to discuss constructively |
| 14:54 |
sfan5 |
it's okay to be upset at times but transporting a "you suck and never listen" attitude to the very people you are asking something from is never helpful |
| 14:56 |
MTDiscord |
<wsor4035> No, I was specifically responding to a question you(iirc) have posed in the past, given it was applicable to the discussion in question |
| 14:58 |
sfan5 |
...? |
| 15:02 |
[MTMatrix] |
<Zughy> I agree with wsor4035 here: as a server admin and modder, it's highly frustrating to try adding something new in your content, as you often find yourself hitting a wall. And you don't always have the time/energy to open the umpteenth issue, especially when you know it's gonna bring to the umpteenth controversial discussion and/or dirty hack suggestion (banning erle helped though) |
| 15:02 |
MTDiscord |
<wsor4035> Fairly sure I recall you in the past asking why things from the community aren't reported, but are common knowledge. But don't ask me to dig through irc logs to verify that |
| 15:03 |
sfan5 |
[on-topic] for example say 5.7.0 has protocol version 12, then 13 is reserved for 5.8.0 and there's no space to use difference one for 5.7.1 |
| 15:03 |
sfan5 |
could tack on a "patch version" somehow but at that point it doesn't really differ from exposing the actual version so dunno |
| 15:05 |
MTDiscord |
<wsor4035> The other issue is older versions pre 5.4? That didn't use a new protocol version each release, you can to a minor degree figure this out based on formspec versions |
| 15:05 |
sfan5 |
the 'compromise' I alluded to earlier would be to allow mods to retrieve the version string but not the numbers, in order to discourage modders from comparing those numbers |
| 15:06 |
sfan5 |
(would solve the dragonfire case but not the x.x.0 vs x.x.1 case) |
| 15:07 |
sfan5 |
tl;dr it's complicated and I'm not sure what the best solution is |
| 15:08 |
sfan5 |
oh also re "we shouldn't have to care about multicraft": that's just not the stance the core team has taken in the past. and of course it's not specifically about multicraft but generally to not set up too many pitfalls if anyone dares to fork MT |
| 15:09 |
MTDiscord |
<wsor4035> Funny you mention multicraft, they removed the limit btw |
| 15:10 |
sfan5 |
anyway, afk |
| 15:12 |
MTDiscord |
<warr1024> Not sure what "retrieve the version string but not the numbers" means but it sounds like exactly what we always actually wanted, and if somebody really wants the numbers they will just have to pattern match and parse those themselves. It's a UserAgent string and people should only expect format confections to be very loosely followed. |
| 15:13 |
MTDiscord |
<warr1024> conventions dyac |
| 15:23 |
sfan5 |
re |
| 15:23 |
sfan5 |
zughy brought up the case that an x.x.1 fixes something essential that was broken in x.x.0. making "just pattern match the string" the official solution to detect that would be ... not optimal |
| 15:24 |
MTDiscord |
<warr1024> That was why I wanted a protocol version bump for every release. |
| 15:25 |
MTDiscord |
<luatic> not optimal, but still better than nothing, esp. given that it will work for old clients as well |
| 15:25 |
sfan5 |
we do it for every release, but it can't be done on patch releases |
| 15:25 |
sfan5 |
@wsor4035 I admit marking the issue as "possible close" from the first (my) reply was unnecessary and it's understandable that it leaves people with a sour taste. sorry. |
| 15:25 |
MTDiscord |
<warr1024> I wanted to treat the "protocol" as including the client behavior, not just the shape of the packets, i.e. it included their meaning and interpretation, not just their format. |
| 15:26 |
rubenwardy |
What do you think about having a separate API version that matches the Minetest version for the official builds, and a semver compare function for it |
| 15:27 |
rubenwardy |
So multicraft might have version=2.3.2, and API version = 5.2.0 |
| 15:27 |
sfan5 |
it might be that this (general term) indeed discourages the community from filing issues but if the community is afraid of coredevs disagreeing with them that's their fault. |
| 15:28 |
MTDiscord |
<warr1024> Ruben: not opposed, though at that point "API version" sounds an awful lot like the protocol version thing and the only thing it saves us is the inconvenience of a lookup. |
| 15:28 |
MTDiscord |
<jordan4ibanez> What if you create a file specifically hosting an immutable version ID and simply increment it every time a commit is made with a github action, this can be the entire file and the github action can automatically make a commit incrementing it using a script |
| 15:29 |
sfan5 |
if you don't tell us about problems you are having the probability of them getting fixed is zero |
| 15:29 |
MTDiscord |
<warr1024> Instead of "possible close" we could just be explicit about it and say "opposed by core dev". In this case the issue would get both "supported" and "opposed" labels. |
| 15:30 |
sfan5 |
@jordan4ibanez if you make a branch and add some commits there you suddenly have multiple different codebases with identical "version IDs" |
| 15:30 |
sfan5 |
this is what I meant by non-linear |
| 15:30 |
MTDiscord |
<warr1024> The problem of course is that the difference in probability between reporting and not reporting has to be large enough to compensate for the cost of reporting and the subsequent discussion. |
| 15:30 |
rubenwardy |
Warr1024: it would be equal to the Minetest version though and solves the fork problem |
| 15:31 |
MTDiscord |
<jordan4ibanez> Can't you have github-actions auth to only run on the main minetest repo? |
| 15:33 |
sfan5 |
you can, but does that mean development branches have a constant ID? |
| 15:33 |
MTDiscord |
<jordan4ibanez> We're only worried about upstream here, we want to have the main repo in which you are downloading from synchronized, this would make protocol actually useful |
| 15:34 |
MTDiscord |
<warr1024> Right, we have a protocol version that's roughly analogous to mintest version and we can just have the engine do the lookup if needed ... though it would be better if we had the lookup already done, and included point releases. Then we should also add a string for whatever the client has self reported. Ideally it would include not just x.x.x but the name of the client, rather than just assuming "minetest", like a proper UA string. |
| 15:34 |
MTDiscord |
Having them pre-parsed into a structure could be a nice bonus assuming we're already going to be strict about that, but I'd still want some space for forks to include data outside the structure. |
| 15:34 |
sfan5 |
@warr1024 true and I also often find myself not bothering to report things, but it's the only way. Minetest isn't some company that will invest money and time into finding out problem users have via testing, surveys, etc. |
| 15:34 |
MTDiscord |
<jordan4ibanez> Have a version number backed up in a micro-repo if you must, there are many ways around this |
| 15:35 |
MTDiscord |
<warr1024> I know the importance of reporting issues, which is why I'm arguing about reducing the level of punishment for users reporting them. |
| 15:35 |
sfan5 |
if you mean getting rid of the weird form thing I'm on-board with that |
| 15:35 |
MTDiscord |
<jordan4ibanez> Commit -> Check the micro repo -> +1 -> write to micro repo -> update minetest upstream, great success |
| 15:35 |
MTDiscord |
<jordan4ibanez> Can literally just be a text file with a number in it |
| 15:36 |
sfan5 |
fwiw you can also ask git for a number of commits since repo creation (not sure if that works for shallow clones) |
| 15:37 |
MTDiscord |
<warr1024> I really think that if a change is important about for us to do an x.x.1 release, then it's important enough for modders to be able to detect. The protocol version thing would work for that if we were disciplined about it, but it still seems unnecessarily error prone. I also think that any information the client makes available to the server should be in the hands of game/mod devs, not arbitrarily censored, as a separate principle, |
| 15:37 |
MTDiscord |
and that clients should share as precise of version information as possible as honestly as possible, for the best experience. |
| 15:39 |
MTDiscord |
<warr1024> The form thing is not bad, I'm more concerned with the tone of the discussion that follows reporting an issue. I went a couple of years avoiding GitHub after paramat, and it extended actually to well after he left. |
| 15:39 |
MTDiscord |
<jordan4ibanez> A sour taste and I barely talked to him |
| 15:41 |
MTDiscord |
<warr1024> Actually I'd like the bug reporting form to include "what did you observe" and "what did you expect" after steps to repro, those always go together. But I also usually treat all fields in a template as optional, so having them marked as required in GH feels jarring and makes me want to have fewer. |
| 15:41 |
MTDiscord |
<luatic> yeah the form sucks |
| 15:42 |
MTDiscord |
<warr1024> The form also asks way too many questions about graphical shit when I don't think I've ever opened an issue that was related to video hardware, including graphical ones (it's always something like texture modifiers or something, which is not even done in hardware) |
| 15:43 |
MTDiscord |
<warr1024> Instead of asking all those questions separately maybe we should just have minetest --version dump that stuff out of there's a $DISPLAY available or something. |
| 15:43 |
sfan5 |
I was thinking the main menu could include a button / text field to copy all relevant info at once |
| 15:44 |
sfan5 |
I can't comment on the tone thing without concrete examples (assuming you want me to), but in general it's important to talk about it |
| 15:46 |
rubenwardy |
#13605 |
| 15:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/13605 -- Allow exporting config and debug.txt with one click (on all platforms) by grorp |
| 15:46 |
sfan5 |
what I think in this case also didn't help is that the issue description contained one narrow usecase that *does* have an alternative solution but everyone is talking about the issue as a representative of *all* the problems they have with this I |
| 15:46 |
sfan5 |
API* |
| 15:47 |
MTDiscord |
<warr1024> The version/UA string thing is the seminal example that led to the discussion here. A lot of us have talked about it but didn't want to bother filing the issue because we knew it would immediately get shot down. It took Zughy finally being willing to face the fire alone to get an issue created, and then a ton of us backing them up to keep it alive. That's a daunting task for almost any individual. |
| 15:48 |
|
Desour joined #minetest-dev |
| 15:49 |
MTDiscord |
<warr1024> We are not going to file a separate issue with each use case because the first will get shot down and then the others will either get marked as duplicate or just fall on their own for similar reasons. We aren't going to open an issue for ALL the possible cases because it's too much to expect any one person to know or gather them all before filing. |
| 15:49 |
MTDiscord |
<bastrabun> I don't doubt paramat meant well, but the interaction with him on a discussion of versionstring and other helpful readouts made me limit the involvement in the MT bugtracker to the minimum possible. Issue ID was 10368 I would like to see as much information about the client as possible, you cannot imagine the amount of players that find something, want to report it and then fail at reading out basic values. Imagine they have to |
| 15:49 |
MTDiscord |
disconnect from the server, to read out values, only to be never seen again. |
| 15:51 |
sfan5 |
I was neither suggesting separate issues nor an all encompassing list |
| 15:52 |
sfan5 |
but at first glance it looks like a single-usecase issue and you have to expect me to respond to exactly that |
| 15:53 |
sfan5 |
and I also don't see any alternative. communication is the only way, telepaths isn't a thing |
| 15:53 |
sfan5 |
telepathy* |
| 15:57 |
MTDiscord |
<mistere_123> Create a new form for feature discussion, with the discussion tag automatically added... if something comes of it, then a real issue gets created for the actual feature request |
| 15:57 |
MTDiscord |
<warr1024> Considering the existing reputation that the MTE core dev team has now (even if its composition is quite different from the one that earned that reputation) you are going to have to be more careful about your communication if you want to earn back the community goodwill. It's not fair but it is what it is. For something like this the appropriate response isn't "this has been suggested and rejected before", it's "this one use case |
| 15:57 |
MTDiscord |
doesn't seem compelling to me, are there any others?" and then giving the community some time to respond rather than putting it on "possible close" death row. The response was right eventually, I think, but we need to work on getting there quicker. |
| 15:58 |
sfan5 |
looks like I should not be responding to issues, because this is not my style |
| 15:58 |
MTDiscord |
<warr1024> Right now we do seem to have competing pressures on the issue tracker to be both the canonical place for open public discussion (we should leave things open) and a backlog of work to be done (we should close things as fast as possible). |
| 15:58 |
sfan5 |
when you say open discussion I'm more thinking the forums |
| 15:59 |
MTDiscord |
<warr1024> GH has a "discussions" feature that's forumesque. If you require feature discussion to happen on the forums first, it would exclude people like me who do not engage in arguments there. |
| 16:00 |
MTDiscord |
<warr1024> It makes about as much sense to make the forums a part of a feature request triage process as twitter. |
| 16:03 |
MTDiscord |
<warr1024> I'm thinking that you have the triagers already to handle this process. But this issue was exceptional because it was opened by a triager. But then that also means that maybe it warrants a more careful consideration already. I would hope you can trust your triagers to self-triage at least. |
| 16:03 |
rubenwardy |
forums are official and we have intentionally not opened up github discussions |
| 16:05 |
MTDiscord |
<warr1024> The forums are the official black hole we send trolls to. Making it part of the process just exacerbates the existing problem of people not wanting to interact with the issue tracker because of the backlash. |
| 16:10 |
MTDiscord |
<wsor4035> On the bright side, at least the forums are usable/maybe even performant after a long while |
| 16:11 |
MTDiscord |
<luatic> the forums are in an okay state |
| 16:11 |
MTDiscord |
<warr1024> If we had a section of the forums that was as tightly moderated for trolling and off-topic as GH is right now, it might be possible, but it will take a lot of time to really change the reputation of the forum overall. |
| 16:12 |
MTDiscord |
<luatic> the forum is actively moderated |
| 16:13 |
MTDiscord |
<warr1024> So I've heard, which makes it seem weird that all the people who have had to be moderated off of other platforms end up being some of the most active there. |
| 16:13 |
MTDiscord |
<wsor4035> Of spam now it seems, thanks, but trolls, not so much |
| 16:13 |
MTDiscord |
<jordan4ibanez> If you are doing a discussion on changes to the game engine, and you're already on the github, why would you go to another site to discuss features and fixes? |
| 16:14 |
MTDiscord |
<luatic> well, where to draw the line with trolls? |
| 16:15 |
MTDiscord |
<luatic> Feel free to report instances of trollery, I think we handle reports decently |
| 16:15 |
MTDiscord |
<luatic> (This is not to say that technical discussions shouldn't stay on GitHub) |
| 16:17 |
MTDiscord |
<warr1024> I'd leave both feature requests and bug reports on GH, but I'd rather see them separated in process. Bug reports need to be confirmed, fixed, and then closed. Feature requests that aren't ready to be accepted yet may need time to incubate instead of having pressure to close them immediately. |
| 16:19 |
MTDiscord |
<warr1024> In fact there's something to be said for leaving feature requests open indefinitely so they show up in searches even if the conclusion thus far is "in its current state this will never be accepted". I maintain todo lists for most of my projects and the bigger ones have separate categorized lists, and that often includes a to-don't list, which items can move into, and in theory, out of. |
| 16:37 |
|
appguru joined #minetest-dev |
| 16:37 |
[MTMatrix] |
<Zughy> Sticking to GH discussions is another vendor lock-in process I personally would like to avoid |
| 16:38 |
MTDiscord |
<wsor4035> iirc its exportable, so its not lockin |
| 16:38 |
MTDiscord |
<wsor4035> *exportable via an api |
| 16:38 |
MTDiscord |
<wsor4035> citation needed |
| 16:42 |
[MTMatrix] |
<Zughy> RE sfan5 "if you don't tell us about problems you are having the probability of them getting fixed is zero": the real problem is, MT has tons of problems, but you know that way better than I do. As a modder, sometimes I feel like having to run the obstacle course just to avoid bugs and missing features here and there. I remember when I had to deal with the celestial vault for the first time: I opened something like 5-6 issue |
| 16:43 |
[MTMatrix] |
<Zughy> and the 3rd PR I closed it because I had lost interest |
| 16:45 |
[MTMatrix] |
<Zughy> I feel like that if core devs developed/played some MT games, we'd see faster improvements on modding |
| 16:46 |
|
appguru joined #minetest-dev |
| 16:48 |
[MTMatrix] |
<Zughy> also, I guess this is what you get when you transition from a bad copy of Minecraft to an actual game platform |
| 16:58 |
sfan5 |
indeed, "historical reasons" as they call it |
| 16:59 |
sfan5 |
minetest is not exactly a good general-purpose (or voxel) game engine as it is now |
| 17:08 |
MTDiscord |
<mistere_123> Re core devs developing games, I hereby shill my idea from the forums "how to get more involvement" to have an officially developed game by the minetest team that is not in feature freeze, that does not intend to replicate minecraft, with the goal of showcasing and expanding what minetest can do. |
| 17:10 |
MTDiscord |
<mistere_123> Well, developed by the minetest github org, but of course accepting PRs from the community. |
| 17:17 |
[MTMatrix] |
<Zughy> I'm pretty sure core devs have enough of the repos they already maintain |
| 17:18 |
[MTMatrix] |
<Zughy> and if you put people like luatic, Wuzzy etc, you're still not having core devs coding it, so it's useless |
| 17:46 |
MTDiscord |
<warr1024> I don't know if forcing core devs to collaborate on a game is going to help the situation. It may just mean more core devs fighting over non-engine-related things, and less time for development, PR review, etc. At worst, it might even actually work, and then we could end up in a new MTG situation with the engine being developed to support just that one game again. |
| 17:57 |
MTDiscord |
<mecha_moonboy> What if it was pre-ordained that the game is put off maintenance after a period of time and a new project started with a new, engine-stretching premise. That's how Unity and Unreal both maintain user engagement, showcase new features, as well as soundboard ideas. |
| 17:58 |
MTDiscord |
<mecha_moonboy> It would mean that the devs would be consistently trying both not to back the engine into a corner, as well as broaden horizons for API featires. |
| 18:00 |
[MTMatrix] |
<Zughy> about the protocol version: another thing is, how can I know after how many versions we're gonna have MT 6.0? Will that happen after 5.9, after 5.14 or 5.21? It sounds like I have to remind myself to update my mod accordingly, which is not something I want to do |
| 18:03 |
MTDiscord |
<warr1024> I mean the realistic answer to "when 6.0" is "probably after we're all long dead" anyway, but how exactly is it relevant to your mods? Like, what are you planning to do for 6.0 without even knowing what changes 6.0 will actually bring? Backward compatibility is hard enough, knowing the past, but forward compatibility is a different beast... |
| 18:05 |
MTDiscord |
<luatic> The next version is 5.8 + 0.1 = 5.9. Every child knows that 5.9 + 0.1 = 6.0, duh. |
| 18:08 |
MTDiscord |
<warr1024> We recently upgraded our k8s cluster at work to 1.27.7 but didn't go all the way to 1.28, and I had to ask why we stopped when we were only 0.0.3 short 😏 |
| 18:11 |
MTDiscord |
<josiah_wi> I thought it was 6.9999999999999 |
| 18:14 |
[MTMatrix] |
<Zughy> warr1024: oh, right, 6.0 won't be compatible |
| 18:17 |
MTDiscord |
<warr1024> You still can't determine if 5.14 will be followed by 5.15 or will there be a 5.14.1 between, but in a way, they are actually BOTH successors to 5.15 and there is no real "between". |
| 18:18 |
[MTMatrix] |
<Zughy> I've decided I'm gonna ignore patch releases |
| 18:26 |
MTDiscord |
<warr1024> As long as you don't have to decide whether to install a workaround for something that's broken in 5.8.0 but fixed in 5.8.1, but 5.9.0 isn't out yet, that works. Once 5.9.0 is out, of course, it may still be fair to drop worrying about 5.8.1 anyway, though I've never personally had too much trouble with (minor > 8 or minor == 8 and revision > 0) type of checks (or better yet, having a proper semver library to do the compare). |
| 20:51 |
|
SpaceManiac joined #minetest-dev |
| 20:51 |
|
Desour joined #minetest-dev |
| 23:32 |
|
panwolfram joined #minetest-dev |
| 23:41 |
|
SpaceManiac joined #minetest-dev |
