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} |
01:12 |
|
YuGiOhJCJ joined #minetest-dev |
01:24 |
|
olliy joined #minetest-dev |
01:37 |
|
Soni joined #minetest-dev |
01:38 |
|
panwolfram joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
04:34 |
|
Guest38 joined #minetest-dev |
04:55 |
|
GreenXenith joined #minetest-dev |
05:59 |
|
vampirefrog joined #minetest-dev |
06:00 |
|
calcul0n__ joined #minetest-dev |
07:13 |
|
YuGiOhJCJ joined #minetest-dev |
07:31 |
|
definitelya joined #minetest-dev |
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:02 |
|
sometalgoo1 joined #minetest-dev |
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:33 |
|
olliy joined #minetest-dev |
09:49 |
|
TheCoffeMaker joined #minetest-dev |
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 |
11:08 |
|
proller joined #minetest-dev |
11:28 |
|
cranezhou joined #minetest-dev |
12:08 |
|
calcul0n joined #minetest-dev |
12:12 |
|
DLKmike joined #minetest-dev |
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:30 |
|
proller joined #minetest-dev |
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:17 |
|
Fixer joined #minetest-dev |
14:39 |
|
GreenXenith joined #minetest-dev |
14:43 |
|
fluxionary_ joined #minetest-dev |
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 |
14:55 |
|
fluxionary_ joined #minetest-dev |
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 |
|
Taoki joined #minetest-dev |
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 |
|
Fixer_ joined #minetest-dev |
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 |
16:48 |
|
ely-the-kitsune joined #minetest-dev |
16:56 |
|
ely-the-kitsune joined #minetest-dev |
17:09 |
|
Guest38 joined #minetest-dev |
17:24 |
|
diceLibrarian joined #minetest-dev |
17:46 |
|
ely-the-kitsune joined #minetest-dev |
18:18 |
|
Fixer joined #minetest-dev |
18:59 |
|
pgimeno joined #minetest-dev |
19:48 |
|
ely-the-kitsune joined #minetest-dev |
20:10 |
|
calcul0n_ joined #minetest-dev |
20:19 |
|
Fixer_ joined #minetest-dev |
20:33 |
|
calcul0n_ joined #minetest-dev |
20:40 |
|
proller joined #minetest-dev |
21:00 |
|
pgimeno_ joined #minetest-dev |
21:00 |
|
proller joined #minetest-dev |
21:19 |
|
calcul0n_ joined #minetest-dev |
21:59 |
|
vampirefrog joined #minetest-dev |
22:20 |
|
vampirefrog joined #minetest-dev |
22:22 |
|
vampirefrog joined #minetest-dev |
22:30 |
|
vampirefrog joined #minetest-dev |
22:31 |
|
proller joined #minetest-dev |
22:37 |
|
cranezhou joined #minetest-dev |
23:03 |
|
pgimeno joined #minetest-dev |
23:34 |
|
panwolfram joined #minetest-dev |
23:59 |
|
GreenXenith joined #minetest-dev |