| Time |
Nick |
Message |
| 00:10 |
|
MTDiscord6 joined #minetest |
| 00:23 |
|
est31 joined #minetest |
| 00:32 |
|
TheBestBandOnEar joined #minetest |
| 00:41 |
|
TheBestBandOnEar left #minetest |
| 00:43 |
* specing |
asks self a hypothetical question |
| 00:43 |
specing |
"What would happen if player's main inventory's size were set to something other than 32"? |
| 00:44 |
MTDiscord |
<oneplustwo> it would be anarchy |
| 00:46 |
specing |
I wonder if any mod implicitly depends on it being 32 |
| 00:46 |
specing |
I also wonder where it is set, grepping mt source yields no results |
| 00:47 |
MTDiscord |
<oneplustwo> > "What would happen if player's main inventory's size were set to something other than 32"? @specing IRC#0000 "What if we used 100% of the brain?" |
| 00:47 |
specing |
aha src/constants.h:#define PLAYER_INVENTORY_SIZE (8 * 4) |
| 00:52 |
MTDiscord |
<oneplustwo> 8 * 4 equal 32 innit? |
| 00:52 |
MTDiscord |
<oneplustwo> that's right, i still remember my times tables ? |
| 01:31 |
MTDiscord |
<Lone_Wolf> That just sets the default |
| 01:32 |
MTDiscord |
<Lone_Wolf> Nodecore has 8 slot inventories |
| 01:40 |
|
swift110 joined #minetest |
| 01:44 |
|
swift110 joined #minetest |
| 01:56 |
MTDiscord |
<Warr1024> NodeCore has an easier time doing that because it doesn't have to worry about formspecs. There are probably a lot of mods out there that have player inventories in their forms and assume a particular player inventory size. |
| 01:57 |
MTDiscord |
<Warr1024> What happens if you shrink the player's inventory to, say, 24, but then a mod formspec tries to show an 8x4 inventory for the player? Are there just dead slots that don't work right? Or maybe they're truncated? But it won't shrink the overall form to collapse that space... |
| 02:02 |
luk3yx |
There is just a blank space where the non-existent slots are |
| 02:02 |
rubenwardy |
The inventory size isn't hard coded, specing. You can use set_size to change it |
| 02:02 |
rubenwardy |
Oh right, misread |
| 02:03 |
specing |
Warr1024 I set it to 6 |
| 02:04 |
specing |
MTG i key formspec shows 6 slots aligned top left |
| 02:04 |
specing |
2 greyed out slots in top right |
| 02:04 |
specing |
and enough empty space below for 24 slots |
| 02:10 |
|
ghoti_ joined #minetest |
| 02:16 |
|
swift110_ joined #minetest |
| 02:21 |
|
milkt joined #minetest |
| 02:25 |
|
nek0 joined #minetest |
| 02:28 |
|
swift110 joined #minetest |
| 02:35 |
|
nek0 joined #minetest |
| 03:45 |
|
SwissalpS joined #minetest |
| 05:38 |
|
TomTom joined #minetest |
| 06:06 |
|
tiwake joined #minetest |
| 06:10 |
|
Flabb joined #minetest |
| 06:38 |
|
Bombo_ joined #minetest |
| 06:41 |
|
est31 joined #minetest |
| 07:16 |
|
fluxflux joined #minetest |
| 08:00 |
|
ShadowNinja joined #minetest |
| 08:12 |
|
NetherEran joined #minetest |
| 09:01 |
|
FeXoR joined #minetest |
| 09:08 |
|
NetherEran joined #minetest |
| 09:33 |
|
NetherEran joined #minetest |
| 09:34 |
|
Sires joined #minetest |
| 09:39 |
|
sagax joined #minetest |
| 09:57 |
|
CopenBra[m] joined #minetest |
| 09:57 |
|
sturm joined #minetest |
| 09:57 |
|
Parnikkapore[m] joined #minetest |
| 09:57 |
|
rschulman joined #minetest |
| 09:57 |
|
Kimapr[m] joined #minetest |
| 09:57 |
|
golden-boy[m] joined #minetest |
| 09:57 |
|
FrostRanger[m] joined #minetest |
| 09:58 |
|
zughy[m] joined #minetest |
| 09:58 |
|
jfred[m] joined #minetest |
| 09:58 |
|
swedneck1 joined #minetest |
| 09:58 |
|
tuxayo[m] joined #minetest |
| 09:58 |
|
xose[m] joined #minetest |
| 09:58 |
|
Andythe_great[m] joined #minetest |
| 09:58 |
|
LPKI_Ramen joined #minetest |
| 09:58 |
|
antoine62[m] joined #minetest |
| 09:58 |
|
Yves[m]1 joined #minetest |
| 09:59 |
|
Fixer joined #minetest |
| 10:00 |
|
calcul0n joined #minetest |
| 10:03 |
|
lisac joined #minetest |
| 10:34 |
|
Boingo joined #minetest |
| 10:40 |
|
deltasquared joined #minetest |
| 10:41 |
|
Flitzpiepe joined #minetest |
| 10:42 |
deltasquared |
something I wanted to query, it came up during discussion with a developer extending the CSM api to include the ability to read nearby node metadata (whether or not that'd be merged upstream is besides the point). how private are detached inventories at the moment from a network protocol perspective, and if the answer is none or close to none does there exist a mechanism to say "only send this |
| 10:43 |
deltasquared |
inventory to this client and nobody else"? |
| 10:43 |
|
bingfengfsx joined #minetest |
| 10:45 |
sfan5 |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L5119-L5121 |
| 10:46 |
deltasquared |
so second (or third) question, why *is* it "send to all players" the default. I never did get the design rationale for that one. for other exploits the reasoning has been player experience under lag sure, but this I never understood. |
| 10:47 |
deltasquared |
(also thanks for the pointer. my search in the doc file was for the word "private" so I must have mentally skipped over it.) |
| 10:49 |
sfan5 |
how would the server know which and when inventories are needed by the client for display? |
| 10:50 |
deltasquared |
sfan5: formspec parsing, probably. |
| 10:50 |
deltasquared |
inb4 not done on the server atm |
| 10:50 |
sfan5 |
sounds error-prone |
| 10:50 |
sfan5 |
also doesn't work if the formspec is from node metadata |
| 10:50 |
sfan5 |
and won't work once CSM is a thing |
| 10:51 |
deltasquared |
well, then surely a rethink needs to happen. a lock-in to a design with security flaws does not seem adviseable. |
| 10:52 |
|
MDude joined #minetest |
| 10:52 |
sfan5 |
there is no reason you can't ask the mod to specify which players should be able to access an inventory |
| 10:52 |
sfan5 |
s/ask/require/ |
| 10:53 |
deltasquared |
no reason? how about the fact an opt-in is always going to be missed in some cases? |
| 10:55 |
sfan5 |
backwards compatbility doesn't allow that to be changed |
| 10:57 |
deltasquared |
oh, don't give me that. there have been deprecations in releases before now. |
| 10:57 |
deltasquared |
at some point those become hard errors, simple. |
| 10:57 |
deltasquared |
you can't let the entire codebase be dragged down by some mediocre-written mods out there. |
| 10:58 |
sfan5 |
sure, but my opinion on that is that there needs to be very good reason to do that |
| 10:59 |
sfan5 |
and I don't consider breaking old mods that use detached invs to satisfy confidentiality of detached inventories (which most people don't need) a good tradeoff |
| 11:00 |
sfan5 |
but once this is implemented nothing prevents you from configuring *your* server in a way that insecure mods hard-error |
| 11:00 |
tango_ |
hello, what are forceloaded mapblocks? |
| 11:00 |
deltasquared |
sure there is good reason. a dumb design decision was made early on and now it's being rectified. there are a *lot* of dumb decisions that let clients (and don't give me the "honest client" argument either) see way more and do way more than they should ought to be. furthermore, have you ever considered that players and server administrators expect that sort of thing to be private by default? |
| 11:00 |
tango_ |
(for the config entry max_forceloaded_blocks) |
| 11:01 |
sfan5 |
tango_: mods can add a mapblock to the forceload list to keep the loaded in memory even if there are no players nearby |
| 11:01 |
tango_ |
sfan5: OK thanks |
| 11:02 |
specing |
all the mods on blocky either have player name as third parameter to create_detached_inv or are inventories for thrashing things |
| 11:02 |
deltasquared |
I also consider the configuration argument to be somewhat rubbish. you should be pushing towards good practice, not letting irrelevant legacies suprise users, admins and developers alike with counter-intuitive behaviours. |
| 11:04 |
deltasquared |
the attitude is what I'm getting at here. have you ever considered that leaning over backwards for backwards compat even when the original rationale was flawed makes the engine and it's developers look like a joke, that the underlying reasons that hack clients are possible will never get fixed, because you're afraid or otherwise unwilling to sit down and really think about the design and allow some |
| 11:04 |
deltasquared |
breakage to occur, even if minimised? |
| 11:04 |
deltasquared |
ok, maybe the developers being a joke was uncalled for. still, it makes me mad all the time when I want to develop mods for this game. |
| 11:08 |
sfan5 |
We seem to disagree on what "minimised breakage" means exactly |
| 11:09 |
sfan5 |
I hope it's obvious that I don't suggest never fixing these, but I am suggesting a slower approach than you consider acceptable |
| 11:10 |
sfan5 |
also this is just my opinion, if you open an issue about this you can get another opinion from different devs |
| 11:19 |
specing |
I've been reading https://github.com/minetest/minetest/issues/6662 |
| 11:19 |
specing |
and it seems the topic is "let's add some more easily bypassed restrictions to the client" |
| 11:20 |
deltasquared |
sfan5: I suspect the act of even gathering all my architectural gripes with the engine would cause me to break something IRL. there really is that much. certainly not right now, as a professional software developer some of it peturbs me so much I question my ongoing faith in the engine as something I can develop for as a hobby. |
| 11:21 |
specing |
I think that the worst thing so far is that I can read books in non-owned locked chests |
| 11:21 |
deltasquared |
admittedly right now my judgement feels emotionally compromised. though it is a common theme this *always* happens with some aspect or another of the minetest API and the design decisions that underlie it. it all feels _wrong_, and I wonder how the heck it got like that. |
| 11:21 |
specing |
probably followed by placing nodes mid-air |
| 11:22 |
deltasquared |
specing: with respect, this extends to more than stuff witnessed on that one server. |
| 11:22 |
specing |
okay |
| 11:23 |
|
NetherEran joined #minetest |
| 11:23 |
sfan5 |
deltasquared: I meant that particular issue with detached inventories, if I wanted to solve all design issues with the engine/api myself I'd give up too |
| 11:24 |
sfan5 |
also "how it got like that" is (usually) easy, it was never considered that confidentiality of inventories would matter |
| 11:24 |
|
proller joined #minetest |
| 11:25 |
|
calcul0n_ joined #minetest |
| 11:25 |
sfan5 |
..or how anticheat should validate the position of where a node is placed |
| 11:26 |
deltasquared |
re: detached invs. it's data potentially sent over the network, for which usually only a single player should know the contents at a given time. how could that _not_ have been considered. |
| 11:26 |
deltasquared |
I honestly find that incredulous at best. |
| 11:28 |
deltasquared |
again, if that's really true, it shakes my faith in the engine and it's developers. this is like network programming 101, man. you don't even have to assume a fully malicious one to realise this is a bad idea; a client that merely breaks only some "rules" is the more insiduous one as it's harder to detect. |
| 11:29 |
sfan5 |
uh |
| 11:30 |
deltasquared |
and don't circle back on the player name argument either. I already made my point why I thought _that_ was flawed. |
| 11:30 |
sfan5 |
I don't think relaxed security requirements should be a surprise in game development |
| 11:31 |
sfan5 |
but your point is not wrong |
| 11:34 |
deltasquared |
sfan5: sigh. ok, so admittedly I only have a sample size of one here (yourself), but it is evident that there is at least some differing opinion on design priorities. laying aside comment on who's position is "better", it nonetheless brings up an idea I've had for a while. |
| 11:34 |
deltasquared |
I think there does need to be an alternate server-side implementation of the minetest protocol. one where different approaches can be explored without breaking the world of mods. |
| 11:35 |
deltasquared |
I don't just mean a fork, either. complete ground-up. now, I'm not suggesting anyone here should be expected to have to do that. |
| 11:36 |
sfan5 |
a fork would allow you to fix whatever you want paying no mind to mods, but if you want a rewrite I have no idea who would want to write that |
| 11:37 |
deltasquared |
I've been toying with the idea on and off myself actually. now, it is certainly a large undertaking, but it's not a complete empty slate either. |
| 11:37 |
deltasquared |
so of course having blown off steam above now, possibly at everyone's mild detriment here, and having said that, I suspect I may be expecting to put my money where my mouth is now huh. |
| 11:38 |
deltasquared |
s/expecting/expected/ |
| 11:38 |
deltasquared |
even if that means I lolfail in the process. |
| 11:39 |
deltasquared |
sfan5: the reason I'd *want* a re-write as well is because well... I have unrelated *cough*opinions about other parts of engine's design that are orthogonal to the exposed API behaviour. |
| 11:39 |
deltasquared |
so it'd be a place to explore those ideas, too, even if just for myself. |
| 11:40 |
sfan5 |
which parts would that be? |
| 11:40 |
deltasquared |
too many globals, for starters. :P |
| 11:41 |
deltasquared |
I'd probably find more the more I delved in. I'm known to be rather pedantic. for someone else, the project might be a fork. for me, it'd have to be a re-write. that's just my own grave. |
| 11:43 |
deltasquared |
in any case, I need to wrap my head around the network protocol first. I imagine that'll take some time. |
| 11:59 |
deltasquared |
sfan5: ok so just wanted to apologise as some of my comments earlier were borderline abrasive and upon retrospect that particular "have you ever considered..." earlier was unfair to be aimed at you in particular. I've always been afraid that trying to fix the individual problems piecemeal would be blocked, especially if they all inter-relate (and trying to push a massive set of changes through at |
| 11:59 |
deltasquared |
once seldom ends well either). so the frustration has been bottled up for a while. |
| 12:01 |
sfan5 |
MT development is not something that runs well, frustration is understandable |
| 12:03 |
sfan5 |
and conversely to what you said fixing problems one-by-one is probably about the only way you'd have success and they can get fixed |
| 12:06 |
deltasquared |
sfan5: re: frustration, huh... and that comes from the point of view of one of the "bigger" developers? not trying to imply anything but I'm actually genuinely curious now. bearing in mind *I* haven't actually made any PRs for the engine before, so I wonder what makes you in particular say that. |
| 12:07 |
sfan5 |
have you read the forum topics about issue/PR management? |
| 12:07 |
deltasquared |
I have not. first time I was aware such thing(s) existed. |
| 12:08 |
sfan5 |
https://forum.minetest.net/viewtopic.php?f=3&t=24629 |
| 12:08 |
sfan5 |
https://forum.minetest.net/viewtopic.php?f=3&t=25417 |
| 12:08 |
deltasquared |
bearing in mind I normally just go in assuming the usual "don't be a jerk" applies and that has worked mostly fine historically... but as for MT itself, *shrug* |
| 12:10 |
sfan5 |
the gist is that coping with all new issues and (esp.) PRs is a problem and most of that is due to lack of time and/or bad prioritization |
| 12:10 |
sfan5 |
but you should definitely read the topics themselves |
| 12:11 |
deltasquared |
am reading |
| 12:11 |
deltasquared |
> Ridiculous coding style rules |
| 12:11 |
deltasquared |
oof. yeah, I could potentially expend a lot of energy fighting that. |
| 12:11 |
deltasquared |
(as the PR author I mean) |
| 12:12 |
deltasquared |
if it seems pointless and/or arbitary I won't go down without a fight. |
| 12:15 |
deltasquared |
> EXTREMELY time-efficient, |
| 12:15 |
deltasquared |
heh, spotted a typo ;). inb4 someone else did |
| 12:16 |
deltasquared |
(on about wuzzy's point about ping-pong latency.) |
| 12:25 |
|
perrier joined #minetest |
| 12:31 |
specing |
yay deltasquared, lets write a massively multithreaded mt server with server-side physics in Ada :P |
| 12:32 |
deltasquared |
oh, of _course_ you'd plug ada. :P |
| 12:33 |
specing |
:) |
| 12:33 |
specing |
Ada is the go-to language where safety and security is a design requirement |
| 12:34 |
deltasquared |
I suspect it's not all that accessible to would-be contributors though. ;) |
| 12:34 |
specing |
Ada is not hard to learn |
| 12:35 |
specing |
plus the compiler doesen't let you do much stupid |
| 12:35 |
deltasquared |
I don't think C++ as the language was ever a part of the problem with minetest anyway, and it's the language I have the most experience in that has a hope to be always fast. |
| 12:36 |
specing |
it may not be part of the problem, but it certainly isnt part of the solution |
| 12:38 |
deltasquared |
specing: given what I'm about to say I think this may be about to get offtopic for here in particular. back to blocky? |
| 13:24 |
|
kamdard joined #minetest |
| 13:29 |
|
deltasquared left #minetest |
| 13:41 |
|
skyliner_369 joined #minetest |
| 13:42 |
skyliner_369 |
trying to figure out how tool durability attrubutes. specifically, cracky, crumbly, and snappy |
| 13:44 |
|
muke_ joined #minetest |
| 13:44 |
MTDiscord |
<Warr1024> Tool capabilities are complex af. They're also very different between games. |
| 13:46 |
MTDiscord |
<Warr1024> For example, for nodecore, each group has a value and that value controls both the level of material it can dig, and the speed. In minetest_game, each group has a speed value of predetermined speed classes, plus a "level" attribute that controls what tools can mine it, and the tools determine speed for each speed class. |
| 13:47 |
MTDiscord |
<skyliner_369> I'm guessing times are for how long each tool takes to break each level, but how is uses calculated? |
| 13:49 |
MTDiscord |
<Warr1024> Each tool has wear from 0 to 65535. If wear exceeds 65535, it breaks. "uses" I believe is how many steps that 65535 is broken up into, so e.g. if uses is 100 it adds 655 wear on each use. |
| 13:49 |
MTDiscord |
<Warr1024> I believe you can have wear vary per-group, so e.g. you can have a tool that wears twice as fast if you use it on stone as on dirt |
| 13:50 |
MTDiscord |
<skyliner_369> that I understand. it's why cracky, crumbly, and snappy are separate |
| 13:50 |
MTDiscord |
<Warr1024> Ha, I figured this stuff out just barely enough to make an abstraction around it like 2 years ago, and haven't dug into it since. lua_api.txt described in broad strokes how MTG does it, and I noped that really quick for NodeCore. |
| 13:51 |
MTDiscord |
<skyliner_369> so durability is 2^16/uses? |
| 13:51 |
MTDiscord |
<Warr1024> In nodecore, you just register a tool with tool_capabilities = nodecore.toolcaps({ cracky = 2, crumbly = 3 }) and most of the stuff like durability and speed calcs are automatic. |
| 13:51 |
MTDiscord |
<Warr1024> durability has a precision of up to 2^16, but you can decide how many of those is used up with each use. |
| 13:52 |
MTDiscord |
<Warr1024> Each time you dig, the tool will add (2^16 / uses) wear. |
| 13:53 |
MTDiscord |
<Warr1024> Non-digging actions may require you to manually adjust wear, so you may have to do that calculation yourself sometimes, and you'll want it to be reasonably consistent. |
| 13:55 |
MTDiscord |
<skyliner_369> hmmmm... maybe? |
| 13:57 |
MTDiscord |
<skyliner_369> no that'd make it so that uses is durability... |
| 13:59 |
|
Daisae joined #minetest |
| 14:00 |
Daisae |
Some mods depend on 'datastorage', but I don't find such a mod. Where is it? |
| 14:01 |
MTDiscord |
<Warr1024> https://content.minetest.net/packages/?q=datastorage - seems to be inside the TechAge modpack. I don't know if there's a standalone version. |
| 14:07 |
specing |
Hmm, why does modstorage not have a savetable? |
| 14:07 |
specing |
set_table() |
| 14:07 |
specing |
and by modstorage I mean MetaDataRef |
| 14:07 |
specing |
possible userdata? |
| 14:08 |
MTDiscord |
<Warr1024> you mean :to_table() and :from_table()? |
| 14:12 |
|
Taoki joined #minetest |
| 14:14 |
|
big_caballito[m] joined #minetest |
| 14:16 |
Daisae |
I see that datastorage is provided by some other mods, just is not available stand-alone. |
| 14:17 |
Daisae |
Hope I can find it stand-alone. |
| 14:18 |
|
thecrag joined #minetest |
| 14:24 |
perrier |
Does anybody play minetest extended? It has some nice features but the thirst function hasn't moved 1 increment maybe it's just slow? |
| 14:33 |
rubenwardy |
So - regarding detached inventories. There should be a warning if the scope isn't specified for the inventory, and then the warning upgraded to an error in a release or so |
| 14:34 |
perrier |
Oh that's mana sorry. |
| 14:36 |
rubenwardy |
it's perfectly possible to improve the API without breaking things |
| 14:37 |
|
NetherEran joined #minetest |
| 14:38 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Fix show_on_minimap default value for local player c7aa92a https://git.io/JTR5x (2020-10-20T14:36:05Z) |
| 14:46 |
specing |
Hmm, when you issues a CSM command with not arguments, the first argument gets set to an empty string |
| 14:46 |
specing |
Hmm, when you issue* a CSM command with no* arguments, the first argument gets set to an empty string |
| 14:46 |
specing |
perrier: I don't recall seeing thirst on any server |
| 14:49 |
perrier |
specing: I use it in my game. But the blue hud bar in MTE was mana not thirst. |
| 14:50 |
skyliner_369 |
I've been staring at tools.lua for a while now, trying to figure out how 10 = 30 and 20 = 60 but then 20 also = 180 and then 20=540 and then 30 = 810... |
| 14:50 |
specing |
rubenwardy: hmm, get_wield_index returns 0-indexed number... |
| 14:50 |
big_caballito[m] |
Hey, how well do CSM's work right now? What's the status of Server-Sent CSMs? |
| 14:52 |
specing |
big_caballito[m]: very well if you add some missing API |
| 14:52 |
specing |
big_caballito[m]: haven't heard of any server sent CSM being used |
| 14:53 |
big_caballito[m] |
yeah, the second question was mainly for @core_devs |
| 14:54 |
big_caballito[m] |
What missing API? |
| 14:54 |
perrier |
I love thirsty it wouldn't be survival without it. |
| 14:54 |
big_caballito[m] |
One second, lemme go look at some docs... |
| 14:55 |
|
vormgear joined #minetest |
| 14:56 |
specing |
big_caballito[m]: I'm mainly interested in client-side CSMs, and you need to API to be able to interact with the world |
| 14:56 |
specing |
to add some API* |
| 14:57 |
big_caballito[m] |
Cool, cool |
| 14:57 |
big_caballito[m] |
that means modding the code, right? |
| 14:57 |
big_caballito[m] |
the C++ code* |
| 15:04 |
specing |
Yes |
| 15:07 |
specing |
I have currently a 300 line patch that enables me to auto-eat, do inventory management, crafting, digging and placing of nodes |
| 15:07 |
specing |
from CSMs |
| 15:08 |
big_caballito[m] |
interesting... |
| 15:08 |
big_caballito[m] |
Actually that's really cool |
| 15:12 |
|
Verticen joined #minetest |
| 15:14 |
|
vormgear joined #minetest |
| 15:15 |
specing |
rubenwardy: the server misses some trivial checks: 1) placing nodes mid-air (under should be not a fluid) 2) set_wield_index should be < hotbar size |
| 15:15 |
sfan5 |
wield index was fixed |
| 15:16 |
|
FreeFull joined #minetest |
| 15:18 |
specing |
sfan5: server or client side? |
| 15:18 |
sfan5 |
how would a server validation bug be fixed client-side? |
| 15:18 |
sfan5 |
we're not that stupid |
| 15:20 |
specing |
is that so? *looks at CSM and fly/noclip/fast restrictions* |
| 15:22 |
MTDiscord |
<Lone_Wolf> I dare you to fix the latter serverside without any noticeable performance decrease ? |
| 15:24 |
MTDiscord |
<oneplustwo> can't you do checks in a time interval of like 1 sec? sure, you may miss the 0.4 seconds the dude was flying, but eventually you will get him. |
| 15:26 |
specing |
Lone_Wolf I understand that it's not easy to fix, but the point still stands |
| 15:26 |
MTDiscord |
<Lone_Wolf> What happens when a player is falling? What if they're walking on top of a mapblock? |
| 15:26 |
MTDiscord |
<oneplustwo> are you talking to me? |
| 15:26 |
sfan5 |
maybe you want minetest to essentially be a vnc client so that cheating is impossible but this does not match the vision of the development team |
| 15:27 |
MTDiscord |
<Lone_Wolf> Yes btw 3 |
| 15:27 |
MTDiscord |
<oneplustwo> oh |
| 15:27 |
MTDiscord |
<oneplustwo> what i was saying is, every 1 second, you pick two frames or something to judge if the player is acting sus |
| 15:28 |
MTDiscord |
<oneplustwo> like if frame 1 player is on y=10, and frame 2 player is on y=13, it could be flagged (ofc after counting in other factors like ladders, jumping) |
| 15:29 |
sfan5 |
@oneplustwo what you want to do is fully recreate player physics server-side, everything else is too inexact and either too permissive or too restrictive (false-positives) |
| 15:31 |
MTDiscord |
<oneplustwo> no not really |
| 15:31 |
MTDiscord |
<oneplustwo> its like a velocity check every one second |
| 15:31 |
MTDiscord |
<oneplustwo> it checks if the velocity is realistic or not |
| 15:31 |
MTDiscord |
<Warr1024> If you want a lot of server-side anti-cheat checks, people are developing mods for this. |
| 15:32 |
MTDiscord |
<oneplustwo> i mean, once every second shouldn't be too bad for performance, but you can always lower it. Players who cheat tend to do it again. |
| 15:32 |
specing |
s/people are developing mods/people are reimplementing minetest in lua/ |
| 15:33 |
specing |
FTFY |
| 15:33 |
MTDiscord |
<Lone_Wolf> There are already velocity checks in place for everything by -y velocity |
| 15:33 |
MTDiscord |
<Lone_Wolf> *everything but |
| 15:33 |
specing |
also, is fly/fast even cheating? Minetest is a sandbox game, not a competitive one |
| 15:36 |
Daisae |
By the rules I play with, fly is cheating and I reduced the speed of fast. |
| 15:36 |
tango_ |
wow what a boring world |
| 15:37 |
tango_ |
I have some ruins far from my home, having to spend half of an in-game day to get there is extremely boring |
| 15:37 |
MTDiscord |
<oneplustwo> fast is a problem if you can use it in short bursts |
| 15:37 |
Daisae |
It makes it more interesting because then there is incentive to build high speed rail. |
| 15:37 |
tango_ |
I've just now been looking on how to support fast walk on my home server to fix that |
| 15:37 |
Daisae |
or travel by boat |
| 15:37 |
MTDiscord |
<oneplustwo> for example in ctf, you can use fast for a fraction of a second to get away from a tough situation |
| 15:37 |
Daisae |
I increased the speed of carts much. |
| 15:38 |
MTDiscord |
<oneplustwo> oh, has entity speed been patched yet? |
| 15:38 |
tango_ |
boat is slow |
| 15:38 |
tango_ |
and the ruins are inland |
| 15:38 |
MTDiscord |
<oneplustwo> i thought Fleckenstein came up with a patch already |
| 15:38 |
tango_ |
rails requires you to have found some mese, which means digging deep underground |
| 15:38 |
tango_ |
which means you spend half the day walking up/down your mine shaft |
| 15:38 |
specing |
or using gravel sieves |
| 15:39 |
tango_ |
specing: what? |
| 15:39 |
specing |
techpack gravelsieves, it's not in MTG |
| 15:39 |
tango_ |
I'm currently running “pure” MTG |
| 15:39 |
specing |
cobblegen -> quarry -> grinder -> gravelsieve |
| 15:39 |
specing |
pure boredom :P |
| 15:40 |
Daisae |
Going down, I made a change so that wool breaks falls. I can fall 1000 nodes onto wool and take no damaeg. |
| 15:40 |
MTDiscord |
<oneplustwo> did the subject just change? |
| 15:40 |
tango_ |
Daisae: so you changed all of your game rules BUT consider fast / fly mode “cheating” |
| 15:40 |
Daisae |
Going up to return home, I have home teleportation enabled. |
| 15:40 |
tango_ |
and you see nothing wrong with that? 8-D |
| 15:41 |
Daisae |
I considered disabling home teleport, but have it for now. Sometimes I played without it. |
| 15:41 |
specing |
Daisae: xdecor iirc has cushions for that |
| 15:42 |
tango_ |
doesn't straw protect from the fall in MTG? |
| 15:42 |
Daisae |
I used cushions initially, but they don't look as good . |
| 15:42 |
Daisae |
I think it may somewhat, but not 100% |
| 15:42 |
tango_ |
wiki says 30% |
| 15:43 |
Daisae |
I have fast slightly slower than boat travel. |
| 15:43 |
tango_ |
boat travel by default is very slow |
| 15:44 |
Daisae |
There are also horses in the game. With diamond horseshoes, they go fast enough to make a difference. |
| 15:44 |
tango_ |
now horses would be a nice addition |
| 15:44 |
tango_ |
but yeah I should probably start looking into building some rails |
| 15:45 |
Daisae |
Default cart speed, I found too slow. |
| 15:46 |
Daisae |
I decreased the cost of rails also. |
| 15:49 |
Daisae |
So, I can travel by falling into a shaft, run fast up ladders, use a hang glider, ride a horse, fly a hot air baloon. I have rope boxes and scaffolding for more climbing. |
| 15:49 |
|
tango_ joined #minetest |
| 15:49 |
Daisae |
increased speed, decreased expense for carts. |
| 15:50 |
Daisae |
many ways to travel, but no teleportation except sometimes home. |
| 15:50 |
Daisae |
You can also play with Mirrors of Returning + Solar Mana. |
| 15:50 |
Daisae |
Travel and getting better travel becomes part of the game play. |
| 15:51 |
Daisae |
Default rail cost, I find too expensive. |
| 15:53 |
|
Foz joined #minetest |
| 16:04 |
|
Taoki joined #minetest |
| 16:25 |
|
Talkless joined #minetest |
| 16:46 |
|
swift110-phone joined #minetest |
| 16:46 |
big_caballito[m] |
where is minetest.conf on macos (neoascetic's build) |
| 17:01 |
big_caballito[m] |
I found minetest.conf.example in /Applications/minetest.app/Content/Resources/minetest |
| 17:02 |
tango_ |
I'm thinking that a partial solution to the fly / fast movement thing to have some special boots to craft |
| 17:02 |
sfan5 |
did you check ~/.minetest? |
| 17:02 |
tango_ |
like the mapping kit for the minimap or the binoculars for zoom |
| 17:14 |
tango_ |
also wow android controls are finnicky |
| 17:15 |
tango_ |
(not that I could do better |
| 17:21 |
big_caballito[m] |
@sfan5 there is no .minetest |
| 17:21 |
big_caballito[m] |
* @sfan5 there is no ~/.minetest |
| 17:22 |
sfan5 |
then |
| 17:22 |
sfan5 |
check ~/Library/Preferences |
| 17:25 |
big_caballito[m] |
there is no minetest folder in ~/library/preferences or /library/preferences |
| 17:25 |
big_caballito[m] |
(i used ls -a) |
| 17:28 |
|
homthack joined #minetest |
| 17:30 |
big_caballito[m] |
found it -_- |
| 17:31 |
big_caballito[m] |
~/Library/Application Support/minetest/minetest.conf |
| 17:31 |
big_caballito[m] |
I somehow overlooked it the five (thousand) times I looked there |
| 17:32 |
Krock |
find -type d -name "*minetest*" |
| 17:42 |
big_caballito[m] |
cd /; find minetest.conf |
| 18:12 |
|
Noclip joined #minetest |
| 18:12 |
Noclip |
tango_: "which means you spend half the day walking up/down your mine shaft" |
| 18:12 |
Noclip |
You can build an elevator out of boats and water. That way you can travel several thousand nodes up and down in just a few seconds. |
| 18:17 |
|
swift110 joined #minetest |
| 18:20 |
Noclip |
tango_: "now horses would be a nice addition" |
| 18:20 |
Noclip |
You could install a mod like 'https://content.minetest.net/packages/TenPlus1/mob_horse' for that. Don't expect horses (or any other mobs) to be added to MTG in the future. If you don't want to use mods then you have to play without horses. |
| 18:22 |
perrier |
I prefer tpads for transport. |
| 18:23 |
swift110 |
cool |
| 18:27 |
|
fluxflux joined #minetest |
| 18:28 |
perrier |
Learned how to make obsidian. |
| 18:29 |
Noclip |
tango_: "I'm thinking that a partial solution to the fly / fast movement thing to have some special boots to craft" |
| 18:29 |
Noclip |
How about this mod for flying?: 'https://content.minetest.net/packages/joe7575/towercrane/' Furthermore I think the ethereal and 3d_armor mods give you special crystal boots with a jump boost and speed effect. |
| 18:32 |
|
Taoki joined #minetest |
| 18:33 |
MTDiscord |
<Jonathon> you could use gliders |
| 18:37 |
perrier |
Fast boots would be awsome and maybe a jet pack. |
| 18:48 |
Noclip |
specing: "also, is fly/fast even cheating? Minetest is a sandbox game, not a competitive one" |
| 18:48 |
Noclip |
That's not really true: Minetest is just an engine for various types of voxel games. Minetest Game is a sandbox game. Agon (https://content.minetest.net/packages/1248/agon/) for example is definitely not a sandbox game. |
| 18:52 |
Noclip |
Also there are many servers with fully or partially competitive games like capture the flag, skywars or just Minetest Game with pvp enabled. |
| 18:53 |
specing |
true |
| 18:54 |
tango_ |
Noclip: hm how does the boat/water elevator shaft work? any details in the wiki or other doc? |
| 18:55 |
tango_ |
Noclip: the crane is an interesting solution, and a realistic one to boot, but I like the boot/jetpack idea more |
| 18:55 |
tango_ |
Noclip: I'm curious about the principle about not having even friendly animals in MTG |
| 18:55 |
tango_ |
I for one hate the fact that wool is made from cotton |
| 18:56 |
|
erlehmann_ joined #minetest |
| 18:56 |
Noclip |
@oneplustwo: "like if frame 1 player is on y=10, and frame 2 player is on y=13, it could be flagged (ofc after counting in other factors like ladders, jumping)" |
| 18:56 |
Noclip |
So you want to make the server brute force through all possible player movements every second? That would most likely kill any server at every time! |
| 18:57 |
MTDiscord |
<oneplustwo> bruh |
| 18:57 |
MTDiscord |
<oneplustwo> wdym "all possible player movements"? |
| 19:00 |
Noclip |
tango_: One of the main goals of MTG is beeing a simple modding base. |
| 19:03 |
|
AndDT joined #minetest |
| 19:04 |
Noclip |
@oneplustwo: How do you want to count factors like ladders, nodes, jumping and more in without calculating all possible player movements? |
| 19:07 |
MTDiscord |
<oneplustwo> i thought there were checks to see if you are in a ladder? |
| 19:08 |
MTDiscord |
<oneplustwo> if your y positions doesn't change while you are in the air, its obviously not jumping |
| 19:10 |
Noclip |
I think compared to that server side movement would be resource-saving: The client sends the pressed keys to the server and the server calculates the movement. But in reality even that could come with big performace issues caused by network delays. |
| 19:16 |
Noclip |
@oneplustwo: Your idea is not completely wrong but it's also far from beeing a perfect solution. The server could only do very rough and inaccurate calculations which brings us back to sfan5's point: "everything else [than server-side physics] is too inexact and either too permissive or too restrictive" |
| 19:18 |
MTDiscord |
<oneplustwo> it does not have to be exact |
| 19:18 |
MTDiscord |
<oneplustwo> cheaters tend to cheat again |
| 19:18 |
MTDiscord |
<oneplustwo> eventually they will be caught |
| 19:31 |
|
Testus joined #minetest |
| 19:32 |
Daisae |
specing: I'm playing with HDX textures. and I can dye the wool many pretty textures. I'm happier adding a line to make wool act as cushions. |
| 19:32 |
specing |
Why would the server do very rough calculations? FPS games have done server side physics for decades now |
| 19:33 |
specing |
I don't understand why it would be a problem for MT to do the same |
| 19:33 |
Daisae |
Or I could change straw from 30% cushioning to 100%. |
| 19:34 |
|
proller joined #minetest |
| 19:34 |
Noclip |
sfan5: How about this idea: We use both client-side and server-side movement / physics. The client keeps calculating and executing movements on it's own but also sends all keystrokes and cursor movements to the server. If the server has enough unused hardware resources at a given moment it then tries to calculate and recreate the players movement and compares it to the original client-side movement. If the differences |
| 19:34 |
Noclip |
between client-side and server-side movement of a specific player are too often too big then the server will assume that player to be a cheater. |
| 19:36 |
sfan5 |
has been proposed before and it'd work |
| 19:37 |
Noclip |
specing: Server-side physics and running regular checks is not the same. |
| 19:38 |
Noclip |
sfan5: So then the problem is already solved in theory? |
| 19:38 |
sfan5 |
sorta |
| 19:40 |
Noclip |
Nice! Is there a forum or github discussion that you could link to? |
| 19:41 |
MTDiscord |
<IhrFussel> Shooters run at 30-60 or more ticks per sec...not even remotely comparable to Minetest's 11 steps per sec (by default) |
| 19:42 |
sfan5 |
Noclip: https://github.com/minetest/minetest/pull/6219 |
| 19:42 |
Noclip |
Thanks! |
| 19:47 |
|
swift110 joined #minetest |
| 19:47 |
|
swift110 joined #minetest |
| 20:28 |
|
submariner joined #minetest |
| 20:47 |
perrier |
Witch houses are looking a lot better I noticed there was an update to handle_schematics recently. |
| 20:49 |
|
bdju joined #minetest |
| 20:49 |
swift110 |
oh |
| 20:52 |
|
pipo joined #minetest |
| 21:14 |
MinetestBot |
[git] paramat -> minetest/minetest: Devtest: Automatically enable zoom capability (#10493) 4d9c918 https://git.io/JT0wy (2020-10-20T21:13:27Z) |
| 21:33 |
MinetestBot |
[git] paramat -> minetest/minetest_game: Do not apply waving shader to bush leaves (#2753) 720d4c8 https://git.io/JT0oc (2020-10-20T21:30:57Z) |
| 21:38 |
|
pipo left #minetest |
| 22:07 |
|
Verticen joined #minetest |
| 22:14 |
FeXoR |
...pipo. Thanks ;) But it was less about being able to breath and more about water not to build away ;) |
| 22:21 |
|
proller joined #minetest |
| 22:59 |
|
swift110 joined #minetest |
