| Time |
Nick |
Message |
| 00:24 |
|
DI3HARD139 joined #minetest-dev |
| 00:30 |
|
Miner_48er joined #minetest-dev |
| 00:56 |
|
STHGOM joined #minetest-dev |
| 00:56 |
|
STHGOM joined #minetest-dev |
| 00:56 |
|
STHGOM joined #minetest-dev |
| 01:00 |
|
crazyR joined #minetest-dev |
| 01:05 |
|
octacian joined #minetest-dev |
| 01:07 |
|
STHGOM joined #minetest-dev |
| 01:07 |
|
STHGOM joined #minetest-dev |
| 01:11 |
|
octacian joined #minetest-dev |
| 01:13 |
|
STHGOM joined #minetest-dev |
| 01:18 |
|
STHGOM joined #minetest-dev |
| 01:18 |
|
STHGOM joined #minetest-dev |
| 04:16 |
|
STHGOM joined #minetest-dev |
| 04:16 |
|
STHGOM joined #minetest-dev |
| 04:25 |
|
Hunterz joined #minetest-dev |
| 05:18 |
|
Lunatrius` joined #minetest-dev |
| 06:20 |
|
Hunterz joined #minetest-dev |
| 06:38 |
|
nrzkt joined #minetest-dev |
| 06:51 |
|
proller joined #minetest-dev |
| 06:54 |
|
proller joined #minetest-dev |
| 07:11 |
|
proller joined #minetest-dev |
| 07:16 |
|
paramat joined #minetest-dev |
| 07:25 |
|
lisac joined #minetest-dev |
| 07:29 |
|
Lunatrius` joined #minetest-dev |
| 07:31 |
|
^v joined #minetest-dev |
| 07:36 |
paramat |
#5146 simple and seems good |
| 07:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/5146 -- Fix fog weirdness by numberZero |
| 07:42 |
nrzkt |
paramat, i agree too, merging |
| 07:43 |
paramat |
great |
| 07:43 |
nrzkt |
paramat, what do you think about #5151 ? |
| 07:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/5151 -- Tell on_punch to expect a return value by duane-r |
| 07:58 |
paramat |
not sure yet |
| 08:01 |
kaeza |
it fixes broken API |
| 08:15 |
|
^v joined #minetest-dev |
| 08:39 |
|
nrzkt joined #minetest-dev |
| 08:45 |
|
^v joined #minetest-dev |
| 09:10 |
|
^v joined #minetest-dev |
| 09:22 |
|
Darcidride joined #minetest-dev |
| 09:25 |
|
Darcidride joined #minetest-dev |
| 09:31 |
|
Darcidride joined #minetest-dev |
| 09:35 |
|
Darcidride joined #minetest-dev |
| 09:37 |
|
^v joined #minetest-dev |
| 09:40 |
|
Darcidride joined #minetest-dev |
| 09:42 |
|
xerox123 joined #minetest-dev |
| 09:43 |
|
Lunatrius` joined #minetest-dev |
| 09:44 |
|
^v joined #minetest-dev |
| 09:45 |
|
Darcidride joined #minetest-dev |
| 10:01 |
|
^v joined #minetest-dev |
| 10:06 |
|
Darcidride joined #minetest-dev |
| 10:10 |
|
^v joined #minetest-dev |
| 10:16 |
|
^v joined #minetest-dev |
| 10:47 |
|
^v joined #minetest-dev |
| 10:49 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:51 |
|
juhdanad joined #minetest-dev |
| 11:00 |
|
^v joined #minetest-dev |
| 11:06 |
|
An0n3m0us joined #minetest-dev |
| 11:22 |
|
^v joined #minetest-dev |
| 11:25 |
red-001 |
!seen davisonio |
| 11:25 |
ShadowBot |
red-001: I saw davisonio in #minetest-dev 20 weeks, 2 days, 20 hours, 31 minutes, and 23 seconds ago saying "Perhaps it can be solved by setting a maximum limit of 14 in the light source definition" |
| 11:27 |
paramat |
^v Darcidride your join / leave messages are spamming this channel, anything you can do to reduce? |
| 11:28 |
paramat |
phew :P #5148 updated and seems to work |
| 11:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/5148 -- Mgvalleys: Fix missing decorations and incorrect function order by paramat |
| 11:30 |
|
troller joined #minetest-dev |
| 11:32 |
paramat |
#1475 updated any comments? this adds sand resources throughout the world instead of just near sea level |
| 11:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/1475 -- Client lag improvement by sapier |
| 11:32 |
paramat |
game#1475 |
| 11:32 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1475 -- Ores: Add silver sand blob ore, relocate other blob ores by paramat |
| 11:35 |
paramat |
input needed on game#1532 i'm unsure |
| 11:35 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1532 -- Bushes: Add leafdecay to bush leaves by paramat |
| 11:37 |
|
Fixer joined #minetest-dev |
| 11:47 |
paramat |
game#1539 |
| 11:47 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1539 -- Creative: Cache creative mode setting by paramat |
| 11:58 |
|
^v joined #minetest-dev |
| 11:59 |
|
juhdanad joined #minetest-dev |
| 12:03 |
red-001 |
for CSM is isolating mods from each other really needed? |
| 12:06 |
red-001 |
I mean if mods are written correctly and set all their internal functions to locals etc I don't see why having them share the environment is a problem |
| 12:15 |
^v |
paramat, sorry lol my VPS is having issues |
| 12:23 |
|
blaze joined #minetest-dev |
| 12:35 |
|
troller joined #minetest-dev |
| 12:36 |
nore |
updated #5143 |
| 12:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/5143 -- Fix anticheat resetting client position after the client is teleported. by Ekdohibs |
| 12:52 |
|
juhdanad joined #minetest-dev |
| 12:54 |
celeron55 |
red-001: most mods are not written correctly and never will be |
| 12:55 |
celeron55 |
that's a silly presumption |
| 12:55 |
red-001 |
still if the worst thing that can happen is a another mod breaking... |
| 12:55 |
red-001 |
plus only the mods that are really badly written will break |
| 12:56 |
nrzkt |
celeron55: the main problem with your approach is the callbacks |
| 12:56 |
nrzkt |
and the fact that builtin should be instancied in every mod |
| 12:56 |
nrzkt |
but it's possible to sandbox them in multiple Lua states |
| 12:56 |
red-001 |
I mean it's not that hard to make sure your internal stuff is local |
| 12:56 |
celeron55 |
assuming client-side mods never have any special privileges, even local ones if they run in the same environment, then there is no security benefit; mods will just break each other |
| 12:57 |
celeron55 |
people will probably start to want to have client-side mods that aren't sandboxed; is there a plan for that? |
| 12:57 |
celeron55 |
just say no? |
| 12:57 |
red-001 |
I think so |
| 12:58 |
celeron55 |
people will want client-side mods that interface with the menu; is there a plan for that? |
| 12:58 |
celeron55 |
just say no to that too? |
| 12:58 |
red-001 |
which menu? |
| 12:58 |
red-001 |
main menu? |
| 12:58 |
celeron55 |
yes |
| 12:58 |
nrzkt |
main menu is already in its own lua state |
| 12:58 |
nrzkt |
client state != main menu |
| 12:58 |
red-001 |
thats already scriptable |
| 12:59 |
nrzkt |
celeron55: i think not sandboxed mods is a good candidate for a modpack |
| 12:59 |
nrzkt |
you want interaction with some mods, use a modpack, it's designed for |
| 12:59 |
nrzkt |
but okay, we will think about sandboxing each mod, this should be too have for init, it just add complexity on callbacks |
| 13:00 |
celeron55 |
i don't think we need to think about that |
| 13:00 |
celeron55 |
we just need to decide what the security model is and if it involves that or not |
| 13:01 |
nrzkt |
what do you want, it's not clear, 1 mod(pack) = 1 lua state or 1 state for all mods ? |
| 13:02 |
Fixer |
on side note, modpack system is so bad, can someone redesign it? https://github.com/minetest/minetest/issues/4183 |
| 13:02 |
red-001 |
is one mod crashing suppose to just print an error to the console then? |
| 13:03 |
celeron55 |
neither; i want that people don't just disregard these issues and assume everything will be fine |
| 13:03 |
red-001 |
I mean if thats still going to cause the client to disconnect then this will be pointless |
| 13:04 |
nrzkt |
red-001: absolutely not, if a mod is crashing it's user responsibility for CSM, like in many games |
| 13:04 |
nrzkt |
if a mod is crashing and it's not in its own lua state it's nearly imposisble to recover safely from error |
| 13:04 |
nrzkt |
ignoring it can trigger many bad things |
| 13:05 |
red-001 |
I meant if sandboxing gets added |
| 13:05 |
|
troller joined #minetest-dev |
| 13:05 |
nrzkt |
i don't think it's a good idea, it's safer, because we can disable mod, but what about user experience ? mod suddenly disappear ? it's strange |
| 13:06 |
red-001 |
surely if faulty code in one mod make other mods crash we are back were we started |
| 13:06 |
nrzkt |
no, because user knows which mod failed and can disable it |
| 13:06 |
nrzkt |
like in every game |
| 13:07 |
celeron55 |
how about error reporting |
| 13:07 |
nrzkt |
error is reported on screen and in logs |
| 13:07 |
celeron55 |
currently mod errors end up in the server owner's hands and they are gnerally somewhat knowledgeable about how to go about fixing them |
| 13:08 |
celeron55 |
csm errors end up in the player's computer unless a system is added that allows them to be sent to the server which provided them |
| 13:09 |
nrzkt |
celeron55: CSM doesn't download anything from server it's not in the first mergeable version of the PR |
| 13:09 |
celeron55 |
as the mods run in a sandbox, they shouldn't have access to anything that should be private so the errors can be sent without issues about what the data contains |
| 13:09 |
celeron55 |
yes but this will surely happen in the future |
| 13:10 |
nrzkt |
maybe, but reporting should be done in two parts, for CSM pure client maybe send the trace to modstore for reporting to modders, for CSM from server yes report to server owner |
| 13:11 |
celeron55 |
well, in any case "send the trace to wherever the code came from" seems to make sense |
| 13:11 |
nrzkt |
celeron55: yes |
| 13:13 |
|
STHGOM joined #minetest-dev |
| 13:13 |
celeron55 |
people have had much hopes about having multithreaded mods on the client though given that the single environment on the server has problems keeping up with things |
| 13:13 |
celeron55 |
i guess that's not happening |
| 13:14 |
red-001 |
well that's a good reason for multiple lua states |
| 13:14 |
nrzkt |
MT mods is not required client side atm |
| 13:14 |
nrzkt |
MT mods = please use all client CPU |
| 13:14 |
red-001 |
better then saving modders from their badly written code |
| 13:15 |
nrzkt |
just optimize mods, it's mod, not a IA |
| 13:15 |
nrzkt |
neither an heavy loaded server |
| 13:15 |
nrzkt |
red-001: did you ahve some PR for CSM to review ? |
| 13:16 |
celeron55 |
my opinion is that it probably doesn't make sense to multithread everything by default; however it might make sense to have multiple "micro-environments" for different things like my lua client-side physics thing and eg. lua map generators on the server possibly |
| 13:17 |
celeron55 |
maybe even essential |
| 13:17 |
nrzkt |
MT mods has sense server side yes, especially for lua mapgen, but it's not the CSM discussion |
| 13:18 |
celeron55 |
well i try to think about the design generally |
| 13:18 |
paramat |
would be nice to be able to multithread the main generation loop of a lua mapgen, which tends to be the processing of a lua voxelmanip |
| 13:19 |
nrzkt |
paramat: it's not easy, and very dangerous to implement, you should be careful about that, the main problem will be the return callbacks, not the calls to lua state |
| 13:19 |
nrzkt |
calls from lua to core when generating |
| 13:20 |
paramat |
yes hmmmm was considering it but afaik ran into issues |
| 13:20 |
celeron55 |
i don't have much reasons to be nitpicky about CSM details but i do have reasons to try to form an idea about what might happen in the future |
| 13:22 |
red-001 |
well it might be a good idea to make all variables created by mods local by default |
| 13:22 |
red-001 |
if thats possible |
| 13:22 |
celeron55 |
the way to make lua mapgens is to completely decouple it from the regular lua environment (aside from some messaging system if needed) and run it in sync with the emergethread just like the C++ mapgen runs |
| 13:22 |
nrzkt |
it's only possible mod side |
| 13:22 |
red-001 |
and add some sort of supported way for mods to add public API's |
| 13:22 |
nrzkt |
celeron55: this is a good and difficult idea |
| 13:23 |
celeron55 |
which is exactly the same as with my lua physics demo |
| 13:23 |
nrzkt |
red-001: we can only write guidelines to help modders |
| 13:23 |
celeron55 |
it's not very difficult at all, you just have to live with the limitations |
| 13:24 |
celeron55 |
which are the same limitations that the C++ mapgen has |
| 13:25 |
|
STHGOM joined #minetest-dev |
| 13:25 |
|
STHGOM joined #minetest-dev |
| 13:25 |
celeron55 |
i probably could implement a demo of that in a day if i wanted to |
| 13:26 |
celeron55 |
i might want to if someone else would like to seriously try using it |
| 13:27 |
|
STHGOM joined #minetest-dev |
| 13:28 |
paramat |
if anyone coded threaded lua mapgen i would use it heavily |
| 13:29 |
paramat |
i have so many lua mapgens that are problematic to use due to the lag they create, especially on servers |
| 13:29 |
celeron55 |
also connecting a fast path from farmap to it would be interesting |
| 13:30 |
nrzkt |
personnaly i have many things to do on the CSM, modstorage and player management server side :p |
| 13:30 |
paramat |
if you consider that a lua mapgen is running in 'on generated' and only modifies the current chunk, maybe it's easier to thread |
| 13:31 |
paramat |
maybe only if no other mod is doing stuff in 'on generated' |
| 13:31 |
celeron55 |
it wouldn't work in that way |
| 13:32 |
celeron55 |
we are talking about a separate file not loaded in to the regular environment with no other APIs than on_generated, probably not even get_node or such |
| 13:32 |
celeron55 |
just the VM |
| 13:32 |
|
blaze joined #minetest-dev |
| 13:32 |
celeron55 |
and noise things |
| 13:33 |
celeron55 |
and anything else that i forget that is absolutely necessary |
| 13:35 |
red-001 |
node ids? |
| 13:37 |
red-001 |
#5152 |
| 13:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/5152 -- [CSM] Add `get_wielded_item` by red-001 |
| 13:37 |
|
proller__ joined #minetest-dev |
| 13:42 |
|
Player_2 joined #minetest-dev |
| 13:47 |
|
STHGOM joined #minetest-dev |
| 13:49 |
|
STHGOM joined #minetest-dev |
| 13:50 |
|
STHGOM joined #minetest-dev |
| 13:53 |
nrzkt |
red-001: you are very active :) |
| 13:53 |
red-001 |
well this is mostly adding lua bindings to c++ stuff |
| 13:54 |
nrzkt |
red-001: can you give me the variable output printed by your example ? |
| 13:54 |
nrzkt |
the PR is trivial and looks great, porting is easy as it seems |
| 13:55 |
red-001 |
{ |
| 13:57 |
red-001 |
{ |
| 13:57 |
red-001 |
metadata = "" |
| 13:57 |
red-001 |
count = 1 |
| 13:57 |
red-001 |
name = "default:sword_steel" |
| 13:57 |
red-001 |
wear = 15232 |
| 13:57 |
red-001 |
} |
| 13:58 |
|
proller__ joined #minetest-dev |
| 14:06 |
nrzkt |
okay nice |
| 14:06 |
* red-001 |
starts working on porting meta-data stuff to client |
| 14:06 |
|
STHGOM joined #minetest-dev |
| 14:06 |
|
STHGOM joined #minetest-dev |
| 14:07 |
nrzkt |
red-001: warning, metadata is only server side, it's possible to have an interface client side, but it will not be persistent |
| 14:07 |
red-001 |
STHGOM, You need to fix your connection |
| 14:07 |
nrzkt |
red-001: can you fix the style on 5152 it's trivial i can merge it |
| 14:07 |
red-001 |
nrzkt, I only want to add meta-data reading |
| 14:08 |
|
lumidify joined #minetest-dev |
| 14:08 |
nrzkt |
but metadata is not send from server to client ? |
| 14:08 |
nrzkt |
sent* |
| 14:08 |
red-001 |
I'm pretty sure it is |
| 14:09 |
est31 |
it is sent |
| 14:09 |
est31 |
all formspecs for chests are in metadata |
| 14:09 |
est31 |
and more thing |
| 14:09 |
red-001 |
the chest formspec is made using metadata |
| 14:10 |
est31 |
in fact, good thing to add would be a client side function that autogenerates formspecs so that in future it doesnt have to be stored in the metadata |
| 14:10 |
est31 |
(but I guess some people want to eliminate formspecs entirely) |
| 14:10 |
est31 |
its quite funny, some mods store passwords in metadata |
| 14:11 |
nrzkt |
est31: it's not like if we store password in memory during client object lifetime :( |
| 14:11 |
est31 |
lol |
| 14:11 |
est31 |
I think we do |
| 14:12 |
est31 |
I more refered to mods like ones where you can add a password so that you can access a chest |
| 14:12 |
nrzkt |
yeah |
| 14:12 |
|
proller__ joined #minetest-dev |
| 14:12 |
red-001 |
well thats a pretty bad way to do it |
| 14:13 |
est31 |
you have to store them *somewhere* |
| 14:13 |
est31 |
a good way would be to store a hash |
| 14:13 |
est31 |
and have a server side secret |
| 14:13 |
nrzkt |
est31: maybe having it in modstorage when merged ? :) |
| 14:13 |
nrzkt |
storage.get("vault_x_y_z_password") |
| 14:13 |
nrzkt |
:D |
| 14:14 |
est31 |
you compute the hash via hash(server side secret, password) |
| 14:14 |
est31 |
then it can still be stored in metadata |
| 14:14 |
nrzkt |
est31: we don't have a password type ? could be good to generalize this model |
| 14:14 |
est31 |
as you cant do a brute force attack, since you dont know the server side secret |
| 14:15 |
est31 |
nrzkt: perfectly it would be stored outside of metadata, in some file or database |
| 14:15 |
red-001 |
nrzkt, updated the PR |
| 14:15 |
est31 |
or we introduce a server side only metadata concept |
| 14:15 |
|
STHGOM joined #minetest-dev |
| 14:15 |
|
STHGOM joined #minetest-dev |
| 14:15 |
est31 |
but idk |
| 14:16 |
est31 |
other than for passwords there are no good use cases |
| 14:16 |
celeron55 |
how about a proposal from 2012 :D http://c55.me/minetest2/wiki/doku.php?id=roadmap:nodemetadata_proposal#todo |
| 14:17 |
|
STHGOM_ joined #minetest-dev |
| 14:17 |
est31 |
:) |
| 14:18 |
celeron55 |
well also other things that are supposed to be hidden inside a node, like inventories of locked chests |
| 14:19 |
|
STHGOM joined #minetest-dev |
| 14:19 |
|
Hunterz joined #minetest-dev |
| 14:20 |
est31 |
https://github.com/ac-minetest/basic_machines/commit/fb5aca17487ccd3f5bf41dfc3385a4b051f4f70f |
| 14:21 |
est31 |
hash makes it at least non-brute forceable |
| 14:21 |
est31 |
err |
| 14:22 |
est31 |
hashing makes it at least non trivial |
| 14:22 |
est31 |
but easy passwords still can be brute forced |
| 14:22 |
est31 |
and yeah, probably some people don't want inventories of locked chests to be sent |
| 14:22 |
* red-001 |
wonders what sort of person would brute force a password for a chest |
| 14:24 |
est31 |
maybe the chest contains an admin pick, which doesnt check for server privilege because "I never lose it" |
| 14:26 |
red-001 |
good point |
| 14:28 |
|
nrzkt joined #minetest-dev |
| 14:31 |
est31 |
with inventories of nodes in fact its quite hard because some players do need them while others dont |
| 14:31 |
est31 |
so you need to dispatch the per node check to a mod |
| 14:32 |
est31 |
or have a whitelist of players allowed to access in the metadata |
| 14:32 |
est31 |
neither is a good solution i think |
| 14:34 |
est31 |
but idk |
| 14:35 |
paramat |
game#1540 |
| 14:35 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1540 -- Trees: Add 'snowy' group for pine sapling snow detection by paramat |
| 14:54 |
nrzkt |
red-001: there is one remaining issue on 5152 |
| 14:56 |
red-001 |
fixed |
| 15:00 |
|
octacian joined #minetest-dev |
| 15:09 |
|
lumidify joined #minetest-dev |
| 15:17 |
VanessaE |
I'd like to suggest a feature (or rather, an API change): if drawtype is set to framedglass, this forces param2 to create a "leveled" appearance to one of the node's textures. If paramtype2 is set to "color", I'd like this to override the leveled behavior and make it behave like any other node (but the "leveled" part of the node would always be "full") |
| 15:20 |
VanessaE |
also the infill of that drawtype needs shifted inward slightly, to eliminate Z-fighting. |
| 15:36 |
|
STHGOM joined #minetest-dev |
| 15:36 |
|
STHGOM joined #minetest-dev |
| 15:39 |
paramat |
currently they 'level' like liquid in a tank afaik, is this levelling a useful feature? always seemed weird to me |
| 15:39 |
paramat |
well i guess it can't be removed now |
| 15:40 |
VanessaE |
I find it a useless feature as well |
| 15:40 |
VanessaE |
however, I'm just proposing an override if paramtype2 is set to "color". |
| 15:41 |
VanessaE |
that way one can apply param2 coloring to the central part of the node. |
| 15:41 |
VanessaE |
(or whatever) |
| 15:41 |
VanessaE |
(as I recall, RBA created that feature with Pipeworks' water tanks in mind, but it was never put to use) |
| 15:55 |
red-001 |
what sort of minimap handlers would be useful for the client? |
| 15:58 |
|
^v joined #minetest-dev |
| 16:01 |
VanessaE |
I imagine being able to enable it only when the user wields a certain node, maybe a similar function for the radar mode |
| 16:02 |
VanessaE |
s/node/item/ |
| 16:02 |
nore |
red-001: #3747 could give you some ideas |
| 16:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/3747 -- Moddable Minimap by est31 |
| 16:04 |
red-001 |
thanks for the link |
| 16:08 |
|
Hunterz joined #minetest-dev |
| 16:18 |
|
STHGOM joined #minetest-dev |
| 16:18 |
|
STHGOM joined #minetest-dev |
| 16:18 |
|
^v joined #minetest-dev |
| 16:19 |
nrzkt |
red-001: position size, type |
| 16:24 |
nrzkt |
red-001: maybe change the texture around it, permitting to customize it from mod |
| 16:44 |
VanessaE |
paramat: bug in mt_game, |
| 16:44 |
VanessaE |
local dir = minetest.facedir_to_dir(param2) |
| 16:44 |
VanessaE |
local p = {x = bed_pos.x + dir.x / 2, y = bed_pos.y, z = bed_pos.z + dir.z / 2} |
| 16:44 |
VanessaE |
this occasionally returns dir = nil (like 90, mt_game/mods/beds/functions.lua) |
| 16:44 |
VanessaE |
line* |
| 16:45 |
VanessaE |
I think it falls over if the target bed isn't normal facedir |
| 16:45 |
VanessaE |
(as opposed to colorwallmounted, in this case) |
| 17:02 |
nore |
sfan5, sofar, could you please recheck #5143 and approve the last commit, so it can be merged? |
| 17:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/5143 -- Fix anticheat resetting client position after the client is teleported. by Ekdohibs |
| 17:02 |
sfan5 |
sure |
| 17:03 |
|
paramat joined #minetest-dev |
| 17:03 |
paramat |
perhaps colorfacedir is causing the problem |
| 17:03 |
paramat |
facedir_to_dir may now need to only look at the first 5 bits |
| 17:05 |
paramat |
it's an engine issue |
| 17:05 |
sfan5 |
nore: you could use MYMAX instead of the if(lag_pool_max < LAG_POOL_MIN) |
| 17:05 |
sfan5 |
also that particular if is missing spacing |
| 17:05 |
nore |
sfan5: ah, indeed |
| 17:05 |
paramat |
please open an issue :] |
| 17:05 |
nore |
fixing that |
| 17:07 |
VanessaE |
paramat: consider this my open issue ;) |
| 17:07 |
paramat |
#5148 is simple and tested, can anyone +1? |
| 17:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/5148 -- Mgvalleys: Fix missing decorations and incorrect function order by paramat |
| 17:07 |
paramat |
reporting a bug in IRC will get forgotten |
| 17:08 |
VanessaE |
too lazy to open an issue :) |
| 17:08 |
paramat |
ok |
| 17:09 |
nore |
#5153 |
| 17:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/5153 -- Fix facedir_to_dir and wallmounted_to_dir for coloured nodes. by Ekdohibs |
| 17:09 |
paramat |
i'll quickly do it |
| 17:09 |
nore |
paramat: no need :p |
| 17:09 |
paramat |
heh |
| 17:09 |
VanessaE |
heh |
| 17:09 |
paramat |
thanks |
| 17:10 |
sfan5 |
lua has modulo operators? |
| 17:10 |
sfan5 |
i guess it does |
| 17:10 |
sfan5 |
¯\_(ツ)_/¯ |
| 17:10 |
paramat |
then there's this #5109 which is simple, well tested, but maybe a reviewer would want to test (that's the boring part) |
| 17:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/5109 -- OpenAL sound: Use a simpler distance model by paramat |
| 17:11 |
nore |
sfan5: yep, it does, but it doesn't have bitwise operators :'( |
| 17:11 |
paramat |
no rush i guess |
| 17:13 |
nore |
sfan5: done the change to use MYMAX |
| 17:15 |
|
proller__ joined #minetest-dev |
| 17:20 |
|
sapier joined #minetest-dev |
| 17:28 |
|
nrzkt joined #minetest-dev |
| 17:51 |
|
STHGOM_ joined #minetest-dev |
| 17:53 |
|
STHGOM joined #minetest-dev |
| 17:54 |
|
STHGOM joined #minetest-dev |
| 18:00 |
red-001 |
could some give #5152 a WIP tag? |
| 18:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/5152 -- [CSM] Add `get_wielded_item` by red-001 |
| 18:00 |
red-001 |
Turns out I need to fix some stuff as l_item.cpp uses getServer often |
| 18:07 |
sofar |
nrzkt: how often does the lua client sandbox run? |
| 18:07 |
sofar |
nrzkt: does it have the same concept of server_step? |
| 18:07 |
sofar |
client_step? |
| 18:07 |
nrzkt |
yeah it's already implemented, but i seem you don't read preview mod |
| 18:08 |
nrzkt |
red-001, and me add each functional feature to preview mod permitting user to see them |
| 18:08 |
sofar |
nrzkt: no time to test, sorry |
| 18:08 |
nrzkt |
just read the mod |
| 18:08 |
sofar |
in between one mt project I'm working on now and the house building design work, 0 free time left |
| 18:08 |
sofar |
:P |
| 18:09 |
nrzkt |
and you also have client_doc_api.txt |
| 18:09 |
sofar |
where's the mod? :D |
| 18:09 |
nrzkt |
everything is documented |
| 18:09 |
sofar |
minetest-mods? :P |
| 18:09 |
nrzkt |
no |
| 18:09 |
nrzkt |
in the branch itself in clientmods |
| 18:09 |
nrzkt |
https://github.com/minetest/minetest/blob/47574ac72e53c3a45a9ed4c4eeabfeb6fd6488de/clientmods/preview/init.lua |
| 18:10 |
sofar |
found it |
| 18:11 |
sofar |
question again |
| 18:11 |
sofar |
can I run something every step and get player controls? e.g. mouse down? |
| 18:11 |
sapier |
Imho clientstep should be removed lua handling in serverstep is one of the major design errors of server |
| 18:12 |
nore |
sapier: what do you mean? |
| 18:12 |
sapier |
if you need somesthing asynchronously to be done create a separate lua thread but don't allow broken mods to cause rendering to be delayed |
| 18:13 |
sfan5 |
yes rendering should never be delayed by an client side mod stuff |
| 18:13 |
sofar |
rendering should never be affected by lua execution period |
| 18:13 |
nore |
ah yes |
| 18:13 |
sapier |
yes but exactly this happens if you implement on_clientstep |
| 18:13 |
nore |
I thought you meant removing on_serverstep |
| 18:14 |
nore |
(hm, on_globalstep actually) |
| 18:14 |
sofar |
hell first test I want to do is make a lua client mod that spins in a loop for 1 second |
| 18:14 |
nrzkt |
sapier, the problem is the rendering itself as it's not, it should be threaded |
| 18:14 |
nrzkt |
client should have its life and renderer too |
| 18:14 |
sapier |
that one too but it's way more hard there then not implement it client side at all |
| 18:14 |
nore |
though, can we really do that without having map concurrency access problems? |
| 18:15 |
nore |
*concurrent map access |
| 18:15 |
sapier |
nrzkt: of course but right now rendering is mixed to ui control adding lua to it too wont make things better |
| 18:15 |
sapier |
client doesn't have map access |
| 18:15 |
sapier |
at least not writeable |
| 18:15 |
nore |
hmm |
| 18:15 |
nrzkt |
we already know that |
| 18:15 |
nrzkt |
client should not modify the map |
| 18:15 |
nrzkt |
but lua should have access to control, can be interesting |
| 18:15 |
sapier |
client MAY NOT modify map |
| 18:16 |
nore |
yes, but couldn't there be concurrent free or things like that? |
| 18:16 |
nore |
I mean, let's say that sector of the map hits unload time limit and is unloaded |
| 18:16 |
nore |
couldn't it cause problems if the map is accessed at the same time? |
| 18:17 |
sapier |
right now we're talking about on_clientstep and imho adding it is a very bad idea because there WILL BE broken mods and modders will claim "but you made the interface available" |
| 18:17 |
sofar |
#define will be broken |
| 18:17 |
sapier |
nore map access is not topic here |
| 18:17 |
nrzkt |
sapier, i got an idea, participate on #5088 and add your comments |
| 18:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/5088 -- Client side scripting/modding by nerzhul |
| 18:17 |
nrzkt |
this permit to prevent repeating things everytime :p |
| 18:18 |
nore |
sapier: the thing is, we *can't* execute lua asynchronously in that case |
| 18:18 |
nore |
like, every callback can take 1s |
| 18:18 |
nore |
so the thing is, adding on_clientstep will not break more things than can already be |
| 18:19 |
sapier |
serverside globalstep is a continous source of lag for about 5 years now I'm absolutely against doing same error clientside once again ;-) |
| 18:19 |
sapier |
of course there are other callbacks causing lag too (doesn't make the main step thing better) |
| 18:20 |
nrzkt |
sapier, the server source of lag is ABM not globalstep |
| 18:20 |
sapier |
nrzkt: only for very very very bad written mods |
| 18:21 |
nrzkt |
in fact no |
| 18:21 |
sapier |
and abm lag is quite easy to track down the global or entitystep lag is extremely hard to find |
| 18:21 |
nrzkt |
just use a valgrind on a classic server modpack and you will see 70% server time spent is on ABM |
| 18:21 |
sapier |
un fact yes because noone reads the important message "ABM's have to be one line functions" |
| 18:22 |
nrzkt |
but they solve many things |
| 18:22 |
sapier |
doing fancy stuff in abm is stupid (sorry if this offends someone) |
| 18:22 |
nrzkt |
with a lag cost, yes |
| 18:22 |
nrzkt |
dirt replacement, flowers , fields etc |
| 18:22 |
sapier |
abms are only supposed to do small stuff or trigger things |
| 18:23 |
sapier |
and the triggering is where globalstep comes in ... as it's not separated from main step there's no good way to do asynchronous things |
| 18:23 |
nrzkt |
in majority of case yes, but the problem is... algorithm is huge, looping on everynode consume some time |
| 18:23 |
sapier |
imho we shouldn't do same mistake once again |
| 18:23 |
nrzkt |
sapier, maybe you can participate on this PR |
| 18:24 |
nrzkt |
just IRC is not sufficient |
| 18:24 |
sapier |
nrzkt: yes but if there's only a one line action in abm it's not that bad (compared to functions reading whole map for each abm) |
| 18:24 |
sapier |
ppl do that especaly those who abuse abm for spawning |
| 18:25 |
nrzkt |
it's normal there is no other mechanism to do it |
| 18:25 |
nrzkt |
the problem is here, ABM are the only way to do things and it consume many time |
| 18:25 |
nrzkt |
globalstep is not very used, except for after functions |
| 18:25 |
nrzkt |
and it's load is tiny |
| 18:26 |
nrzkt |
it's not the problem |
| 18:28 |
sapier |
yes it's normal but not because there's no other mechanism to do it. It's because it's easiest way to do it. See I wrote "advanced spawning" mod exactly to do the spawning. There's no need to use abm's for spawning at all |
| 18:29 |
nrzkt |
then why it's not used ? |
| 18:30 |
sapier |
I guess because of well known "not invented here" syndrom ;-) |
| 18:30 |
nrzkt |
or less documented ? and can you proof it's lightweight ? also don't forget one thing with global step, async = many locking issue, in fact everytime, the benefit is not here client side |
| 18:30 |
sapier |
well documentation is a little bit short too yes but it'd be enough to start |
| 18:30 |
sapier |
it's not lightweight, but it's lag free |
| 18:31 |
sapier |
basicaly adv_spawning impelments it's own scheduling |
| 18:31 |
sapier |
it ensures there (usually) won't be consumed more the a couple of ms per server step and delays any other work to be done to future steps |
| 18:33 |
sapier |
sadly there's no preemption in lua so user can break the delayed work mechanism in adv spawning too ... but you have to break it on purpose |
| 18:33 |
sapier |
https://github.com/sapier/adv_spawning |
| 18:33 |
|
numZero joined #minetest-dev |
| 18:35 |
sapier |
but back to client on globalstep Imho there's no reason to run async thread within main client thread |
| 18:35 |
sapier |
on server it's required to have map r/w access but that's not required in client anyway |
| 18:37 |
sapier |
same for core.after that one could be run in a separate thread too (well I quess it'd be automaticaly there anyway) |
| 18:58 |
|
Krock joined #minetest-dev |
| 19:00 |
|
numZero_ joined #minetest-dev |
| 19:05 |
celeron55 |
is anyone in the current csm developers willing to try those? |
| 19:11 |
nrzkt |
no not actually |
| 19:18 |
|
STHGOM joined #minetest-dev |
| 19:18 |
|
STHGOM joined #minetest-dev |
| 19:26 |
|
rubenwardy joined #minetest-dev |
| 19:28 |
|
STHGOM joined #minetest-dev |
| 19:30 |
|
STHGOM joined #minetest-dev |
| 19:39 |
red-001 |
ok fixed all the issues I could find with the get_wielded_item pr but it will need to be reviewed again and it's a way larger change now |
| 19:48 |
rubenwardy |
I'm currently working on meta data. I've made NodeMetadata inherit from Metadata, and made item metadata mostly work (I'm just working on serialisation atm) |
| 19:48 |
sapier |
metadata? clientside? |
| 19:50 |
rubenwardy |
see my shared_metadata branch |
| 19:50 |
rubenwardy |
gtg now |
| 19:51 |
sapier |
ahh paramat merged the multiply pull ;-) thanks |
| 19:53 |
* red-001 |
was working on client-sided metadata |
| 19:56 |
sapier |
red-001 what are client side metadata supposed to do? |
| 19:57 |
red-001 |
it's a copy of the server-sided metadata |
| 19:57 |
red-001 |
for use by mods |
| 19:57 |
sapier |
but there's no way back to server? |
| 19:57 |
red-001 |
no |
| 19:57 |
red-001 |
there isn't even a way to change it localy |
| 19:57 |
red-001 |
just a read-only copy of the server metadata |
| 19:58 |
sapier |
hmm well you'll have a usecase for it for sure as you spend time on it |
| 19:58 |
red-001 |
easy stop the digging of a chest if it has items in it |
| 19:59 |
sapier |
wouldn't that be better done in core instead of csm? |
| 19:59 |
red-001 |
stops the chest from disappearing and reappearing as soon as the server catches up to the client |
| 20:00 |
red-001 |
why so? |
| 20:00 |
sapier |
seems like exactly same usecase as protection |
| 20:01 |
red-001 |
well that could also be improved my client-sided modding |
| 20:01 |
red-001 |
by* |
| 20:01 |
sapier |
no |
| 20:01 |
red-001 |
why not? |
| 20:01 |
sapier |
protection is nothing to be done in mods as protection has to be enforced by server |
| 20:02 |
red-001 |
yes server enforces it, but the client can make it seem less laggy by not digging nodes that are protected |
| 20:02 |
sapier |
of course everything can be done in mods ... but question is always does it make sense to do it in mods |
| 20:03 |
sapier |
basicaly this is check a flag "can node be digged" ... it#s quite simple to check in c++ but a lot of overhead in lua |
| 20:18 |
|
octacian_ joined #minetest-dev |
| 20:23 |
|
juhdanad joined #minetest-dev |
| 20:28 |
|
STHGOM joined #minetest-dev |
| 20:31 |
|
Fixer joined #minetest-dev |
| 20:34 |
|
DonBatman joined #minetest-dev |
| 20:41 |
|
STHGOM joined #minetest-dev |
| 20:52 |
|
DFeniks joined #minetest-dev |
| 21:32 |
|
STHGOM_ joined #minetest-dev |
| 21:32 |
red-001 |
closed #4798 as it should be done using client-sided modding |
| 21:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/4798 -- Allow overriding and disabling the death formspec. by red-001 |
| 21:36 |
|
STHGOM_ joined #minetest-dev |
| 22:06 |
|
turtleman joined #minetest-dev |
| 22:10 |
|
octacian joined #minetest-dev |
| 22:22 |
|
proller__ joined #minetest-dev |
| 22:30 |
|
proller joined #minetest-dev |
| 22:44 |
|
DI3HARD139 joined #minetest-dev |
| 22:47 |
|
proller joined #minetest-dev |
| 23:00 |
|
Karazhan joined #minetest-dev |
| 23:03 |
|
sapier1 joined #minetest-dev |
| 23:08 |
|
rubenwardy joined #minetest-dev |
| 23:25 |
|
QwertyDragon joined #minetest-dev |
