| Time |
Nick |
Message |
| 00:00 |
|
diemartin joined #minetest-dev |
| 00:23 |
proller |
much simpler spawn falling object from c++ |
| 00:59 |
|
diemartin joined #minetest-dev |
| 01:02 |
hmmmm |
taoki, it must be pretty tough to build villages on that sort of terrain... why don't you just tweak the mapgen settings so it's more suitable? |
| 01:03 |
hmmmm |
don't really see why you'd subject yourself to that torture |
| 01:20 |
hmmmm |
ugh nevermind, i changed my mind on putting calcLighting/updateLiquids in VoxelManipulator |
| 01:20 |
hmmmm |
i'm going to create a base Mapgen object |
| 01:26 |
hmmmm |
feels pretty weird since it's the first time i ever used Mapgen in that manner |
| 01:48 |
kahrl |
if somebody is here who knows the particle code... (addNodeParticle in particular) |
| 01:48 |
kahrl |
let's say you're digging a torch |
| 01:49 |
kahrl |
how does this code ensure that the texture this particle is based on is only the first frame of the animation? |
| 01:49 |
kahrl |
am I missing some addition of ^[verticalframe:N:0 somewhere in the call chain? |
| 01:50 |
kahrl |
I mean, it obviously works, but I don't know why |
| 01:51 |
kahrl |
I tried printing getTextureName(ap.id) and it returns "default_torch_animated.png" |
| 01:58 |
kahrl |
OH! |
| 01:58 |
kahrl |
ap.size.Y = (ap.x1() - ap.x0()) * texsize; |
| 01:59 |
kahrl |
and the line above it made ap.x1() much smaller |
| 01:59 |
kahrl |
well... not sure if that is intended but it solves the problem |
| 02:41 |
kahrl |
whoever does a code review of https://github.com/minetest/minetest/pull/789, have fun :D |
| 02:44 |
|
Miner_48er joined #minetest-dev |
| 03:04 |
|
djcyberslash joined #minetest-dev |
| 03:06 |
|
ffoxin joined #minetest-dev |
| 03:32 |
|
ch98 joined #minetest-dev |
| 03:34 |
|
OWNSyouAll joined #minetest-dev |
| 05:21 |
|
kaeza joined #minetest-dev |
| 05:49 |
|
emptty joined #minetest-dev |
| 06:18 |
|
darkrose joined #minetest-dev |
| 06:18 |
|
darkrose joined #minetest-dev |
| 06:46 |
hmmmm |
hrmm |
| 06:55 |
hmmmm |
updateLiquid just doesn't fit anywhere besides mapgen |
| 06:55 |
hmmmm |
does it go into voxelalgorithms.cpp? nope, because it requires a Map, therefore it'd be a MapVoxelManipulator, but even then, you can't access m_map |
| 06:56 |
hmmmm |
does it go into voxel.cpp? nope, because that's full of VoxelManipulator things only |
| 06:56 |
hmmmm |
does it go into map.cpp? nope, because MapVoxelManipulator methods only deal with getting blocks and writing them back |
| 06:57 |
hmmmm |
and if i were to call using the mapgen version, i'd have to perform a 100% unnecessary and preventable copy of the entire contents of the queue for no reason |
| 06:58 |
hmmmm |
which is just stupid and ugly |
| 06:59 |
hmmmm |
really this sort of thing belongs in Map:: which handles the rest of the liquid stuff, except it doesn't deal with VoxelManipulators of any sort |
| 06:59 |
hmmmm |
although i disagree with the way it's set up in the first place - there should've been a separate Liquid class, and it should've had its own source file |
| 07:19 |
|
neko259 joined #minetest-dev |
| 07:29 |
|
ImQ009 joined #minetest-dev |
| 07:37 |
|
ssieb joined #minetest-dev |
| 08:00 |
|
Calinou joined #minetest-dev |
| 08:01 |
|
emptty joined #minetest-dev |
| 09:04 |
|
darkrose joined #minetest-dev |
| 09:04 |
|
darkrose joined #minetest-dev |
| 09:10 |
|
iqualfragile joined #minetest-dev |
| 10:31 |
|
PilzAdam joined #minetest-dev |
| 10:50 |
|
proller joined #minetest-dev |
| 10:53 |
|
Calinou joined #minetest-dev |
| 11:10 |
PilzAdam |
I found a reproduceable way to trigger the duplication bug: an ufo from the ufo mod is in an unloaded block; walk into the block so the ufo gets loaded, attach yourself to it and fly away so that the block gets unloaded; when flying back into the block (without detaching from the ufo) a copy of your ufo will appear at the same position again |
| 11:22 |
proller |
reducing liquid transform queue on map generate (for *finite) - http://paste.org.ru/?nkco8p |
| 12:14 |
|
BackupCoder joined #minetest-dev |
| 12:41 |
|
BackupCoder joined #minetest-dev |
| 12:42 |
proller |
312.40% minetest |
| 13:03 |
|
arsdragonfly joined #minetest-dev |
| 13:10 |
|
ecube joined #minetest-dev |
| 13:42 |
|
Zeg9 joined #minetest-dev |
| 14:05 |
|
ecube joined #minetest-dev |
| 14:14 |
|
ImQ009 joined #minetest-dev |
| 14:18 |
|
BrandonReese joined #minetest-dev |
| 14:38 |
|
iqualfragile joined #minetest-dev |
| 14:51 |
|
hmmmm joined #minetest-dev |
| 14:56 |
|
BlockMen joined #minetest-dev |
| 14:57 |
|
Jordach joined #minetest-dev |
| 15:12 |
|
Calinou joined #minetest-dev |
| 15:20 |
proller |
hmmmm, reducing liquid transform queue on map generate (for *finite) - http://paste.org.ru/?nkco8p |
| 15:22 |
|
salamanderrake joined #minetest-dev |
| 15:39 |
hmmmm |
erm |
| 15:39 |
hmmmm |
what is that...? |
| 15:39 |
hmmmm |
and what am i supposed to think about that |
| 15:42 |
|
dexter0 joined #minetest-dev |
| 15:44 |
|
PilzAdam joined #minetest-dev |
| 15:48 |
proller |
hmmmm, i will fix it, its adding every 6 node in liquid transform queue |
| 15:48 |
hmmmm |
i see |
| 15:48 |
proller |
inet_ntop needs up #define _WIN32_WINNT 0x0501 |
| 15:49 |
hmmmm |
um isn't that windows xp? |
| 15:49 |
hmmmm |
0x500 is windows nt 4.0 |
| 15:50 |
proller |
need to 600 |
| 15:51 |
hmmmm |
if you're suggesting we change it to 0x600, then the answer is a definite 'no' |
| 15:51 |
proller |
or i can return old ugly code for windows |
| 15:51 |
hmmmm |
well, that sucks |
| 15:51 |
proller |
for normal os - inet_ntop, for windows - old |
| 15:52 |
kahrl |
something else about the new socket.cpp |
| 15:52 |
kahrl |
the sockaddr_in6 structures are not always initialized completely |
| 15:52 |
kahrl |
this gives warnings in valgrind |
| 15:53 |
proller |
memset 0 need? |
| 15:53 |
kahrl |
yeah, would probably be the best idea |
| 15:54 |
kahrl |
(I don't know if the fields on sockaddr_in6 are the same on all platforms) |
| 15:54 |
kahrl |
of* |
| 15:54 |
Jordach |
anyways, if people have Teredo; (IPV6 for XP) then it *should* work |
| 15:54 |
Jordach |
or we depend on it silently for windows. |
| 15:57 |
kahrl |
proller: does WSAAddressToString work on xp? |
| 15:57 |
proller |
maybe |
| 15:57 |
proller |
but i cant test it |
| 15:58 |
|
arsdragonfly joined #minetest-dev |
| 15:58 |
|
ImQ009 joined #minetest-dev |
| 15:58 |
hmmmm |
i don't think it does |
| 15:58 |
hmmmm |
yes it does |
| 16:06 |
Jordach |
i have 7, but using Compat. Mode i could *attempt* it |
| 16:09 |
proller |
now i commit old code |
| 16:09 |
proller |
and who can make better for windows - do it |
| 16:15 |
proller |
commited |
| 16:17 |
|
dexter0 joined #minetest-dev |
| 16:45 |
|
proller joined #minetest-dev |
| 16:46 |
|
Mallot1 joined #minetest-dev |
| 17:19 |
|
proller joined #minetest-dev |
| 17:29 |
|
sweetbomber joined #minetest-dev |
| 17:31 |
sweetbomber |
i challenge you to draw your prompt at VanessaE's server. Go to the minimap at the forum to see where to draw. |
| 17:31 |
sweetbomber |
:) |
| 17:31 |
sweetbomber |
no scripting |
| 17:32 |
PilzAdam |
sweetbomber, not in this channel |
| 17:32 |
sweetbomber |
sorry |
| 17:39 |
proller |
maybe rewrite falling in c++ ? |
| 17:40 |
proller |
with queue like liquids, for falling unlimited volumes |
| 17:40 |
PilzAdam |
there is no need to; flowing liquids shouldnt fall |
| 17:40 |
Jordach |
technially yes |
| 17:41 |
Jordach |
how do you think it flows ;) |
| 17:41 |
proller |
but they already fall |
| 17:41 |
PilzAdam |
proller, great! nothing to do |
| 17:42 |
proller |
if you create large sky island from sand and touch it - you recieve segfault |
| 17:42 |
PilzAdam |
what does "large" mean? |
| 17:42 |
hmmmm |
hey sweetbomber, what's up |
| 17:42 |
proller |
try 50x50x50 |
| 17:42 |
Jordach |
PilzAdam, 100^2 sand box from WE |
| 17:43 |
Jordach |
or that. |
| 17:43 |
proller |
or smaller |
| 17:43 |
PilzAdam |
I tested 50^2 and it worked fine |
| 17:43 |
hmmmm |
sweetbomber, this may be of interest to you: https://github.com/minetest/minetest/commit/c1b829077a3518f3a129eee11887b2358a53f20b |
| 17:43 |
proller |
try larger |
| 17:44 |
proller |
and make ABM for falling sand after mapgen |
| 17:45 |
proller |
current falling is buggy |
| 17:45 |
PilzAdam |
its works for normal cases |
| 17:46 |
proller |
no |
| 17:46 |
PilzAdam |
of course it will fail if you overdo it |
| 17:46 |
proller |
sand stuck in air frequently |
| 17:46 |
PilzAdam |
how so? |
| 17:46 |
proller |
no, with standard usage |
| 17:46 |
PilzAdam |
I never saw sand stuck in air since the last update in falling nodes |
| 17:47 |
Jordach |
PilzAdam, you have a powerful computer. the rest of us dont. |
| 17:47 |
hmmmm |
falling node->object collision gets it stuck |
| 17:47 |
PilzAdam |
hmmmm, there is a pull request by me that disables object collision for falling nodes |
| 17:47 |
hmmmm |
to be honest, even with my monster of a processor, falling nodes sucked until luajit - it was like butter after that |
| 17:47 |
hmmmm |
i think we can do even better though |
| 17:48 |
hmmmm |
falling nodes in C++ might be a good idea because it's too intensive in lua |
| 17:49 |
proller |
and not optimail |
| 17:49 |
hmmmm |
pilzadam, falling node and object collision is the cause of them getting stuck i've noticed, so it might be a good idea to add that |
| 17:50 |
Exio |
and if it is done in C++ |
| 17:50 |
hmmmm |
sapier had an objection to it though |
| 17:50 |
Exio |
should be "easy" to make it have a client-side prediction, too? |
| 17:50 |
Jordach |
sapier always has an objection |
| 17:50 |
hmmmm |
hmmmm |
| 17:50 |
hmmmm |
you know, i've been thinking a lot about client side prediction |
| 17:50 |
hmmmm |
client-side lua is really big |
| 17:51 |
Exio |
i really think client-side lua for things like changing node door:closed to door:open when you right click |
| 17:51 |
hmmmm |
what if we hard-coded all of the predictions, except do it in a modular way |
| 17:51 |
Exio |
is ok, not for more things |
| 17:52 |
hmmmm |
we should hard code door prediction too |
| 17:52 |
Exio |
not door prediction, more like a "node change" |
| 17:52 |
hmmmm |
yeah, node change in general. |
| 17:52 |
hmmmm |
so that could be the generalized, modular thing to do |
| 17:52 |
Exio |
modular in what way exactly? |
| 17:53 |
celeron55 |
umm... that sounds like damn hard to generalize |
| 17:53 |
Exio |
a client-side-predictions-here/lotsof.cpps? |
| 17:53 |
PilzAdam |
hmmmm, every single modder will come here and wants full hardcoded prediction for his mod |
| 17:53 |
hmmmm |
no, i'm thinking of containing all client-side prediction into one file if possible |
| 17:53 |
celeron55 |
it would be a better idea to create a limited client-side api |
| 17:53 |
hmmmm |
PilzAdam, we'll have a policy to deny it |
| 17:53 |
hmmmm |
deny most requests anyway |
| 17:53 |
PilzAdam |
people dont care about policies |
| 17:54 |
hmmmm |
fuck them |
| 17:54 |
Exio |
PilzAdam: that people already hate you :D |
| 17:54 |
hmmmm |
client-side lua is ridiculous and i think it'd, in the end, make things worse but at least really modular |
| 17:54 |
celeron55 |
making independent mods too much of second class citizens isn't a good idea |
| 17:54 |
sweetbomber |
hmmmm: in the code im writing, ill leave a file format for latter |
| 17:55 |
sweetbomber |
probably ill use your code afterwards |
| 17:55 |
PilzAdam |
hmmmm, we already have client side Lua in the next gen mainmenu |
| 17:55 |
hmmmm |
sweetbomber, i left out cutoff handling |
| 17:55 |
hmmmm |
i thought that was formspec? |
| 17:55 |
hmmmm |
if it's already there then it might be okay |
| 17:55 |
celeron55 |
there simply are so many things that would be useful to predict that it's not sane to try to make definition-based predictions |
| 17:55 |
celeron55 |
(more than there is now, that is) |
| 17:55 |
sweetbomber |
hmmmm: what do you mean? you will not support it, or you found an alternative method? |
| 17:56 |
Jordach |
if it has an on_place, dont predict |
| 17:56 |
PilzAdam |
the general direction should be moving things out of the core into Lua, not the other way round |
| 17:56 |
hmmmm |
sweetbomber, neither of those; i'm basically leaving it up to you if you'd like |
| 17:56 |
hmmmm |
it's just not there at the moment |
| 17:56 |
sweetbomber |
hmmmm: thanks |
| 17:56 |
Exio |
Jordach: that is even worse |
| 17:56 |
sweetbomber |
im working on it right now |
| 17:56 |
sweetbomber |
the engine im designing will alow really big structures |
| 17:56 |
sweetbomber |
namely towns or cities |
| 17:56 |
hmmmm |
an engine, jeez |
| 17:57 |
Jordach |
sweetbomber, improve the renderer |
| 17:57 |
hmmmm |
it sounds to me like what you're doing is something that ought to not be part of decorationdef |
| 17:57 |
sweetbomber |
hmmmm: im aiming at structures, not just decorations like flowers and stuff |
| 17:58 |
hmmmm |
random procedurally generated structures, right? |
| 17:58 |
sweetbomber |
yes |
| 17:58 |
proller |
PilzAdam, things that operates large volumes must be in core |
| 17:58 |
hmmmm |
right, like i said this isn't really so much a decoration thing |
| 17:58 |
sweetbomber |
in the future i could allow the use of whatever fileformat you architect |
| 17:58 |
|
ssieb joined #minetest-dev |
| 17:59 |
sweetbomber |
but right now, the structure data will be input from lua |
| 18:00 |
hmmmm |
sweetbomber, it might be a good idea to use the schematic file format that i have already, except you can use param1 for something different than probability (since you won't need that field really), like IDs for connection points |
| 18:00 |
sweetbomber |
hmmmm: whenever i use a file format, it will be yours |
| 18:00 |
sweetbomber |
no need for double work |
| 18:00 |
hmmmm |
i'm flattered |
| 18:00 |
sweetbomber |
but ill also support designing structures from lua |
| 18:01 |
hmmmm |
if you mean a table full of nodes describing the structure itself |
| 18:01 |
sweetbomber |
no |
| 18:02 |
hmmmm |
okay then |
| 18:02 |
sweetbomber |
do you know "structure I/O and mapgen mod for minetest" mod? |
| 18:02 |
sweetbomber |
it has already some structures designed |
| 18:02 |
sweetbomber |
and some lua code to register nodes one by one |
| 18:02 |
hmmmm |
i don't really know of any mods |
| 18:03 |
sweetbomber |
what ill do is to tweak the I/O code so that it will register the structures in my system |
| 18:03 |
hmmmm |
erm okay |
| 18:03 |
sweetbomber |
at least it will ease my debugging at start, since ill have some structures to start |
| 18:04 |
sweetbomber |
direct loading from files will be my prefered method, though |
| 18:05 |
sweetbomber |
but first things first. |
| 18:05 |
sweetbomber |
well, ill return to work |
| 18:08 |
sweetbomber |
btw, how did you handled the fact that the MapNode content can only be resolved after the registration process? |
| 18:09 |
sweetbomber |
used any palette or something? |
| 18:09 |
sweetbomber |
im using a palette right now |
| 18:10 |
sweetbomber |
and i did it in such a way so that the same structure can be built with different palettes |
| 18:10 |
sweetbomber |
for example, the same house can be build with cobble, or with sandstone |
| 18:10 |
sweetbomber |
and only one model is required |
| 18:11 |
sweetbomber |
just two different palettes |
| 18:11 |
Jordach |
node x can be brick, node y can be glass |
| 18:12 |
Jordach |
and the same structure spawns, only with different materials |
| 18:16 |
hmmmm |
sweetbomber, for that, i store (temporarily if there are a lot) the node names in strings associated with that structure or whatever |
| 18:17 |
hmmmm |
then in EmergeManager::initMapgens() i call each of the structure's own resolveNodeNames() method, which looks up all the content ids |
| 18:17 |
sweetbomber |
hmmmm: ok, its the same thing im doing |
| 18:17 |
|
kaeza joined #minetest-dev |
| 18:29 |
|
sapier joined #minetest-dev |
| 18:32 |
|
jin_xi joined #minetest-dev |
| 18:45 |
|
Anchakor_ joined #minetest-dev |
| 18:45 |
|
jin_xi joined #minetest-dev |
| 19:01 |
|
BlockMen left #minetest-dev |
| 19:05 |
Jordach |
bad allocation in meshupdatethread |
| 19:05 |
Jordach |
also: unhandled with direct3d9 |
| 19:16 |
hmmmm |
hey guys, am i just being stupid, or is the whole item/node distinction weird |
| 19:16 |
hmmmm |
IItemDefManager::registerAlias() is used to register node aliases as well |
| 19:16 |
hmmmm |
but it only writes it to the item alias thing |
| 19:17 |
sapier |
item <-> node is different but maybe for some things it's not handled different |
| 19:17 |
sapier |
item == inventory element |
| 19:17 |
sapier |
node == static map element |
| 19:18 |
sapier |
entity/object == dynamic element |
| 19:18 |
hmmmm |
both of them go into the content features array, though, right? |
| 19:18 |
sapier |
at leats that's my personal view :-) |
| 19:22 |
|
iqualfragile_ joined #minetest-dev |
| 19:28 |
Jordach |
btw, vanessa is correct; when digging, i only have 10fps |
| 19:28 |
Jordach |
when it idles at 45 |
| 19:28 |
Jordach |
when not digging |
| 19:29 |
sapier |
may this be related to lua calls while digging? |
| 19:32 |
|
neko259 joined #minetest-dev |
| 19:33 |
|
ffoxin_entry joined #minetest-dev |
| 19:34 |
|
ffoxin joined #minetest-dev |
| 19:35 |
hmmmm |
hey PilzAdam |
| 19:35 |
hmmmm |
how's the init.lua split coming along |
| 19:35 |
hmmmm |
how's the nice gold textures coming along |
| 19:35 |
Exio |
the init.lua in mt_game is already splitted |
| 19:35 |
|
ch98 joined #minetest-dev |
| 19:35 |
hmmmm |
oh? |
| 19:35 |
hmmmm |
i must've missed it |
| 19:36 |
|
arsdragonfly|pho joined #minetest-dev |
| 19:36 |
hmmmm |
ahh very nice |
| 19:39 |
Jordach |
i think we need to have a theme for the textures, not just some random ones thrown together and called default |
| 19:40 |
Jordach |
heck, even minecraft alpha had better textures. |
| 19:40 |
sapier |
jordcach I'm same oppinion but thatd require someone to do them ... prefereably someone who is skilled enough to make it look consistent |
| 19:40 |
Jordach |
sapier, its called cisoun. |
| 19:41 |
sapier |
"its"? lol |
| 19:41 |
hmmmm |
odd |
| 19:41 |
Jordach |
sapier, he should be in #minetest |
| 19:41 |
hmmmm |
you'd think for a community with too many non-technical people, the texutres and all that would be super nice |
| 19:41 |
Jordach |
yes |
| 19:42 |
Jordach |
and i know cisoun's a pixel artist: http://forum.minetest.net/viewtopic.php?id=16 |
| 19:43 |
kaeza |
torch textures are too "realistic" |
| 19:43 |
Jordach |
kaeza, the current ones are derived from a real torch |
| 19:43 |
Jordach |
vanessa filmed one |
| 19:44 |
kaeza |
they look good with realistic TPs, but look weird in default |
| 19:44 |
kaeza |
(no offense V) |
| 19:44 |
Jordach |
sapier, heres the interesting thing: rapid digging causes my RTT = 1.117 to goto 1.119 |
| 19:44 |
Jordach |
it seems like the network stack gets jammed |
| 19:45 |
Jordach |
digging with a stone pick moves the counter to 1.118 |
| 19:46 |
sapier |
doesn't seem to be a big difference |
| 19:46 |
Jordach |
sapier, but it drops FPS |
| 19:46 |
Jordach |
by at least 2.3x |
| 19:46 |
|
VanessaE joined #minetest-dev |
| 19:46 |
sapier |
yes |
| 19:46 |
VanessaE |
(yes, I read the logs) |
| 19:47 |
sapier |
rtt not beeing influenced let's me guess it's a client issue |
| 19:47 |
Jordach |
its also consistent with the prediction |
| 19:47 |
Jordach |
any time the prediction is over used, the FPS drops and RTT grows in size |
| 19:47 |
VanessaE |
fwiw: the digging-causes-fps-loss started at roughly the same time as chests were moved to Lua. If that's related or not, I don't know. |
| 19:47 |
sapier |
is there any way to inspect packet rate? |
| 19:48 |
sapier |
maybe there are sent drasticaly more messages by server while digging |
| 19:48 |
Jordach |
sapier, checking task manager to see the network graph |
| 19:49 |
sapier |
does network graph schow packet rate too? I don't have windows ;-) |
| 19:49 |
Exio |
Jordach: how is the RTT related to the client performance |
| 19:49 |
Jordach |
Exio, dunno, but it slightly moves uop |
| 19:49 |
Jordach |
up* |
| 19:50 |
sapier |
question is if rtt is cleaned by server/client processing time or not |
| 19:51 |
Jordach |
sapier, http://i.imgur.com/9Vhdvpg.png |
| 19:52 |
Jordach |
yellow is bytes recievesd |
| 19:52 |
Jordach |
red is output |
| 19:52 |
Jordach |
the first set of spikes is mese pick digging |
| 19:52 |
Jordach |
then a rest, and restarted digging at the end over the course of a 1 minute |
| 19:52 |
celeron55 |
22:16:39 <+hmmmm> hey guys, am i just being stupid, or is the whole item/node distinction weird |
| 19:52 |
sapier |
grrr I wonder why i always have problems to see those images |
| 19:52 |
celeron55 |
nodes are basically items with a lot of extra features |
| 19:53 |
Jordach |
sapier, at the end, im sending more bytes than recieving |
| 19:53 |
celeron55 |
(to, like, make them handle the situation of being a voxel in the world) |
| 19:53 |
sapier |
jordach it's bandwidth not packet rate ... only a indication |
| 19:53 |
* ShadowNinja |
would like to see rollback fixed... Anyone have the skills and some time? |
| 19:54 |
Jordach |
sapier, my framerate didnt drop |
| 19:54 |
sapier |
oh I see |
| 19:54 |
Jordach |
thats because i was using a freshly loaded client |
| 19:54 |
VanessaE |
Jordach: the fps dropoff is so severe on my box that with some nodes (seems anything that has a right click or punch handler) I have to dig with the hand to avoid breaking the node behind it after it disappears. |
| 19:54 |
Jordach |
any client thats been used for more than 15 minutes will suffer from digging drops |
| 19:55 |
celeron55 |
VanessaE: have you ever before said that it's the ones with a right click or punch handler? |
| 19:55 |
celeron55 |
because that's very useful information |
| 19:55 |
sapier |
jordach is there anything obvious? like excessive memory usage for example? |
| 19:55 |
Jordach |
sapier, no, not at all |
| 19:55 |
VanessaE |
celeron55: I only today made that guess. But I have said multiple times that it only happened with some nodes and not others, and have listed at least a few examples, and I have said multiple times when it started, |
| 19:56 |
Jordach |
however, i've noticed my CPU fan and GPU fan are over active |
| 19:56 |
VanessaE |
s/made that guess/came to that conclusion, however false it might be/ |
| 19:56 |
celeron55 |
VanessaE: well if it's false, then of course it's useless |
| 19:56 |
Jordach |
something is definitely borked in the renderer |
| 19:56 |
Jordach |
(this is with a 32x texture pack) |
| 19:57 |
VanessaE |
celeron55: I meant whatever chance it might be irrelevant (in other words, I just don't know) |
| 19:59 |
hmmmm |
well |
| 19:59 |
Jordach |
im also going to note that node prediction fails to place "nodes" when i build |
| 19:59 |
hmmmm |
if you know the approximate timeframe in which it started happening, that's great |
| 19:59 |
VanessaE |
hmmmm: when chests were moved to Lua |
| 19:59 |
hmmmm |
a good way to be useful is to track down the specific commit that made it happen |
| 19:59 |
Jordach |
only when i get the server message that they exist in the world: they then appear |
| 19:59 |
hmmmm |
find a timeframe, do a binary search |
| 19:59 |
VanessaE |
which puts it at some time around 2012 1Q |
| 20:00 |
hmmmm |
and lots and lots of compiling ;/ |
| 20:01 |
Exio |
like compiling would take time ;P |
| 20:01 |
Exio |
it is under a minute here |
| 20:02 |
Exio |
(unless i compile lua and other stuff with it) |
| 20:02 |
hmmmm |
takes under a minute, but it's annoying when you need to do lots of it |
| 20:02 |
VanessaE |
celeron55: also, when you mentioned how I complain about things being slow and then turn around and purportedly request to add stuff that makes the engine slower -- um, you didn't do what I did, you don't see what I see, and you don't play how I play (or at all, as you've said), so you frankly don't know what you're talking about. |
| 20:03 |
Exio |
hmmmm: i'm pretty sure having to "try" the game is more annoying |
| 20:03 |
hmmmm |
yeah that too. |
| 20:04 |
sapier |
accusing anyone doesn't help if punching does have such a bad effect we need to track that down |
| 20:04 |
hmmmm |
there's still the stuttering that i unsuccessfully tried to track down |
| 20:04 |
sapier |
if we can proove it's not related to server we have half effort to find it so imho we schould find out this first |
| 20:04 |
hmmmm |
and then there was that huge lag when you placed nodes after one release i never found |
| 20:05 |
VanessaE |
tell me this: is a punch event in the client triggered on a button press, or on a button *release*? |
| 20:05 |
sapier |
it can't be release vanessae |
| 20:06 |
sapier |
hmm unless animation is completely independent |
| 20:06 |
VanessaE |
sapier: why not? that's a standard mouse event. |
| 20:06 |
VanessaE |
I'm asking for the sake of understanding what tells the client to begin a dig or punch event |
| 20:07 |
VanessaE |
(not what it does inside that event) |
| 20:07 |
|
sapier1 joined #minetest-dev |
| 20:07 |
sapier1 |
something has to be done on mouse click but yes you're right that isn't necessaryly sent to server |
| 20:08 |
hmmmm |
WTF is this |
| 20:08 |
hmmmm |
if(lua_isnumber(L, 3)) |
| 20:08 |
hmmmm |
stepsize = lua_tonumber(L, 3); |
| 20:08 |
hmmmm |
no indentation even |
| 20:08 |
hmmmm |
are you trying to hide that it's a conditional? |
| 20:08 |
hmmmm |
grrr |
| 20:09 |
VanessaE |
the reason I'm asking is because my first instinct is that the dig or punch event is triggered by the button-down event and is being *re-triggered* over and over as long as the button is down. In that case I'd change to triggering on a button-up event and decide if it's a punch by checking the time since the last button-down event. |
| 20:09 |
sapier1 |
of course not ;-) simple typo |
| 20:10 |
VanessaE |
it wouldn't fix the core issue, but in the old days, that's what we would have done to solve a problem like this. |
| 20:10 |
|
diemartin joined #minetest-dev |
| 20:11 |
sapier1 |
where's that code from hmmmm? |
| 20:18 |
celeron55 |
VanessaE: there isn't any such trivial bug |
| 20:18 |
VanessaE |
celeron55: didn't think so. |
| 20:18 |
VanessaE |
just a first instinct, that's all. |
| 20:19 |
celeron55 |
you can see a lot of what's going on by running minetest with --verbose |
| 20:19 |
celeron55 |
you'd definitely immediately see stuff like that |
| 20:21 |
celeron55 |
(or, most likely) |
| 20:21 |
VanessaE |
pfff.. through all that spew? :) |
| 20:23 |
VanessaE |
hah, I can't even all the way into a world with --verbose |
| 20:25 |
sapier1 |
vanessae that's what we all need to do to find bugs ;-) I recently inspected 300mb of network dump (after filtering) to find one wrong byte ;-) |
| 20:26 |
|
proller joined #minetest-dev |
| 20:27 |
celeron55 |
enabling shittons of logging and then grepping through it is the only working way to diagnose complex systems that can't be taken apart 8) |
| 20:27 |
VanessaE |
true. |
| 20:27 |
VanessaE |
IF you know what to look for and understand what you're reading :P |
| 20:28 |
celeron55 |
(the first "wrong" in that is when you can't take it apart, though...) |
| 20:29 |
celeron55 |
(but even if you can, reproducing a situation can be harder than just reading the log) |
| 20:29 |
sapier1 |
vanessae you can only "hope" to realize what is wrong when you see it ... most time you find false positives ... or completely unrelated errors ;-) |
| 20:29 |
VanessaE |
celeron55: ok, challenge. reproduce this: minetest: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. |
| 20:29 |
VanessaE |
:) |
| 20:44 |
|
hmmmmm joined #minetest-dev |
| 20:47 |
hmmmmm |
sapier, script/lua_api/l_env.cpp:574. don't bother fixing it though, that'll just cause a merge conflict..... |
| 20:48 |
sapier1 |
so you already fixed it? |
| 20:48 |
hmmmmm |
well, no, but i added code near it |
| 20:48 |
hmmmmm |
besides, it's a single tab... i can manage |
| 20:48 |
sapier1 |
I guess you can ;-) |
| 20:55 |
|
sapier1 left #minetest-dev |
| 20:55 |
|
hmmmmmm joined #minetest-dev |
| 21:01 |
|
Miner_48er joined #minetest-dev |
| 21:02 |
|
NakedFury joined #minetest-dev |
| 21:13 |
|
PilzAdam joined #minetest-dev |
| 21:27 |
PilzAdam |
hmmmmmm, I thought about removing default:snow and just use default:dirt_with_snow |
| 21:27 |
PilzAdam |
I just dont see the point of an extra snow layer above the snow |
| 21:28 |
proller |
NOOO! |
| 21:28 |
proller |
its TODO |
| 21:28 |
hmmmmmm |
if you do that, dirt_with_snow better drop dirt and snow |
| 21:28 |
hmmmmmm |
that's not a good idea anyway |
| 21:28 |
proller |
making rain and snow |
| 21:29 |
hmmmmmm |
we have lots of uses for it |
| 21:29 |
proller |
leveled snow with melting |
| 21:29 |
PilzAdam |
proller, snow will turn dirt_with_grass and dirt into dirt_with_snow |
| 21:30 |
proller |
did you see real snow? |
| 21:30 |
proller |
and water? |
| 21:30 |
PilzAdam |
did you see a real world consisting of cubes? |
| 21:30 |
proller |
lego |
| 21:32 |
hmmmmmm |
how are you going to cover trees with snowfall without a snow node |
| 21:32 |
proller |
snow must grow when snowfall |
| 21:33 |
proller |
2-3 blocks per winter |
| 21:33 |
proller |
and than melt |
| 21:33 |
PilzAdam |
proller, we dont have seasons or wether yet |
| 21:33 |
PilzAdam |
*weather |
| 21:33 |
proller |
now - not, but in future - yes |
| 21:33 |
proller |
and you want to stop future |
| 21:33 |
PilzAdam |
in far future |
| 21:34 |
proller |
i think in this year |
| 21:34 |
Exio |
hey man |
| 21:34 |
PilzAdam |
hmmmmmm, hm, maybe leave the snow node but remove dirt_with_snow; I just dont like the idea of two snow nodes above each other |
| 21:35 |
proller |
+1 |
| 21:35 |
Exio |
i think it looks nice |
| 21:35 |
proller |
futute is not stopable! 8) |
| 21:36 |
proller |
and maybe make grass like snow |
| 21:36 |
|
hmmmmm joined #minetest-dev |
| 21:36 |
proller |
leveled and growable |
| 21:37 |
hmmmmm |
PilzAdam, why not exactly? |
| 21:37 |
hmmmmm |
it makes sense to be able to dig some snow off the ground |
| 21:37 |
hmmmmm |
besides, minecraft does this as well |
| 21:38 |
PilzAdam |
"MC does this" is not a valid argument |
| 21:38 |
hmmmmm |
it's just easier for me as well to top everything off with a snow layer |
| 21:41 |
PilzAdam |
its more realistic if there is grass under the snow layer |
| 21:42 |
hmmmmm |
my only complaint is that it might look weird on ridges |
| 21:46 |
|
hmmmmmm joined #minetest-dev |
| 21:48 |
|
hmmmmm joined #minetest-dev |
| 21:57 |
|
kaeza joined #minetest-dev |
| 22:00 |
|
hmmmmmm joined #minetest-dev |
| 22:05 |
|
hmmmmm joined #minetest-dev |
| 22:24 |
|
arsdragonfly joined #minetest-dev |
| 22:24 |
arsdragonfly |
https://github.com/minetest/minetest/pull/783 |
| 22:26 |
PilzAdam |
seems good |
| 22:28 |
arsdragonfly |
and this one https://github.com/minetest/minetest/pull/790 |
| 22:29 |
arsdragonfly |
check them out |
| 22:29 |
arsdragonfly |
I need some comments :-) |
| 22:29 |
PilzAdam |
any screenshots how the new fonts look like? |
| 22:30 |
arsdragonfly |
If I enlarge the font size ,will the menu size be enlarged accordingly? |
| 22:30 |
PilzAdam |
no |
| 22:30 |
arsdragonfly |
Cropped? |
| 22:31 |
arsdragonfly |
Cuz basically I don't see much difference |
| 22:31 |
arsdragonfly |
well since it's the font that android used I'll take a screenshot right now on my phone |
| 22:32 |
PilzAdam |
no, I want to see how it looks in-game |
| 22:33 |
|
Anchakor_ joined #minetest-dev |
| 22:34 |
arsdragonfly |
-_-z well wait a moment |
| 22:34 |
arsdragonfly |
I haven't gotten up yet |
| 22:40 |
arsdragonfly |
:-\ dunno how to change gettext's locale |
| 22:41 |
PilzAdam |
run minetest with LANG=<language code> bin/minetest |
| 22:42 |
arsdragonfly |
oh w8 I forgot to generate the locales with $locale |
| 22:47 |
arsdragonfly |
PilzAdam that doesn't work :-( |
| 22:48 |
celeron55 |
what do you use as the language code? |
| 22:51 |
arsdragonfly |
en_US.UTF-8 |
| 22:51 |
arsdragonfly |
maybe I should change that elsewhere |
| 22:51 |
PilzAdam |
C should work too |
| 22:52 |
PilzAdam |
LANG=C bin/minetest |
| 22:52 |
celeron55 |
what are you trying to do then? |
| 22:52 |
arsdragonfly |
Make Gettext use English |
| 22:52 |
celeron55 |
try simply "en_US" |
| 22:53 |
celeron55 |
or en-Us |
| 22:53 |
celeron55 |
en-US* |
| 22:54 |
arsdragonfly |
oh |
| 22:54 |
arsdragonfly |
C and POSIX both work |
| 22:57 |
arsdragonfly |
<arsdragonfly> https://github.com/minetest/minetest/pull/783 |
| 22:57 |
arsdragonfly |
posted it there |
| 23:28 |
|
jojoa1997 joined #minetest-dev |
| 23:36 |
|
Mallot1 joined #minetest-dev |
| 23:40 |
VanessaE |
regarding fps can I at LEAST request that someone fix the view range auto-tuner so that it adjusts at a usable rate? |
| 23:41 |
VanessaE |
make it adjust at say 10 nodes/sec (presently, it's more along the lines of 1 node a minute) |
| 23:43 |
PilzAdam |
when I join a game it takes < 10 sec. to get to the max value |
| 23:43 |
VanessaE |
not for me, for reasons I can't even begin to estimate, it move so slowly as to be basically useless. |
| 23:43 |
VanessaE |
moves* |
| 23:51 |
VanessaE |
oh sure now that I've said it, it moves faster. about 1 node in three seconds. |
| 23:54 |
|
kaeza joined #minetest-dev |
| 23:54 |
VanessaE |
I think it just needs to have some kind of minimum adjustment speed is the issue |
| 23:55 |
VanessaE |
it slows down to a crawl as it gets close to the desired fps but it gets so slow by the time it's within ~5 fps of the target that it may as well not be moving at all. |
| 23:56 |
VanessaE |
(slows down as in the step rate goes way down) |
| 23:56 |
VanessaE |
this makes the game feel sluggish, jittery when the actual fps is close to but less than the target |
| 23:57 |
VanessaE |
(and there's presumably still some room left to adjust it) |
| 23:58 |
PilzAdam |
camera.cpp:554 // Dampen the change a bit to kill oscillations |
