| Time |
Nick |
Message |
| 00:10 |
|
behalebabo joined #minetest-dev |
| 00:27 |
|
Extex joined #minetest-dev |
| 00:28 |
|
Extex joined #minetest-dev |
| 00:37 |
|
rubenwardy joined #minetest-dev |
| 00:40 |
|
Extex joined #minetest-dev |
| 02:46 |
|
v-rob joined #minetest-dev |
| 03:09 |
MTDiscord |
<Benrob0329> What does Minetest use for unittests? (do we even have unit tests?) |
| 03:40 |
rubenwardy |
Busted for Lua tests |
| 03:40 |
rubenwardy |
Own framework for CPP tests |
| 03:59 |
MTDiscord |
<Benrob0329> thanks |
| 04:01 |
MTDiscord |
<Benrob0329> would be nice if this was mentioned in README or CONTRIBUTING files |
| 05:15 |
MTDiscord |
<Warr1024> I guess you need a second for 9315 ... am I qualified for that? I'm not making the assumption here that "I see nothing wrong with your code" means I would... |
| 05:16 |
MTDiscord |
<Warr1024> I can at least test the 5.5 client against a 5.4 server though... |
| 05:21 |
MTDiscord |
<Warr1024> Seems to work for me, and I neither see nor smell any problem with the code. |
| 05:46 |
|
specing_ joined #minetest-dev |
| 06:33 |
|
appguru joined #minetest-dev |
| 06:49 |
celeron55 |
<+rubenwardy> any objections to ignoring `/irrlicht` in the repo <+rubenwardy> actually, I suppose it should be `/lib/irrlicht` maybe |
| 06:50 |
celeron55 |
i think i requested this already so obviously no objection |
| 07:21 |
|
tekakutli joined #minetest-dev |
| 07:28 |
sfan5 |
there's already a PR that adds the "automatically use irrlichtmt if we see it" and it uses /lib/irrlichtmt for that |
| 07:51 |
celeron55 |
ah, and the related irrlicht PR was merged already |
| 07:52 |
celeron55 |
so this one https://github.com/minetest/minetest/pull/11276 |
| 07:54 |
* celeron55 |
tests |
| 08:01 |
celeron55 |
well, works for me, i guess there's that irrlicht sub library thing still being figured out |
| 09:32 |
Calinou |
hmm, I just noticed now that there's auto-walk functionality in the client |
| 09:32 |
Calinou |
it's nice, but it doesn't make you float in liquids, so you end up drowning if you use it to travel through a lake |
| 09:32 |
celeron55 |
it's a debug feature not intended for gameplay |
| 09:33 |
celeron55 |
...having said that, i guess it also could require the debug privilege |
| 09:33 |
celeron55 |
that is being added |
| 09:33 |
Calinou |
I'm aware this used to exist as `continuous_forward` in minetest.conf, but it's exposed in the key settings now |
| 09:33 |
Calinou |
so I assume it's an user-facing feature |
| 09:33 |
Calinou |
I think nrzkt added it because WoW also has auto-walk |
| 09:33 |
celeron55 |
wait did someone add a key binding to it |
| 09:33 |
Calinou |
yeah, it's in 5.5.0-dev at least |
| 09:34 |
Calinou |
it doesn't have a default shortcut, you have to add one |
| 09:34 |
celeron55 |
ehm... well i guess it's there to stay then |
| 09:34 |
Calinou |
to be fair, it's useful on servers that don't have fast mode and you have to travel through a long straight road… so I'd be for keeping it |
| 09:34 |
celeron55 |
i think it shouldn't do anything but walk though |
| 09:35 |
Calinou |
with automatic jump, you can also travel on natural terrain as long as it's not too steep |
| 09:39 |
specing |
Calinou: those servers also tend to dislike automated clients |
| 09:39 |
specing |
you are supposed to enjoy that 1000 node walk! |
| 09:39 |
specing |
(and the one back, and the next one there, and so on) |
| 09:40 |
celeron55 |
it's an interesting problem in real time games actually |
| 09:40 |
celeron55 |
you'd like to have the gameplay effects of a long walk that you can have in a single player game with adjustable time speed |
| 09:40 |
celeron55 |
but you can't adjust the speed of time |
| 09:41 |
celeron55 |
how can you then make a long distance have any kind of meaning |
| 09:41 |
celeron55 |
probably by making it consume some kind of resource instaed of consuming time |
| 09:43 |
celeron55 |
you see that all the time in online games with some kind of travelling, you start by walking but then sometime later when the developers expect you to be bored of it they enable some kind of fast travel which usually consumes something |
| 09:44 |
celeron55 |
while in a single player game they could have just made fast travel which fast forwards the calendar |
| 09:49 |
|
queria joined #minetest-dev |
| 09:56 |
|
CeeGee joined #minetest-dev |
| 09:57 |
VanessaE |
so, a bit of a discussion with someone just now, he doesn't like MT, thinks "the physics are fucked up".. after a bit of distilling it down :P seems all he's complaining about is that there's no real accel/decel for going from standstill to regular walk speed or the inverse, and that there should be a "cooldown delay" for multiple jumps. thoughts? |
| 09:58 |
celeron55 |
my opinion is that the MC character is clumsy and weak |
| 09:59 |
celeron55 |
anyway, it should be the (sub)game's decision, not the engine's |
| 09:59 |
VanessaE |
agreed |
| 10:00 |
VanessaE |
since I never mess with player physics, I don't know.. do those capabilities already exist? |
| 10:00 |
Calinou |
you can tweak friction/acceleration already |
| 10:00 |
VanessaE |
that's what I thought |
| 10:00 |
Calinou |
but the way Minetest does friction/acceleration is a bit weird compared to other games |
| 10:00 |
Calinou |
it's more like linear instead of quadratic or something |
| 10:00 |
VanessaE |
so his real complaint is that the defaults need adjusted :P |
| 10:01 |
Calinou |
also, modern games *love* their near-instant friction/acceleration |
| 10:01 |
Calinou |
compare Quake to something like Overwatch |
| 10:01 |
VanessaE |
heh, tell HIM that |
| 10:01 |
VanessaE |
it was like pulling teeth just to get him to describe what "fucked up physics" actually means :P |
| 10:02 |
VanessaE |
he was looking at the motion/physics as a ....a sort of "black box" |
| 10:02 |
Calinou |
current Minetest physics are mostly fine to me, the main thing I lament is the slow walking speed |
| 10:02 |
VanessaE |
to him, those "other" games (again, unspecified) have much better motion controls |
| 10:02 |
VanessaE |
same here |
| 10:03 |
Calinou |
one of my ideas was to make continuous walking in one direction progressively faster, effectively acting as a kind of automatic sprinting |
| 10:03 |
Calinou |
e.g. if you walk straight for 3 seconds, your speed increases to 5 nodes/s |
| 10:03 |
VanessaE |
while I'm on the ground I pretty much always run if it's more than a few meters |
| 10:03 |
VanessaE |
(while flying, I vary a lot between fast and slow due because of my own slow reaction times) |
| 10:04 |
Calinou |
also, you know what's fun? Swimming physics in Minecraft feel a lot like Minetest's now, default sinking is slower and you can manually sink by sneaking while in water |
| 10:04 |
Calinou |
so they pretty much copied Minetest on this :P |
| 10:04 |
VanessaE |
well that's kind of a half sprint. run speed is like, 15 m/s isn't it? |
| 10:04 |
VanessaE |
(I don't remember offhand) |
| 10:04 |
Calinou |
it's 20 m/s |
| 10:04 |
VanessaE |
close enough. |
| 10:04 |
VanessaE |
good idea though |
| 10:05 |
|
tekakutli joined #minetest-dev |
| 10:05 |
Calinou |
fast mode is kind of overpowered for survival mode, so we need something more reasonable that works automatically |
| 10:05 |
VanessaE |
I wonder how easy it would be to make a mod out of that |
| 10:05 |
Calinou |
sprintjumping in Minecraft is about 5.6 nodes/s, and sprinting in Minecraft with a Speed II potion is around 6 nodes/s |
| 10:05 |
Calinou |
so I guess automatic sprinting could be between 5 nodes/s and 5.5 nodes/s |
| 10:06 |
VanessaE |
for comparison, I have "Nitro" stations on a couple of my servers that boosts your speed to 3x normal, so 60/ms, for a couple of minutes once you've "fueled up" |
| 10:06 |
Calinou |
making a server-side mod with this should be fairly easy, but it involves global step for every player |
| 10:06 |
celeron55 |
i think currently it's perfectly doable for a mod to increase speed when walking for some time |
| 10:06 |
celeron55 |
maybe a bit laggy |
| 10:06 |
celeron55 |
adding some more engine support would make sense |
| 10:06 |
Calinou |
detect the player's forward input and see if it was held for more than X seconds, then increase speed until the forward key is let go |
| 10:07 |
VanessaE |
yeah, it's the globalstep part that I figured would be the hang-up |
| 10:07 |
VanessaE |
Calinou: problem there is there isn't any kind of "on key press"/"on key release" events |
| 10:07 |
VanessaE |
if we had those, this would be trivia; |
| 10:07 |
VanessaE |
trivial* |
| 10:08 |
Calinou |
yeah, so you need polling :( |
| 10:08 |
Calinou |
also, another way to make walking speed more controllable would be to give aome bonus speed when holding nothing in your hand. This could work in tandem to automatic sprinting, or as an alternative |
| 10:08 |
Calinou |
some* |
| 10:08 |
Calinou |
say, walking at 4.5 nodes/s instead of 4 nodes/s |
| 10:08 |
VanessaE |
technic did something like that |
| 10:08 |
VanessaE |
or the armor mod rather |
| 10:08 |
Calinou |
like holding a knife in Counter-Strike :P |
| 10:08 |
VanessaE |
if you were wearing a hazmat suit, your speed was reduced |
| 10:09 |
VanessaE |
(jump height too I think) |
| 10:09 |
celeron55 |
i think we could have a "general good ideas for games with example code" wiki or forum page or something |
| 10:09 |
celeron55 |
so that not everyone has to invent everything that makes sense from scratch |
| 10:09 |
VanessaE |
celeron55: we could, but really I just wanted to pass along his arguments in a more.... constructive form :) |
| 10:09 |
celeron55 |
these are things that can't necessarily be added by default to the engine, or it isn't the right place |
| 10:10 |
Calinou |
we can make a mod for this kind of stuff, but we have to figure out a way to make it easy on server resources |
| 10:10 |
VanessaE |
(because honestly, I'm happy with the way movement is handled now, though I might find uses for on-key/on-release callbacks if they came into being some time) |
| 10:10 |
celeron55 |
checking they keys of players in globalstep doesn't take enough resources to matter |
| 10:10 |
VanessaE |
you sure? |
| 10:10 |
celeron55 |
110% sure |
| 10:11 |
celeron55 |
but it might be laggy due to other code the server is running |
| 10:11 |
VanessaE |
well if you're *110%* sure then I'll accept that :D |
| 10:11 |
VanessaE |
yeah, that's the prob |
| 10:11 |
sfan5 |
*cough* CSM |
| 10:11 |
celeron55 |
it can't be helped even if it's C++ |
| 10:11 |
celeron55 |
sfan5 is on point |
| 10:11 |
VanessaE |
the code in the globalstep might be super fast, but general game lag would be a prob |
| 10:11 |
celeron55 |
altough, i'd like to not call it CSM but just a physics modifier script |
| 10:11 |
VanessaE |
well, a CSM might be a place for this, |
| 10:12 |
VanessaE |
but it would have to be SSCSM for sure |
| 10:12 |
sfan5 |
sure that's what I meant |
| 10:12 |
celeron55 |
if someone isn't taking the ball on this, i will, some day |
| 10:12 |
VanessaE |
I mean, altering physics client-side will definitely break some games, like Nodecore |
| 10:12 |
celeron55 |
but i read through that last implementation i made and it was over 1000 lines |
| 10:12 |
celeron55 |
a bit scary for such a simple feature |
| 10:13 |
VanessaE |
eep |
| 10:13 |
celeron55 |
well i guess it's not that simple |
| 10:13 |
VanessaE |
1000 LOC to implement SSCSM> |
| 10:13 |
celeron55 |
i'm pretty sure it will be revolutionary |
| 10:13 |
celeron55 |
and think i'm stupid for not adding it then |
| 10:13 |
celeron55 |
back then |
| 10:13 |
VanessaE |
that's a little on the... verbose side I guess |
| 10:14 |
VanessaE |
but maybe not stupid big |
| 10:14 |
VanessaE |
I mean, how much of that was whitespace, comments, and shit like proper code style? |
| 10:14 |
celeron55 |
it's not generic SSCSM, i'm not sure if i want generic SSCSM |
| 10:14 |
Calinou |
I can try my hand at writing such a mod if there's interest, it's been a while since I wrote a Minetest mod |
| 10:14 |
Calinou |
might not be ideal, but can be a decent stopgap for smaller servers |
| 10:14 |
Calinou |
(or singleplayer) |
| 10:14 |
sfan5 |
what would "generic SSCSM" entail? |
| 10:15 |
celeron55 |
the server sending code to run within the current client-side lua environment |
| 10:15 |
VanessaE |
as opposed to what? |
| 10:15 |
specing |
> celeron55 | i'm pretty sure it will be revolutionary |
| 10:15 |
specing |
yes |
| 10:15 |
celeron55 |
i think it makes sense to inject just a little bit of lua into the client to specific places to run synchronously and replace some hardcoded calculations |
| 10:15 |
celeron55 |
in very tight sandboxes |
| 10:15 |
VanessaE |
mmmmm |
| 10:15 |
VanessaE |
no... |
| 10:16 |
specing |
Also, I'd like to see the "SSCSMs" being downloaded from a central contentDB and not individual servers |
| 10:16 |
celeron55 |
none of this "make everything possible and make the client and server fight with each other" |
| 10:16 |
VanessaE |
that'll put things into that real of "oh damn it, now I have to expose this, this, and THIS to Lua, this is nasty" |
| 10:16 |
VanessaE |
realm* |
| 10:16 |
VanessaE |
(did I get your general speech pattern right this time? l;) ) |
| 10:16 |
VanessaE |
;) |
| 10:17 |
VanessaE |
I mean on the one hand, a CSM shouldn't be able to send keystrokes or tell the server "hey I'm zapping over to this spot 200m away" |
| 10:17 |
celeron55 |
again, read this if you want to know what i want to make https://github.com/celeron55/minetest/compare/297546af3d3b5b3a07a61ade041ad7c26e9a531d..1f4ca9df4219768d7678ccccd5e6ceba720e2930 |
| 10:18 |
VanessaE |
but on the other hand if you try to limit how much the code is allowed to do, you'll end up forever adding more and more to the client's Lua API |
| 10:18 |
celeron55 |
you end up forever adding more and more anyway, that's not something you can avoid |
| 10:18 |
VanessaE |
mmm, yeah I suppose |
| 10:18 |
celeron55 |
unless you just decide not to |
| 10:18 |
VanessaE |
but there's a limit to how specific an API call should be |
| 10:18 |
celeron55 |
just have some discipline |
| 10:20 |
VanessaE |
I mean take the aforementioned key-down/key-up events -- it would be enough to just have the client send a packet to the server any time a key is pressed identifying the key, regardless of what that key is assigned as (along with exchanging a map of assignments at login), rather than say sending "sneak pressed", "sneak released", "run pressed", etc. etc |
| 10:20 |
celeron55 |
why i want this is mostly a security thing, to be honest |
| 10:21 |
celeron55 |
VanessaE: you still can't avoid lag, the server is inhrently laggy internally |
| 10:21 |
VanessaE |
nono |
| 10:21 |
VanessaE |
nevermind that |
| 10:21 |
specing |
CSMs should be able to intercept all but one key |
| 10:21 |
VanessaE |
nonononono |
| 10:21 |
specing |
I said CSMs, not SSCSMs :P |
| 10:21 |
VanessaE |
I'm just using it as an example, because it was the first thing to come to mind |
| 10:22 |
VanessaE |
I fear that if "generic SSCSM" is disallowed, then API calls will tend more toward the latter, overly-specific stuff |
| 10:22 |
VanessaE |
plus, |
| 10:22 |
celeron55 |
there's benefit to limiting the keymapping to a reasonable size, it allows other control methods than a keyboard to be used |
| 10:23 |
VanessaE |
it's SSCSM, so shouldn't the server already be ready to deal with the results of the code it sends to the client? :) |
| 10:23 |
celeron55 |
of course it would be a nice trick for server owners to ban all mobile clients by asking them to press a key on the keyboard |
| 10:23 |
VanessaE |
haha |
| 10:24 |
specing |
on-screen keyboards exist |
| 10:24 |
celeron55 |
you can't usually open one without a text field to input into |
| 10:24 |
VanessaE |
I was thinking more like assigning keys to do neat shit in-game that the client can't do now, but triggering server-side code rather than relying on the client to do something with it |
| 10:25 |
celeron55 |
anyway you're both getting into something completely different than what i wanted to discuss |
| 10:25 |
VanessaE |
like, I dunno, pressing say "B" to pop up the contents of your most recently used bag or something |
| 10:25 |
celeron55 |
so i'll now go mow the grass that i wanted to do yesterday -> |
| 10:25 |
VanessaE |
yeah, sorry about that. off on a tangent again |
| 10:26 |
celeron55 |
that sounds like everyone will just use a CSM that sends all keys to the server and you'd be better off just hardcoding sending all the keys into the client |
| 10:26 |
VanessaE |
btw the lawn can wait :) |
| 10:27 |
VanessaE |
I didn't even notice that the previous convo was kinda on this subject heh |
| 10:27 |
|
entuland joined #minetest-dev |
| 10:28 |
VanessaE |
this was not intended to encroach on that. it had been 13 minutes, so I thought y'all were idle |
| 10:28 |
VanessaE |
(that much I *did* check, to avoid interrupting) |
| 10:30 |
specing |
> that sounds like everyone will just use a CSM that sends all keys to the server |
| 10:30 |
specing |
nah, latency is a problem |
| 10:31 |
VanessaE |
well, latency would still be a problem even without that, after all a command to start walking still takes time to reach the server so that it can relay the player's movements to other clients. |
| 10:32 |
VanessaE |
but in this case I was talking about using this hypothetical feature for things where lag wouldn't really be any more of a problem than, say, opening the inventory |
| 10:32 |
VanessaE |
than say, lag while opening* |
| 10:33 |
celeron55 |
you can't even imagine the things i want to make possible 8) |
| 10:34 |
specing |
VanessaE: client-side prediction |
| 10:34 |
specing |
client can start walking before others take note of it |
| 10:35 |
VanessaE |
still all of this boils down to: it's possible to fake what that guy wants right now by polling during globalstep and altering player physics in a semi-smart way |
| 10:36 |
celeron55 |
that's not faking |
| 10:36 |
celeron55 |
it's an implementation |
| 10:36 |
specing |
Hmm |
| 10:36 |
celeron55 |
i just faked firefox onto my computer in order to read the news |
| 10:36 |
celeron55 |
wait, that's called installing |
| 10:36 |
specing |
the whole walking logic could be moved to a CSM that traps w,a,s,d,space,sneak |
| 10:37 |
celeron55 |
now i'll go fake the lawn |
| 10:37 |
VanessaE |
well, it's faking in that the client wouldn't be sending discrete start/stop actions or controlling the physics on its own, the server would be doing it. but your point stands. |
| 10:37 |
specing |
then you could implement a chessboard server, where players take the role of some figurines and can only move by pointing and clicking at a valid tile |
| 10:37 |
specing |
the server would just not load the movement CSM |
| 10:37 |
VanessaE |
specing: don't forget the aux key :) ) |
| 10:37 |
specing |
VanessaE:? |
| 10:38 |
specing |
I don't know of any aux key |
| 10:38 |
VanessaE |
"E" on mine, its use varies |
| 10:38 |
celeron55 |
i'm still going to link this one more time https://github.com/celeron55/minetest/compare/297546af3d3b5b3a07a61ade041ad7c26e9a531d..1f4ca9df4219768d7678ccccd5e6ceba720e2930 |
| 10:38 |
VanessaE |
but I use it for fast running, and for descend while flying |
| 10:38 |
celeron55 |
maybe someone some day will tell me one comment about it |
| 10:39 |
specing |
VanessaE: ah,yes |
| 10:39 |
VanessaE |
celeron55: I would, but I'm just not qualified :P |
| 10:39 |
sfan5 |
- |
| 10:40 |
sfan5 |
oops |
| 10:40 |
sfan5 |
celeron55: what is your opinion on client scripts stalling the client? (as in: is it okay if this happens) this could be avoided by moving them to a separate thread and doing everything over IPC but that'd be a lot of extra work |
| 10:43 |
VanessaE |
why not have a timeout, which if exceeded kills the offending function and prevents it from running again (until the next restart)? |
| 10:43 |
VanessaE |
like say 10s (during which time the client would display some message) |
| 10:43 |
sfan5 |
how do you safely recover your main thread from being stuck inside a function? |
| 10:44 |
sfan5 |
you pretty much need the IPC solution if you'd want to do this |
| 10:44 |
VanessaE |
or a watchdog thread? |
| 10:44 |
VanessaE |
but I see your point |
| 10:46 |
specing |
You know, CSMs seem like a "fresh start" where you force people to get used to multithreaded lua |
| 10:46 |
sfan5 |
you cannot multithread lua |
| 10:46 |
specing |
you can force* |
| 10:46 |
specing |
Why not? |
| 10:46 |
sfan5 |
isolated environments in separate threads is not multithreading |
| 10:47 |
sfan5 |
not according to my mental definition at least |
| 10:47 |
VanessaE |
I'm just thinking that for some mods, it might be desirable to offload some work to the client, though only during times when the player wouldn't be expecting instant responses. Maybe you have an inventory button that if clicked, launches a feature that would lag the server....unless it triggers that code to run on the client. then only that one client lags. |
| 10:47 |
specing |
sfan5: it is when those isolated environments are concurently accessing the same API |
| 10:49 |
specing |
sfan5: the point here is to get people used to multithreading |
| 10:49 |
specing |
so that at some later point, it'll be easier to multithread server lua |
| 10:50 |
sfan5 |
ok so here's the thing with multithreaded server lua: if you want all those environment to use the exact same APIs you will end up with a giant lock that covers the server |
| 10:50 |
sfan5 |
then you have multiple threads only one of which can only ever do real work |
| 10:51 |
specing |
Why would you need to lock say the whole inventory manipulation API just to access one list of one node? That's crazy |
| 10:51 |
specing |
you just lock that node and that's it |
| 10:53 |
sfan5 |
map access is probably one of the easier problems |
| 10:55 |
VanessaE |
it's not like you'd have to worry about lua threads stomping on each others' states either, if you sandbox them |
| 10:56 |
celeron55 |
if every node has a lock, that slows down the entire works |
| 10:56 |
VanessaE |
even globals would be local within the sandbox, so you'd have to explicitly request access to a truly meta-global environment for ... well I guess you could call it a primitive IPC |
| 10:56 |
celeron55 |
even if every mapblock has a lock |
| 10:56 |
celeron55 |
any locks whatsoever actually |
| 10:57 |
celeron55 |
if the threaded mods only communicated through ipc, then of course it's an entire different thing and would owrk |
| 10:57 |
celeron55 |
work* |
| 10:57 |
celeron55 |
the apis would be hideous though and nobody would want to use it |
| 10:57 |
celeron55 |
and nobody would want to make it |
| 10:57 |
pgimeno |
if two Lua threads have to share variables, every access to every variable needs a global lock. That's how emerge threads are working now, and it's awful. |
| 10:58 |
celeron55 |
if the api was just a communication queue to a part of the mod in the non-threaded lua environment, i.e. worker threads, it would be doable |
| 10:58 |
sfan5 |
I do have a WIP PR for that |
| 10:58 |
celeron55 |
so just tell me if you want worker threads or not, if the answer is yes i say ok that'll happen sometime, if the answer is no i'll say that will never happen, don't even propose it |
| 10:58 |
sfan5 |
though there's no IPC yet |
| 10:58 |
|
calcul0n joined #minetest-dev |
| 10:59 |
sfan5 |
(apart from pushing jobs to a worker) |
| 10:59 |
sfan5 |
(and getting a result back) |
| 10:59 |
VanessaE |
let's be clear, |
| 10:59 |
celeron55 |
sfan5: that's actually already enough |
| 10:59 |
VanessaE |
"worker threads" would be chunks of lua running async from the "normal" server process? |
| 10:59 |
sfan5 |
yes |
| 10:59 |
celeron55 |
yes, with no synchronous interfaces available whatsoever |
| 11:00 |
celeron55 |
i.e. pretty much no interfaces |
| 11:00 |
celeron55 |
just data in, data out |
| 11:00 |
sfan5 |
it *is* enough but you do want to be able to push a vmanip into there without serializing to and endless string first |
| 11:00 |
VanessaE |
if biome_lib could benefit from such a thing, then by G*d yes, I want. :) |
| 11:00 |
sfan5 |
push = copy, not by reference |
| 11:01 |
sfan5 |
#11131, it's probably not of any use unless you have computationally intensive work that doesn't touch the map or can work on a copy |
| 11:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/11131 -- Async environment for mods to do concurrent tasks by sfan5 |
| 11:01 |
specing |
sending stuff to a thread will often outweight the benefits, esp with vmanip |
| 11:01 |
celeron55 |
what's the main workload of biome_lib? |
| 11:01 |
specing |
just give us proper locking |
| 11:01 |
VanessaE |
it would mean I could finally ditch the thing I do now which is *almost* multi-thread (if you use the old definition from back in the day) |
| 11:01 |
celeron55 |
i started minetest by trying to allow locking parts of the map, it wasn't possible and made everything slow |
| 11:01 |
VanessaE |
celeron55: writing nodes to the map |
| 11:01 |
celeron55 |
it won't happen, it's impossible |
| 11:02 |
VanessaE |
if I could launch an async thread, I could run an entire block's worth of actions in one go, instead of splitting them up across many globalsteps. |
| 11:02 |
specing |
celeron55: locking blocks? |
| 11:02 |
celeron55 |
writing node to the map will always stop almost everything because almost everything depends on the map content |
| 11:02 |
VanessaE |
it would undoubtedly be faster than what I'm doing nowe |
| 11:02 |
VanessaE |
-e |
| 11:02 |
specing |
celeron55: or nodes or random shapes? |
| 11:03 |
celeron55 |
specing: i recall it was mapblocks at the time |
| 11:03 |
specing |
take technic reactor check ABM for example.It would lock a maximum of 8 blocks and run the check, then unlock (technically it could work even without locking, by just reading data that could change underneath) |
| 11:04 |
VanessaE |
celeron55: well in this instance, I might have the async thread write to its own buffer, and then relay that to the map in the main thread via vmanip or something |
| 11:04 |
specing |
but at the same time, all other threads can run on the other 1000 blocsk |
| 11:04 |
specing |
including more reactor check abms |
| 11:04 |
VanessaE |
which would be more or less what the engine does with decorations |
| 11:04 |
sfan5 |
does the ABM do any write operations? |
| 11:04 |
celeron55 |
VanessaE: so if vmanip was transferrable to the worker thread and out, that would enable you to do it? |
| 11:04 |
specing |
sfan5: none, but it can trigger meltdown (after warning siren) |
| 11:04 |
celeron55 |
i think vmanip is probably the key to these |
| 11:04 |
specing |
meltdown swaps the reactor node afaik |
| 11:05 |
sfan5 |
it can safely operate on a copy then, good |
| 11:05 |
sfan5 |
is it that slow? |
| 11:05 |
celeron55 |
copying them, that is |
| 11:05 |
specing |
sfan5: copying takes time |
| 11:05 |
VanessaE |
celeron55: it might -- I'm kinda guessing here, since like most MT folks, I have no real experience with coding for a multi-thread environment (though I did try to make sure biome_lib would be thread-safe if that day ever came) |
| 11:05 |
celeron55 |
copying is just memcpy, it's very fast |
| 11:05 |
celeron55 |
faster than locking |
| 11:05 |
sfan5 |
and locking halt everything, your point? |
| 11:05 |
celeron55 |
that's why it's used |
| 11:05 |
sfan5 |
+s |
| 11:05 |
specing |
sfan5: it just counts node names, that's it |
| 11:05 |
specing |
sfan5: no, locking halts everything only in the locked blocks |
| 11:05 |
specing |
all the other stuff can still run elsewhere |
| 11:06 |
sfan5 |
I asked about slow because if the ABM is fast then you don't need to optimize it |
| 11:07 |
celeron55 |
what does the reactor check actually do, and in how big area? how slow is it now? |
| 11:07 |
VanessaE |
celeron55: but sure, provided I can come to understand how vm's work, if the engine passed me a vm for a mapblock or a chunk or whatever, and I could DO ALL THE THINGS on it while the engine goes on to handle normal stuff, and just hand it back to the engine whenever I feel like it, that may just work. again, 100% guessing, 0% experience here. |
| 11:07 |
specing |
it runs a dozen ifs in a loop over 7^3 nodes |
| 11:08 |
celeron55 |
copying a vmanip is ideal for operating on 7^3 nodes |
| 11:08 |
specing |
It's probably not much, but if you have hundreds of reactors active on a server.... it adds up |
| 11:08 |
celeron55 |
it's literally made for it |
| 11:08 |
celeron55 |
imagine that |
| 11:08 |
celeron55 |
there's already a thing designed for what you want to do and it can be copied into a thread |
| 11:08 |
celeron55 |
and you don't want it |
| 11:09 |
sfan5 |
https://github.com/minetest-mods/technic/blob/1c219487d3f4dd03c01ff9aa1f298c7c18c7e189/technic/machines/HV/nuclear_reactor.lua#L141-L210 |
| 11:09 |
celeron55 |
...what, it already uses a vmanip also |
| 11:09 |
specing |
it does |
| 11:10 |
celeron55 |
we don't need to even discuss about this, what sfan5 is doing will work almost directly for it |
| 11:10 |
specing |
I didn't say that I don't want it. What I don't want is minetest being 100% cpu on one core and others being idle |
| 11:10 |
sfan5 |
question is will it even matter? that code looks like it should be fast |
| 11:11 |
sfan5 |
though it can't hurt to offload everything that can be offloaded |
| 11:11 |
celeron55 |
if there are hundreds of those and they are forceloaded, then i guess it adds up |
| 11:12 |
VanessaE |
of course where technic is concerned, the biggest CPU suck can't really be offloaded, as it involves reading from the map in an ABM |
| 11:12 |
celeron55 |
especially as the abm is set up so that every one runs at the same step |
| 11:12 |
celeron55 |
no spreading of work at all |
| 11:12 |
VanessaE |
(the switching station and battery loops) |
| 11:12 |
celeron55 |
it would be a good idea to have a higher chance value and lower interval value |
| 11:13 |
sfan5 |
I guess I do need to finish my PR after all |
| 11:13 |
celeron55 |
set it to interval=1 and chance=10 and you'll probably have no lag at all, you won't even know the code is there |
| 11:13 |
celeron55 |
and it'll have some fun randomness also |
| 11:14 |
celeron55 |
abms are highly optimized for random effects, having a very short interval and low 1/chance value makes them happyu |
| 11:14 |
VanessaE |
that would almost certainly work for the nuke integrity check |
| 11:14 |
celeron55 |
-u |
| 11:46 |
|
appguru joined #minetest-dev |
| 12:28 |
rubenwardy |
merging #11374 as trivial doc fix in 10 |
| 12:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/11374 -- Document hypertext escaping by Wuzzy2 |
| 12:31 |
|
tekakutli joined #minetest-dev |
| 12:36 |
|
hecks joined #minetest-dev |
| 12:41 |
|
queria^clone joined #minetest-dev |
| 13:10 |
|
queria joined #minetest-dev |
| 13:10 |
|
queria joined #minetest-dev |
| 13:59 |
|
olliy joined #minetest-dev |
| 14:11 |
nrz |
celeron55, strange it's a debug feature, it's my favourite feature in world of warcraft while traveling on long distances :D |
| 14:11 |
nrz |
oops i have few hours late... i talk about auto walk :D |
| 14:14 |
celeron55 |
i think a game design where auto walk is needed is automatically questionable |
| 14:17 |
celeron55 |
a bit like C++ code with gotos... like ok maybe if you insist and it feels nice, but very oldskool |
| 14:20 |
|
Fixer joined #minetest-dev |
| 15:26 |
MTDiscord |
<Benrob0329> Some thoughts/notes: Nodecore has gradual sprinting. fast_mode has a settable speed. There are Lua modules for multithreading, these may just spawn up multiple instances though. |
| 15:38 |
|
tekakutli joined #minetest-dev |
| 15:39 |
|
tekakutli joined #minetest-dev |
| 15:50 |
MTDiscord |
<Warr1024> NodeCore automatically handles player speed and doesn't require a "sprint" keybinding ... but its base "walking" speed is already 25% faster than MTG's anyway... |
| 15:51 |
MTDiscord |
<Warr1024> Is "auto-walk" like where you run by default but automatically slow down when you near boundary conditions or points of interest? |
| 15:51 |
celeron55 |
no, it's like putting a stone on your up key on the keyboard |
| 15:53 |
MTDiscord |
<Warr1024> oh, you mean like the "auto-forward" toggle that MT has? |
| 15:53 |
MTDiscord |
<Warr1024> I use that feature all the time. It's a great way to fall into a ravine while you're trying to chat and travel at the same time :-D |
| 16:05 |
|
olliy joined #minetest-dev |
| 16:33 |
nrz |
celeron55, whats the point to press up key for 1 hour to go straight forward ? instead just run and go make a coffee :D |
| 16:43 |
celeron55 |
what's the point to make a game where you have to press up key for 1 hour? |
| 16:43 |
celeron55 |
or, walk for 1 hour |
| 16:44 |
celeron55 |
it, of course, really emphasizes the distance, but on the other hand 1 hour of walking isn't that much anyway |
| 16:45 |
celeron55 |
it's like 5 kilometers, barely enough for a trip to another town |
| 16:45 |
celeron55 |
if you compare to real life |
| 16:47 |
nrz |
celeron55 map is pretty huge, imagine you build at 1000 1000 1000 and you need to go to friend house at -24000 1000 1000 :D |
| 16:47 |
nrz |
it's not fun to walk like IRL in a game :D |
| 16:48 |
celeron55 |
well i would argue it's not fun to walk IRL either |
| 16:48 |
celeron55 |
but what i'm saying is travelling should be fast in time but cost something else |
| 16:48 |
celeron55 |
in most games |
| 17:01 |
MTDiscord |
<Jonathon> Auto forward sounds like a good thing if your making run(flash game) in minetest |
| 17:05 |
|
Wuzzy joined #minetest-dev |
| 17:27 |
nrz |
or just for servers with very big corridors :D |
| 17:31 |
Krock |
sfan5: negative setting layer values might not even be needed. `*m_hierarchy` defines whether it's bound or not |
| 17:32 |
Krock |
but then again, it makes no difference |
| 17:36 |
sfan5 |
I think so too |
| 17:37 |
nrz |
i think you always have a setting layer, then -1 has no sense :) |
| 17:37 |
nrz |
why create empty settings ? |
| 17:38 |
Krock |
I think the map_meta.txt uses its own Settings object |
| 17:38 |
Krock |
err. world-mt |
| 17:38 |
nrz |
and it's not possible to setup the Settings on world.mt with virtually one layer ? at least we are coherent everywhere |
| 17:39 |
Krock |
stuff that happens to be unrelated to the normal settings, such as mod.conf, override.txt (perhaps?), world.mt |
| 17:39 |
Krock |
layers are only needed for fallbacks |
| 17:39 |
Krock |
if there's no need for a fallback, layers are useless anyway |
| 17:39 |
nrz |
then i think i didn't understood the purpose of layers |
| 17:39 |
nrz |
it's not to haveff settinga.sub_b.sub_c setting ? |
| 17:39 |
nrz |
have* |
| 17:40 |
Krock |
nope. they define the order of fallback in case a setting was not found |
| 17:40 |
nrz |
okay then i think we have a naming issue :D |
| 17:40 |
nrz |
it's why i asked for a zero layer :p |
| 17:43 |
Krock |
will push https://krock-works.uk.to/u/patches/0001-Server-Ignore-whitespace-only-chat-messages.patch to supersede #11187 in 15 minutes. followed by #11355 |
| 17:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11187 -- Disallow empty messages by DiamondPlane |
| 17:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11355 -- Buildbot: Use posix on Win64 builds while running from Ubuntu based distributions by juozaspo |
| 17:44 |
Krock |
unless there are objections for former |
| 17:44 |
rubenwardy |
I haven't been tracking that setting hierarchy PR, but I hope it doesn't make world specific settings harder |
| 17:44 |
Krock |
no, it's unaffected |
| 17:44 |
sfan5 |
if anything it makes it easier |
| 17:45 |
nrz |
then you have my approval |
| 17:45 |
Krock |
well it depends on whether the mapgen needs fallback to world-specific settings, but I doubt that. |
| 17:45 |
sfan5 |
because right now we have settings layer called SL_MAP which is *not* a world-specific minetest.conf like you might guess |
| 17:45 |
Krock |
but it can be abused as such |
| 17:46 |
Krock |
since the API functions are there and are accessible to all mods |
| 17:50 |
Krock |
however now this could be restricted by checking whether the setting is contained in m_defaults, and only allow write for those |
| 17:58 |
Krock |
pushing/merging |
| 18:41 |
|
appguru joined #minetest-dev |
| 19:04 |
|
v-rob joined #minetest-dev |
| 19:09 |
hecks |
Any idea why minetest.exe started being written to /src/ instead of /bin/? Older PRs still write to the correct location. mingw64 cygwin |
| 19:16 |
sfan5 |
I changed that for cross-compiling |
| 19:16 |
sfan5 |
so I could build multiple builds from a single source folder safely |
| 19:52 |
hecks |
hm okay |
| 20:14 |
|
queria^clone joined #minetest-dev |
| 20:19 |
|
queria joined #minetest-dev |
| 21:32 |
|
specing joined #minetest-dev |
| 21:45 |
|
v-rob joined #minetest-dev |
| 23:04 |
|
Alias joined #minetest-dev |
| 23:12 |
|
v-rob joined #minetest-dev |
| 23:15 |
|
calcul0n joined #minetest-dev |
| 23:20 |
v-rob |
Is it possible to make a PR on top of another PR, but make it in the Minetest repo instead of my fork's repo so everyone can see it? |
| 23:31 |
pgimeno |
is your repo private? |
| 23:32 |
v-rob |
No, but if it's in the main Minetest repository, I could get feedback better |
| 23:33 |
pgimeno |
I don't understand well. PRs are sent to the Minetest repository, and the commits are visible by others. |
| 23:36 |
MTDiscord |
<exe_virus> don't make it in the minetest/ repo, please fork and do it in yours, it's absolutely public for everyone and will get auto compiled by the CI just as you would expect |
