Minetest logo

IRC log for #minetest-dev, 2023-05-31

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

All times shown according to UTC.

Time Nick Message
01:01 YuGiOhJCJ joined #minetest-dev
01:07 ShadowBot joined #minetest-dev
03:38 celeron55 fyi: i'm on road trip in central europe. at north west germany today and headed to france this week and then probably towards the alps from there. if anyone would like to have a quick meet-up let me know
03:44 celeron55 hmm, well we might be south west bound for up to two weeks and then have to get back to where we started. that's pretty much the full the extent of the plan
03:49 celeron55 i won't have a lot of time to check on irc or anything so if you want to make damn sure to see me then email me
04:00 MTDiscord joined #minetest-dev
05:12 calcul0n_ joined #minetest-dev
05:24 srifqi joined #minetest-dev
05:25 srifqi hello. merging #13526 in 5 minutes
05:25 ShadowBot https://github.com/minetest/minetest/issues/13526 -- Option to invert direction or disable mouse wheel for hotbar item selection by srifqi
05:30 srifqi done
05:32 srifqi uh ... i think i made a mistake
05:32 srifqi it should be squash and merge, isn't it?
05:35 srifqi ... and i broke the PR on GitHub
05:38 srifqi i'll do manual push then in 2 minutes
05:40 srifqi done
05:41 srifqi ah wait
05:42 srifqi now, it should be done. sorry for the fuss and confusion
06:30 appguru joined #minetest-dev
06:38 Warr1024 joined #minetest-dev
06:52 YuGiOhJCJ joined #minetest-dev
07:07 tekakutli joined #minetest-dev
08:10 tekakutli joined #minetest-dev
10:21 Alias joined #minetest-dev
10:39 appguru joined #minetest-dev
11:28 proller joined #minetest-dev
11:39 Zughy[m] srifqi: if a rebase is needed, please tell the user (aside applying the rebase needed label) or they won't be able to know
11:40 srifqi joined #minetest-dev
11:40 srifqi okay. thank you for reminding me
12:20 srifqi hello. i want to ask about the merging process and about the "Rebase needed" label.
12:20 srifqi (1) if i understand correctly, the merging process consists of rebase, squash, and then merge, am I right?
12:20 srifqi (2) i also found some PR that is labeled merge-able by GitHub, but i can not rebase it into recent master branch. how to deal with that case?
12:20 srifqi the usual way i test a PR is by rebasing the PR first and then test it.
12:29 MTDiscord <MisterE> Hey, @Slimeist / apprentice : I had a thought regarding VAE:  its not supposed to simply be another entity display style, there was theoretically supposed to be some kind of physics benefit, where walking (colliding) on the entity was about as consistent / stable as walking on normal nodes
12:29 MTDiscord <MisterE> And where the collisionbox was defined by the nodes
12:40 proller joined #minetest-dev
13:14 apprentice Ah, yes @MisterE. my wording of 'simply' may not have been the best - I certainly plan to have an (optional) collision option
13:14 apprentice however - do we want 2 VAEs to collide in a node-based way? Because that could quickly get *very* expensive
13:16 MTDiscord <MisterE> Seems like that should be optional as well, with a warning
13:18 MTDiscord <MisterE> Since, there are usecases for that, such as ship battles, where you do want collision info so as to destroy part of the ships.
13:19 MTDiscord <MisterE> But other usecases where you don't need node collisions
13:23 MTDiscord <MisterE> Couldn't it be simplified, where each node is a sphere/point? Only check node collisions near the collision area?
13:24 MTDiscord <MisterE> See if the node spheres overlap
13:24 apprentice there are certainly optimizations that would be made - still fairly complex though - especially since VAEs can rotate just as well as any other entity
13:26 MTDiscord <MisterE> well, it would seem that various levels of collision simulation with their various levels of computation should be optional so modders can pick the least expensive solution for their usecase
13:31 MTDiscord <MisterE> For non-battling ships, simple rectangular VAE-VAE collision would be sufficient.  Unless you wanted realism, then, the possibilities are quite amazing, at the cost of computation
13:31 apprentice yeah certainly. first to get reliable rendering though - the little teaser I showed was copying a chunk mesh into the entity, which isn't the best solution (I realized later) because it skips all the normal rendering optimizations, as well as being a potential problem for transparency - which isn't available as a full-fledged mesh, only some buffers. So now I'm switching to an approach where clientmap.cpp collects VAEs for ren
13:31 apprentice g.
13:31 apprentice After that, the next required step is allowing 'outside of view distance' chunks to be sent to the client if they are used in a VAE.
13:31 apprentice Once that is all done, we can get to collision
13:32 apprentice s/reng/rendering
13:33 MTDiscord <MisterE> If you need testing (with experimental lua apis), let me know
13:36 apprentice certainly. I also got some advice on collision algorithms, and got two recommended by the Create: Aeronautics devs: "Separating Axis Theorem or Gilbert Johnson Keerthi + Expanding polytope algorithm"
13:36 apprentice Yes, please don't throw me to the wolves, I am an active Minecraft modder as well
13:37 proller joined #minetest-dev
13:41 pgimeno srifqi: about (1) yes, though the "Rebase and squash" button does everything for you. Also, once you have rebased a branch onto master, merging that branch should just consist of moving the pointer of 'master' to the last commit, That's what in git terms is called a fast-forward (option --ff-only in `git merge`). In Minetest master, you should never introduce a merge commit.
13:42 pgimeno about (2), can you cite an example?
13:45 pgimeno in the PR, the Merge button is actually a selection, last time I checked (a few years ago) you could change it between Merge, Squash And Rebase, or Rebase
13:45 srifqi wait, i forgot which PR is it
13:46 pgimeno in Minetest you usually do Squash and Rebase, except if the title of the PR says [NO SQUASH]
13:47 pgimeno in that case you do just Rebase
13:47 pgimeno please a core dev correct me if I'm wrong, it's long since I left github and things may have changed since
13:57 proller joined #minetest-dev
14:00 srifqi oh, never mind. i guess, it was a bug on GitHub interface. it was #13146 that was problematic
14:00 ShadowBot https://github.com/minetest/minetest/issues/13146 -- Inventory mouse shortcut improvements by OgelGames
14:14 srifqi thank you for the answer
14:24 proller joined #minetest-dev
14:28 imi joined #minetest-dev
14:38 Zughy[m] srifqi: about (2), there is no need to rebase it to recent master if there are no conflicts. In short, #13146 doesn't need a rebase
14:38 ShadowBot https://github.com/minetest/minetest/issues/13146 -- Inventory mouse shortcut improvements by OgelGames
14:45 fluxionary joined #minetest-dev
14:45 srifqi joined #minetest-dev
14:45 srifqi "This branch cannot be rebased due to conflicts"
14:47 srifqi (said GitHub)
14:47 srifqi ... and I also can not rebase it manually since there are merge conflicts.
14:50 srifqi Zughy[m]: can i retain my request for a rebase?
14:54 Zughy[m] that's what I see
14:54 * Zughy[m] uploaded an image: (22KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/WBRaKumnnTGZAskIyViMAKWW/image.png >
14:54 Zughy[m] Idk how IRC displays sent pictures
14:56 Desour joined #minetest-dev
14:57 Desour srifqi: you usually first squash, and then rebase the single commit
14:58 srifqi Desour: is that manually (using a Git client) instead of using GitHub interface?
14:58 apprentice new clientmap-based rendering system starting to take shape: https://cdn.discordapp.com/attachments/369137254641303560/1113481525292437634/screenshot_20230531_075719.png
14:58 Desour this is also what github does with the squash merge option. it depends on what option you choose (with or without squash) whether it's fast-forward mergabl
14:58 Desour e
14:58 Desour both
15:00 MTDiscord <srifqi> https://cdn.discordapp.com/attachments/747163566800633906/1113482039996448849/13146-conflict.png
15:00 srifqi i sent an image via Discord about what i see on mine
15:00 Desour select the squash option. the conflict will likely be gone then
15:02 srifqi oh, i see. it is wrong then (probably because of the accident some hours ago)
15:02 srifqi sorry about that and thank you for the answer
15:03 Desour it's not wrong per se. it says it's getting conflicts if it doesn't squash before
15:03 Desour you're welcome :)
15:04 srifqi oh, i meant that i selected wrong action (rebase and merege) before (^_^")
15:09 proller joined #minetest-dev
16:01 apprentice joined #minetest-dev
16:19 srifqi1 joined #minetest-dev
17:04 appguru joined #minetest-dev
17:30 v-rob joined #minetest-dev
17:47 v-rob joined #minetest-dev
17:52 proller joined #minetest-dev
19:53 Krock srifqi1: you could try to use curl -Ls PR_URL.diff | git apply -    example: https://gist.github.com/SmallJoker/4d411b958295d9e694cd9aa5984563db/
19:54 Krock this uses Github to compress all PR changes into a single diff which you then can apply on top of master
19:54 Krock I like it to do it this way because switching branches is tedious
20:23 nrz joined #minetest-dev
21:04 YuGiOhJCJ joined #minetest-dev
21:25 tekakutli joined #minetest-dev
21:58 appguru joined #minetest-dev
22:01 appguru joined #minetest-dev
22:26 v-rob joined #minetest-dev
22:30 srifqi Krock: thank you for the command. i was using the GitHub CLI: gh pr checkout PR_URL
22:32 panwolfram joined #minetest-dev
22:57 v-rob joined #minetest-dev
23:18 AliasAlreadyTake joined #minetest-dev

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