| Time |
Nick |
Message |
| 00:02 |
hmmmm |
i don't remember exactly why i would use at() |
| 00:02 |
hmmmm |
but erm, change that to find |
| 00:03 |
hmmmm |
no reason for that odd exception flow |
| 00:11 |
PilzAdam |
like this? https://github.com/PilzAdam/minetest/commit/250770d3c5e324bdfbc7b4e0698c2017c94fee92 |
| 00:52 |
hmmmm |
yeah, like that. except maybe put the declaration and initialization of it on separate lines |
| 00:52 |
hmmmm |
(or is that below 80 columns?) |
| 00:55 |
PilzAdam |
its 82 |
| 00:56 |
PilzAdam |
Ill split it |
| 00:57 |
PilzAdam |
I push it to upstream then |
| 01:04 |
|
PilzAdam joined #minetest-dev |
| 02:36 |
|
IceCraft joined #minetest-dev |
| 03:34 |
|
IceCraft joined #minetest-dev |
| 03:35 |
|
Anchakor1 joined #minetest-dev |
| 03:36 |
|
init joined #minetest-dev |
| 03:47 |
|
IceCraft joined #minetest-dev |
| 04:38 |
|
Akien joined #minetest-dev |
| 04:47 |
|
IceCraft joined #minetest-dev |
| 05:01 |
|
aoper joined #minetest-dev |
| 05:55 |
|
kaeza joined #minetest-dev |
| 06:46 |
|
Strikeboba joined #minetest-dev |
| 06:50 |
|
Strikeboba joined #minetest-dev |
| 07:57 |
|
darkrose joined #minetest-dev |
| 07:57 |
|
darkrose joined #minetest-dev |
| 08:03 |
|
neko259 joined #minetest-dev |
| 08:28 |
|
Calinou joined #minetest-dev |
| 08:31 |
|
iqualfragile joined #minetest-dev |
| 08:35 |
|
jin_xi joined #minetest-dev |
| 08:47 |
iqualfragile |
i think that there is a problem with minetests view range adjusting |
| 08:47 |
iqualfragile |
for one its clearly broken and shows a far too small range |
| 08:48 |
iqualfragile |
(pressing r and by that adding 3 times the view range does not decrease the fps by a bit) |
| 08:48 |
iqualfragile |
the other problem is that minetest might prevent the gpu to increase its frequency |
| 08:48 |
Calinou |
are you serious? |
| 08:48 |
Calinou |
GPUs increase their frequency too often in most programs, actually |
| 08:48 |
Calinou |
feel free to look in your driver's control panel |
| 08:53 |
VanessaE |
the view range autotuner IS way too slow, yes |
| 08:55 |
VanessaE |
there are parts of my server's map that could be displayed with a range of 150+ (on my GPU) and still do 60 fps, while other places need a range of about 50 or so just to maintain ~30 fps |
| 08:55 |
VanessaE |
but the amount of time it takes the autotuner to get from one to the other is so long that it's basically useless. |
| 08:56 |
VanessaE |
and it gets especially slow as it approaches your target fps |
| 09:06 |
iqualfragile |
oh, wow, i never recognized that there actualy was an autotuner |
| 09:07 |
iqualfragile |
but now that you have told me i see it, too |
| 09:07 |
iqualfragile |
yep, waay to slow |
| 09:09 |
iqualfragile |
s/recognized/noticed/ |
| 09:42 |
|
serengeor joined #minetest-dev |
| 10:06 |
|
Calinou_ joined #minetest-dev |
| 10:09 |
|
PilzAdam joined #minetest-dev |
| 10:19 |
|
iqualfragile_ joined #minetest-dev |
| 11:13 |
|
Calinou joined #minetest-dev |
| 11:20 |
celeron55 |
VanessaE: can i get such a world from somewhere? |
| 11:21 |
celeron55 |
(connecting to your server is too slow from here) |
| 11:25 |
celeron55 |
hmm, found one server where this might be possible to test |
| 11:29 |
|
kaeza joined #minetest-dev |
| 11:36 |
celeron55 |
except that now it became night and i don't see anything |
| 11:37 |
|
Jordach joined #minetest-dev |
| 11:52 |
celeron55 |
i'm starting to fear that the input to this algorithm has been changed |
| 11:52 |
celeron55 |
it's hard to tell how |
| 11:53 |
celeron55 |
i need to start picking random versions of minetest and looking up what this eats in each one, fuck this |
| 11:53 |
celeron55 |
does anyone know in which version this works? |
| 11:54 |
celeron55 |
that would be, like, helpful |
| 11:55 |
|
kaeza joined #minetest-dev |
| 11:55 |
celeron55 |
yeah |
| 11:56 |
celeron55 |
i found it i think |
| 11:56 |
celeron55 |
i think the fuckup has been there ever since kahrl moved stuff to camera.cpp 2 years ago |
| 11:57 |
celeron55 |
your minds will be blown if this happens to work... |
| 11:57 |
ShadowNinja |
Any comments? Can someone test it with IPv6? https://github.com/ShadowNinja/minetest/compare/bind_address |
| 11:59 |
celeron55 |
actually no |
| 11:59 |
celeron55 |
i was wrong |
| 12:00 |
celeron55 |
this variable naming is totally screwed up though, i'll need to look more |
| 12:11 |
celeron55 |
bah, this server testing sucks, there's not enough crap built and nobody is to give me fast or anything anyway... |
| 12:12 |
ShadowNinja |
celeron55: Try mine. :-) |
| 12:12 |
celeron55 |
it's too empty |
| 12:12 |
celeron55 |
and homogenous |
| 12:12 |
celeron55 |
(tried already) |
| 12:13 |
init |
you can download VanessaE's world if you have some time |
| 12:14 |
init |
it is 400 or 300 mb though |
| 12:16 |
init |
celeron55: if you want to decrease your FPS super-fast, you can just enable new_style_leaves and look at a big jungle |
| 12:18 |
celeron55 |
well i'd need quite a huge jungle |
| 12:18 |
Jordach |
celeron55, install moretrees; that works too |
| 12:19 |
celeron55 |
testing these kinds of things really sucks; why hasn't someone for example created a compact test world for causing this bug? |
| 12:19 |
celeron55 |
it's ridiculous that nobody wants to help even a tiny bit in a problem that everyone wants to get fixed... or maybe i'm just thinking VanessaE is everyone |
| 12:20 |
celeron55 |
it's ridiculous anyway |
| 12:21 |
init |
i would like to see it fixed but my download&upload are worse than a dialup |
| 12:21 |
Calinou |
I don't use the dynamic view distance thingy |
| 12:21 |
|
neko259 joined #minetest-dev |
| 12:22 |
init |
it doesn't work |
| 12:22 |
init |
pretty well |
| 12:23 |
celeron55 |
well hell |
| 12:23 |
celeron55 |
that's why it needs to be fixed |
| 12:24 |
celeron55 |
things don't fix themselves, if that comes as surprise to someone |
| 12:25 |
celeron55 |
anyway, now with some moretrees crazyness i have a good test setup |
| 12:26 |
init |
my fps counter is: 150 when looking everywhere but, 5 when looking at a 'moretree(s) jungle' :D |
| 12:27 |
PilzAdam |
I noticed that the auto-tuner gets slower when using a HD texture pack |
| 12:39 |
|
neko259 joined #minetest-dev |
| 12:54 |
celeron55 |
okay, i found the bug |
| 12:54 |
celeron55 |
and fixed it |
| 12:55 |
celeron55 |
however, now this is so fast that this needs a way to know how far away stuff was actually drawn so that it can limit the range there |
| 12:55 |
celeron55 |
otherwise it assplodes to 240 even if the map was loaded only to 100 |
| 12:56 |
celeron55 |
and then looking at a jungle is kind of uncomfortable for half a second |
| 13:02 |
|
Taoki[mobile] joined #minetest-dev |
| 13:15 |
celeron55 |
plantlife and moretrees really kill the server |
| 13:16 |
celeron55 |
it's ridiculously unresponsive when it's generating anything |
| 13:16 |
celeron55 |
i thought the days of this were gone already |
| 13:16 |
init |
it was worse before |
| 13:17 |
iqualfragile_ |
are you using luajit? |
| 13:18 |
iqualfragile_ |
at least for mobs-mods it helps |
| 13:18 |
celeron55 |
i guess not |
| 13:18 |
PilzAdam |
they dont use schematics or vmanip yet, I think |
| 13:19 |
init |
it is using the place_lsystem or w/e |
| 13:19 |
PilzAdam |
oh, right |
| 13:20 |
celeron55 |
hmm, actually i have only moretrees and plants_lib i think |
| 13:20 |
PilzAdam |
a schematic would be faster, I guess |
| 13:20 |
init |
PilzAdam: but less "real" |
| 13:21 |
celeron55 |
http://paste.dy.fi/0XL |
| 13:21 |
celeron55 |
try that, everyone |
| 13:21 |
celeron55 |
and enable the view range tuner with it's default values |
| 13:21 |
* PilzAdam |
clicks random finish links to get the raw paste |
| 13:22 |
celeron55 |
gist.github.com didn't work so i used that; that works always (finnish are best!) |
| 13:23 |
PilzAdam |
sometimes you have to click the button twice on gist |
| 13:25 |
PilzAdam |
its not so good: the fog seems to jump directly to the max border way faster than the map loads |
| 13:25 |
PilzAdam |
previously the fog was always at the "loading edge" |
| 13:26 |
celeron55 |
i clicked like 10 times |
| 13:26 |
celeron55 |
well it was way closer to the player than the "loading edge" |
| 13:26 |
celeron55 |
i need to make some silly hack to make it follow the loading border |
| 13:27 |
PilzAdam |
I never had problems with old code, though |
| 13:27 |
PilzAdam |
(only when using HDX) |
| 13:28 |
celeron55 |
oh also, fuck hell this anticheat on laggy servers; i knew it's a nightmare but i didn't remember |
| 13:29 |
celeron55 |
someone should fix it |
| 13:29 |
Calinou |
even on non-laggy servers, it catches players |
| 13:29 |
Calinou |
(0.5s of lag = server thinks I go too fast when walking) |
| 13:30 |
PilzAdam |
oh god, fancy leaves are horrible |
| 13:33 |
|
EdB joined #minetest-dev |
| 13:34 |
PilzAdam |
when the FPS go to about 25 then the fog just directly jumps 10 nodes closer to get at >30 again |
| 13:34 |
PilzAdam |
the old one was way smoother |
| 13:34 |
celeron55 |
well the old one updated twice as slow |
| 13:35 |
celeron55 |
but it was unable to do anything fast so it looked smoother |
| 13:35 |
celeron55 |
anyway, the question really is, how fast should it be |
| 13:36 |
init |
make it a setting, PA likes it smoother, V likes it uber-fast |
| 13:36 |
PilzAdam |
the problem is not the speed, but rather that its way beyond the loading edge when starting amap |
| 13:37 |
celeron55 |
well okay, i'll do that thing then |
| 13:38 |
PilzAdam |
with fancy leaves enabled the old one is indeed too slow, you are too long under 30 FPS |
| 13:39 |
celeron55 |
i'm quite proud of how fast this can determine the right range even when the range/fps curve is very wonky |
| 13:40 |
celeron55 |
it's a nightmare for simpler algorithms to do anything fast when you're looking at a jungle at a distance |
| 13:40 |
kahrl |
when I set wanted_fps = 60 the new one doesn't reduce the viewing range at all when I'm standing in a spot with steady 30FPS |
| 13:40 |
kahrl |
haven't tried the old one yet |
| 13:41 |
celeron55 |
it's an illegal condition to have wanted_fps >= fps_max |
| 13:41 |
kahrl |
nvm, something overwrote my minetest.conf |
| 13:41 |
celeron55 |
but i guess it should work |
| 13:41 |
celeron55 |
it gives too little headroom for the tuner though |
| 13:43 |
PilzAdam |
I wonder why it still caps the FPS at 60 when I set fps_max to 120 |
| 13:43 |
init |
vsync |
| 13:43 |
celeron55 |
on my box wanted_fps=60 always results in a minimum viewing range though |
| 13:44 |
celeron55 |
can't render at that speed 8) |
| 13:44 |
Calinou |
wanted_fps = 30 gives best results |
| 13:44 |
PilzAdam |
wow, with wanted_fps = 60 the new code always keeps the FPS over 55 |
| 13:44 |
Calinou |
too high gives low FPS for some reason |
| 13:44 |
Calinou |
I used to use wanted_fps = 100 and got like 25 FPS |
| 13:44 |
PilzAdam |
even when flying with fast speed into a jungle |
| 13:45 |
init |
PilzAdam: that is the idea somehow |
| 13:45 |
celeron55 |
well yeah, that's kind of what it should do |
| 13:45 |
PilzAdam |
init, the old fog was a billion times slower |
| 13:46 |
PilzAdam |
init, I have vsync disabled |
| 13:49 |
celeron55 |
if you don't do any extreme fancy_leaves stuff, then you never see it even tuning anything, it's so fast 8) |
| 13:49 |
celeron55 |
(on a decent computer) |
| 13:50 |
celeron55 |
(when it's in the 160-240 range just making sure that fps doesn't drop under 30) |
| 13:51 |
celeron55 |
(assuming world is generally loaded that far) |
| 13:56 |
Calinou |
PilzAdam: "Sync to VBlank"? |
| 13:56 |
PilzAdam |
hm? |
| 13:56 |
init |
in nvidia-settings vsync is called "Sync to VBlank" |
| 13:57 |
init |
that is what he meant |
| 13:58 |
Calinou |
yep |
| 13:58 |
PilzAdam |
oh, now I get over 60 FPS |
| 13:59 |
PilzAdam |
now I can play at 200 FPS again :-) |
| 14:00 |
|
jin_xi joined #minetest-dev |
| 14:03 |
celeron55 |
yeah, and completely waste 70% of frames |
| 14:03 |
celeron55 |
(well okay, it can give a bit faster keyboard input) |
| 14:04 |
Calinou |
you usually don't care for a game like minetest :P |
| 14:04 |
Calinou |
and, what if you have a 120 or 144hz :P |
| 14:06 |
celeron55 |
they you should vsync to that |
| 14:10 |
celeron55 |
n* |
| 14:46 |
celeron55 |
http://paste.dy.fi/Po1 |
| 14:47 |
celeron55 |
that limits the fog to where the farthest mapblocks are drawn |
| 15:05 |
celeron55 |
(i'm still figuring out some sane constants in this) |
| 15:28 |
|
hmmmm joined #minetest-dev |
| 15:33 |
PilzAdam |
hmmmm, https://github.com/PilzAdam/minetest/commit/e5567254c2a092dc5a3e555b0725947861a821f4 |
| 15:33 |
hmmmm |
what is this |
| 15:34 |
hmmmm |
why would content ignore ever, ever be placed? |
| 15:35 |
PilzAdam |
ignore is written to the files when the node has a probability of 0 |
| 15:35 |
hmmmm |
oh shit don't tell me i never fixed that |
| 15:35 |
PilzAdam |
and ignore is ignored when actually placing the schematic, so its never actually placed |
| 15:36 |
hmmmm |
yeah |
| 15:36 |
hmmmm |
that's fine then |
| 15:37 |
hmmmm |
i really wish i could change the way probabilities work |
| 15:39 |
PilzAdam |
is that possible without breaking the current format? |
| 15:40 |
hmmmm |
it's not |
| 15:40 |
kahrl |
increment the file version and, when loading an old file, fix up all param1 values |
| 15:40 |
hmmmm |
it hasn't been officially released yet even |
| 15:41 |
hmmmm |
alright, pilzadam, i'll make a new version for schematics, you don't have to commit that |
| 15:43 |
hmmmm |
i need my coffee first though |
| 15:46 |
celeron55 |
i'm going to push a slightly tuned version of what i pasted; i guess that's ok |
| 15:48 |
PilzAdam |
yep |
| 15:51 |
celeron55 |
then i'd have a... thing that makes it less likely for the sky to look odd when turning to look it after looking at a ground that has caves |
| 15:51 |
celeron55 |
http://paste.dy.fi/Pj3 |
| 15:52 |
celeron55 |
these tend to look kind of messy because... well, that's just their nature as they try to hide the deficiencies of the actual things 8) |
| 15:53 |
celeron55 |
i wanted to do that because that happens in moretrees jungles too |
| 15:54 |
celeron55 |
i'll just push it, nobody should have any reason to complain i guess |
| 15:54 |
PilzAdam |
that patch doesnt apply correctly... |
| 15:55 |
celeron55 |
umm |
| 15:55 |
celeron55 |
well i have no idea why that would be |
| 15:56 |
PilzAdam |
the pastebin has converted tabs to spaces |
| 15:56 |
celeron55 |
oh, i think i know... yes, that 8) |
| 15:57 |
celeron55 |
http://paste.dy.fi/Pyz/plain |
| 15:57 |
celeron55 |
it was actually my terminal who did it |
| 15:59 |
PilzAdam |
cant really see a major difference, throw it in |
| 16:01 |
kahrl |
definitely looks nicer |
| 16:01 |
celeron55 |
the sky color glitch is still visible with it if you look for it, but accidentally noticing it is harder |
| 16:02 |
kahrl |
I was wondering what could be done about it since every time I watched somebody on youtube play minetest for the first time, they noticed it |
| 16:03 |
celeron55 |
of course making it even less visible is possible by just changing a value, but then i'd risk making it glitch visibly in some other kind of situation |
| 16:05 |
|
Calinou joined #minetest-dev |
| 16:06 |
celeron55 |
next in this bug-fixing sprint: i will set up a minetest server with moretrees where you will join, and i will tune the anticheat until it doesn't screw you up |
| 16:06 |
celeron55 |
other laggy mod suggestions are welcome |
| 16:06 |
PilzAdam |
Simple Mobs |
| 16:06 |
Calinou |
why not mobf, PilzAdam :P |
| 16:07 |
celeron55 |
i don't think those should cause such lag that would affect this |
| 16:07 |
celeron55 |
or... hope |
| 16:07 |
celeron55 |
oh well, i bet it'll hate you even without any mods |
| 16:08 |
kahrl |
just put a sleep(5) in a register_globalstep :P |
| 16:12 |
|
NakedFury joined #minetest-dev |
| 16:14 |
celeron55 |
running now at c55.me |
| 16:15 |
celeron55 |
hmm, i should remove fast to make it more apparent |
| 16:15 |
celeron55 |
oh i don't have privileges to set privileges |
| 16:15 |
celeron55 |
well lol |
| 16:17 |
PilzAdam |
umm, do you use finite liquids? |
| 16:18 |
celeron55 |
dunno, they might be on for testing |
| 16:18 |
celeron55 |
apparently they are |
| 16:19 |
kahrl |
well this is unrelated to everything but the first thing I saw was the water glitch |
| 16:19 |
Calinou |
it looks like mod downloader doesn't work for me |
| 16:19 |
Calinou |
when I click "download", I just get 2 empty windows |
| 16:19 |
kahrl |
where the water looks opaque when looking horizontally and transparent when looking down |
| 16:21 |
celeron55 |
it's up |
| 16:31 |
|
salamanderrake joined #minetest-dev |
| 16:33 |
kaeza |
Calinou, same here |
| 16:37 |
|
AllegedlyDead joined #minetest-dev |
| 16:39 |
celeron55 |
i need to make some kind of a "cheat time pool" for each player |
| 16:40 |
celeron55 |
which collects time to a certain maximum, and when the player does something, that pool is checked and if there's enough time in it, the action is allowed and the time required for it is removed from the pool |
| 16:40 |
celeron55 |
the maximum needs to be larger than the maximum server lag spike |
| 16:40 |
|
BlockMen joined #minetest-dev |
| 16:41 |
celeron55 |
with moretrees on this thing the server seems to halt for about 15 seconds when generating, i think |
| 16:42 |
init |
configurable time? |
| 16:42 |
celeron55 |
or, well... that pool is required for digging anticheat |
| 16:42 |
celeron55 |
movement can be just made to be checked at a veeery long interval |
| 16:42 |
celeron55 |
like half a minute should generally work |
| 16:42 |
celeron55 |
(it's currently 1s, which just doesn't work) |
| 16:43 |
PilzAdam |
why dont check movement each time a player sends his position? |
| 16:43 |
celeron55 |
and then what? |
| 16:43 |
celeron55 |
that's the time pool way of doing it |
| 16:43 |
celeron55 |
but it doesn't matter when you check it, it's all the same |
| 16:44 |
celeron55 |
(the interval just matters) |
| 16:45 |
celeron55 |
PilzAdam: the way a server sees it when it lags is that there is a dtime of 15 seconds when the player doesn't move much, then there is some normal movement and then there is a dtime of 0.1 when the player moves the amount it moves in 15s |
| 16:45 |
celeron55 |
8) |
| 16:45 |
celeron55 |
digging goes similarly |
| 16:45 |
PilzAdam |
why not add a timestamp to the position the client sends? |
| 16:46 |
celeron55 |
timestamp... set by whom? |
| 16:46 |
init |
that wouldn't fix it |
| 16:46 |
init |
the client, i guess he meant |
| 16:46 |
init |
a client that can fake it |
| 16:46 |
PilzAdam |
celeron55, time since last position update |
| 16:47 |
celeron55 |
so a client sends always 0.1 is and the server is happy? |
| 16:47 |
celeron55 |
-is |
| 16:47 |
PilzAdam |
the server checks then a) if the amount of time already passed and b) if the client can move that far in this amount of time |
| 16:48 |
celeron55 |
or do you mean we'd modify the network stack to attach a time to each received packet |
| 16:48 |
PilzAdam |
yea |
| 16:48 |
celeron55 |
doing that in the network stack work for mod lag because the network stack runs in an another thread |
| 16:48 |
celeron55 |
however, it does not help for network lag |
| 16:49 |
celeron55 |
how large problem is network lag though |
| 16:49 |
celeron55 |
what kind of RTT did you get? |
| 16:50 |
init |
my normal latency to any server in europe is between 250 to 450 |
| 16:50 |
init |
(argentina) |
| 16:51 |
BlockMen |
i found a way to fix the formspec issue on win builds |
| 16:51 |
PilzAdam |
imagine the scenario that the client lags for 1 second, and the server gets all the 10 position update packages at once |
| 16:51 |
BlockMen |
can someone test if it breaks sth on linux? |
| 16:51 |
BlockMen |
https://github.com/BlockMen/minetest/commit/d2cee9111c845a2af0725492e78b15f97bb517a6 |
| 16:51 |
PilzAdam |
if there is no time difference added to the package then the server would think that client has moved all the way at once |
| 16:52 |
PilzAdam |
but if the client adds the delta time to each package, then the server could reconstruct what actually happened on the client side |
| 16:52 |
init |
PilzAdam: the client can fake the number |
| 16:52 |
PilzAdam |
and to prevent false delta times the server subtracts it from 1 second lag |
| 16:53 |
celeron55 |
the server wouldn't do that but it would periodically check that the client's delta times add up to roughly what the server thinks they should |
| 16:53 |
celeron55 |
however, that requires a protocol change and doesn't give any actual benefit over the "lag pool" that i originally intended to do |
| 16:53 |
PilzAdam |
each client could have a time pool on the server where the deltas are subtracted |
| 16:53 |
celeron55 |
i'll probably do the lag pool |
| 16:53 |
celeron55 |
you don't need that protocol thing for it at all |
| 16:54 |
kahrl |
why not simply check the "evil" bit in the IP header? |
| 17:24 |
celeron55 |
okay, it's up now |
| 17:24 |
celeron55 |
try if you can cause cheat prevention with regular playing and try if you can cause it with a hacked client |
| 17:33 |
PilzAdam |
celeron55, you actually dont need a hacked client |
| 17:33 |
|
aoper joined #minetest-dev |
| 17:33 |
PilzAdam |
the sneak elevator is enough to trigger it |
| 17:35 |
celeron55 |
oh, that's right |
| 17:36 |
Calinou |
except if you do it slowly :p |
| 17:36 |
celeron55 |
well you do need a 30 second long sneak elevator to trigger it in this though |
| 17:37 |
celeron55 |
or, well, walk continuously, then take the elevator and walk more :P |
| 17:37 |
celeron55 |
oh |
| 17:37 |
celeron55 |
actually if you just take it, jump down and do that in a loop, that'll cause it too |
| 17:38 |
Calinou |
isn't downward speed ignored? |
| 17:39 |
PilzAdam |
I cant seem to trigger it |
| 17:40 |
celeron55 |
Calinou: yes but upward is not |
| 17:42 |
PilzAdam |
I cant trigger it with a not hacked client |
| 17:45 |
celeron55 |
i did some changes, i'll restart the server |
| 17:47 |
PilzAdam |
I just got reverted on the sneak elevator |
| 17:47 |
PilzAdam |
it works |
| 17:48 |
celeron55 |
i made it a bit more strict for movement |
| 17:48 |
|
BlockMen joined #minetest-dev |
| 17:48 |
celeron55 |
it still shouldn't fuck up regular players because it's Good(tm) |
| 17:48 |
PilzAdam |
it seems to revert too much |
| 17:48 |
celeron55 |
does it, i'll still have to test myself |
| 17:48 |
PilzAdam |
even when I stop fast or completly stop moving I get reverted |
| 17:49 |
celeron55 |
hacking gets pooled up in the lag pool |
| 17:49 |
celeron55 |
and if lag happens in a certain way, the effect can come much later |
| 17:50 |
PilzAdam |
so short "sprints" are not reverted? |
| 17:51 |
celeron55 |
no; how could they? the server can't be sure if what it's seeing is happening now or 15 seconds before |
| 17:52 |
celeron55 |
also you can dig a bunch of nodes fast in a row, but if you continue it more than what you could in the time the lag pool contains, they'll get reverted |
| 17:52 |
celeron55 |
the server reverts everything it can be sure didn't happen legitimately and allows everything else |
| 17:53 |
PilzAdam |
normal walking works without problems |
| 17:56 |
celeron55 |
also the lag pool starts at 0 |
| 17:56 |
celeron55 |
so if you start going fast or spamming nodes immediately, you get limited immediately |
| 17:58 |
PilzAdam |
can you turn off creative mode so I can test too fast digging? |
| 17:58 |
celeron55 |
oh yes, i was just going to |
| 17:58 |
kahrl |
BlockMen: that looks like a memory leak |
| 17:59 |
kahrl |
btw instead of narrow_to_wide("string literal") you can do L"string literal" |
| 18:01 |
PilzAdam |
celeron55, wow, that works amazingly good |
| 18:02 |
PilzAdam |
oh wait |
| 18:02 |
kahrl |
oh, wlabel = (wchar_t*) narrow_to_wide("").c_str(); was in the original code too, what the heck |
| 18:02 |
init |
i guess someone was trying to code in brainfuck kahrl |
| 18:02 |
kahrl |
this allocates a temporary std::wstring and gets the c_str() from it, then destructs the std::wstring and continues to use the c_str() |
| 18:02 |
celeron55 |
kahrl: that code will work only by shere luck |
| 18:02 |
celeron55 |
(and often does) |
| 18:03 |
celeron55 |
sheer* |
| 18:04 |
BlockMen |
kahrl, memory leak at my code? |
| 18:04 |
PilzAdam |
hmm, if I try to dig stone with a hand it always gets reverted; but when insta-digging dirt the first ~40 nodes are actually removed, and then they still move faster in my inv than normal digging |
| 18:04 |
kahrl |
BlockMen: yeah, wgettext's return value is allocated by new wchar_t[] |
| 18:04 |
kahrl |
but your code never deletes it |
| 18:05 |
BlockMen |
so with my idea i need wchar_t AND wstring, but delete wchar_t again, right? |
| 18:05 |
kahrl |
I wonder why wgettext doesn't return std::wstring |
| 18:06 |
kahrl |
that's just asking for memory leaks |
| 18:06 |
kahrl |
BlockMen: yep, should work |
| 18:07 |
kahrl |
you could make a wrapper around wgettext that does exactly that (returns a std::wstring, deletes the temporary wchar_t*) |
| 18:08 |
BlockMen |
with wrapper you mean a function? |
| 18:09 |
kahrl |
yep |
| 18:09 |
BlockMen |
ok, thx |
| 18:09 |
BlockMen |
will do then |
| 18:12 |
celeron55 |
i have to do one thing still though... and fix an another thing that i broke 8) |
| 18:15 |
PilzAdam |
you can insta-break 14 tree nodes in a row before the server thins you are cheating |
| 18:16 |
PilzAdam |
if you cut down regular trees then it will probably be a lot more (since they only have a 4 to 5 nodes trunk) |
| 18:16 |
celeron55 |
that's why i need to make a lag detector that scales the lag pool |
| 18:16 |
celeron55 |
also, insta-break isn't much of hakcing |
| 18:16 |
celeron55 |
hacking* |
| 18:17 |
celeron55 |
that doesn't really matter; what matters is when people come and immediately delete the spawn of a server with mass command 8) |
| 18:17 |
celeron55 |
or insta-break steel towers |
| 18:18 |
PilzAdam |
yea, breaking stone with a hand is always reverted |
| 18:18 |
celeron55 |
or teleport around |
| 18:18 |
PilzAdam |
also something should be written to log, like a "hack counter" for each player |
| 18:18 |
celeron55 |
i think it should also be reported to the player in chat |
| 18:18 |
celeron55 |
so that they know why things go oddly |
| 18:18 |
PilzAdam |
e.g. if a player tries to break 10 stone nodes with a hand then admins will probably want to ban him |
| 18:18 |
celeron55 |
cheaters know they're cheating anyway so they don't get any extra information of it |
| 18:19 |
sfan5 |
how 'bout VL(Violation Level) many plugins for MC use this term? |
| 18:19 |
Calinou |
NoCheatPlus uses a VL system |
| 18:19 |
PilzAdam |
maybe just report it to a mod? |
| 18:19 |
PilzAdam |
so |
| 18:19 |
PilzAdam |
so it can be handled by mods to auto-ban or something |
| 18:19 |
celeron55 |
i'll try to get this in a simple and working form; you can attempt to design something fancy |
| 18:19 |
celeron55 |
but yes, a mod callback would be good |
| 18:20 |
Calinou |
it'd be nice if you were forced to look at the node to mine it |
| 18:20 |
Calinou |
NCP does that |
| 18:20 |
sfan5 |
not only a callback also a way to check the value of a player |
| 18:20 |
PilzAdam |
sfan5, what value? |
| 18:20 |
celeron55 |
Calinou: that isn't really doable because of how laggy a minetest server is, and also that is incredibly easy to cheat with a hacked client without anything noticing |
| 18:20 |
Calinou |
yes, that is the main problem about it |
| 18:20 |
celeron55 |
sfan5: a value will not be stored by the minetest engine |
| 18:20 |
sfan5 |
PilzAdam: "hack counter" |
| 18:20 |
celeron55 |
it's a mod thing |
| 18:21 |
PilzAdam |
sfan5, the mod should implement that |
| 18:23 |
BlockMen |
is this function ok? -> http://pastie.org/private/gg4ld6xjsxypetlah0gtg |
| 18:24 |
sfan5 |
BlockMen: no |
| 18:24 |
BlockMen |
:( why? |
| 18:25 |
sfan5 |
if the casting to std::wstring is not done by something that uses strcpy 'out' will be invalid after the delete[] |
| 18:25 |
sfan5 |
but I don't know its behaviour |
| 18:25 |
sfan5 |
so you'd have to test it |
| 18:33 |
celeron55 |
what |
| 18:33 |
celeron55 |
that's completely valid |
| 18:34 |
celeron55 |
std::wstring contains a buffer in itself and happily strcopies a C-style string into it in the contructor or operator= |
| 18:40 |
sfan5 |
<sfan5> but I don't know its behaviour |
| 18:41 |
sfan5 |
celeron55: do you know what params the callback will have? |
| 18:44 |
VanessaE |
celeron55: that autotuner commit seems to work pretty good, save for one glitch: sometimes the view range will jump down by some large step and then back up while running. |
| 18:44 |
VanessaE |
(I'd have checked earlier but I was AFK, sleeping) |
| 18:47 |
VanessaE |
that might annoy some people, but it's a vast improvement over the previous code. |
| 18:47 |
celeron55 |
sfan5: no, that's to be designed |
| 18:47 |
celeron55 |
sfan5: feel free to propose something |
| 18:47 |
VanessaE |
init: I don't have a download of the server anymore - it's like 1.4GB now. |
| 18:48 |
sfan5 |
player[object], numberofblocksdugtoofast[uint], (others that may be useful) |
| 18:48 |
sfan5 |
something like that |
| 18:49 |
BlockMen |
celeron55, ok. thanks for the hint |
| 18:50 |
init |
VanessaE: oh |
| 18:50 |
BlockMen |
kahrl, what have you ment with ' L"string literal" '? why shouldnt i use this util function? |
| 18:50 |
PilzAdam |
minetest.register_on_hack(func(player, hack)) -- hack = {type="<moved_to_fast/dug_unbreakable_node/dug>} |
| 18:50 |
PilzAdam |
*minetest.register_on_hack(func(player, hack)) -- hack = {type="<moved_to_fast/dug_unbreakable_node/dug_too_fast>, amount=<int>} |
| 18:51 |
VanessaE |
celeron55: also, it likes to settle on a fps that's considerably higher than what I've requested in minetest.conf (typically around 10fps more). Not that I'm complaining about that :P |
| 19:40 |
BlockMen |
kahrl, nvm |
| 19:41 |
hmmmm |
anyway |
| 19:41 |
hmmmm |
this is going to change how place_schematic works a little bit |
| 19:42 |
hmmmm |
the old schematic files would still work fine, it's just that everybody who is using the api would have to change their usage of it (if they use 0 probability anywhere, that is) |
| 19:42 |
PilzAdam |
hmmmm, I guess thats ok |
| 19:43 |
hmmmm |
it is because it's upstream, unstable |
| 19:43 |
hmmmm |
if this sort of change were to happen after some releases, i'd add a separate place_schematic_ex() or maybe have another optional requested_version parameter |
| 19:44 |
hmmmm |
so basically what i'm doing is, now a probability of 0 means never placed, a probability of 255 means always placed, and everything in between is the random |
| 19:45 |
hmmmm |
if the schematic version is 1, it needs to fix some things, basically goes through all the nodes changing probability value 0, which previously meant always place, to 0xFF, which now means always placed, and if there was an ignore entry in the node id map, it'll replace that with air and set the probability for all nodes of that type to 0 |
| 19:45 |
hmmmm |
hacky but what do you honestly expect |
| 19:46 |
hmmmm |
i suppose i can make a forum topic about the changes so people can do something about it |
| 19:56 |
BlockMen |
ok, changed everything now -> https://github.com/BlockMen/minetest/commit/f6cb5215911659ff9531e175d28c31e4ce0a9774 |
| 19:56 |
BlockMen |
want someone look again or should i open pull? |
| 19:57 |
PilzAdam |
wstrgettext() should go into gettext.h |
| 19:57 |
sfan5 |
BlockMen: please s/needed for displayed in win-builds/Needed for displaying text on Windows/ |
| 19:58 |
PilzAdam |
s/windows/MSVC/ |
| 19:58 |
PilzAdam |
since it works fine with mingw |
| 19:59 |
BlockMen |
PilzAdam, sfan5 ok |
| 20:00 |
BlockMen |
and do you know it works with mingw or do you guess? |
| 20:00 |
PilzAdam |
I know the my builds work |
| 20:00 |
PilzAdam |
*that |
| 20:01 |
BlockMen |
but you are compiling under linux, so it may be an windows issue |
| 20:02 |
PilzAdam |
no that doesnt matter, you can compile under windows with mingw too |
| 20:02 |
sfan5 |
BlockMen: its not important where you compile on, its only important for what you compile |
| 20:02 |
PilzAdam |
its just MSVC being stupid again |
| 20:02 |
PilzAdam |
as always |
| 20:04 |
BlockMen |
fine. i will change to msvc :P |
| 20:14 |
BlockMen |
when i move it to gettext.h i get many errors like this -> http://pastie.org/private/3iici7qhruqjlsupshwexa |
| 20:17 |
celeron55 |
PilzAdam: i have made final tunings and fixes to the anticheat |
| 20:17 |
celeron55 |
now it measures maximum server lag and bases it's lag pools on that; /status tells the max_lag value measured like that |
| 20:20 |
PilzAdam |
should I test it on your server again? |
| 20:20 |
celeron55 |
you could give it a short try 8) |
| 20:21 |
BlockMen |
nvm |
| 20:21 |
BlockMen |
found out |
| 20:24 |
PilzAdam |
celeron55, that works a lot better, I only can insta-dig 10 instead of 40 dirt now |
| 20:27 |
sfan5 |
its is heavily rtt dependant |
| 20:27 |
sfan5 |
with rtt = 0.500 I can dig 35 dirt before resetting |
| 20:27 |
BlockMen |
ok, i made a pull request now -> https://github.com/minetest/minetest/pull/858 |
| 20:28 |
sfan5 |
BTW: I've already written a NoCheat mod that works with PilzAdam's proposal of the callback |
| 20:29 |
PilzAdam |
celeron55, is the max_lag per client or global? |
| 20:31 |
celeron55 |
global |
| 20:31 |
celeron55 |
it measures "mod lag" |
| 20:31 |
celeron55 |
sfan5: it's not RTT dependent at all |
| 20:32 |
PilzAdam |
is it in seconds? |
| 20:32 |
sfan5 |
with dirt it is for me |
| 20:32 |
celeron55 |
sfan5: it's dependent on how long you sit still without cheating between tries |
| 20:32 |
celeron55 |
PilzAdam: yes |
| 20:33 |
celeron55 |
maybe it's been tested enough now |
| 20:34 |
PilzAdam |
its better than before |
| 20:35 |
celeron55 |
of course on a server with less mod lag it will be more strict, as it knows mod lag can't be the reason for things happening at odd times |
| 20:35 |
VanessaE |
still using moretrees as a source of mod lag? :P |
| 20:35 |
celeron55 |
anyway, the goal of this was that anticheat doesn't ever need to be switched off |
| 20:35 |
celeron55 |
VanessaE: yes |
| 20:36 |
celeron55 |
VanessaE: it's good at doing that |
| 20:36 |
VanessaE |
heh yeah |
| 20:36 |
VanessaE |
it's the engine's lighting code I guess |
| 20:36 |
VanessaE |
hmmmm could better explain it |
| 20:36 |
sfan5 |
VanessaE: moretrees gives me 10 fps |
| 20:37 |
VanessaE |
sfan5: yep, I know. can't be helped without further improvements in the rendering code I gues |
| 20:37 |
VanessaE |
+s |
| 20:38 |
celeron55 |
without fancy leaves moretrees works perfectly fine on this i3 box |
| 20:39 |
sfan5 |
I meant with fancy leaves |
| 20:39 |
sfan5 |
almost no graphics card can handle fancy leaves without fps drop |
| 20:39 |
celeron55 |
well that's probably never going to be fast |
| 20:39 |
celeron55 |
better just live with that |
| 20:40 |
VanessaE |
that VBO patch + exio's "hardcode the value of 'e' " tweak, fancy leaves on moretrees have little effect on my fps |
| 20:40 |
VanessaE |
+with |
| 20:41 |
VanessaE |
the biggest drop I see is when the engine used to do that "out of indicies"/"too many for 16-bit type" thing. When that was fixed, it got a little better (at least stuff renders now), but I suspect something isn't working right with that code. |
| 20:41 |
celeron55 |
not likely |
| 20:42 |
VanessaE |
just a guess |
| 20:42 |
hmmmm |
i haven't profiled the L-system tree spawning myself, but i'm fairly sure that the slowness mostly comes from Map::updateLighting() which is based on the original slow algorithm and it also takes all corner cases into account, like updating the light in the edge of blocks for instance |
| 20:42 |
VanessaE |
I used to see massive framerate drops when that error would happen |
| 20:42 |
hmmmm |
i could create a dummy Mapgen base class and run Mapgen::calcLighting on it and see what happens |
| 20:42 |
VanessaE |
hmmmm: thanks for (repeating) the explanation. (I can never seem to remember it in full) |
| 20:43 |
hmmmm |
I really wonder if l-system trees in the core is necessary these days with VoxelManip and all |
| 20:43 |
VanessaE |
hmmmm: it definitely is necessary, because it allows for randomness with each placed tree |
| 20:43 |
|
jin_xi joined #minetest-dev |
| 20:43 |
celeron55 |
they don't hurt |
| 20:44 |
celeron55 |
of course if they were made now, one could seriously consider using lua only but whatever |
| 20:44 |
hmmmm |
yeah, but jin_xi's real lsystems require quite a bit of custom lua code |
| 20:44 |
hmmmm |
lsystem trees are quite limited in that they only do tree stuff |
| 20:44 |
VanessaE |
hmmmm: I mean in the standard L-systems code. there are randomness features. |
| 20:44 |
PilzAdam |
I think the lsystem in the engine is too ungeneric |
| 20:44 |
hmmmm |
jin_xi's system is the ideal l-system implementation pretty much |
| 20:44 |
hmmmm |
pilzadam, yes.. |
| 20:44 |
|
salamanderrake left #minetest-dev |
| 20:45 |
VanessaE |
PilzAdam: only the name is perhaps too specific, you can use it to generate most anything that can use three or fewer nodes |
| 20:45 |
VanessaE |
node types |
| 20:45 |
hmmmm |
I am really hoping that he upgrades it to use LuaVoxelManip and whatever |
| 20:45 |
hmmmm |
hrmm |
| 20:45 |
VanessaE |
hmmmm: someone said the tree code first emerges and allocates a 1x3x1 chunk area to write to, maybe making it use vmanip wouldn't be that hard? |
| 20:45 |
hmmmm |
a lot of people seem to use place_schematic as a "fast way" to do things but it's not designed to be fast |
| 20:46 |
hmmmm |
if i wanted to make place_schematic faster, the very first thing i'd do is add a separate load_schematic function |
| 20:46 |
hmmmm |
and then i'd add the option to use fast lighting or accurate lighting |
| 20:46 |
hmmmm |
see, using the fast lighting means that light sources will get cut off at the end of the emerged chunk |
| 20:47 |
hmmmm |
VanessaE, what do you mean? |
| 20:47 |
hmmmm |
the lsystem tree code uses vmanip already |
| 20:47 |
PilzAdam |
hmmmm, the reason why people see it as "the fast way" is that it is faster than what was done previously |
| 20:47 |
VanessaE |
oh. ok :D |
| 20:47 |
VanessaE |
in that case ignore that last comment |
| 20:48 |
jin_xi |
i did some experiments yesterday: generating roads with pathfinding and bresenham, to get a line |
| 20:48 |
hmmmm |
alright, so here's what i'll do |
| 20:48 |
jin_xi |
then spawn short axioms or schems along it |
| 20:48 |
hmmmm |
well |
| 20:48 |
jin_xi |
schematics is waay faster |
| 20:48 |
hmmmm |
i'll add a load_schematic function that returns some sort of schematic ID which is then referenced in place of the schematic table in subsequent place_schematic calls |
| 20:49 |
hmmmm |
and the optional fast lighting param |
| 20:50 |
PilzAdam |
why do you want to increase the speed now? doesnt it make things more complicated? |
| 20:50 |
hmmmm |
of course, only the conscientious people will use this... but that's fine, because those who don't care are already doing stupid slow things |
| 20:50 |
hmmmm |
like taoki, i said to him "show me the code where you use voxelmanip when you're done with it so i can catch if you're doing anything stupid" |
| 20:50 |
hmmmm |
which he didn't |
| 20:51 |
hmmmm |
and i looked at it a week later and he did exactly what i figured he'd do |
| 20:51 |
hmmmm |
thing is, being fast is really important because in a mod you're holding up the entire server to do whatever it is |
| 20:51 |
sokomine |
there are still some slight errors with place_schematic on not yet generated land. somehow, dirt generates on top of the houses, and sand is falling down. also there are some lighting errors. most of the time it works very fine :-) |
| 20:52 |
|
mrtux joined #minetest-dev |
| 20:52 |
sokomine |
many thanks to hmmm for implementing place_schematic and to pilzadam for implementing a replacement function! |
| 20:52 |
sokomine |
now i can avoid a very hacky read-file-change-value-write-file-feed-it-to-place_schematic used yesterday |
| 20:53 |
celeron55 |
okay so i pushed the anticheat stuff |
| 20:54 |
celeron55 |
the callback should yet be made |
| 20:54 |
sfan5 |
celeron55: could you install the spoiler tag forum plugin |
| 20:54 |
sokomine |
fine! that will help as well. it was annoying to constantly getting reset for doing nothing but moving fast |
| 20:54 |
celeron55 |
sfan5: for the millionth time: i don't maintain the forum |
| 20:54 |
sfan5 |
but you are also an admin |
| 20:55 |
celeron55 |
i don't want to touch it; thexyz does that job well |
| 20:55 |
sfan5 |
and you haven't told me once that you don't maintain it |
| 20:55 |
celeron55 |
oh well whatever; that's the answer anyway |
| 20:56 |
sokomine |
btw, any hints on how to do on_create for the placed nodes in the schematic in the best way? calling it for each node seems a bit too much. only a few nodes need special treatment (furnaces, chests - those need special handling anyway, water sources) |
| 20:58 |
sokomine |
that is...running on_create for each node in the area placed or using find_nodes_in_area on the area - or using something else- what would you recommend? |
| 20:59 |
PilzAdam |
its called on_construct |
| 21:00 |
sokomine |
oh, sorry, yes, that's what i mean |
| 21:00 |
PilzAdam |
its nil by default, so you just can loop through the area and check if its defined |
| 21:06 |
|
nore_ joined #minetest-dev |
| 21:09 |
nore_ |
do you think 655 should be merged before 0.4.8? |
| 21:10 |
nore_ |
it is configuration for max far objects |
| 21:12 |
nore_ |
and 852, for TP selection? |
| 21:13 |
VanessaE |
I'd like to know more about #655 actually |
| 21:13 |
VanessaE |
since no one has answered the "why 49?" part |
| 21:14 |
nore_ |
i think it is quite old, back to times where entities where buggy |
| 21:14 |
VanessaE |
entities are still buggy :P |
| 21:14 |
PilzAdam |
celeron55, FYI, 1.3 to 0.8 seconds max_lag with builtin stuff only |
| 21:14 |
VanessaE |
that duplication bug is getting pretty severe as more people use entities |
| 21:14 |
nore_ |
i reckon only celeron55 knows the answer |
| 21:14 |
PilzAdam |
my game does not do anything dynamic |
| 21:17 |
nore_ |
vanessae, less than before |
| 21:17 |
VanessaE |
nore_: somewhat - but I still see weird things, like signs entities duplicating themselves over time, even though they're totally static |
| 21:18 |
nore_ |
and what about TP selection? Several core devs are OK for it, I reckon |
| 21:19 |
PilzAdam |
nore_, there is still stuff to do / to decide for TP selection |
| 21:19 |
PilzAdam |
see my last comment on it |
| 21:21 |
celeron55 |
(i'm doing an initial version of the callback thing now) |
| 21:21 |
nore_ |
the "all" folder thing? it is for compatibility and for textures that willbe overridden regardless of TP |
| 21:22 |
VanessaE |
imho, texture folders belong in textures/ not textures/all |
| 21:22 |
VanessaE |
then textures/all could be linked to "the default textures" |
| 21:22 |
VanessaE |
or not |
| 21:22 |
nore_ |
textures folders are in textures/ |
| 21:22 |
VanessaE |
that would break custom fonts |
| 21:23 |
celeron55 |
what are you even talking about |
| 21:23 |
VanessaE |
so textures/all will override whatever's in say textures/my_kickass_textures ? |
| 21:23 |
nore_ |
textured/all is for default |
| 21:23 |
PilzAdam |
celeron55, https://github.com/minetest/minetest/pull/852 |
| 21:23 |
nore_ |
celeron5852 |
| 21:23 |
celeron55 |
textures/ is supposed to have texture packs under subfolders; all is just the name of the texture pack that has no name because there weren't named texture packs before |
| 21:23 |
PilzAdam |
basically a GUI to change texture_path to folders in textures/, each folder represents a texture pack |
| 21:24 |
nore_ |
default is textures/all, so no chnage |
| 21:24 |
nore_ |
to what was before |
| 21:25 |
PilzAdam |
there is no "default" texture pack, such a thing does not exist |
| 21:25 |
VanessaE |
nore_: what happens if I have a file or two in textures/all but I have textures/my_kickass_pack selected in the main menu. Will those couple of files still be used, like usual? |
| 21:25 |
PilzAdam |
what people mean by "default" should simply be called "non" |
| 21:25 |
PilzAdam |
*none |
| 21:25 |
nore_ |
it is texture path =tex /alltures |
| 21:26 |
celeron55 |
it should be thought so that currently only one texture pack is supported and is always selected, and it is the texture pack called "all" |
| 21:26 |
nore_ |
first, those in the TP folder, then textures/all |
| 21:26 |
VanessaE |
nore_: ok, good. |
| 21:27 |
celeron55 |
...what, are you making it so that textures/all is always checked not depending on the chosen texture pack? |
| 21:27 |
nore_ |
celeron55, exactly, except that in the menu, it is called default, because this isbetter for users |
| 21:27 |
PilzAdam |
celeron55, so "all" would be become deprecated if we actually have support for texture packs in textures/ |
| 21:27 |
celeron55 |
PilzAdam: yes |
| 21:27 |
PilzAdam |
and there is no point in keeping it |
| 21:27 |
VanessaE |
textures/all needs to always be checked no matter what |
| 21:27 |
PilzAdam |
VanessaE, use base/pack instead |
| 21:28 |
PilzAdam |
for your font and stuff |
| 21:28 |
VanessaE |
base/pack? that's kinda hacky isn't it? |
| 21:28 |
celeron55 |
nore_: there's probably space in the gui to call it "all (old location)" or something more informative |
| 21:28 |
nore_ |
celeron55, i did not change the engine, it only changes texture_path |
| 21:29 |
nore_ |
so textures/all was checked after texture_path, same now |
| 21:29 |
celeron55 |
uhm |
| 21:30 |
celeron55 |
well i think i'll have to be okay with that then |
| 21:30 |
nore_ |
and what about #655 |
| 21:31 |
sfan5 |
nore_: needs a rebase |
| 21:31 |
nore_ |
the 49 objects limit had what origin? |
| 21:31 |
nore_ |
sfan5, again? |
| 21:31 |
sfan5 |
yes |
| 21:32 |
nore_ |
i will do itt tomorrow, i am on a tablet right now, and that is why i make tons of typos |
| 21:36 |
nore_ |
bbl |
| 21:37 |
VanessaE |
if anticheat works well now, #797 can be closed I guess |
| 21:39 |
sfan5 |
damnit PilzAdam |
| 21:39 |
sfan5 |
you're too fast |
| 21:39 |
PilzAdam |
<- ninja |
| 21:39 |
VanessaE |
haha |
| 21:40 |
|
proller joined #minetest-dev |
| 21:48 |
celeron55 |
http://paste.dy.fi/omH |
| 21:48 |
celeron55 |
i guess that's quite KISS |
| 21:49 |
celeron55 |
it can be extended sometime if needed; as of now there's just a type |
| 21:49 |
PilzAdam |
seems good |
| 21:50 |
sfan5 |
would be good if that'd get commited right now |
| 21:50 |
celeron55 |
well i'll do that |
| 21:50 |
celeron55 |
this is probably kind of breaking the semi feature freeze, but it wasn't really declared anyway so whatever |
| 21:52 |
celeron55 |
it's there |
| 22:01 |
celeron55 |
does someone have some DoS tool available? |
| 22:03 |
Exio4 |
ask sfan5 |
| 22:29 |
sokomine |
something else that would be great for schematics: mirror |
| 22:42 |
sfan5 |
PilzAdam: I need HackerAdam on sfan5.duckdns.org:30009 |
| 22:52 |
sfan5 |
thanks for helping me test |
| 23:07 |
|
ch98 joined #minetest-dev |
| 23:08 |
|
ch98 left #minetest-dev |
| 23:26 |
|
ch98 joined #minetest-dev |
| 23:27 |
|
ch98 left #minetest-dev |
| 23:59 |
|
Miner_48er joined #minetest-dev |
