| Time |
Nick |
Message |
| 01:06 |
|
calcul0n joined #minetest-dev |
| 02:26 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:28 |
|
queria joined #minetest-dev |
| 02:33 |
|
queria joined #minetest-dev |
| 03:42 |
|
dzho joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:35 |
|
Kimapr[i] joined #minetest-dev |
| 04:38 |
|
dzho joined #minetest-dev |
| 05:10 |
|
MTDiscord1 joined #minetest-dev |
| 05:23 |
|
tekakutli joined #minetest-dev |
| 07:04 |
|
ssieb joined #minetest-dev |
| 07:14 |
|
specing_ joined #minetest-dev |
| 07:52 |
|
tekakutli joined #minetest-dev |
| 08:03 |
|
hendursa1 joined #minetest-dev |
| 08:06 |
|
hendursa2 joined #minetest-dev |
| 08:11 |
erlehmann |
i find it ridiculous that this has no core dev support. many humans have TWO HANDS! https://github.com/minetest/minetest/pull/11016/files |
| 08:11 |
erlehmann |
are there technical/engine limitations here? |
| 08:57 |
MTDiscord |
<Sublayer plank> the only limitation preventing dual wielding in the engine is the fact that PR hasn't been merged :P |
| 09:03 |
|
olliy joined #minetest-dev |
| 09:12 |
MTDiscord |
<Sublayer plank> seriously though from the comments it seems like people think a special condition for a second wield hand is too hardcoded to be an engine feature |
| 09:18 |
erlehmann |
Sublayer plank yeah but why? look how many hands you have. i would understand criticism that the patch should be able to add infinite hands! |
| 10:08 |
|
Kimapr[i] joined #minetest-dev |
| 10:26 |
|
calcul0n joined #minetest-dev |
| 10:37 |
|
tech_exorcist joined #minetest-dev |
| 11:37 |
erlehmann |
i am not sure if removing the software renderer is a good idea. is it because you can always use LIBGL_ALWAYS_SOFTWARE with mesa? |
| 11:40 |
erlehmann |
oh my |
| 11:42 |
erlehmann |
again, i think that “remove lots of unused features” PR should never ever have been approved. figure it out for yourself why it makes development harder, not easier, if you remove the *example* code, that shows how the library is used, and built. |
| 11:43 |
erlehmann |
“removing all unit tests” is also not a good idea. i am sure *some* of them tested features that are still in the library. |
| 11:43 |
erlehmann |
and how are you going to know these still work? |
| 11:45 |
MTDiscord |
<Sublayer plank> examples used a lot of the features unused by minetest and therefor removed |
| 11:45 |
erlehmann |
yeah you know the responsible thing is to NOT remove the tests that tests what minetest needs |
| 11:47 |
MTDiscord |
<Sublayer plank> I agree removing all unit tests was a bit too much though, but irrlicht is being progressively cut away until it's gone and absorbed into the engine, it's just a bit of a transitional period until that |
| 11:47 |
erlehmann |
uh nno |
| 11:47 |
MTDiscord |
<Sublayer plank> uh? |
| 11:48 |
MTDiscord |
<Sublayer plank> so it was a good thing all the unit tests got removed? |
| 11:49 |
erlehmann |
no, the “transitionary period” story is a story that devs tell themselves. i have never once in 15 years of development see it work out if a person refactoring rather deletes tests than putting in the effort. |
| 11:50 |
erlehmann |
here is what will happen: there will be no examples and no tests, for the foreseeable future. every preventable breakage will only be found by playing the game. |
| 11:50 |
erlehmann |
the reason for that is not that it is not doable |
| 11:51 |
erlehmann |
but cultural |
| 11:52 |
erlehmann |
basically, the only way to get test cases is to make anyone refactoring stuff write test cases … or have them already |
| 11:53 |
erlehmann |
it never directly hurts a program to ignore testing for new features |
| 11:53 |
erlehmann |
it hurts later |
| 11:53 |
erlehmann |
for example, i came up with a strategy to let a program spit out test cases for the texture bugs and integrate them into tests |
| 11:53 |
erlehmann |
fat chance i'll be able to do that when there aren't any tests |
| 11:54 |
erlehmann |
and the original once failed because of the gutting |
| 11:56 |
sfan5 |
nobody even knew how to run the original tests or if they worked |
| 11:57 |
erlehmann |
i just got something runnign |
| 11:57 |
erlehmann |
but i am on 5.4.1 |
| 12:00 |
sfan5 |
what? |
| 12:00 |
erlehmann |
all the stuff is in irrlichtmt in the past |
| 12:00 |
erlehmann |
don't worry, you'll get more crashes at some point |
| 12:01 |
sfan5 |
you're still not making any sense |
| 12:03 |
erlehmann |
i think i can use the old test cases, largely unnmodified, to find bugs at scale for everything tested. |
| 12:03 |
erlehmann |
and the old example code |
| 12:04 |
erlehmann |
sfan5 is hecktest planning to add new tests? |
| 12:05 |
sfan5 |
I don't think so |
| 12:05 |
erlehmann |
welllllllllllllll |
| 12:05 |
erlehmann |
but didn't hecktest want to rewrite the renderer? |
| 12:06 |
sfan5 |
and |
| 12:06 |
erlehmann |
well rewriting stuff *usually* needs exhaustive test cases for everything that worked before |
| 12:07 |
erlehmann |
i'm not sure how else it could work |
| 12:07 |
sfan5 |
you test it by hand |
| 12:11 |
erlehmann |
uh |
| 12:14 |
MTDiscord |
<Sublayer plank> the rendering rewrite is going to be separate to irrlicht right? like, it'd use the opengl context that hecks implemented into irrlichtmt that exposes opengl to the engine |
| 12:14 |
|
calcul0n_ joined #minetest-dev |
| 12:15 |
sfan5 |
afaik yes |
| 12:16 |
erlehmann |
you know what, i think “rewriting the renderer without tests” is a horrible suggestion, but i'm not going to try and change your mind right now. figure it out for yourself. good luck. |
| 12:17 |
erlehmann |
rationale: you approved hecks stuff so far, so you obviously thinking the breakage is worth something (haven't seen any of that, but i know how these stories go) |
| 12:21 |
sfan5 |
I think it's okay to do like this, yes |
| 12:23 |
sfan5 |
more tests would undoubtly be better but you have to consider the context and resources of an open-source project |
| 12:23 |
sfan5 |
differently worded: I'd rather have a better renderer and no tests than tests an the same bad renderer |
| 12:28 |
erlehmann |
i don't see how you can even approve a refactoring of that scale without any tests |
| 12:29 |
erlehmann |
like how would you make sure everything works … not just on the machine that hecks and core devs have |
| 12:29 |
erlehmann |
i mean shadows already broke stuff and however approved that obv did not have the time to test out everything |
| 12:29 |
erlehmann |
however → whoever |
| 12:30 |
erlehmann |
“I'd rather have a better renderer and no tests than tests an the same bad renderer” – this only works if reliability is of no concern |
| 12:31 |
erlehmann |
well, whatever, i'll keep submitting bug reports |
| 12:32 |
sfan5 |
where would your hypothetical tests run that they can cover more than the machines devs have access to? |
| 12:33 |
|
Kimapr[i] joined #minetest-dev |
| 12:36 |
erlehmann |
sfan5 does not matter. i just managed to instrument the irrlicht md2 example to an extent i can now autogenerate models that should be able to crash minetest. |
| 12:36 |
erlehmann |
the helloworld thing |
| 12:37 |
erlehmann |
and yes, i am aware that md2 support has been removed. i just wanted to see if the technique is viable |
| 12:37 |
erlehmann |
it's pretty slow though |
| 12:37 |
sfan5 |
which fuzzer are you using? |
| 12:37 |
erlehmann |
afl-fuzz |
| 12:37 |
erlehmann |
it's magic |
| 12:38 |
erlehmann |
but if you have ever used, you see why “test the entire program” does not work |
| 12:38 |
erlehmann |
you need to have proper unit tests |
| 12:38 |
erlehmann |
i mean it does work … very slowly |
| 12:38 |
erlehmann |
by which i mean it is infeasible |
| 12:47 |
pgimeno |
erlehmann: any luck crashing feh? |
| 12:48 |
sfan5 |
pgimeno btw https://github.com/minetest/minetest/pull/11615#issuecomment-918802164 |
| 12:49 |
|
adfeno_ joined #minetest-dev |
| 12:50 |
erlehmann |
pgimeno yes, years ago, try it yourself. it's not that hard. i'd rather have others learn that. look into how afl-fuzz works! |
| 12:52 |
adfeno_ |
Hi there, how do I disable itens from appearing on creative inventory? Is it possible to do via settings/settingtypes? Can it be done without depending on the mods explicitly? |
| 12:54 |
adfeno_ |
I see that there is minetest.override_item, and I haven't tested it but I'm afraid that if I were to do something such as groups={not_in_creative_inventory=1}, Minetest would erase all the groups for that item and only enable the one I used. |
| 12:55 |
sfan5 |
I don't think it does but test it |
| 12:55 |
adfeno_ |
(Well, not that the others matter much given they are in creative, but it is still worrying) |
| 12:59 |
adfeno_ |
Also, does minetest.registered_items include all other minetest.registered_{nodes,craftitems,tools} ? Or are them all separated sets? |
| 13:00 |
sfan5 |
a {node,tool,craftitem} is also an item |
| 13:00 |
sfan5 |
so yes |
| 13:01 |
adfeno_ |
Hm I see, thanks ;) |
| 13:13 |
|
hendursaga joined #minetest-dev |
| 13:30 |
|
Wuzzy joined #minetest-dev |
| 13:45 |
|
Taoki joined #minetest-dev |
| 14:06 |
|
calcul0n joined #minetest-dev |
| 14:12 |
pgimeno |
sfan5: updated #11615 with Wuzzy's suggestion, but note it's probably easier for you to amend the commit than to pull the changes |
| 14:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/11615 -- [MANUAL MERGE] Add an option `-t` to force text output in /help by sfan5 |
| 14:53 |
|
Fixer joined #minetest-dev |
| 15:08 |
|
v-rob joined #minetest-dev |
| 15:15 |
erlehmann |
pgimeno, why do you write “[MANUAL MERGE]” |
| 15:16 |
pgimeno |
I don't, read the post |
| 15:21 |
|
v-rob joined #minetest-dev |
| 15:30 |
erlehmann |
> don't squash when merging to preserve authorship |
| 15:30 |
erlehmann |
uh |
| 15:30 |
erlehmann |
why would anyone squash merge by default |
| 15:31 |
erlehmann |
i mean i have seen it already, but you need extreme discipline among committers and tiny PRs to have that work |
| 15:31 |
erlehmann |
otherwise it basically breaks any use of git revert and git bisect that are meaningful |
| 15:32 |
erlehmann |
i mean … the people who do that usually don't use bisect |
| 15:32 |
erlehmann |
so it just makes it horrible for someone else years later |
| 15:36 |
erlehmann |
i mean, it is kinda self-enforcing in a way |
| 15:36 |
erlehmann |
if you squash merge stuff that makes huge commits, git-bisect is useless and then anyone can say “why should we change it, it was never useful so far” |
| 15:38 |
erlehmann |
i mean, take irrlichtmt feature removal. if hecktest had made many small commits, you could give the unit tests to git bisect and let it figure out which commit breaks what and then decide if you want to revert it. |
| 15:38 |
erlehmann |
but right now bisect can only say “this big commit broke stuff” lol |
| 15:38 |
erlehmann |
which is something we already know |
| 15:56 |
|
v-rob joined #minetest-dev |
| 16:00 |
MTDiscord |
<josiah_wi> I try to discipline myself to make small commits in order to preserve the specific purpose of the different changes, so I don't particularly like the squashing, but I don't think complaining about it would help anyone. I'm not that good at making commits yet; I still have to push fixes for typos etc. that clutter the commit tree. Maybe if we all worked together to be professional in our commits and develop a unified commit style, |
| 16:00 |
MTDiscord |
people would hear us out about whether we want them squashed or not. |
| 16:01 |
erlehmann |
josiah_wi if you learn to interactive rebase it helps a lot |
| 16:02 |
erlehmann |
it is a pain to amend commits otherwise |
| 16:02 |
erlehmann |
by now i usually interactively rebase my stuff so the typos were never there hehe |
| 16:03 |
pgimeno |
@josiah_wi if you want your PRs to preserve the commits, add [NO SQUASH] to the title, but be ready to manually squash the commits resulting from the review |
| 16:03 |
erlehmann |
josiah_wi if you want to lie about the history that it never contained any typos (which i think is ok), read this: https://www.sitepoint.com/git-interactive-rebase-guide/ |
| 16:04 |
erlehmann |
but this is *never* ok on master, main or any other branch anyone relies on |
| 16:04 |
erlehmann |
not even if you warn them |
| 16:04 |
erlehmann |
so use it on your own branches to clean up or reorder commits only |
| 16:05 |
erlehmann |
and by “never ok” i mean, ofc you can get the consent of all involved, but that means “everyone who ever checked this branch out”, so it only works on a very short-term basis usually |
| 16:05 |
pgimeno |
@josiah_wi examples: #11253, #11262, #11289, #11584 |
| 16:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/11253 -- [NOSQUASH] CMake/Gui: organizational changes + some refacto commits by nerzhul |
| 16:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/11262 -- [NO SQUASH] Joystick sensitivity for player movement by NeroBurner |
| 16:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/11289 -- Minor fixes (don't squash) by sfan5 |
| 16:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/11584 -- [DONT SQUASH] CMake / CI maintenance by sfan5 |
| 16:05 |
erlehmann |
((it breaks git pull) |
| 16:07 |
erlehmann |
so next time you want to fix a typo on a branch (i.e. the typo is not on master yet), just use interactive rebase and rewrite the history from the point where it diverged from master |
| 16:07 |
erlehmann |
i mean rebase is useful in general |
| 16:07 |
erlehmann |
but many ppl submit PRs where at least a few of them are “fix typos” or “remove whitespace” |
| 16:07 |
erlehmann |
you know |
| 16:09 |
MTDiscord |
<josiah_wi> I'm pretty new to open source contribution yet, and working with other devs in general, but it seems like unity and consistency is important to work well together. Putting no squash on all my commits seems like it would abuse the the project's intended use of no squash, and make me stand out as doing things my own way. |
| 16:09 |
pgimeno |
not on all your commits, but in your PR |
| 16:10 |
erlehmann |
josiah_wi just do it, i doubt anyone will hold back telling you to do it differently if they think it is wrong. |
| 16:11 |
pgimeno |
Minetest's PRs are most often single-commit features, with the subsequent commits being amendments arising from the review. The natural action in these cases is to merge squashing. |
| 16:12 |
erlehmann |
pgimeno that is what i meant with discipline |
| 16:12 |
pgimeno |
erlehmann: why don't you read about minetest's procedures before ranting on what you ignore then? |
| 16:15 |
MTDiscord |
<josiah_wi> I've heard that the Minetest code is a mess, and I've observed and heard about a lot of disagreement that didn't seem professional to me. I've also heard that it's difficult for new developers without specific skills to get involved. I don't think it has to be this way. For this reason I don't intend to request PRs not be squashed that could perfectly well be squashed. |
| 16:16 |
|
Extex joined #minetest-dev |
| 16:16 |
erlehmann |
josiah_wi if you think it could be squashed, then do it! |
| 16:16 |
erlehmann |
sometimes development history is important, but projects differ on it. |
| 16:20 |
pgimeno |
I mean, you *do* want this squashed, for example: https://github.com/minetest/minetest/pull/10173/commits |
| 16:20 |
pgimeno |
it's most often easier for reviewers to look at what changed with respect to the previous commit, than to read the whole patch from the beginning again |
| 16:21 |
MTDiscord |
<josiah_wi> Slight change of topic, but how fast do you think we could get a working clang format script that we agree new commits should conform to, except by special exception; I know some people seem to feel strongly that there are times you should ignore the formatter if it improves readability. This doesn't include refactoring existing code. |
| 16:22 |
rubenwardy |
josiah_wi: minetest's code style is way too particular, and there's way too much code to go and find all the edge cases |
| 16:25 |
MTDiscord |
<josiah_wi> So you're saying clang format isn't capable of representing our code style? Perhaps we could agree to remove clang format altogether. |
| 16:26 |
MTDiscord |
<josiah_wi> Sorry, that was rude. I'm just looking for a clarification of your point. |
| 16:27 |
erlehmann |
pgimeno you are right, i should read up on stuff before going on anyones nerves |
| 16:28 |
erlehmann |
pgimeno i guess i have focussed too much on the negatives bc the project is full of holes, i should look at what is working! |
| 16:32 |
MTDiscord |
<josiah_wi> Discussing holes doesn't have to be negative. Finding bugs is an opportunity to make the project even better, no? |
| 16:34 |
erlehmann |
josiah_wi the point is i am at the same time poking at the wounds while not knowing enough about How Its Done™ and asking around, while the first is helpful, the second one is not necessarily |
| 16:35 |
erlehmann |
i.e. if i want ppl to read what i write i should not waste their time |
| 16:36 |
pgimeno |
@josiah_wi yes but following due process, i.e. submiting bug reports, not ranting |
| 16:37 |
erlehmann |
just found a b3d file that seems to hang minetest 5.4.1 clients, bug report coming soon |
| 16:44 |
sfan5 |
we don't take bug reports for 5.4.1 |
| 16:44 |
sfan5 |
unless the same bug also exists in 5.5-dev of course |
| 16:45 |
sfan5 |
(don't take that literally, I'm just mentioning it because I know you have the ability to test on 5.5) |
| 16:46 |
sfan5 |
pgimeno: pulled |
| 16:48 |
MTDiscord |
<josiah_wi> In any case, if I can get people interested I'd like to demonstrate that it's possible to clean things up (and I mean actually cleaning, not just axing stuff) by coming to a decision about clang format and implementing it. The benefit from having a code style tool comes from being able to double check your style and format it very quickly. We already have a code style, and to my knowledge style guidelines for contributing aren't |
| 16:48 |
MTDiscord |
supposed to be optional. It doesn't have to be clang format, and we don't even need to have a style tool, but having a broken one sitting around taking up space seems a shame. |
| 16:50 |
erlehmann |
sfan5 look i have very little energy rn, very little time … and the build system is extremely not helping. i am currently recompiling stuff, but i will report that bug probably against 5.4.1 and deliver a very simple test case you can stuff into your test client. |
| 16:50 |
sfan5 |
that's okay |
| 16:51 |
erlehmann |
like a mod that hangs clients |
| 16:52 |
erlehmann |
also my bug-finding setup relies on irrlicht having its example code intact, so … well … |
| 16:53 |
erlehmann |
i'll probably ruin it if i build 5.5-dev rn |
| 16:53 |
sfan5 |
I doubt yet setup requires all 30 or so example apps from Irrlicht to work |
| 16:53 |
sfan5 |
your* |
| 16:53 |
sfan5 |
https://0x0.st/-3Hm.png github does not like my usecase >.> |
| 16:55 |
erlehmann |
sfan5 i basically chose the first example and told afl-fuzz to work its magic on it – and that means, it needed to actually compile and be able to load the example b3d model. since the example code, the b3d model and probably a huge chunk of irrlicht that would make it compile … have been removed … i don't see myself doing that for any newer version. |
| 16:56 |
erlehmann |
sfan5, btw, removing the software renderer was entirely legit, it sucks big time |
| 16:56 |
erlehmann |
(just so you know i do agree with gutting stuff that does not work correctly) |
| 16:57 |
erlehmann |
(and does not have a superior alternative, like LIBGL_ALWAYS_SOFTWARE=1) |
| 16:57 |
sfan5 |
https://github.com/minetest/irrlicht/blob/master/examples/AutomatedTest/main.cpp#L48-L50 loading a model on irrmt is just as easy |
| 16:59 |
erlehmann |
sfan5 i see, thx. is this the only test case that remains? |
| 16:59 |
sfan5 |
yes |
| 17:00 |
erlehmann |
why? |
| 17:00 |
erlehmann |
what makes it so special? |
| 17:00 |
erlehmann |
is it a collection of all things that should still work? |
| 17:00 |
sfan5 |
we wrote it ourselves |
| 17:00 |
erlehmann |
ah ok |
| 17:00 |
MTDiscord |
<Sublayer plank> it's automatically tested by CI on each commit |
| 17:01 |
erlehmann |
nice. if i wanted to extend that (in particular, make it so that there are X tests for X features so they can be instrumented), where to start reading up on it? |
| 17:01 |
erlehmann |
like what is the command the CI runs? |
| 17:02 |
erlehmann |
(if it is a shell script, i could start there) |
| 17:02 |
sfan5 |
https://github.com/minetest/irrlicht/blob/master/.github/workflows/build.yml#L50 |
| 17:02 |
erlehmann |
thx |
| 17:02 |
MTDiscord |
<Sublayer plank> https://github.com/minetest/irrlicht/blob/master/.github/workflows/build.yml |
| 17:02 |
MTDiscord |
<Sublayer plank> oh whoops |
| 17:02 |
MTDiscord |
<Sublayer plank> ninja'd :P |
| 17:03 |
sfan5 |
it tests three extremely basic things right now, I don't see how you could easily expand it to test e.g. graphics related stuff |
| 17:03 |
|
calcul0n_ joined #minetest-dev |
| 17:03 |
sfan5 |
where "tests" = doesn't crash and maybe it even checks the result |
| 17:03 |
erlehmann |
sfan5, why would it not be easily expandable? have a bunch of binaries that either render a single frame or crash? |
| 17:04 |
sfan5 |
well how do you check the frame for correctness |
| 17:04 |
erlehmann |
well, that's a question that comes after “does it even run before crashing” |
| 17:05 |
erlehmann |
i am mostly concerned with someone ripping out something and not noticing |
| 17:05 |
erlehmann |
if they have to delete the corresponding test case for a feature to be removed so the CI lets them, then they DO know. |
| 17:06 |
sfan5 |
in what way? if you remove a function definition code that does use it won't compile |
| 17:06 |
sfan5 |
and the code that uses it here would be in Minetest |
| 17:06 |
|
v-rob joined #minetest-dev |
| 17:07 |
erlehmann |
there are lots of ways stuff can compile and still crash. i would, for example, advocate to put in each media file that causes a crash or hang as a test case. |
| 17:07 |
erlehmann |
to make sure refactorings do not reintroduce the bug |
| 17:07 |
sfan5 |
that's not a bad idea but there are much more relevant things that could be tested |
| 17:07 |
erlehmann |
i have no good answer to “how to verify the frame” btw |
| 17:08 |
erlehmann |
what would you want to test? |
| 17:08 |
sfan5 |
take for example spritesheets animations, they are currently broken in Irrlicht 1.9 (presumably they don't have a test case for them either) |
| 17:09 |
sfan5 |
as far as I have looked at it the bug is "just" forgetting to load the texture matrix |
| 17:09 |
sfan5 |
so you'd want to catch such basic things with a test that sets up an animated scene nodes, renders, steps time and verifies changes |
| 17:11 |
sfan5 |
pgimeno: btw you forgot to account for CSM, I'll be fixing this myself https://0x0.st/-3H_.txt |
| 17:12 |
erlehmann |
sfan5, obv you have a better grasp on that than i do |
| 17:12 |
sfan5 |
if you think I know lots (or even a medium amount) about OpenGL you're mistaken |
| 17:13 |
erlehmann |
don't worry, i already assume everyone (including me and the original authors of irrlicht) has no idea what they are doing most of the time |
| 17:41 |
pgimeno |
sfan5: maybe csm should have a get_player_by_name()? (obviously not within the scope of the PR, I know) |
| 17:42 |
pgimeno |
I have never used CSM so I don't really know about its limitations, sorry about that |
| 17:42 |
MTDiscord |
<luatic> I actually prefer it if clients can't distinguish players and entities |
| 17:45 |
|
erle joined #minetest-dev |
| 17:45 |
erle |
luatic they need to for stuff like teamchat |
| 17:46 |
|
appguru joined #minetest-dev |
| 17:49 |
erlehmann |
pgimeno you can look at some of the battle-tested CSMs here: https://repo.or.cz/waspsaliva.git/tree/HEAD:/clientmods |
| 17:51 |
MTDiscord |
<luatic> erlehmann: no they don't need to |
| 17:51 |
erlehmann |
luatic how are you going to do “send this message to players near me” then? |
| 17:51 |
MTDiscord |
<luatic> not as a client mod |
| 17:52 |
erlehmann |
you know what |
| 17:53 |
erlehmann |
if you can't distinguish between players and other entities then one really important use case for CSMs becomes dangerous |
| 17:53 |
erlehmann |
“punch every entity” |
| 17:53 |
erlehmann |
used for a) killaura b) better item pickup on laggy servers |
| 17:53 |
erlehmann |
i have seen the second use case much more |
| 17:54 |
sfan5 |
ruining cheat client users' ability to do thing makes implementing suddenly much more appealing |
| 17:54 |
sfan5 |
+this |
| 17:54 |
erlehmann |
killaura can easily be detected though |
| 17:55 |
erlehmann |
if someone punches inhumanely fast, cheater |
| 17:55 |
|
cora joined #minetest-dev |
| 17:55 |
erlehmann |
for an example of how it is done btw: https://repo.or.cz/waspsaliva.git/blob/HEAD:/clientmods/autoaim/init.lua |
| 17:55 |
cora |
hey guys :) |
| 17:55 |
erlehmann |
> for k, v in ipairs(minetest.localplayer.get_nearby_objects(10)) do |
| 17:55 |
sfan5 |
the player distinction doesn't matter that much really, no normal entity will have a texture called character.png |
| 17:55 |
erlehmann |
> if (v:is_player() and v:get_name() ~= minetest.localplayer:get_name()) then |
| 17:56 |
MTDiscord |
<luatic> sfan5: but they can |
| 17:56 |
cora |
i cant comment on discord: i'm just honestly interested: for what exactly is vanilla csm supposed to be used ? |
| 17:56 |
MTDiscord |
<luatic> I was planning anticheat as tricking cheat clients into punching fake player entities |
| 17:56 |
MTDiscord |
<luatic> but of course that's not gonna work if players can simply distinguish the two |
| 17:56 |
sfan5 |
it wasn't intended for anything really, it just kinda exists |
| 17:56 |
sfan5 |
SSCSM was the plan from the beginning but about following plans... |
| 17:57 |
sfan5 |
what it can be reasonably used for is chat-enhancing mods |
| 17:57 |
MTDiscord |
<luatic> SSCSM is probably bad for anticheat too... |
| 17:57 |
cora |
oh yeah ok |
| 17:57 |
cora |
that makes some sense i guess |
| 17:58 |
cora |
fair (/re chat enhancements) |
| 17:58 |
erlehmann |
sfan5, would you say fried and enemy lists and autocoloring their nametags client side (red / blue) would be good? |
| 17:58 |
MTDiscord |
<luatic> Well, every time something is offloaded to the client, cheaters benefit a bit. |
| 17:58 |
Pexin |
theres also waypoint/teleport help stuff that only works if the player has appropriate privs |
| 17:58 |
cora |
teamchat prob works 90% on vanilla |
| 17:58 |
erlehmann |
i bet faction servers would LOVE that |
| 17:58 |
MTDiscord |
<luatic> I prefer it if red/blue team is clear. |
| 17:59 |
MTDiscord |
<luatic> Absolute colors instead of relative ones that is. |
| 17:59 |
sfan5 |
erlehmann: my general stance is that it's good if the server admin is okay with people doing that |
| 17:59 |
erlehmann |
luatic you are obviously not thinking of cases where there are no official teams |
| 17:59 |
MTDiscord |
<luatic> Also note that with a modded engine, that should already be possible ;) |
| 17:59 |
cora |
i agree |
| 17:59 |
erlehmann |
sfan5, we already have haxnotify for that |
| 17:59 |
MTDiscord |
<luatic> You can just send different nametag colors out to different players |
| 17:59 |
cora |
well the custom version string is prob more helpful tbh |
| 17:59 |
erlehmann |
sfan5 waspsaliva chats “HEY EVERYONE I AM USING A HACKED CLIENT” |
| 17:59 |
cora |
you can just disable the haxnotify csm |
| 18:00 |
MTDiscord |
<luatic> Yeah, waspsaliva might be a well made client with (minor) abuse protection |
| 18:00 |
MTDiscord |
<luatic> But there's other clients |
| 18:00 |
cora |
i was actually thinking of doing sth more sneaky |
| 18:00 |
MTDiscord |
<luatic> Please do |
| 18:00 |
erlehmann |
i think “let's not enhace vanilla bc cheaters might abuse it” is a ridiculous stance, cheaters can always have a better client. the protection needs to be on the server, so the client does not matter. |
| 18:00 |
cora |
but knowing server admins they wouldnt even implement it :P |
| 18:01 |
erlehmann |
cora assuming i know what you mean, it would be defeated the moment server admins knew how to detect it |
| 18:01 |
cora |
yes that would be ideal (doing it on the server) |
| 18:01 |
MTDiscord |
<luatic> I'm not saying "let's not enhance vanilla", I'm saying "enhance vanilla but keep server authority", because that makes implementing serverside "protection" as you call it easier. |
| 18:02 |
erlehmann |
who is harmed by users having friend/enemy lists on servers? |
| 18:02 |
erlehmann |
or team chat |
| 18:02 |
cora |
yeah you might be right |
| 18:02 |
erlehmann |
based on that |
| 18:02 |
cora |
its totally based on obscurity |
| 18:03 |
cora |
uh according to the api.txt get_player_names() exists in vanilla though |
| 18:04 |
Pexin |
I have made debugging CSMs that, for example, query the light level at a specified node |
| 18:04 |
erlehmann |
sfan5 coming from an IT security perspective, the server admin has no business knowing who is on whose friend or enemy list and it represents a liability (if it gets leaked, stuff is weird) |
| 18:04 |
cora |
o yeah for debugging it can be p helpful - even more so if you can interact with entities and items ^^ |
| 18:05 |
Pexin |
is it possible for CSM to find entities? I must have missed that |
| 18:05 |
erlehmann |
btw, if vanilla had the capabilities of waspsaliva, one could make csms that speedrun the game basically |
| 18:05 |
erlehmann |
to figure out if it is still working |
| 18:05 |
erlehmann |
on each commit |
| 18:05 |
|
appguru joined #minetest-dev |
| 18:05 |
cora |
Pexin, no |
| 18:05 |
cora |
thats basically the 2 big things we added to csm api |
| 18:06 |
erlehmann |
Pexin you should obv use hax |
| 18:06 |
Pexin |
there have been several times I wanted to make a CSM that could insert player actions |
| 18:07 |
Pexin |
having a whole optional bot api would be sweeeet. "this server is for botwars" |
| 18:08 |
cora |
https://repo.or.cz/waspsaliva.git/blob/HEAD:/src/script/lua_api/l_clientobject.cpp |
| 18:08 |
cora |
https://repo.or.cz/waspsaliva.git/blob/HEAD:/src/script/lua_api/l_inventoryaction.cpp |
| 18:09 |
erlehmann |
sfan5 look you can just IFDEF the cheaty actions and never make a release with it. will help much more with debugging than it will enable cheating. |
| 18:11 |
erlehmann |
sfan5 also it would make developing anticheat much easier |
| 18:12 |
sfan5 |
what are you trying to convince me of |
| 18:13 |
sfan5 |
minetest already has "cheat" features hidden behind the debug privilege |
| 18:13 |
cora |
to merge all our cheaty cpp stuff so we can do everything in lua :P |
| 18:13 |
erlehmann |
oh right |
| 18:13 |
erlehmann |
yes i'd definitely use it for CI purposes |
| 18:14 |
erlehmann |
sfan5 i see, hiding the APIs behind the debug priv would be much neater |
| 18:19 |
|
v-rob joined #minetest-dev |
| 18:33 |
erlehmann |
sfan5 https://github.com/minetest/minetest/issues/11633 |
| 18:35 |
sfan5 |
it indeed still happens on 5.5 |
| 18:36 |
erlehmann |
sfan5, pls add that to the ticket then |
| 18:37 |
erlehmann |
a good result of the file format massacre: less stuff to break |
| 18:39 |
MTDiscord |
<luatic> What's up with "You can't comment at this time. " |
| 18:39 |
MTDiscord |
<luatic> (on GitHub) |
| 18:39 |
erlehmann |
where? |
| 18:40 |
MTDiscord |
<luatic> Your bad3d isssue |
| 18:40 |
MTDiscord |
<luatic> anyways, I'm just gonna say it here: |
| 18:40 |
MTDiscord |
<luatic> This is interesting. I had to try modlib's B3D reader (which is written in Lua) at it, and it crashed as expected. It seems the file contains a chunk of invalid type. I suppose Irrlicht doesn't handle this case. |
| 18:40 |
erlehmann |
maybe bc sfan5 moved it to irrlichtmt? |
| 18:40 |
MTDiscord |
<luatic> ohh |
| 18:40 |
erlehmann |
i bet github stupid |
| 18:41 |
MTDiscord |
<luatic> apparently yes |
| 18:41 |
erlehmann |
pls comment it there as well |
| 18:41 |
erlehmann |
for future reference |
| 18:43 |
erlehmann |
well i can put it there |
| 18:43 |
erlehmann |
or not |
| 18:43 |
erlehmann |
You can't comment at this time |
| 18:43 |
erlehmann |
lol |
| 18:43 |
erlehmann |
ok now |
| 18:43 |
MTDiscord |
<luatic> lol |
| 18:43 |
erlehmann |
i put both sfan5 and luatic comments there |
| 18:44 |
erlehmann |
appguruea will be sued for plagiarizing luatic |
| 18:44 |
erlehmann |
or are you the same person |
| 18:44 |
MTDiscord |
<luatic> lol |
| 18:45 |
MTDiscord |
<luatic> I am lol |
| 18:45 |
erlehmann |
anyone could say that |
| 18:45 |
MTDiscord |
<luatic> indeed |
| 18:46 |
|
appguru joined #minetest-dev |
| 18:46 |
appguru |
But what about my registered IRC account saying it? |
| 18:47 |
erlehmann |
ok i believe you |
| 18:48 |
erlehmann |
i guess your irc account will not be demonetized today |
| 18:48 |
Pexin |
we are all Kosh |
| 18:51 |
MTDiscord |
<luatic> Irrlicht's B3D reader has a gross length if you ask me: About 1k lines. For reference, the original Blitz loader is a mere 300 something lines of not even C++, but plain C: https://github.com/blitz-research/blitz3d/blob/master/blitz3d/loader_b3d.cpp |
| 18:51 |
MTDiscord |
<luatic> But it seems they do check for invalid chunk types. |
| 18:52 |
erlehmann |
there is only one way to be sure, full recognition before processing |
| 18:52 |
erlehmann |
length does not matter, rather complexity |
| 18:57 |
|
longerstaff13 joined #minetest-dev |
| 19:13 |
|
specing_ joined #minetest-dev |
| 19:17 |
rubenwardy |
<cora> i cant comment on discord: i'm just honestly interested: for what exactly is vanilla csm supposed to be used ? |
| 19:17 |
rubenwardy |
https://dev.minetest.net/Client_scripting_plans |
| 19:17 |
rubenwardy |
(written pre CSM) |
| 19:17 |
cora |
oh thanks |
| 19:18 |
erlehmann |
> Unlike with Web browsers, Lua code should run in a separate thread. Also, to be completely separate, it shouldn't share the Lua environment with the mainmenu Lua (to forestall intra-environment exploits). |
| 19:18 |
erlehmann |
good luck |
| 19:18 |
erlehmann |
> there will be no way (without changing C++ source code) to execute code outside of that sandbox |
| 19:19 |
erlehmann |
[press x to doubt] |
| 19:20 |
erlehmann |
good that you do not want to send bytecode though |
| 19:20 |
erlehmann |
that would make it much easier to exploit |
| 19:20 |
rubenwardy |
bytecode is already blocked by both sandboxes |
| 19:22 |
rubenwardy |
there are number of issues discussing various aspects of introducing ~~RCEs~~ SSCSMs |
| 19:22 |
Krock |
sfan5: what would you think about using DISABLE_CLASS_COPY in Buffer, and introducing an explicit copyTo() function? |
| 19:23 |
Krock |
in regard to #11607 |
| 19:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/11607 -- Shave off buffer copies in networking code by sfan5 |
| 19:24 |
erlehmann |
rubenwardy as i said, if the server starts to execute code on the client, the client should send code back |
| 19:24 |
erlehmann |
just make them equals |
| 19:25 |
rubenwardy |
the server-side sandbox isn't designed to be completely secure - it has the insecure environment, for example |
| 19:26 |
rubenwardy |
clients are also less trusted in terms of making gameplay decisions, and servers can contain sensitive data like IP addresses and SRP hashes |
| 19:27 |
erlehmann |
oh i don't mean the sandbox |
| 19:27 |
|
ssieb joined #minetest-dev |
| 19:28 |
rubenwardy |
anyway, SSCSM is notably missing from the roadmap for a reason. It will be hard to get it right, and there's more important stuff with greater benefits to do first |
| 19:28 |
rubenwardy |
for example, I should finally finish that Android PR |
| 19:28 |
rubenwardy |
as soon as I can be bothered to Java |
| 19:30 |
Krock |
writing patch..... |
| 19:30 |
cora |
cant wait for sscmsm ^^ |
| 19:30 |
erlehmann |
Krock, for what? |
| 19:30 |
Krock |
erlehmann: last message |
| 19:32 |
Krock |
found one more class copy |
| 19:39 |
erlehmann |
quick question about this, am i really weird or is “-2147483648 >= 1” a normal thing to expect from C++? https://github.com/minetest/minetest/issues/11620#issuecomment-921175826 |
| 19:44 |
Krock |
afaik it's undefined behaviour for signed numbers, but in terms of binary representation it's not surprising at all |
| 19:45 |
erlehmann |
Krock -2147483648 is negative. 1 is positive. how can it be bigger? |
| 19:49 |
rubenwardy |
quick maths |
| 19:50 |
Krock |
erlehmann: "i + INT_MAX" standalone evaluates to integer, however within the comparator they seem to use 64-bit registers |
| 19:50 |
Krock |
or it's because the overflow bit is set |
| 19:52 |
|
appguru joined #minetest-dev |
| 19:52 |
appguru |
I'd appreciate it if #11427 was looked at, it's still very much ready for review and IMO mergeable. |
| 19:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/11427 -- Redo serialize.lua by appgurueu |
| 19:53 |
|
v-rob joined #minetest-dev |
| 19:55 |
erlehmann |
Krock the actual answer is something else entirely, the optimizer is allowed to do anything and just randomly chooses this branch |
| 19:55 |
erlehmann |
Krock, by which i mean it can change based on moon phase or whatever |
| 19:55 |
Krock |
then it's not a good RNG |
| 19:55 |
erlehmann |
“randomly” as in, you won't be able to guess it |
| 19:56 |
Krock |
then why is it always the same branch? :P |
| 19:56 |
erlehmann |
Krock, the other one is optimized out |
| 19:56 |
erlehmann |
https://blog.regehr.org/archives/140 |
| 19:56 |
erlehmann |
> This loop only terminates if it finds a counterexample to a special case of Fermat’s Last Theorem. |
| 19:56 |
erlehmann |
> It turns out that when optimizations are enabled, several compilers (LLVM/Clang 2.7, Open64-x86 4.2.3, Sun CC 5.10, and Intel CC 11.1.072) go ahead and permit this loop to terminate. |
| 19:57 |
erlehmann |
> Faced with this incredible mathematical discovery, I held my breath and added a line of code at the end of the function to print the counterexample: the values of a, b, and c. Unfortunately, with their bluffs called in this fashion, all of the compilers emitted code that actually performed the requested computation, which of course does not terminate. |
| 19:57 |
Krock |
ah yes. can confirm with Ghidra |
| 19:57 |
erlehmann |
Krock, as soon as you compile my example code with “-fsanitize=undefined”, the compiler chooses the other branch |
| 19:58 |
erlehmann |
i have to go |
| 19:58 |
Krock |
https://i.postimg.cc/vH8BZcGC/grafik.png |
| 19:58 |
erlehmann |
will be back in 1 hour or more |
| 19:59 |
erlehmann |
Krock obv neither of us knows basketball basketball |
| 20:16 |
Krock |
dear lord |
| 20:17 |
Krock |
minetest deep copies all timed out packages |
| 20:24 |
sfan5 |
Krock: I think that would break stdlib containers |
| 20:25 |
MTDiscord |
<Jordach> you could run it in browser with the compiler explorer right |
| 20:28 |
sfan5 |
appguru: "if a priority queue was used to implement minetest.after" doesn't it do that? |
| 20:28 |
|
Extex joined #minetest-dev |
| 20:28 |
appguru |
No it does not do that |
| 20:28 |
Krock |
sfan5: https://krock-works.uk.to/u/patches/0001-Delete-copy-constructor.patch |
| 20:28 |
Krock |
did a quick test and it seems to work okay so far |
| 20:29 |
appguru |
minetest.after is implemented in Lua in a straightforward way: see https://stackoverflow.com/a/8236407/7185318 |
| 20:29 |
appguru |
it simply keeps an unordered list of all callbacks and iterates it in reverse order |
| 20:29 |
Krock |
it's easier to search for copyTo() |
| 20:30 |
sfan5 |
ah if it's for searching maybe marking with __attribute__((deprecated)) works |
| 20:30 |
sfan5 |
it should throw a warning on every use |
| 20:31 |
Krock |
deprecating an operator overload and constructor? that's an interesting idea |
| 20:32 |
sfan5 |
+return std::move(m_event_queue.pop_front(timeout_ms)); |
| 20:32 |
|
nore joined #minetest-dev |
| 20:32 |
sfan5 |
I remember reading that is this pointless (if not counterproductive) because copy elision already does this |
| 20:34 |
Krock |
oh right |
| 20:34 |
Krock |
I wonder why I got errors on that previously... no idea what's changed now |
| 20:34 |
sfan5 |
since I just looked for the link anyway here's the thing https://en.cppreference.com/w/cpp/language/copy_elision |
| 20:35 |
Krock |
good to know. thank you! |
| 20:36 |
sfan5 |
@luatic I think you linked the wrong SO answer there |
| 20:36 |
Krock |
confirmed that the patch works by connecting and playing on Blocky Survival |
| 20:43 |
Krock |
I updated the patch file accordingly (Ctrl + F5 reload). Feel free to add it to your PR, or I'll open a separate one afterwards |
| 20:45 |
sfan5 |
separately is more convenient for me |
| 20:45 |
sfan5 |
;) |
| 21:02 |
rubenwardy |
disabling the copy constructor makes more sense than deprecated it |
| 21:03 |
|
v-rob joined #minetest-dev |
| 21:04 |
sfan5 |
sure, the latter is just a less intrusive way of discovering usage |
| 22:23 |
erlehmann |
Krock, do you have a test that proves/suggests this thing behaves the same afterwards as before or that it fixes some error? |
| 23:05 |
|
v-rob joined #minetest-dev |
| 23:07 |
|
corarona joined #minetest-dev |
