| Time |
Nick |
Message |
| 00:02 |
|
kaeza joined #minetest-dev |
| 00:07 |
|
domtron joined #minetest-dev |
| 00:13 |
|
Void7 joined #minetest-dev |
| 00:19 |
|
kaadmy joined #minetest-dev |
| 00:56 |
|
stdh joined #minetest-dev |
| 00:59 |
|
est31 joined #minetest-dev |
| 00:59 |
est31 |
yeah in fact i do like it |
| 01:00 |
est31 |
saw your video on youtube sofar where you had demo'd the fences, and it was a bit bad that the selection boxes were only so small |
| 01:00 |
est31 |
and OldCoder the bug is fixed afaik |
| 01:01 |
est31 |
I'd sent you a PM i think with the issue link |
| 01:04 |
est31 |
OldCoder, #3831 |
| 01:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/3831 -- Esc stops working when in F10 mode and form invoked, and F10 pressed again |
| 01:04 |
est31 |
if you still can reproduce it, file a bug, or say something here :) |
| 01:18 |
ShadowNinja |
est31: Sure, I'll change atend. And move to to util while I'm at it. |
| 01:19 |
est31 |
to? |
| 01:19 |
est31 |
the strfind class you mean? |
| 01:19 |
est31 |
well okay, i hope its not that much used :} |
| 01:21 |
|
domtron joined #minetest-dev |
| 01:22 |
ShadowNinja |
it to* |
| 01:23 |
ShadowNinja |
StrSplitter would really be e better name for it. |
| 01:23 |
ShadowNinja |
Or Tokenizer. |
| 01:25 |
est31 |
nah |
| 01:25 |
est31 |
the current name is fine imo |
| 01:26 |
est31 |
tokenizer is better than StrSplitter though |
| 01:26 |
est31 |
just dont clean up other code in unrelated classes only because you touch it :) |
| 01:27 |
est31 |
except its whitespace fixes only |
| 01:28 |
ShadowNinja |
Pushed. |
| 01:29 |
est31 |
commit is fine |
| 02:16 |
|
Terusthebird joined #minetest-dev |
| 02:38 |
|
Terusthebird joined #minetest-dev |
| 02:47 |
|
proller joined #minetest-dev |
| 03:18 |
|
linkedinyou joined #minetest-dev |
| 03:24 |
|
domtron joined #minetest-dev |
| 03:53 |
|
Dragonop joined #minetest-dev |
| 04:37 |
ShadowNinja |
sofar: Feature for connected: connected_post: like fixed, but not used if connected on opposide sides but not to top. This way posts are only shown at corners. Useful for walls and concrete posts. |
| 04:40 |
sofar |
I was thinking of another one: connect_none: boxes drawn in place of "fixed" boxes when connected to no edges. |
| 04:47 |
ShadowNinja |
sofar: That sounds good too. |
| 04:49 |
|
DevBox joined #minetest-dev |
| 05:54 |
|
Hunterz joined #minetest-dev |
| 07:03 |
|
Weedy joined #minetest-dev |
| 08:14 |
sofar |
#3888, then bedtime |
| 08:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/3888 -- Particles: Remove particles on collision (WIP) by sofar |
| 09:07 |
|
nrzkt joined #minetest-dev |
| 09:39 |
|
Player_2 joined #minetest-dev |
| 09:48 |
|
Obani joined #minetest-dev |
| 09:53 |
|
Dragonop_ joined #minetest-dev |
| 10:39 |
|
Calinou joined #minetest-dev |
| 10:48 |
|
numZero joined #minetest-dev |
| 11:28 |
|
Megaf joined #minetest-dev |
| 11:31 |
|
Fixer joined #minetest-dev |
| 11:32 |
|
Krock joined #minetest-dev |
| 11:57 |
|
turtleman joined #minetest-dev |
| 12:24 |
nore |
I'll try to change NodeTimerList to use a priority queue before feature freeze |
| 12:25 |
nore |
it should improve performance, and make NodeTimers always more efficient than ABMs |
| 12:26 |
nore |
probably a ~10-100 performance improvement in NodeTimerList::step I guess |
| 12:26 |
nore |
well, it would be in O(number of elapsed timers * log(number of active timers)) instead of O(number of active timers) |
| 12:35 |
|
DevBox joined #minetest-dev |
| 13:39 |
nrzkt |
nore: the problem with too many nodetimers is the memory overhead if node timer are used everywhere |
| 13:40 |
|
DFeniks joined #minetest-dev |
| 14:01 |
|
PilzAdam joined #minetest-dev |
| 14:19 |
|
kaadmy joined #minetest-dev |
| 14:28 |
|
Megaf joined #minetest-dev |
| 14:29 |
Megaf |
folks, so, I'm running minetest here, connected to my server and observing CPU and GPU use |
| 14:29 |
Megaf |
it seems like it's being bottlenecked by the CPU |
| 14:30 |
Megaf |
since it's using only 25% of the GPU and always 70% of one core and around 30% of another core |
| 14:34 |
|
luizrpgluiz joined #minetest-dev |
| 14:36 |
Megaf |
the GPU utilization doesnt change much when enabling and disabling shaders |
| 14:37 |
Megaf |
is as if shader were running on the CPU |
| 14:39 |
|
Megaf_ joined #minetest-dev |
| 14:49 |
|
rubenwardy joined #minetest-dev |
| 15:48 |
|
hmmmm joined #minetest-dev |
| 15:51 |
|
Taoki joined #minetest-dev |
| 15:53 |
|
Dragonop_ joined #minetest-dev |
| 15:59 |
|
DFeniks joined #minetest-dev |
| 16:05 |
|
ud1 joined #minetest-dev |
| 16:08 |
|
Megaf joined #minetest-dev |
| 16:24 |
nore |
nrzkt: Even a million nodetimers is but a few megabytes of memory, so it should not be a problem |
| 16:48 |
|
Samson1 joined #minetest-dev |
| 17:06 |
|
Void7 joined #minetest-dev |
| 17:11 |
|
kaadmy joined #minetest-dev |
| 18:14 |
|
Obani joined #minetest-dev |
| 18:20 |
|
Sokomine_ joined #minetest-dev |
| 18:20 |
|
est31 joined #minetest-dev |
| 18:21 |
est31 |
nore, i think you should use a map that maps from the time to a vector of nodetimer pointers instead |
| 18:22 |
est31 |
if you make an environment wide queue: there we insert and remove often, and for insertion a map is better |
| 18:23 |
est31 |
if you keep the nodetimer management block wise, then you can do a queue if you want |
| 18:43 |
|
Void7 joined #minetest-dev |
| 18:46 |
ssieb |
^[colorize overwrites the alpha values of the destination. Is that intentional? Would a fix for that be accepted? |
| 18:46 |
sfan5 |
if you don't break something in the process a fix would be appreciated |
| 18:47 |
sfan5 |
as long as nobody relies on ^[colorize being broken in this way |
| 18:49 |
ssieb |
I was wondering about that. I'll check through the mods I have to see if it would change anything. |
| 18:50 |
|
linkedinyou joined #minetest-dev |
| 18:54 |
nore |
est31: ah, didn't know maps were faster; so I'm thinking about a map + caching the min time (per block probably, because we need to be able to add and remove positions dynamically) |
| 18:55 |
|
ud1 joined #minetest-dev |
| 18:55 |
nore |
but again, there needs to me a way to remove bindings per position and not per time |
| 18:55 |
* nore |
should read std::map documentation |
| 19:41 |
|
Amaz joined #minetest-dev |
| 19:47 |
|
Player_2 joined #minetest-dev |
| 20:23 |
|
kaeza joined #minetest-dev |
| 20:29 |
sofar |
is there a way in the engine to determine if a node has nodemeta or not? |
| 20:36 |
|
est31 joined #minetest-dev |
| 20:36 |
|
Darcidride joined #minetest-dev |
| 20:41 |
nore |
sofar: not from lua |
| 20:42 |
* nore |
misread sofar's question :/ |
| 20:43 |
sofar |
right, I have a MapNode object in c++ and want to see if there's metadata attached to it |
| 20:43 |
sofar |
my thought is this |
| 20:44 |
sofar |
if we add digging prediction disabling, I want to enable it by default for nodes that have metadata |
| 20:44 |
sofar |
since, logically, those will have code to handle such an event |
| 20:44 |
sofar |
(and are likely to deny digging) |
| 20:44 |
sofar |
so then, dig prediction would be enabled by default for all nodes without metadata |
| 20:44 |
sofar |
and disabled for nodes with metadata |
| 20:45 |
sofar |
and then nodedef can override the setting |
| 20:45 |
sofar |
doing it that way seems like a really good way to prevent lots of types of unauthorized digging |
| 20:46 |
nore |
hm... |
| 20:48 |
nore |
sofar: also, I just tested replacing the set_node to air by remove_node in your beds patch |
| 20:48 |
nore |
and it looks like it works :p |
| 20:48 |
nore |
s/p/o/ |
| 20:48 |
sofar |
huh |
| 20:48 |
sofar |
maybe it's just an ordering thing then |
| 20:48 |
sofar |
lol |
| 20:49 |
nore |
yes, that is sure though |
| 20:49 |
nore |
because when the node is removed, destroy_bed will remove the other part |
| 20:49 |
sofar |
I must have just futzed the order |
| 20:49 |
sofar |
e.g. place bottom first rotated, then remove top |
| 20:49 |
nore |
so if you change the other part *before* destroying this one, it won't work |
| 20:49 |
sofar |
(old top) |
| 20:49 |
sofar |
yeah |
| 20:49 |
sofar |
seems like a typical thing I would mess up ;) |
| 20:52 |
nore |
sofar: also, about your meta question: you only have a MapNode? |
| 20:52 |
nore |
or do you have its position too? |
| 20:52 |
nore |
because you need its position IIRC |
| 20:52 |
sofar |
nodepos, yes, I haz |
| 20:52 |
|
STHGOM joined #minetest-dev |
| 20:53 |
nore |
then you need the mapblock that contains this pos |
| 20:54 |
sofar |
this is a clientmap, not the servermap |
| 20:55 |
nore |
and use m_node_metadata.get |
| 20:55 |
nore |
clientmap also has mapblocks, hasn't it? |
| 20:55 |
nore |
#ifndef SERVER // Only on client MapBlockMesh *mesh; |
| 20:55 |
nore |
#endif |
| 20:55 |
sofar |
idk, first time messing around in it this week |
| 20:55 |
nore |
NodeMetadataList m_node_metadata; |
| 20:56 |
nore |
^ yep, this file is for the client too |
| 20:56 |
nore |
so, you find the mapblock containing the position |
| 20:56 |
nore |
(I don't remember how, maybe you already have it anyway) |
| 20:56 |
nore |
and in that block, you call m_node_metadata.get(pos) |
| 20:57 |
nore |
and check if the pointer you get is null or not |
| 20:57 |
nore |
(I don't remember if the position is local within the block or global though) |
| 20:58 |
|
red-001 joined #minetest-dev |
| 21:10 |
nore |
~tell est31 what I think I will do is to keep a std::multimap<double, NodeTimer> giving for each NodeTimer when it should be triggered, and a std::map<v3s16, std::multimap<double, NodeTimer>::iterator> to map each position to the iterator in the multimap to be able to remove the NodeTimers that match these positions; and finally the same thing globally in the environment, that gives for each mapblock the next time a timer will be triggered, to avoi |
| 21:10 |
ShadowBot |
nore: O.K. |
| 21:13 |
sofar |
nore: Map::getBlockNoCreate(pos) ? |
| 21:14 |
nore |
sofar: probably, I don't remember if you need to give pos or blockpos either though |
| 21:14 |
nore |
there's getBlockNoCreateNoEx too |
| 21:14 |
sofar |
yes |
| 21:15 |
nore |
maybe it would be better |
| 21:16 |
nore |
so: you need to give pos |
| 21:16 |
nore |
it returns null if the block doesn't exist |
| 21:17 |
nore |
wait, you're in client |
| 21:17 |
nore |
isn't it ClientMap then? |
| 21:18 |
nore |
ah, it inherits from Map |
| 21:18 |
sofar |
ClientMap &map |
| 21:19 |
nore |
wait, you've even got Map::getNodeMetadata |
| 21:20 |
nore |
just give it your position and you're done ;) |
| 21:20 |
sofar |
error: 'class ClientMap' has no member named 'getNodeMetaData' |
| 21:21 |
nore |
with a 'd' |
| 21:21 |
nore |
not 'D' |
| 21:21 |
sofar |
oh goodness, thanks for spotting that |
| 21:22 |
sofar |
yah, works |
| 21:22 |
nore |
yay :) |
| 21:22 |
sofar |
I can do the lua parts now, and serialization |
| 21:22 |
* nore |
gets back to her nodetimers |
| 21:23 |
sofar |
this is awesome, this is going to make trespass hacking a *lot* harder |
| 21:28 |
nore |
sofar: good :) |
| 21:28 |
sofar |
server owners will likely want to force strict client versions, though |
| 21:29 |
sofar |
but if we can get this in 0.4.14 that might be nice. |
| 21:29 |
nore |
yep :) |
| 21:29 |
nore |
it doesn't help with the players digging a hole through the roof of a building though, but I don't know how that can be fixed |
| 21:30 |
|
est31 joined #minetest-dev |
| 21:30 |
nore |
but it's useful for doors |
| 21:31 |
sofar |
server owners can make a whole bunch of nodes not predict diggable |
| 21:31 |
sofar |
so that does help |
| 21:31 |
sofar |
you could make everything that way |
| 21:32 |
sofar |
so there's a huge array of options available |
| 21:32 |
sofar |
even protection mods could work by attaching metadata to the nodes in protected areas |
| 21:32 |
sofar |
of course, the server should really stop allowing players to move through walls |
| 21:32 |
est31 |
nore, i think iterators are invalidated when editing, no? |
| 21:33 |
nore |
est31: I checked that iterators are not invalidated when doing erase if they don't reference the element that was erased |
| 21:33 |
est31 |
we should first fix noclip anti cheat |
| 21:33 |
est31 |
only then we should add noclip prevention |
| 21:33 |
est31 |
ermm |
| 21:34 |
nore |
est31: how would you fix it? |
| 21:34 |
nore |
est31: http://www.cplusplus.com/reference/map/multimap/erase/ |
| 21:34 |
nore |
"Iterators, pointers and references referring to elements removed by the function are invalidated. |
| 21:34 |
nore |
All other iterators, pointers and references keep their validity." |
| 21:35 |
est31 |
hrmm |
| 21:35 |
|
celeron55_ joined #minetest-dev |
| 21:36 |
est31 |
isnt it doing any operations to balance the tree |
| 21:36 |
est31 |
perhaps it stores the parent |
| 21:36 |
sofar |
est31: do you have a sec to check if the particle remove() call is correct in my particle change from yesterday evening? I'm seeing it get called 20x in a row really fast |
| 21:36 |
nore |
well, it may be doing them, but the pointers to the leaves will still be correct I guess |
| 21:36 |
sofar |
it works (visually) but it looks weird with debug code enabled. |
| 21:36 |
est31 |
probably |
| 21:38 |
est31 |
okay then nore |
| 21:38 |
est31 |
nore, what was your question "how would you fix it" about |
| 21:38 |
rubenwardy |
noclip anticheat |
| 21:38 |
est31 |
ah |
| 21:38 |
est31 |
yeah that one... very simple |
| 21:39 |
est31 |
the client periodically sends the player pos to the server |
| 21:39 |
sofar |
YESSSS, it works |
| 21:39 |
est31 |
and the server updates it in its memory and sends the pos to all other clients |
| 21:39 |
est31 |
so far so good, this is the current state |
| 21:39 |
est31 |
now to how to add noclip checking |
| 21:40 |
est31 |
each time the server gets a new position from the client, the server takes the path between the old pos and the new |
| 21:40 |
est31 |
and checks every node the path crosses |
| 21:41 |
est31 |
if there is one solid node on the path, it rejects the move, and moves the player back to the last position |
| 21:41 |
est31 |
other clients won't even notice that the player tried to cheat |
| 21:41 |
est31 |
(or lag through walls or something) |
| 21:41 |
rubenwardy |
what if there is a slight bend due to lag? |
| 21:41 |
Obani |
How often would happend the check ? |
| 21:42 |
est31 |
Obani, every time the client updates its position |
| 21:42 |
rubenwardy |
Is this to stop going through walls? |
| 21:42 |
est31 |
rubenwardy, that's the issue, of course, it will give false positives then |
| 21:42 |
rubenwardy |
it's a good compromise though |
| 21:43 |
est31 |
well yeah its an issue for server owners |
| 21:43 |
nrzkt |
est3 |
| 21:44 |
est31 |
to decide whether its lag or whether they want to ban |
| 21:44 |
nrzkt |
est31, i think checking if player is in node is good |
| 21:44 |
est31 |
imo its not required to ban people just because they _tried_ something |
| 21:44 |
est31 |
but let server owners decide |
| 21:45 |
est31 |
only then we can add checks to the client to prevent digging through walls |
| 21:45 |
est31 |
through protected walls* |
| 21:45 |
est31 |
if somebody wants to implement that check go on |
| 21:46 |
est31 |
but its more involved than a simple register_on_globalstep, you actually have to check the whole path |
| 21:46 |
red-001 |
what is someone goes through a door and ten closes it? |
| 21:46 |
est31 |
otherwise the check isnt proper and you can abuse it in lag times |
| 21:47 |
red-001 |
how often does the client update it's position? |
| 21:47 |
est31 |
red-001, they will be reset in lag times, in no lag times its no issue |
| 21:47 |
est31 |
very often |
| 21:47 |
est31 |
> 10 times per sec |
| 21:47 |
red-001 |
what about fly? |
| 21:48 |
red-001 |
how do you stop that? |
| 21:48 |
est31 |
thats harder to check |
| 21:48 |
nrzkt |
difficult because it's nearly impossible to detect if fly or throw |
| 21:48 |
est31 |
you have to find a way to distinguish falling and flying :) |
| 21:49 |
red-001 |
well you could at least stop flying upwards? |
| 21:49 |
red-001 |
that shouldn't be similar to anything else |
| 21:50 |
red-001 |
you could detected if a client is moving upwards an isn't near a climbable node |
| 21:51 |
rubenwardy |
Just look at upwards velocity, I guess |
| 21:51 |
nrzkt |
fall* :) |
| 21:52 |
nrzkt |
red-001, other problem is teleportation |
| 21:52 |
rubenwardy |
what if the player is attached/being moved by a mod? |
| 21:52 |
red-001 |
psychics override? |
| 21:53 |
red-001 |
the mod would be resetting their position anyway |
| 21:54 |
red-001 |
maybe add a setting for every player to temporally disable anticheat for them |
| 21:54 |
sofar |
#3891 |
| 21:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/3891 -- Allow influencing of client dig prediction. by sofar |
| 21:55 |
red-001 |
nrzkt there is code for stopping teleporting already |
| 21:58 |
nrzkt |
i talked about lgtm teleport |
| 21:59 |
est31 |
rubenwardy, if the player is being attached, its known by the server |
| 22:00 |
red-001 |
lgtm? |
| 22:01 |
red-001 |
what do you mean? |
| 22:06 |
est31 |
it means "looks good to me" |
| 22:06 |
est31 |
but it doesnt make sense in this context |
| 22:08 |
est31 |
sofar, even if it was suggested by PilzAdam, i still -1 the pr |
| 22:09 |
sofar |
even though you -1 it, I'm not going to implement your idea, since I have no idea HOW to do that |
| 22:10 |
sofar |
I don't work that way |
| 22:10 |
sofar |
I have hundreds of things in my head that I'd like to do |
| 22:10 |
PilzAdam |
est31, anti-cheat is not the only (not even the primary) use case of disabling prediction |
| 22:10 |
sofar |
but I only start coding when I think can make something *work* |
| 22:11 |
est31 |
PilzAdam, what is it then |
| 22:11 |
PilzAdam |
node_placement_prediction is already available; it's used for items that have a special handling when being used |
| 22:11 |
|
Megaf joined #minetest-dev |
| 22:11 |
PilzAdam |
there may be nodes in mods that don't turn into air when being dug |
| 22:11 |
Megaf |
Hi all, so, I'm trying to build Minetest Server on Haiku, a reimplementetion of BeOS |
| 22:11 |
Megaf |
but I'm getting this error. http://paste.debian.net/plain/417478 |
| 22:12 |
Megaf |
Haiku is not UNIX, nothing to do with it, but it's POSIX |
| 22:13 |
sofar |
that's why I hooked it to node metadata |
| 22:13 |
PilzAdam |
est31, imagine a game where when you hit rock with a pickaxe it turns into cobble instead of dropping to the user's inventory |
| 22:13 |
sofar |
that's an obvious sign that code needs to specially handle the node removal anyway |
| 22:13 |
PilzAdam |
est31, the current dig prediction would totally ruin this effect even on servers with a bit of lag |
| 22:13 |
est31 |
I can live with the nodefef part |
| 22:13 |
est31 |
but making it based on the metadata? |
| 22:13 |
est31 |
thats stupid |
| 22:14 |
sofar |
ok, now we're talking |
| 22:14 |
est31 |
<sofar> so best hope it makes it into 0.4.14 and then force strict client version checking, I suppose. |
| 22:14 |
PilzAdam |
est31, oh, I didn't see that part in the PR |
| 22:14 |
sofar |
we may just have to bump versions in 0.4.14 |
| 22:14 |
est31 |
^ that doesnt help at all |
| 22:14 |
PilzAdam |
yes, thats not (at least not the way it's implemented) |
| 22:14 |
est31 |
sofar, think of that cheater on just test server |
| 22:15 |
red-001 |
Megaf I not sure anyone here know much about Haiku, maybe you should ask on their irc channel It's possible they didn't implement part of the standard |
| 22:15 |
PilzAdam |
+useful |
| 22:15 |
red-001 |
*C++ standard |
| 22:15 |
Megaf |
but can you think about anything from the error message? |
| 22:15 |
sofar |
well the patch becomes even less code if I do that |
| 22:15 |
Megaf |
Its gcc 5 |
| 22:16 |
PilzAdam |
est31, sofar, a better way (TM) would be to make it similar to node_placement_predicition: the field in nodedef defines the node name that the node is being replaced with when dug |
| 22:16 |
est31 |
Megaf, it seems they didnt implement that particular function. you must talk to somebody who can write C/C++ and they will have to port minetest to haiku |
| 22:16 |
PilzAdam |
default is "" (air), if nil then prediction is disabled |
| 22:16 |
Megaf |
oh, ok, thanks red-001 est31 |
| 22:16 |
red-001 |
It's something to do with a byte order function |
| 22:17 |
est31 |
PilzAdam, thats even better |
| 22:17 |
red-001 |
according to google |
| 22:17 |
PilzAdam |
est31, sofar, and maybe add a special value that reads the nodename from metadata |
| 22:17 |
sofar |
PilzAdam: est31: OK, I'll go and implement that |
| 22:17 |
est31 |
no |
| 22:17 |
est31 |
reading from metadata is stupid |
| 22:17 |
est31 |
sorry |
| 22:17 |
sofar |
just disable it then |
| 22:18 |
est31 |
that wont help against abuse from server owners |
| 22:18 |
PilzAdam |
est31, thing of a cauldron: a single node that gets replaced by different liquids when being dug |
| 22:18 |
sofar |
I need to do some grocery shopping first, though |
| 22:18 |
PilzAdam |
*think |
| 22:18 |
sofar |
let's take it one step at a time |
| 22:19 |
sofar |
let me do the node_placement_predict api for this first |
| 22:19 |
PilzAdam |
est31, node_placment_prediction can be abused for anti-cheat, too, but it isn't |
| 22:19 |
|
nrzkt joined #minetest-dev |
| 22:19 |
PilzAdam |
(with placment prediction one can build up into the air while the number of items in the inventory isn't removed) |
| 22:19 |
est31 |
you suggested the abuse yourself https://github.com/minetest/minetest_game/issues/954#issuecomment-198681699 |
| 22:20 |
est31 |
we need proper noclip fixing before this gets merged |
| 22:20 |
PilzAdam |
thats not metadata based |
| 22:21 |
est31 |
even then its an abuse, not performance wise, but because it punishes people who update minetest |
| 22:21 |
PilzAdam |
my "fix" for game#954 would be to disable prediction for all steel doors in nodedef |
| 22:21 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/954 -- locked doors useless on servers |
| 22:21 |
est31 |
well for me thats not a fix, sorry |
| 22:21 |
est31 |
its just a workaround |
| 22:21 |
PilzAdam |
hence the " |
| 22:21 |
est31 |
we dont control all clients out there, and we dont want to add DRM |
| 22:22 |
PilzAdam |
> but because it punishes people who update minetest |
| 22:22 |
PilzAdam |
that sounds really weird |
| 22:22 |
sofar |
we don't |
| 22:22 |
sofar |
server operators do |
| 22:22 |
est31 |
well if you go to a server |
| 22:22 |
sofar |
subtle, but important difference |
| 22:22 |
PilzAdam |
you are blocking a functional enhancement, because it may be abused for anticheat that is dependent on client version |
| 22:23 |
est31 |
and the server owner has enabled that check |
| 22:23 |
est31 |
e.g. they have installed that mod |
| 22:23 |
est31 |
mtgame |
| 22:23 |
est31 |
and you connect to that server, you build a nice house all protected etc |
| 22:23 |
est31 |
now it is badly administered and the admin doesnt care |
| 22:23 |
est31 |
or visits every year or so |
| 22:24 |
est31 |
now a bad guy enters your house and steals stuff or something |
| 22:24 |
est31 |
they can because they hacked their client, or simply because they use an unofficial app |
| 22:24 |
est31 |
and you want to do revenge, but you are prevented because you updated minetest? |
| 22:24 |
est31 |
that is punishment |
| 22:25 |
PilzAdam |
#3891 is not about anti-cheat; it's a functional enhancement |
| 22:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/3891 -- Allow influencing of client dig prediction. by sofar |
| 22:26 |
PilzAdam |
just because you can imagine a situation where server owners abuse this feature doesn't mean you should block that PR |
| 22:26 |
est31 |
I block it until we have proper noclip prevention |
| 22:26 |
PilzAdam |
there are already tons of features in the engine to discriminate people based on their client version |
| 22:27 |
sofar |
PilzAdam: est31: OK, I'll go and implement that after I do some groceries :) |
| 22:29 |
est31 |
sofar, the check is in PlayerSAO::checkMovementCheat() |
| 22:29 |
est31 |
you only need to extend it |
| 22:29 |
sofar |
you're funny |
| 22:30 |
sofar |
like I said, I usually don't start coding until I'm convinced I know the underlying mechanics, and know that it works |
| 22:30 |
est31 |
well then I do it. |
| 22:31 |
PilzAdam |
est31, btw, I agree that there should be proper noclip checks |
| 22:32 |
sofar |
this is where I clearly don't feel comfortable enough yet with a lot of the C++ code base... I'll get better and more confident, I just have to touch more pieces of code |
| 22:32 |
PilzAdam |
but I think that functional enhancement shouldn't be blocked because of this |
| 22:32 |
sofar |
e.g. https://forum.minetest.net/viewtopic.php?f=7&t=14229 |
| 22:32 |
est31 |
I'm coding this thing now, and leaving chat because i can concentrate better outside of chat |
| 22:33 |
red-001 |
shouldn't damage also be check server side? |
| 22:34 |
red-001 |
currently it's mostly client sided |
| 22:34 |
PilzAdam |
red-001, it is |
| 22:34 |
PilzAdam |
the server handles all damage (except falling and lava) |
| 22:34 |
PilzAdam |
sofar, I left a comment in your PR so you can update it later |
| 22:35 |
Megaf |
I got a word from one of the guys from Haiku |
| 22:35 |
Megaf |
[22:34] <mmu_man> why didn't they use the ntoh* stuff from <netinet/in.h> anyway? |
| 22:35 |
Megaf |
[22:35] <mmu_man> man byteorder -> CONFORMING TO POSIX.1-2001. |
| 22:36 |
red-001 |
maybe it doesn't work on windows? |
| 22:36 |
red-001 |
idk |
| 22:37 |
sofar |
ask for a patch :) |
| 22:38 |
|
Fritigern joined #minetest-dev |
| 22:42 |
Megaf |
I have to go, I will be back tomorrow, thanks folks, cya! |
| 22:51 |
|
celeron55 joined #minetest-dev |
| 22:56 |
|
PilzAdam joined #minetest-dev |
| 22:59 |
|
yang2003 joined #minetest-dev |
| 23:11 |
|
exoplanet joined #minetest-dev |
| 23:15 |
|
red-001 joined #minetest-dev |
| 23:28 |
|
Samson1 joined #minetest-dev |
