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 |