| Time |
Nick |
Message |
| 00:09 |
|
AliasAlreadyTake joined #minetest-dev |
| 00:32 |
|
AliasAlreadyTake joined #minetest-dev |
| 00:52 |
|
YuGiOhJCJ joined #minetest-dev |
| 01:02 |
|
lhofhansl joined #minetest-dev |
| 01:26 |
|
Foz joined #minetest-dev |
| 01:30 |
|
Lone_Wolf joined #minetest-dev |
| 01:39 |
|
Lone_Wolf joined #minetest-dev |
| 03:39 |
|
AliasAlreadyTake joined #minetest-dev |
| 03:47 |
|
Extex joined #minetest-dev |
| 04:04 |
|
Extex joined #minetest-dev |
| 04:06 |
|
Extex joined #minetest-dev |
| 04:08 |
|
Extex joined #minetest-dev |
| 04:47 |
|
tekakutli joined #minetest-dev |
| 05:02 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:07 |
|
Alias2 joined #minetest-dev |
| 07:39 |
|
AliasAlreadyTake joined #minetest-dev |
| 07:48 |
|
behalebabo joined #minetest-dev |
| 08:03 |
|
hecks joined #minetest-dev |
| 09:23 |
|
calcul0n_ joined #minetest-dev |
| 09:28 |
|
specing_ joined #minetest-dev |
| 10:28 |
specing |
Why is core.hash_node_position not available to CSMs? Its in builtin/game/misc.lua |
| 10:30 |
specing |
Also, it looks fairly expensive, lots of floating point math (not sure if this gets optimised to bit shifts by luajit) |
| 10:35 |
VanessaE |
er, isn't that one doable just with a bunch of bit shifting? |
| 10:35 |
specing |
yes |
| 10:35 |
specing |
but I don't think lua supports bit shifting |
| 10:36 |
VanessaE |
that ain't float maths :) |
| 10:36 |
VanessaE |
actually there are bit ops in like, 5.2 or above, and luajit too I think |
| 10:36 |
VanessaE |
but not in 5.1 |
| 10:37 |
VanessaE |
sorry if I misread, I just woke up, still on my first cup of coffee :P |
| 10:38 |
VanessaE |
still perhaps best not to use that function at all. the more it and others that used fixed 16-bit coords are used, the less incentive the devs have to expand the map beyond 62x62km :) |
| 10:38 |
VanessaE |
consider using a string operation instead |
| 10:38 |
VanessaE |
(if your use-case can deal with that) |
| 10:39 |
VanessaE |
even if you just do `foo = x.."/"..y.."/"..z` or something |
| 10:40 |
specing |
I want efficient storage for visited nodes for a search algorithm around get_node_or_nil() |
| 10:50 |
sfan5 |
sounds like a simple oversight |
| 10:52 |
specing |
Hmm, I suppose one way would be to find_node_near and then do a connectivity search + iterate over larger and larger radiues |
| 10:52 |
specing |
why is there no connectivity search? |
| 11:09 |
VanessaE |
it almost sounds like you could exploit the pathfinding functions for that? |
| 11:10 |
specing |
hmm |
| 11:11 |
VanessaE |
I mean, the way you put it sounds like you want to evaluate an electrical circuit |
| 11:11 |
VanessaE |
though idk if the pathfinding thing can be restricted to paths only over certain nodes/groups |
| 11:13 |
specing |
Ah, actually, I want to scan whole digtron for inventories and controller after it is unpacked |
| 11:13 |
VanessaE |
digtron! *KILL* |
| 11:13 |
VanessaE |
oh wait |
| 11:13 |
VanessaE |
:) |
| 11:14 |
specing |
Yeah, they are dangerous. But I'm impressed |
| 11:15 |
specing |
Anyway, I'm planning to use this same algo for enumerating drawers around a drawer controller |
| 11:16 |
specing |
According to the pathfinder doc in lua_api, it's not usable for me. Seems to focus on walkable paths and ... oh well .. I need a graph / list of all suitable connected nodes :) |
| 11:16 |
VanessaE |
well, a digtron-type machine is traditionally just a big box full of nodes isn't it? or are we talking about a machine with an actual, passable-in-real-world shape now? |
| 11:16 |
VanessaE |
(full as in a solid block without airspaces) |
| 11:17 |
specing |
Ah, Mine have plenty of airspaces (6x6x2) |
| 11:17 |
specing |
I use dual heads, so I can inspect what's ahead |
| 11:18 |
VanessaE |
gotchya |
| 11:19 |
specing |
I did think about handling this as just one big box of nodes (and using get_nodes_in_area), but what if I unpack two digtrons and the area happens to intersect both? And also, it could very well be a 50x2x1 digtron in the future, so the search area could get fairly large |
| 11:20 |
VanessaE |
the reason I asked was I'd have thought it would be sufficient to just check the volume occupied by the machine (but only when a node is dug or placed in its vicinity) to see if it has all the parts needed, and cutting implements facing the right way |
| 11:20 |
VanessaE |
connectivity-testing seems like overkill, that is |
| 11:23 |
|
Fixer joined #minetest-dev |
| 11:28 |
specing |
VanessaE: the problem with volume-testing is that digtrons can be large or small and rotated in all directions |
| 11:29 |
VanessaE |
hm |
| 11:29 |
VanessaE |
truew |
| 11:29 |
VanessaE |
-w |
| 11:31 |
|
entuland joined #minetest-dev |
| 11:43 |
specing |
Well, I just need visited node storage for now. Perhaps I'll just copy the reversible hashing function and call it a day |
| 11:43 |
specing |
but probably this algo should be in-engine |
| 12:22 |
hecks |
question; are we enforcing a tab width of any kind in code |
| 12:23 |
hecks |
I just realized I can't find anything about it anywhere, been assuming 4-space tabs the whole time |
| 12:23 |
VanessaE |
hecks: to a degree, yes. 4-space tabs is part of the official code style |
| 12:23 |
hecks |
should be documented somewhere |
| 12:24 |
VanessaE |
https://dev.minetest.net/Code_style_guidelines |
| 12:24 |
hecks |
check that page, it doesn't say 4 anywhere |
| 12:24 |
VanessaE |
celeron55: fix your certs |
| 12:24 |
rubenwardy |
Doesn't matter how big a tab is |
| 12:24 |
VanessaE |
https://www.kernel.org/doc/html/latest/process/coding-style.html |
| 12:24 |
rubenwardy |
We don't align between indentation levels |
| 12:24 |
sfan5 |
kernel code style says 8 spaces |
| 12:24 |
sfan5 |
but in our document: |
| 12:24 |
sfan5 |
>Try to keep lines under 95 characters. It's okay if it goes over by a few, but do not exaggerate. (Note that this column count assumes 4-space indents.) |
| 12:24 |
hecks |
I'm asking because I noticed that we can use an .editorconfig in the git repo to squish tabs to 4 from 8 |
| 12:25 |
hecks |
and that makes the code fit in compares |
| 12:25 |
rubenwardy |
It only matters when you consider line length, in which case we use 4 |
| 12:25 |
rubenwardy |
Yeah |
| 12:25 |
sfan5 |
sounds like good idea |
| 12:25 |
hecks |
let me pr this |
| 12:29 |
hecks |
#11412 pomf |
| 12:29 |
pgimeno |
https://github.com/minetest/minetest/pull/11412 -- add .editorconfig by hecktest |
| 12:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/11412 -- add .editorconfig by hecktest |
| 12:31 |
MTDiscord |
<Warr1024> Oh interesting, is this purely advisory for GH, or does it also affect other things, like does VS Code honor it or something? |
| 12:31 |
hecks |
Editors might honor it actually |
| 12:32 |
hecks |
https://editorconfig.org/ |
| 12:33 |
hecks |
though my motivation is mainly squishing GH compares |
| 12:34 |
rubenwardy |
Most editors honor it |
| 12:37 |
hecks |
am i allowed to self approve something this trivial |
| 12:45 |
|
longerstaff13 joined #minetest-dev |
| 12:48 |
MTDiscord |
<Warr1024> I at least approve of the concept. Code style should be the responsibility of editors, formatters and linters, not human labor. |
| 12:50 |
MTDiscord |
<Warr1024> If it were possible to automatically enforce code style for all new code (e.g. a tool that throws an error on non-compliant code) and grandfather in existing code where necessary that would be even better. :-) |
| 12:50 |
hecks |
sometimes the linter is wrong, see contributing.md |
| 12:51 |
MTDiscord |
<Warr1024> I actually have a pre-commit gate for NodeCore that rejects my commits if (1) I have luacheck warnings, or (2) the code I'm trying to commit doesn't match what the auto-formatter would produce (I still have to manually run and check the format though). |
| 12:51 |
MTDiscord |
<Warr1024> Yes, linter-gating is risky. It's important to have a mechanism to override the linter when it's wrong. |
| 12:52 |
hecks |
anyway this is just to make gh render it all properly... should be an easy sell |
| 12:52 |
MTDiscord |
<Warr1024> I do a bunch in js and use jshint, but I had it warning me on unused params, and js has no _ convention for unused vars like lua. For a while I used /* jshint: unused = false */ overrides per-case but eventually had to abandon and reduced the strictness of that rule. |
| 12:53 |
MTDiscord |
<Warr1024> Yeah, this is a good first step toward automated style consistency :-) |
| 12:58 |
sfan5 |
the paragraph about the linter should be dropped from contributing.md |
| 12:58 |
sfan5 |
because we don't even have one right noiw |
| 12:58 |
sfan5 |
-i |
| 13:10 |
MTDiscord |
<Warr1024> It's pretty hard to add style standards to an existing project that already has a mix of styles... |
| 13:11 |
hecks |
it's mostly consistent |
| 14:00 |
celeron55 |
depending on what you compare it to, it's very consistent |
| 14:58 |
hecks |
ShadowNinja: if renderdoc is acting up with minetest, you can try gDEBugger |
| 14:58 |
hecks |
running MT through any GL debugger is truly a horror show |
| 15:02 |
sfan5 |
the act of running it or the results? ;) |
| 15:02 |
MTDiscord |
<appguru> both I'd guess |
| 15:22 |
specing |
Well |
| 15:23 |
specing |
you could run the linter on pre-commit repo and the post commit repo. Then error out if diff is larger |
| 15:23 |
specing |
basically, count the style errors/warnings and reject if new code results in more |
| 15:29 |
MTDiscord |
<josiah_wi> I think the right time to decide "the linter is wrong here" is after you have 0 linter warnings. |
| 15:45 |
|
Extex joined #minetest-dev |
| 15:52 |
|
kilbith joined #minetest-dev |
| 16:02 |
|
kilbith_ joined #minetest-dev |
| 17:24 |
|
hlqkj joined #minetest-dev |
| 17:25 |
|
hlqkj left #minetest-dev |
| 17:25 |
|
hlqkj joined #minetest-dev |
| 18:30 |
|
hecks joined #minetest-dev |
| 18:43 |
|
SFENCE joined #minetest-dev |
| 19:04 |
|
Lone_Wolf joined #minetest-dev |
| 19:34 |
|
hecks joined #minetest-dev |
| 19:36 |
|
longerstaff13 joined #minetest-dev |
| 20:09 |
|
v-rob joined #minetest-dev |
| 20:11 |
v-rob |
sfan5: in #6101, what were you referring to when you said that there need to be zero changes to the map format? |
| 20:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/6101 -- Allow registering more than 32768 nodes |
| 20:50 |
|
hecks joined #minetest-dev |
| 20:52 |
hecks |
merging #11412 in 10 minutes |
| 20:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/11412 -- Add .editorconfig by hecktest |
| 20:57 |
|
SFENCE left #minetest-dev |
| 21:08 |
|
hlqkj_ joined #minetest-dev |
| 21:29 |
|
specing joined #minetest-dev |
| 21:56 |
|
v-rob joined #minetest-dev |
| 22:27 |
MTDiscord |
<Warr1024> Hmm, I read 6101 and I also couldn't find that explanation. Would be nice to have that, or at least a link to it, in the issue thread for people who weren't there for any off-thread portions of the discussion. |
| 23:24 |
|
Extex joined #minetest-dev |
| 23:49 |
|
Alias2 joined #minetest-dev |
