Time  Nick           Message
00:23 kilbith        https://i.imgur.com/pKx5hJQ.png
00:23 kilbith        cam1:set_viewport{x = 0, y = 0, w = 800, h = 600}
07:31 definitelya    One of the recently merged PRs might have broken node placement.
07:32 definitelya    Trying to place any node horizontally, while looking North or East, will position the node closer to the player by one node, instead of the appropriate place selected.
07:32 definitelya    Tested with MTG master and Devtest.
07:34 definitelya    Oh also placing downwards is broken.
08:03 sfan5          can confirm
08:08 MTDiscord      <luatic> this was introduced by my selectionbox changes it seems
08:09 MTDiscord      <luatic> working on it
08:20 MTDiscord      <luatic> alright, it seems all negative normals have twice the length for some reason
08:27 MTDiscord      <luatic> ah I think i have it
08:27 MTDiscord      <luatic> I forgot to translate the box center back
08:27 MTDiscord      <luatic> into absolute space
08:50 definitelya    Thanks for the quick fix, luatic.
09:51 nrz            the fix in the opened PR
10:02 MTDiscord      <luatic> nrz: #12913
10:02 ShadowBot      https://github.com/minetest/minetest/issues/12913 -- Fix node placement regression by appgurueu
13:07 sfan5          merging #12913, #12910, #12911 in 10m
13:07 ShadowBot      https://github.com/minetest/minetest/issues/12913 -- Fix node placement regression by appgurueu
13:07 ShadowBot      https://github.com/minetest/minetest/issues/12910 -- Send crosshair setting after the touch screen GUI has been initialized by srifqi
13:07 ShadowBot      https://github.com/minetest/minetest/issues/12911 -- Android: Increase target/compiled SDK version to 32 by srifqi
13:09 nrz            imagine at a point we'll refacto the engine to increase our velocity 😄
13:10 rubenwardy     no need,   player:set_physics_override({ speed = 2 })
13:10 nrz            no need what ?
13:23 MTDiscord      <luatic> rubenwardy: something tells me by "velocity" nrz means dev pace
13:24 MTDiscord      <Warr1024> Doubling your speed has no effect on total net velocity if it was zero before... 🤔
13:51 schwarzwald[m] If you guys decide to do that kind of refactor count me in lol.
14:00 rubenwardy     luatic: I know :)
14:03 MTDiscord      <Warr1024> What even IS the project velocity?  How do you gauge the cost/value of each item?  If you don't know what your velocity is, then you can't really know if you're increasing it or not.
14:46 pgimeno        making the code better structured, easier to maintain and easier to understand may or may not speed up development, but even if not, it's beneficial, so it doesn't really matter if dev speed improvements aren't measurable
14:47 pgimeno        chances are that it will help speed up development
15:06 kilbith        https://i.imgur.com/vu6ZXwh.png
15:07 kilbith        placing your cameras anywhere on the screen using :set_viewport(rect)
15:08 nrz            pgimeno, clearly the idea, ease the development is a form of velocity increase (i think i work for agile companies for too long time)
15:10 pgimeno        nrz: yes, my point was that you don't have to prove dev speed improvements to justify a refactor. My comment was motivated by what Warr1024 said.
15:57 rubenwardy     why has the GitLab pipeline usage jumped up by so much? It's gone from 80 mins a month to almost 2000
15:58 rubenwardy     GitLab has an open source program that would give us 25x the quota for free, although not sure they'd accept us as it's a mirror
15:58 rubenwardy     50,000 vs 2,000 minutes per month
16:00 sfan5          my guess is that they changed their billing / accounting method
16:00 rubenwardy     GitHub is also current 2,000 minutes per month
16:00 rubenwardy     hmm bizarre
16:03 rubenwardy     yeah https://docs.gitlab.com/ee/ci/pipelines/cicd_minutes.html#cost-factor
16:04 rubenwardy     they changed a multiplier from 0.04 to 1
16:05 rubenwardy     so we were previously using 84*(1/0.04) = 2100 minutes per month
16:05 rubenwardy     bizarre and opaque way to do it
16:13 schwarzwald[m] Would it be a good idea to just refactor in general, or to have a certain feature we want to add that guides our refactoring?
16:13 schwarzwald[m] They're probably both good ideas, but which one makes more sense for us?
16:18 Pexin          about that: I have been meaning to dig through the codebase to figure out how widespread the distance/raycasting stuff is for purposes of eventually (if necessary) abstracting stuff for world-edge-wrapping. maybe someone else has already had this thought?
16:18 Pexin          re refactor
16:19 Pexin          as in, instead of a naive distance calc, if a flag is set then do a piecewise calc due to worldwrapping at a (potentially arbitrary) worldbound value
16:21 rubenwardy     you should refactor with a purpose in mind really
16:21 rubenwardy     like, I'm currently refactoring the input system to support using formspecs with a gamepad
16:22 schwarzwald[m] While trying to structure the build into more independent pieces, I noticed once that there's a cyclic dependency between the client Tile class and some other class shared by the client and server, which prevented me from doing it, but I didn't ever have time to understand why.
16:22 rubenwardy     the purpose can be to achieve a particular architecture goal