Minetest logo

IRC log for #minetest-dev, 2021-09-16

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

All times shown according to UTC.

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

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