| Time |
Nick |
Message |
| 00:04 |
|
jojoa1997 joined #minetest-dev |
| 00:07 |
|
jojoa1997|PC joined #minetest-dev |
| 00:07 |
|
jojoa1997|PC left #minetest-dev |
| 00:12 |
|
kaeza1 joined #minetest-dev |
| 00:19 |
|
smoke_fumus joined #minetest-dev |
| 00:26 |
|
OWNSyouAll_DESK1 joined #minetest-dev |
| 00:30 |
|
nyuszika7h joined #minetest-dev |
| 00:31 |
|
ssieb joined #minetest-dev |
| 00:32 |
|
ShadowNinja_ joined #minetest-dev |
| 00:32 |
|
mrtux_ joined #minetest-dev |
| 00:35 |
|
Exio joined #minetest-dev |
| 00:38 |
|
IceCraft joined #minetest-dev |
| 00:48 |
|
kaeza joined #minetest-dev |
| 00:52 |
|
dexter0 joined #minetest-dev |
| 00:52 |
|
smoke_fumus joined #minetest-dev |
| 00:52 |
|
VanessaE joined #minetest-dev |
| 00:52 |
|
BrandonReese joined #minetest-dev |
| 00:52 |
|
thexyz joined #minetest-dev |
| 00:52 |
|
RealBadAngel joined #minetest-dev |
| 00:52 |
|
khonkhortisan joined #minetest-dev |
| 00:52 |
|
salamanderrake joined #minetest-dev |
| 00:52 |
|
darkrose joined #minetest-dev |
| 00:52 |
|
Tracerneo joined #minetest-dev |
| 00:52 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 00:53 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 01:11 |
hmmmm |
hmmm |
| 01:12 |
hmmmm |
you know, the whole "here's the default, just change it if it's not default" paradigm is out the window now that i have to allocate all noiseparams |
| 01:21 |
hmmmm |
alright, i guess proller had the right idea |
| 01:22 |
hmmmm |
i won't even do that though |
| 01:23 |
hmmmm |
if i just leave it as null, that'll be fine.. if it crashes, then it's clearly an internal problem, not a problem with the way i made the interface |
| 01:25 |
hmmmm |
the whole point of having the default defined constants for noiseparams was: here are the initial, default values for this mapgen. great, try getting the values from map metadata, okay, then try getting them from the config, and so on |
| 01:26 |
hmmmm |
honestly, the entire mapgen parameter system is fucked. it's totally overcomplicated for what it is |
| 01:26 |
hmmmm |
but before i start calling it crap, how can i do it better? |
| 01:27 |
hmmmm |
make more assumptions? |
| 01:31 |
|
jojoa1997 joined #minetest-dev |
| 01:33 |
hmmmm |
i can simplify things somewhat and clean up bad code by making defaults for the Settings when the map metadata is read |
| 01:35 |
hmmmm |
set all the defaults to an empty string so 1). it doesn't throw a stupid exception, preventing the rest of the metadata from being read, and 2). i'd be able to tell which settings need to be fetched from the config at least |
| 01:36 |
hmmmm |
but what i really want the default to be is the contents of the global config |
| 01:37 |
hmmmm |
map metadata has the highest precedence, then config, then defaults, so it'd make sense to write the defaults, write the config, then write the map metadata |
| 01:38 |
hmmmm |
i guess the reason why i read the config only after the metadata fails is to prevent duplicate work |
| 01:39 |
hmmmm |
and then on top of all this nonsense, i still have to handle the fixed seed specially |
| 01:39 |
|
kaeza1 joined #minetest-dev |
| 01:50 |
hmmmm |
you know, it'd probably be better if i just expand Settings to do what i want it to do |
| 01:51 |
hmmmm |
getNoEx() |
| 02:28 |
|
ShadowNinja joined #minetest-dev |
| 02:57 |
|
ecube joined #minetest-dev |
| 08:02 |
|
Calinou joined #minetest-dev |
| 10:47 |
|
Calinou joined #minetest-dev |
| 11:04 |
|
serengeor joined #minetest-dev |
| 11:04 |
|
ImQ009 joined #minetest-dev |
| 11:30 |
|
PilzAdam joined #minetest-dev |
| 12:59 |
|
serengeor joined #minetest-dev |
| 13:21 |
|
smoke_fumus|2 joined #minetest-dev |
| 13:22 |
|
smoke_fumus joined #minetest-dev |
| 13:31 |
|
iqualfragile joined #minetest-dev |
| 13:39 |
|
VanessaE joined #minetest-dev |
| 14:09 |
|
hmmmm joined #minetest-dev |
| 14:09 |
|
ImQ009 joined #minetest-dev |
| 15:07 |
|
Jordach joined #minetest-dev |
| 15:07 |
|
Jordach joined #minetest-dev |
| 15:18 |
|
rubenwardy joined #minetest-dev |
| 15:46 |
|
dexter0 joined #minetest-dev |
| 15:52 |
|
rubenwardy joined #minetest-dev |
| 16:17 |
|
Calinou joined #minetest-dev |
| 16:21 |
|
dexter0 joined #minetest-dev |
| 17:48 |
|
PilzAdam joined #minetest-dev |
| 17:51 |
|
kahrl joined #minetest-dev |
| 18:08 |
|
Calinou joined #minetest-dev |
| 18:17 |
|
sapier joined #minetest-dev |
| 18:22 |
|
ssieb joined #minetest-dev |
| 18:44 |
|
rubenwardy joined #minetest-dev |
| 18:52 |
|
ImQ009 joined #minetest-dev |
| 19:46 |
|
ShadowNinja joined #minetest-dev |
| 19:52 |
|
Taoki joined #minetest-dev |
| 20:10 |
|
salamanderrake joined #minetest-dev |
| 20:10 |
|
Jordach joined #minetest-dev |
| 20:10 |
|
Jordach joined #minetest-dev |
| 20:32 |
|
ShadowNinja joined #minetest-dev |
| 20:35 |
sfan5 |
can I commit a fix for the uk translation? its annoying that I need to fix it myself before making a win32 build |
| 20:36 |
PilzAdam |
link? |
| 20:36 |
sfan5 |
well, I don't have a link |
| 20:36 |
sfan5 |
i'll just add "\n" to the entry that causes the problem |
| 20:37 |
sfan5 |
add = prepend |
| 20:37 |
PilzAdam |
seems good then |
| 20:37 |
sfan5 |
ok |
| 20:37 |
Jordach |
when did we have a united kingdom translation |
| 20:38 |
sfan5 |
https://github.com/minetest/minetest/commit/f9b5771274f662ed12c209c3f1b563eb29d99ca7 |
| 20:39 |
sfan5 |
that translation contains russian things, but whatever |
| 20:39 |
sapier |
uk translation with russian entrys? |
| 20:39 |
sfan5 |
yeah |
| 20:40 |
sfan5 |
look at it: https://github.com/minetest/minetest/blob/master/po/uk/minetest.po |
| 20:40 |
sapier |
sounds wrong to me ... isn't anyone else puzzled too? |
| 20:40 |
PilzAdam |
sfan5, seems to work fine |
| 20:41 |
|
ShadowNinja joined #minetest-dev |
| 20:49 |
|
kaeza joined #minetest-dev |
| 21:05 |
sapier |
does anyone have an idea how to portably call unzip from within minetest? |
| 21:06 |
Calinou |
os.execute()? |
| 21:06 |
sapier |
portably ;-) |
| 21:06 |
sapier |
"unzip" most likely isn't available on windows ;) |
| 21:07 |
PilzAdam |
who cares about windows ;-) |
| 21:07 |
sapier |
I do as I want to improve usability of minetest |
| 21:08 |
sapier |
I already managed to create a ingame mod manager fixing common mod problems on it's own but this isn't very usefull if those users most likely to do those mistakes can't use it |
| 21:10 |
sapier |
e.g. mod having wrong dirname |
| 21:11 |
|
kaeza1 joined #minetest-dev |
| 21:30 |
|
serengeor joined #minetest-dev |
| 21:44 |
PilzAdam |
any objections to this: https://github.com/Warr1024/minetest/commit/4c2459852968f4564688fe356407367c791de67e |
| 21:44 |
PilzAdam |
I have tested it and it works fine |
| 22:10 |
|
tucebrin joined #minetest-dev |
| 22:10 |
tucebrin |
i need assistance |
| 22:12 |
PilzAdam |
tucebrin, note that this channel is for core development only; go to #minetest for anything else |
| 22:12 |
tucebrin |
may i pm you? |
| 22:12 |
tucebrin |
its just a simple thing |
| 22:12 |
PilzAdam |
sure |
| 22:31 |
kahrl |
sapier: include the minizip source (adjusted as needed) |
| 23:09 |
sapier |
looks reasonable kahrl ... I guess I have to add some filesystem handling support to core in order to get mod/game whatever management done in a portable way |
| 23:14 |
sapier |
https://github.com/sapier/minetest/tree/next_gen_main_menu prototype mod and game manager , enable by setting "main_menu_game_mgr" and "main_menu_mod_mgr" in minetest.conf to 1 |
| 23:15 |
|
ShadowNinja joined #minetest-dev |
| 23:15 |
sapier |
I'm going to move the filesystem functions to core, it's way more portable than doing this in lua |
| 23:17 |
|
Warr1024 joined #minetest-dev |
| 23:18 |
Warr1024 |
Would changing the server-side FOV to 180 really have a significant impact on bandwidth? |
| 23:18 |
Warr1024 |
I thought that the blocks sent to the client were rate-limited somehow... |
| 23:18 |
sapier |
as you say "somehow" ;-) |
| 23:18 |
Warr1024 |
...so that would mean that you'd get wider near-terrain faster, and it'd take a bit longer to get far terrain...? |
| 23:19 |
sapier |
as far as I know player fov is used to determine wich blocks to send ... but I'm not sure if this is the only limitation |
| 23:19 |
Warr1024 |
I guess it doesn't seem right to leave it locked in at 72 and have a 72-degree swath in the middle of your vision get loaded, and have to turn your head to get the rest. |
| 23:19 |
Warr1024 |
sapier: the server doesn't know the player's FOV, it uses a hard-coded 72-degrees. |
| 23:20 |
sapier |
ok maybe 72 degrees have been a evaluated value ... maybe they were just some number set when programming ... who knows ;-) |
| 23:20 |
Warr1024 |
I started the work on adding a TOSERVER_FOV packet to the proto, so the server would know each player's REAL FOV, and send the correct blocks. |
| 23:21 |
Warr1024 |
that would be a more optimized solution, but it's significantly more code, and complexity, added than the fixed 180 solution. |
| 23:21 |
sapier |
how do you protect server from malicious clients? |
| 23:21 |
hmmmm |
erm |
| 23:21 |
sapier |
e.g. player fov 360 |
| 23:21 |
Warr1024 |
well, clients can't specify an FOV more than 170 degrees, actually. |
| 23:21 |
hmmmm |
probably not a good idea to do that |
| 23:21 |
Warr1024 |
do which? |
| 23:22 |
hmmmm |
_i_ have plans to rip that entire FOV thing out and just send everything in a D-sized radius |
| 23:22 |
Warr1024 |
yeah, I like that idea... |
| 23:22 |
hmmmm |
there'd have to be a loading screen though |
| 23:22 |
Warr1024 |
even though you're sending blocks behind the client, it's pretty easy for them to just whip their head around... |
| 23:23 |
hmmmm |
so that first radius of blocks is completely loaded when the client actually starts to play |
| 23:23 |
Warr1024 |
ah, I see |
| 23:23 |
hmmmm |
every time the player moves and crosses a block boundary, the blocks in the new radius that weren't sent are then sent |
| 23:23 |
sapier |
do we know how performance is effected by a change like that? |
| 23:23 |
hmmmm |
so the edge of the radius keeps getting updated this way |
| 23:23 |
hmmmm |
it shouldn't matter in theory |
| 23:23 |
sapier |
maybe it's even a improvement .. I just don't have any idea ;-) |
| 23:23 |
hmmmm |
the performance is going to be roughly the same |
| 23:24 |
hmmmm |
you're still sending the same amount of blocks in the same timeframe |
| 23:24 |
hmmmm |
just in a different order |
| 23:24 |
hmmmm |
as for setting the FOV wider, well |
| 23:24 |
hmmmm |
having the server know any sort of FOV is a bad idea |
| 23:24 |
Warr1024 |
if network bandwidth is an issue, then the better solution is probably bandwidth limiting and better traffic prioritization, instead of trying to limit FOV server-side. |
| 23:25 |
sapier |
I assume latency is more an issue than bandwidth |
| 23:25 |
hmmmm |
perhaps you should check out https://github.com/minetest/minetest/commits/client_requests_blocks_2 |
| 23:25 |
Exio |
sapier: actually, it is both |
| 23:25 |
hmmmm |
should also see an increase in performance if TCP is used to transfer blocks |
| 23:25 |
Exio |
as sending stuff is very slow |
| 23:25 |
sapier |
oh :-) I remember your connection is quite slow exio |
| 23:25 |
hmmmm |
the main bottleneck in singleplayer at least is the mesh making |
| 23:26 |
hmmmm |
so even though the client might receive the blocks fast enough and all, it can't make the meshes for them fast enough |
| 23:26 |
Warr1024 |
hmmmm: yeah, that's a pain point for me on my Atom n450 :-) |
| 23:27 |
Exio |
i'd actually like the "client_requests" way for that |
| 23:27 |
Warr1024 |
so the idea is to have the client tell the server what blocks it needs instead of having the server use the player position tracking data and sending them unsolicited? |
| 23:28 |
sapier |
I don't think this is a good idea warr1024 |
| 23:29 |
Warr1024 |
which idea isn't good? |
| 23:30 |
Exio |
limiting that server-sidely |
| 23:30 |
sapier |
allowing client to request data ... this way you need a client to guess whats required and server needs to do same thing to protect itself |
| 23:30 |
Exio |
but allowing the clients to request "how many" do they way |
| 23:30 |
Exio |
s/way/want/ |
| 23:30 |
Warr1024 |
ok, well, that makes sense if the blocks client-side are stale and only the server knows they've changed... |
| 23:31 |
Warr1024 |
yeah, sorry, I'm late to the party, so to speak, and am still learning the internals. |
| 23:31 |
Exio |
sapier: moving stuff to the client seems something what needs "to be done" |
| 23:31 |
sapier |
no problem ... we all are ;-) except maybe celeron ;-) but I assume not even he knows every single detail |
| 23:31 |
hmmmm |
the reason why that's "something to be done" is because the FOV check is cpu intensive |
| 23:32 |
hmmmm |
if we remove the FOV check completely, then we don't need the client to request the blocks anymore |
| 23:32 |
Exio |
why not? |
| 23:32 |
hmmmm |
why would you? |
| 23:33 |
Exio |
i'm not saying the client requesting the blocks |
| 23:33 |
Warr1024 |
I guess all the client needs to do is ACK/NAK whether it successfully received the blocks, and the server can just decide and prioritize the blocks to send to the player. |
| 23:33 |
sapier |
a client never will know what blocks have been changed by other players ... server still needs to be able to override clients requests to speedup display of changes |
| 23:33 |
Exio |
but "limiting" the radius |
| 23:33 |
hmmmm |
you can move it to the client if you'd like, but like sapier said, if you'd like to protect against abuse you're going to have to duplicate drawing up a list of which blocks that the client needs anyway |
| 23:33 |
Warr1024 |
Exio: you're saying have the client send its draw range to the server so the server doesn't waste time sending blocks to the client that won't be immediately drawable? |
| 23:34 |
Exio |
exactly |
| 23:34 |
Exio |
what will be the point of having a radius of 15 mapblocks in memory in a netbook if it can barely render some near ones? |
| 23:34 |
Exio |
s/will/would/ |
| 23:34 |
Warr1024 |
you could do that, but if the server prioritizes near blocks first anyway, it doesn't necessarily hurt to send them, as you might need them later... |
| 23:35 |
Warr1024 |
after all, that's less the server will have to send once you start walking. |
| 23:35 |
sapier |
I don't think having them in memory is a problem ... loading and transfering most likely are the critical paths |
| 23:35 |
Exio |
as there is no client-side prediction for most of stuff, you need to wait (atm) for the whole world to load to be able to do stuff |
| 23:35 |
Exio |
like using a bucket |
| 23:35 |
Exio |
the whole world around* |
| 23:36 |
Warr1024 |
yeah, the process of emerging a new player is tricky for me on my netbook. |
| 23:36 |
Warr1024 |
I noticed that my player sprite enters the world, and its controls are uninitialized, almost immediately |
| 23:36 |
sapier |
you'll always need to wait for server ;-= prediction just fools user to not recognize he's waiting ,-) |
| 23:36 |
Warr1024 |
but it can take up to half a minute to load item visuals, during which time I'm exposed and vulnerable... |
| 23:37 |
Exio |
nah, not that |
| 23:37 |
Warr1024 |
I was thinking I should file a bug about it, since IIRC one of the other devs said that we should probably change that sequence. |
| 23:37 |
PilzAdam |
if I want to delte all meshes in MeshUpdateThread::m_queue_out should I create a destrcutor in MeshUpdateThread or loop through m_mesh_update_thread.m_queue_out in ~Client() and delte it there? |
| 23:37 |
PilzAdam |
*delete |
| 23:38 |
Exio |
sapier: if you want to play an online game |
| 23:38 |
Exio |
you do NOT want to see the lag |
| 23:38 |
sapier |
I theory the one creating the mesh is responsible for deleting it |
| 23:39 |
Exio |
i mean, being able to identify it, yes |
| 23:39 |
Exio |
but affecting the gameplay thanks "to that"? |
| 23:40 |
sapier |
exio I'm completely with you about hiding the lag but there's a tradeoff when moving to client ... if you move to much you either open up far more ways for a client to crash your server or need to do doublecalculations |
| 23:41 |
Exio |
both sides needs to share stuff |
| 23:41 |
|
tucebrin left #minetest-dev |
| 23:42 |
sapier |
sharing between multiple partners is one of the big (in general) unsolved issues of computer sciences ;-) |
| 23:42 |
Exio |
or you will end with a quake3 where you can't play with more than 150 ms of latency without getting a shitty gameplay, or a game where for cheating you just comment safety-checks |
| 23:42 |
Exio |
s/needs/need/ |
| 23:42 |
Warr1024 |
The amount of stuff NOT happening on the client was actually one of the things I really liked about minetest as compared to certain other mine* games. |
| 23:43 |
Exio |
sapier: i mean the server and the client |
| 23:43 |
Exio |
you can't let the client "manage alone" the movement, as you can't let the server alone do that |
| 23:43 |
Exio |
you need to do some stuff in the client and server |
| 23:43 |
Warr1024 |
I hate when client-side prediction tells me that something happened that the server rejected, and I get rewinds... |
| 23:43 |
sapier |
it's not only server <-> client it's server <-> n* clients |
| 23:45 |
Exio |
sapier: hmm, "you open X door", when you right click - some code runs on the client(for example), and it changes "door:closed" to "door:open" with some other code for doing that in reverse |
| 23:45 |
Exio |
if the packets are sent in order(?) the player would open it, join in the house, and then close the door |
| 23:46 |
sapier |
and what happens if some other player in right same moment does same? |
| 23:46 |
Exio |
that would be like a race-condition, actually in MC if you open a door what got open by other player it "keeps open" (iirc) |
| 23:46 |
Exio |
didn't try for a while |
| 23:47 |
Exio |
(or gets toggled, i can't recall atm) |
| 23:47 |
sapier |
difficult to handle in consistent way with prediction |
| 23:47 |
Exio |
what do you suggest for that, making the client wait "always" for the server? |
| 23:48 |
Exio |
for some of that stuff, i mean |
| 23:48 |
sapier |
I don't want to suggest something at current point of discussion I just point at the issues I recognize |
| 23:49 |
sapier |
I want to finish some of my open tasks prior starting a new one ;-) |
| 23:49 |
Exio |
i actually would prefer a race-condition-based client-side prediction more than a based-on-server-response |
| 23:56 |
|
ShadowNinja joined #minetest-dev |
| 23:59 |
PilzAdam |
anything against this: https://github.com/PilzAdam/minetest/commit/9397b5de083fabe2e93c55de5bf90e5c75bbe9c1 ? |
