Time Nick Message 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 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 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 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 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 And where the collisionbox was defined by the nodes 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 Seems like that should be optional as well, with a warning 13:18 MTDiscord 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 But other usecases where you don't need node collisions 13:23 MTDiscord Couldn't it be simplified, where each node is a sphere/point? Only check node collisions near the collision area? 13:24 MTDiscord 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 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 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 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: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 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: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 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: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 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 (^_^") 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 22:30 srifqi Krock: thank you for the command. i was using the GitHub CLI: gh pr checkout PR_URL