| Time |
Nick |
Message |
| 00:07 |
|
cg72 joined #minetest-dev |
| 00:25 |
hmmmm |
:\ |
| 00:25 |
hmmmm |
I'm about to push the mapgen.cpp split |
| 00:28 |
|
Zeno` joined #minetest-dev |
| 00:33 |
VanessaE |
there was consensus? |
| 00:43 |
hmmmm |
nope |
| 00:43 |
hmmmm |
that's why |
| 00:44 |
VanessaE |
[11-01 13:23] <hmmmm> I won't push this to upstream until I get 3 approvals |
| 00:44 |
VanessaE |
um... |
| 00:45 |
hmmmm |
i just realized how tough that's going to be when it's already been how many hours and nobody did so much as look at it |
| 00:45 |
VanessaE |
um... |
| 00:46 |
hmmmm |
um... |
| 00:46 |
VanessaE |
isn't that EXACTLY what happens with every other damn pull request for this engine? |
| 00:46 |
hmmmm |
yeah. |
| 00:46 |
VanessaE |
so, no. |
| 00:46 |
hmmmm |
this policy of having multiple people review things would work if devs were full time |
| 00:46 |
hmmmm |
but this is open source land |
| 00:47 |
VanessaE |
so put it in a pull request. |
| 00:47 |
hmmmm |
... |
| 00:47 |
hmmmm |
I'm going to merge it just to piss you off |
| 00:47 |
VanessaE |
you won't piss me off.. |
| 00:47 |
VanessaE |
but you get to be the one that fields all of MegaF's crash reports ;) |
| 00:48 |
hmmmm |
meh |
| 00:49 |
hmmmm |
it's a development build |
| 00:49 |
hmmmm |
what did you expect, i mean |
| 00:49 |
|
chchjesus joined #minetest-dev |
| 00:49 |
VanessaE |
I didn't expect any different - if shit breaks, I get that. |
| 00:50 |
VanessaE |
just reminded you of your previous comment is all. |
| 00:50 |
VanessaE |
you know, a "good enough for the goose" sorta thing. |
| 00:50 |
hmmmm |
i am cognizant of that |
| 00:53 |
RealBadAngel |
hmmmm, +1 |
| 00:57 |
RealBadAngel |
good to see something is goin on with mapgens |
| 00:57 |
RealBadAngel |
i just wish you will use lsystem trees one day ;) |
| 00:58 |
hmmmm |
i plan on going back and implementing the generation component types that aren't implemented |
| 00:58 |
hmmmm |
e.g. DECO_LSYSTEM, ORE_CLAYLIKE (renaming that to ORE_BLOB) |
| 00:59 |
RealBadAngel |
i noticed DECO_LSYSTEM but it was empty ;) |
| 00:59 |
hmmmm |
i hope i can get mapgen to a happy enough place so i can work on things that really need work |
| 00:59 |
hmmmm |
like i need to stop talking and start doing about the hardware lighting |
| 00:59 |
hmmmm |
i have a great idea of how to accomplish that already |
| 01:00 |
RealBadAngel |
go on |
| 01:00 |
hmmmm |
well I already told you that I generate the lightmaps alongside the meshes |
| 01:01 |
hmmmm |
the idea is to separate the light from the node |
| 01:02 |
hmmmm |
each time the client receives a block with light sources it gets added to a map of light sources |
| 01:02 |
hmmmm |
whenever the client renders something that would be influenced by (in the range of) that light source, it gets calculated and added to the lightmap while rendering the mesh |
| 01:03 |
hmmmm |
i haven't figured out how to do sunlight yet though |
| 01:03 |
hmmmm |
probably global illumination |
| 01:03 |
RealBadAngel |
imho sunlight is most easy to do |
| 01:04 |
hmmmm |
it would have to be separate from this |
| 01:04 |
VanessaE |
hmmmm: what about zeno's refactor_the_game ? |
| 01:04 |
RealBadAngel |
i tried adding light source up above the player with big radius |
| 01:04 |
VanessaE |
why is it still being left to rot? |
| 01:04 |
hmmmm |
VanessaE, i don't know |
| 01:04 |
RealBadAngel |
it works quite good |
| 01:04 |
hmmmm |
RealBadAngel I saw that |
| 01:04 |
hmmmm |
it made the sand look fake though |
| 01:05 |
Zeno` |
Oh yeah |
| 01:05 |
Zeno` |
Did you get a chance to test it RBA? |
| 01:05 |
hmmmm |
isn't there some sort of tiledef specular setting that you could change? |
| 01:05 |
RealBadAngel |
maybe some tweaks will do the trick |
| 01:06 |
RealBadAngel |
speculars are kinda fake right now |
| 01:06 |
RealBadAngel |
there are no specular maps |
| 01:06 |
RealBadAngel |
thats why it may look a bit weird |
| 01:06 |
hmmmm |
yeah |
| 01:06 |
hmmmm |
no kidding. |
| 01:06 |
RealBadAngel |
Zeno`, it works |
| 01:06 |
hmmmm |
well we'll cross that bridge when we get to it |
| 01:07 |
hmmmm |
man I can't imagine how many cool things we'll be able to do with 8 more bits of mapnode |
| 01:07 |
RealBadAngel |
jeeez |
| 01:07 |
Zeno` |
compiles, works, merge! :D |
| 01:07 |
RealBadAngel |
a lot |
| 01:07 |
VanessaE |
hmmmm: I thought you were against adding more data to the map? |
| 01:07 |
hmmmm |
VanessaE, not adding more |
| 01:08 |
RealBadAngel |
we are going to set 8 bits free :) |
| 01:08 |
hmmmm |
param1's purpose will change after lighting stops being fake |
| 01:08 |
VanessaE |
hm, ok |
| 01:08 |
hmmmm |
also |
| 01:08 |
VanessaE |
didn't think of it from that standpoint |
| 01:08 |
hmmmm |
the lightmap method supports colors |
| 01:08 |
hmmmm |
so woohoo colored lighting |
| 01:09 |
Zeno` |
can param1, 2 and 3 be split out from Node as well? |
| 01:09 |
hmmmm |
huh |
| 01:09 |
Zeno` |
They current a member of Node (or NodeDef... whatever it's called), so can't do fast memcpy() etc |
| 01:10 |
* hmmmm |
scratches head |
| 01:10 |
Zeno` |
have to iterate over them all to get the data into vmanip |
| 01:10 |
hmmmm |
you can most definitely memcpy mapnodes as they are POD |
| 01:10 |
hmmmm |
in fact we do that already for certain vmanip things |
| 01:11 |
Zeno` |
But you don't use the whole node in the voxel manip stuff (do you?) |
| 01:11 |
hmmmm |
the whole node is there |
| 01:11 |
hmmmm |
you almost never set anything aside from the content though |
| 01:11 |
Zeno` |
I'll look at it again so I can explain it better (it was a few months ago I was looking at it) |
| 01:12 |
RealBadAngel |
Zeno`, i think that game stuff should be merged, if there will be problems, more testers of dev version will find them |
| 01:12 |
hmmmm |
yeah let's merge it |
| 01:12 |
Zeno` |
ok :) |
| 01:13 |
RealBadAngel |
shall i do that? |
| 01:13 |
hmmmm |
sure |
| 01:13 |
RealBadAngel |
ok |
| 01:13 |
Zeno` |
thanks |
| 01:13 |
* kaeza |
throws #1770 at RealBadAngel |
| 01:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/1770 -- Remove wield item camera clipping. |
| 01:15 |
|
casimir joined #minetest-dev |
| 01:15 |
kahrl |
ugh, why does github decide for me if I want to see the game.cpp changes when I look at #1756 |
| 01:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/1756 -- Refactor the game by Zeno- |
| 01:16 |
Zeno` |
Because it's scared? |
| 01:17 |
Zeno` |
RBA there are two commits, can they be left as 2? Because the one I added yesterday has not been tested for 3 weeks like the other ones (that I squash upon request) |
| 01:17 |
hmmmm |
bit of a personal preference but |
| 01:17 |
hmmmm |
i haaaaate the term 'app' |
| 01:17 |
Zeno` |
hmmmm, I do as well |
| 01:17 |
hmmmm |
could you change it to Game? |
| 01:17 |
hmmmm |
MinetestGame? |
| 01:17 |
hmmmm |
or just Game? |
| 01:17 |
Zeno` |
hmmmm, it was client at first but that was confusing |
| 01:18 |
Zeno` |
Game... yeah |
| 01:18 |
hmmmm |
thank you |
| 01:18 |
Zeno` |
Which means I have to squash. Can you take a quick look at the second commit? |
| 01:18 |
hmmmm |
yea |
| 01:19 |
Zeno` |
and I'll squash the second commit (still leave as two commits) |
| 01:19 |
kahrl |
Zeno`: could boolToCStr be moved to util/string.h? |
| 01:19 |
Zeno` |
kahrl, it must be at some point, but I was trying to minimise the number of files I touched |
| 01:20 |
hmmmm |
shouldn't FpsControl *params be called FpsControl *fps or something? |
| 01:20 |
Zeno` |
yep, updating |
| 01:21 |
hmmmm |
i'm not entirely sure what setting dtime to 0.03 on overflow in practice |
| 01:21 |
hmmmm |
isn't there already a TimeDiff-type function? |
| 01:21 |
hmmmm |
<hmmmm> i'm not entirely sure what setting dtime to 0.03 on overflow in practice will do* |
| 01:22 |
Zeno` |
in the original code it was simply set to 0, but I noticed that setting it to 0 caused a freeze when I forced an overflow when testing |
| 01:23 |
kahrl |
can't you just calculate (time - last_time) / 1000.0 regardless of overflow |
| 01:23 |
hmmmm |
the overflow case is if the counter looped around |
| 01:24 |
hmmmm |
if you have some negative time then.. |
| 01:24 |
Zeno` |
yes and then would sleep a very long time |
| 01:24 |
Zeno` |
it's unsigned so it will be very large rather than -ve |
| 01:25 |
kahrl |
so e.g. last_time = 2**32 - 1, time = 50 |
| 01:25 |
kahrl |
then (time - last_time) would be 51 |
| 01:25 |
kahrl |
not very large |
| 01:25 |
Zeno` |
I guess it's not huge |
| 01:26 |
Zeno` |
hmm |
| 01:26 |
Zeno` |
ok, I've done the renaming |
| 01:26 |
Zeno` |
now ... |
| 01:27 |
Zeno` |
Maybe I could just put 0 like the original code? |
| 01:27 |
Zeno` |
no |
| 01:27 |
Zeno` |
setting dtime to 0 pauses things |
| 01:28 |
kahrl |
then I guess put a *dtime = MYMAX(*dtime, 1) at the end of limitFps |
| 01:29 |
kahrl |
er |
| 01:29 |
Zeno` |
yeah it wasn't to do with FPS (I remember now) it was more client->step(*dtime); |
| 01:29 |
kahrl |
thought it was in milliseconds, should be MYMAX(*dtime, 0.001) |
| 01:29 |
Zeno` |
and if singleplayer server->step(*dtime); |
| 01:29 |
Zeno` |
and things went mental |
| 01:30 |
RealBadAngel |
kahrl, btw any progress with extruded mesh code? |
| 01:30 |
Zeno` |
I can make it .001 if that seems safer |
| 01:31 |
kahrl |
RealBadAngel: not really |
| 01:31 |
RealBadAngel |
you mentioned youre about to rewrite it? |
| 01:31 |
kahrl |
RealBadAngel: yes |
| 01:32 |
RealBadAngel |
so, what are you waitin for? xmas? ;) |
| 01:32 |
kahrl |
the problem I'm having is that I want different ContentFeatures (actually their ClientCached) to share the wield mesh, but I can't because the materials are different |
| 01:32 |
Zeno` |
just add *dtime = 0.03 (take away the conditionals) and also 0.001 and you can see the difference heh |
| 01:33 |
kahrl |
so either getWieldMesh's return value is only valid until someone else calls getWieldMesh() (problematic), every caller would have to handle the material issue or I need to abstract wield mesh rendering into a scene node or something like that |
| 01:33 |
RealBadAngel |
imho separate scene node |
| 01:34 |
kahrl |
yeah, that's the way I'd have gone with |
| 01:34 |
RealBadAngel |
im going to make the same with highlighted and cracked one |
| 01:35 |
RealBadAngel |
so pointing something (or punching) wont require block updates |
| 01:39 |
kahrl |
would it make sense to get rid of the wieldmesh in ClientCached and, in the new scene node, just take mesh_ptr[0] when rendering a node's wield mesh? |
| 01:39 |
kahrl |
scaled appropriately of course |
| 01:40 |
kahrl |
guess that won't work with drawtypes that aren't normal, nodebox or mesh |
| 01:40 |
RealBadAngel |
but only static ones have that ptr |
| 01:41 |
RealBadAngel |
nodeboxes and meshes |
| 01:41 |
kahrl |
yeah, I mean rendering NDT_NORMAL is trivial |
| 01:41 |
kahrl |
and for nodebox and mesh, mesh_ptr[0] can be used |
| 01:42 |
RealBadAngel |
when its aviable just use it |
| 01:42 |
RealBadAngel |
it will be faster |
| 01:43 |
RealBadAngel |
ptr[0] is useable for inv and wielded |
| 01:44 |
RealBadAngel |
ive changed lately inv mesh code for wallmounted, so theres no need to supply the inv image for wallmounted nodes anymore |
| 01:46 |
kahrl |
I guess allfaces, torchlike and signlike could all be converted to mesh on startup |
| 01:47 |
kahrl |
plantlike too |
| 01:47 |
RealBadAngel |
allfaces yes, plantlike too |
| 01:47 |
RealBadAngel |
torchlike.... we need 3d models for torches |
| 01:48 |
kahrl |
3d torches would be a different drawtype |
| 01:48 |
RealBadAngel |
signlike shall be added ability to write the text |
| 01:48 |
VanessaE |
not signlike. |
| 01:48 |
VanessaE |
ANY node |
| 01:49 |
VanessaE |
see #1367 |
| 01:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/1367 -- Proper display of text on the surface of a node(box) |
| 01:49 |
RealBadAngel |
text means a texture generated runtime |
| 01:49 |
RealBadAngel |
adding that to ANY node will kill any engine |
| 01:50 |
RealBadAngel |
but apart from that model can be cached |
| 01:50 |
RealBadAngel |
it doesnt matter at all |
| 01:53 |
kahrl |
how much memory would it cost? |
| 01:54 |
kahrl |
(assuming no sharing of meshes between different nodedefs) |
| 01:54 |
RealBadAngel |
in case of dreambuilder all meshes takes circa 0.5 gb |
| 01:55 |
RealBadAngel |
that means all nodeboxes too |
| 01:55 |
RealBadAngel |
but note that we do count there an anomaly: wires |
| 01:56 |
RealBadAngel |
64 defined nodes multiplied by 24 |
| 01:56 |
RealBadAngel |
of several kinds |
| 01:56 |
RealBadAngel |
also the tubes |
| 01:57 |
RealBadAngel |
those screams out loud for specialized drawtype |
| 02:00 |
RealBadAngel |
but anyway payin that 0.5gb is a good deal |
| 02:00 |
RealBadAngel |
mapblock mesh updates are way smoother |
| 02:04 |
RealBadAngel |
in case of minetest_game cost is next to nothing, unnoticeable |
| 02:06 |
kahrl |
I think caching allfaces nodes would be quite nice for performance in heavily forested areas |
| 02:13 |
|
casimir_ joined #minetest-dev |
| 02:14 |
|
iqualfragile joined #minetest-dev |
| 02:14 |
RealBadAngel |
kahrl, i will try it |
| 02:16 |
|
Taoki joined #minetest-dev |
| 02:21 |
hmmmm |
hrmm |
| 02:22 |
hmmmm |
remember how I advocated against m_ prefixes for member variables |
| 02:22 |
hmmmm |
sorta going back on that now, i think it should be there at least for private members |
| 03:04 |
Zeno` |
I like it for private members |
| 03:29 |
hmmmm |
but the thing is, i almost never use private members |
| 03:30 |
hmmmm |
i don't like the concept of enforced access, i think it should be a hint at best. the programmer is assumed to be responsible and use it appropriately - if they wanted to create bugs, there are plenty of other opportunities to do so |
| 03:41 |
RealBadAngel |
https://github.com/minetest/minetest/commit/d221917170c2bb43c66e5e09f2a43350cf28d71b |
| 03:41 |
RealBadAngel |
see what i had to do to get smgr |
| 03:41 |
RealBadAngel |
and rethink that |
| 03:42 |
RealBadAngel |
*that* is sick |
| 03:44 |
RealBadAngel |
instead of getting a member directly , creating dummy server side functions to get shit compiled |
| 03:44 |
RealBadAngel |
if thats normal, shoot me |
| 03:46 |
kahrl |
why the hell does one need a ISceneManager anyway to get an IMeshManipulator |
| 03:46 |
kahrl |
an* |
| 03:46 |
kahrl |
it makes no sense |
| 03:47 |
RealBadAngel |
if theres any other way i would like to know it |
| 03:48 |
kahrl |
I'd say this isn't minetest's fault but irrlicht's |
| 03:52 |
hmmmm |
I wonder if I'm going to break anybody's mods by changing the biome ID from a sequential array index to an opaque handle that needs to get decoded |
| 03:52 |
kahrl |
RealBadAngel: what prevented you from passing the scene manager to updateTextures, btw? |
| 03:52 |
RealBadAngel |
propably thats why we copy mesh primitive functions instead of using engine ones |
| 03:53 |
RealBadAngel |
kahrl, we had gamedef passed there |
| 03:53 |
RealBadAngel |
*have |
| 03:53 |
kahrl |
so? |
| 03:53 |
RealBadAngel |
it should be enough |
| 03:53 |
kahrl |
640k should be enough :P |
| 03:53 |
RealBadAngel |
rotfl |
| 03:54 |
RealBadAngel |
i will change that |
| 03:55 |
RealBadAngel |
gamedef should carry smgr |
| 03:56 |
RealBadAngel |
and those dummy server side calls to get texture, shader etc shall be removed |
| 03:56 |
RealBadAngel |
its way more than just confusing |
| 03:58 |
kahrl |
> Segmentation fault |
| 03:58 |
kahrl |
guess the wield mesh scene node needs some more work |
| 03:59 |
RealBadAngel |
backtrace? |
| 03:59 |
kahrl |
oh, found it |
| 03:59 |
kahrl |
just a stupid mistake, missed a negation |
| 03:59 |
RealBadAngel |
me or u? |
| 04:00 |
kahrl |
me |
| 04:01 |
RealBadAngel |
good to hear im not the only source of bugs ;) |
| 04:14 |
hmmmm |
hmm |
| 04:14 |
hmmmm |
probably a stupid question, but: is there a type for a "generic" iterator? |
| 04:14 |
|
MikeFair_ joined #minetest-dev |
| 04:21 |
|
CraigyDavi joined #minetest-dev |
| 04:36 |
|
AnotherBrick joined #minetest-dev |
| 04:41 |
|
Miner_48er joined #minetest-dev |
| 04:59 |
kahrl |
hmmmm: auto :P |
| 05:09 |
|
Zeno` joined #minetest-dev |
| 05:13 |
hmmmm |
:/ |
| 05:19 |
Zeno` |
auto not good :( |
| 05:19 |
Zeno` |
I drive manual car |
| 05:43 |
|
sol_invictus joined #minetest-dev |
| 05:45 |
|
kaeza joined #minetest-dev |
| 06:21 |
Zeno` |
can #1776 be merged? The whole reason my bug slipped through the other day was because I disable unit tests constantly because of that ipv6 failure |
| 06:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/1776 -- Clean up code style of sockets and fix unit tests failing if IPv6 not available by Zeno- |
| 06:23 |
Zeno` |
The most important part of the change is https://github.com/Zeno-/minetest/commit/31fb4a8abed79f32accbd9d3c8cf5399aae12950#diff-521e0711bdefd4d33b5ef108ee1baf2fR1518 |
| 06:24 |
Zeno` |
and the new init() function to allow that change |
| 06:25 |
Zeno` |
init() simply moved stuff out of the ctor into its own function |
| 06:54 |
hmmmm |
wait, why are you omitting parentheses around sizeof? |
| 06:57 |
Zeno` |
same reason as I omit them around return :( |
| 06:58 |
Zeno` |
parenthesis confuse me |
| 06:58 |
Zeno` |
clutter |
| 06:58 |
Zeno` |
I guess I should put them back since you're the second person to ask that :/ |
| 06:58 |
hmmmm |
the code style is to have parentheses around sizeof as if it were a function |
| 06:58 |
Zeno` |
ok I didn't know that was part of the code style |
| 06:58 |
Zeno` |
I'll put them back |
| 06:59 |
Zeno` |
should it be sizeof(x) or sizeof (x)? |
| 06:59 |
hmmmm |
sizeof(x) |
| 06:59 |
hmmmm |
also, what's with https://github.com/Zeno-/minetest/commit/31fb4a8abed79f32accbd9d3c8cf5399aae12950#diff-d999b22f05a7d6687dee3151d4552f0aL453 ? |
| 06:59 |
hmmmm |
why add the extra <<? |
| 07:00 |
Zeno` |
that's how the rest of the code does it (i.e. does not relying on string literal concatenation) |
| 07:00 |
Zeno` |
the rest of the codebase I should say |
| 07:01 |
Zeno` |
I'm aware that the compiler concatenates string literals |
| 07:01 |
hmmmm |
i'd prefer literal concatenation over an extra << personally |
| 07:01 |
hmmmm |
every time I see an extra << I remove it |
| 07:02 |
Zeno` |
ok, I was just copying the rest of the code. If you're actively removing them then it's silly for me to add them |
| 07:02 |
hmmmm |
the current code isn't a great indication of what the rest of the code should be :p |
| 07:02 |
Zeno` |
I know, but... yeah point taken |
| 07:03 |
hmmmm |
best thing to do is use the style of the surrounding code if you're modifying a small piece |
| 07:03 |
Zeno` |
I decided after that commit that that's what I'd do anyway |
| 07:03 |
Zeno` |
Mainly because the code style cleanup hid the important bits ;? |
| 07:03 |
Zeno` |
:/ |
| 07:04 |
Zeno` |
I was going to suggest something radical |
| 07:04 |
Zeno` |
that after 0.4.11 the entire codebase just be blindly forced through astyle or something heh |
| 07:04 |
Zeno` |
something like astyle -U -A3 --indent=force-tab=8 --min-conditional-indent=2 -f -p -H -k3 -W3 -xC100 -xL (which is not quite right yet) |
| 07:05 |
Zeno` |
but that's not important... fixing sizeof() |
| 07:06 |
hmmmm |
celeron would murder if minetest is run through astyle |
| 07:06 |
Zeno` |
Sounds fun |
| 07:06 |
Zeno` |
Why though? |
| 07:07 |
hmmmm |
i forget why |
| 07:07 |
Zeno` |
Surely it's better to draw a line in the sand and say "from now on this is the codestyle, stick to it". |
| 07:07 |
Zeno` |
umm, ok |
| 07:08 |
|
kilbith joined #minetest-dev |
| 07:08 |
|
Krock joined #minetest-dev |
| 07:12 |
Zeno` |
so sizeof should have the opening parenthesis hard against the operator (sizeof) to differentiate it from a function? |
| 07:12 |
Zeno` |
yeah |
| 07:12 |
Zeno` |
ok |
| 07:18 |
hmmmm |
grr |
| 07:18 |
hmmmm |
I find myself having to do this often: |
| 07:18 |
hmmmm |
class IFoobar {}; |
| 07:18 |
|
nore joined #minetest-dev |
| 07:19 |
hmmmm |
class ISomeInterface { public: virtual IFoobar *createFoobar() = 0; ... } |
| 07:19 |
hmmmm |
where I use it like: |
| 07:20 |
hmmmm |
class CFoobar { actual foobar things here; }; class CSomeThing : public ISomeInterface { CFoobar *createFoobar() { blah blah blah return new CFoobar; } } |
| 07:21 |
hmmmm |
why should I have to define a blank interface class that my foobars inherit from |
| 07:21 |
Zeno` |
style changes fixed |
| 07:22 |
hmmmm |
naturally, the interface should deal with void * |
| 07:22 |
hmmmm |
but alas I can't do that because of depreicated covariant return type |
| 07:22 |
Zeno` |
hmmmm, macro abuse time then? |
| 07:22 |
hmmmm |
and nevermind that, I'd have to still do an explicit cast to a CFoobar * because lol C++ has super annoyingly strong typing! |
| 07:23 |
hmmmm |
#1776 |
| 07:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/1776 -- Clean up code style of sockets and fix unit tests failing if IPv6 not available by Zeno- |
| 07:24 |
Zeno` |
? |
| 07:24 |
hmmmm |
well i just did that so i can get a link to click |
| 07:24 |
hmmmm |
yea looks good |
| 07:27 |
Zeno` |
from now on... updating code style. Just in the code immediately near changes? |
| 07:27 |
hmmmm |
yeah |
| 07:28 |
Zeno` |
ok |
| 07:28 |
hmmmm |
hmmm |
| 07:28 |
hmmmm |
see the problem is |
| 07:28 |
hmmmm |
i expose the data structure used to store some items publically |
| 07:29 |
hmmmm |
if someone wants to retrieve the size, they can do that, if they want to enumerate them, they can do that, etc. |
| 07:29 |
hmmmm |
but at their own risk, obviously they shouldn't do things like modify the container on their own and so on |
| 07:30 |
hmmmm |
this can't be done in a generic manner though - what if instead of std::vector, one manager type needs to store things as a std::map for whatever reason? |
| 07:30 |
hmmmm |
how does this get abstracted? by adding wrapper functions for all the attributes i mentioned earlier? |
| 07:31 |
hmmmm |
std::vector, std::list, std::map, so on, they're all containers and they all have iterators |
| 07:31 |
|
Hunterz joined #minetest-dev |
| 07:31 |
hmmmm |
hrmm |
| 07:33 |
Zeno` |
can't you wrap the "should be private" stuff in a struct and expose the struct instead (with a getThisIMeantToPrivateData() function)? Then there is no need to return new, you simply return a pointer to the private parts |
| 07:33 |
Zeno` |
in a generic manner would probably require templates though :( |
| 07:34 |
hmmmm |
yeah, I'm avoiding templates |
| 07:35 |
Zeno` |
I dunno. If a programmer is messing stuff that' |
| 07:35 |
Zeno` |
s suppose to private maybe it's best to trust them to correctly case a void* |
| 07:35 |
Zeno` |
cast |
| 07:37 |
hmmmm |
i find that i have much more success when i sit down and try to code uses of my interface before actually writing the interface |
| 07:37 |
hmmmm |
and i try to figure out how i actually want this to work |
| 07:38 |
Zeno` |
stub functions! |
| 08:45 |
|
Amaz joined #minetest-dev |
| 08:45 |
Zeno` |
hmmmm, I have quite a few warnings |
| 08:45 |
Zeno` |
with emerge changes |
| 08:46 |
Zeno` |
ugh, he's not here |
| 08:53 |
|
ImQ009 joined #minetest-dev |
| 08:53 |
|
Calinou joined #minetest-dev |
| 09:15 |
|
lag01 joined #minetest-dev |
| 09:21 |
|
CraigyDavi` joined #minetest-dev |
| 09:33 |
|
GrimKriegor joined #minetest-dev |
| 09:42 |
kilbith |
devs : recently I can't take a screenshot with F12 when I show the game console (F10) |
| 09:42 |
Calinou |
you can't take a screenshot if screenshot path doesn't exist |
| 09:42 |
Calinou |
create folders… :/ |
| 09:43 |
kilbith |
not at all |
| 09:43 |
kilbith |
the default path is /home/jp |
| 09:43 |
kilbith |
and it works when the game console is not shown |
| 09:43 |
kilbith |
Zeno`, nore ^ |
| 09:45 |
celeron55 |
hmmmm: astyle sucks |
| 09:45 |
Zeno` |
celeron55, why? |
| 09:45 |
celeron55 |
i tried using it in buildat |
| 09:45 |
celeron55 |
it's incapable of formatting anything well |
| 09:45 |
celeron55 |
then i moved to uncrustify |
| 09:45 |
Zeno` |
works fine for me |
| 09:45 |
celeron55 |
it's a bit better, but still sucks |
| 09:45 |
celeron55 |
then i implemented my own indenter that i run after unrcustify: https://github.com/celeron55/buildat/blob/master/util/cpp_indent.py |
| 09:46 |
celeron55 |
this combination gives a usable result for me |
| 09:46 |
Zeno` |
I can't think why it's necessary to re-invent the wheel though. What astyle options do you use? |
| 09:46 |
celeron55 |
with a couple of sed hacks: https://github.com/celeron55/buildat/blob/master/util/codestyle.sh#L76 |
| 09:46 |
Zeno` |
s/do you use/have you tried |
| 09:46 |
celeron55 |
it has almost zero options |
| 09:46 |
celeron55 |
it's not useful |
| 09:47 |
Zeno` |
zero options? |
| 09:47 |
Zeno` |
there are hundreds |
| 09:47 |
celeron55 |
https://github.com/celeron55/buildat/blob/master/util/uncrustify.cfg |
| 09:47 |
celeron55 |
check out uncrustify |
| 09:47 |
celeron55 |
this is more useful |
| 09:47 |
celeron55 |
but still sucks; it's unable to format C++ lambdas properly, for example |
| 09:47 |
celeron55 |
that's why i had to write my own indenter |
| 09:48 |
celeron55 |
and it's unable to indent stuff as i want; it doesn't have enough flexibility in terms of when it uses a tab and when it uses a space |
| 09:48 |
Zeno` |
when is a space used apart from alignment? |
| 09:49 |
celeron55 |
the issues are quite complex, i'm not going to try to explain |
| 09:49 |
Zeno` |
the lambda issue I'm not sure about |
| 09:49 |
celeron55 |
astyle doesn't have the lambda issue or the tab-space issue, but it has a lot of more basic flexibility issues |
| 09:50 |
celeron55 |
for example, astyle thinks that inside lambdas, pointers are multiplications |
| 09:50 |
celeron55 |
and you can't fix that |
| 09:50 |
Zeno` |
I'm not sure that without full lexical parsing any tool could |
| 09:51 |
celeron55 |
and it doesn't have proper options for indenting function parameters |
| 09:51 |
Zeno` |
Anyway, I didn't raise this to discuss astyle (astyle was an example) |
| 09:51 |
celeron55 |
uncrustify does a much better job at that |
| 09:51 |
celeron55 |
with a custom indenter, it's tolerable |
| 09:52 |
Zeno` |
The suggestion was: pick a fixed point in the future and run *something* to reformat the entire codebase |
| 09:52 |
Zeno` |
Whether it's astyle or uncrustify wouldn't really matter |
| 09:53 |
celeron55 |
anyway, my issue with these formatters has mostly been that they are incapable of a good enough result; but i *really* wanted to use one in buildat so i made a system that i can tolerate 8) |
| 09:53 |
Zeno` |
There will be issues that need manual fixing but surely it would be in a better state than it's now in with about 500 different styles :) |
| 09:53 |
Zeno` |
ok, maybe not 500 |
| 09:54 |
Zeno` |
It'd save time with people manually doing something that can be done 98-99% automatically (with some kind of auto formatter) |
| 09:54 |
celeron55 |
i'm fine with MT taking that system from buildat and using it; but it needs some tweaks to follow MT's current style |
| 09:54 |
Zeno` |
ok cool :) |
| 09:54 |
celeron55 |
it's a matter of just tweaking some uncrustify variables probably |
| 09:54 |
Zeno` |
most likely |
| 09:54 |
celeron55 |
i think MT uses a similar indentation that i use in buildat otherwise |
| 09:59 |
Zeno` |
my point really wasn't about the tool, but setting a specific time to do the automatic reformatting to save people wasting time (and really, it is) reformatting all the time as they go along |
| 10:04 |
Zeno` |
celeron55, are you against that idea totally? |
| 10:04 |
Zeno` |
I guess maybe it could cause issues with PRs :( |
| 10:06 |
celeron55 |
yes it breaks every PR, basically, and rebasing them will be almost impossible |
| 10:06 |
|
CraigyDavi joined #minetest-dev |
| 10:06 |
celeron55 |
or, hmm |
| 10:07 |
celeron55 |
actually, i think they can be rebased by running the formatter on the PR, then amending the formatted result to the pull request commit (one by one, starting from the first PR commit), and then rebasing it on master |
| 10:07 |
celeron55 |
i guess a tool could be made to do that |
| 10:08 |
Zeno` |
maybe |
| 10:25 |
|
jin_xi joined #minetest-dev |
| 10:36 |
|
CraigyDavi` joined #minetest-dev |
| 10:46 |
Megaf |
please, can someone help us with this? https://forum.minetest.net/viewtopic.php?p=159364&sid=101d1331ae848acd22067adb5754902f#p159364 |
| 10:46 |
Megaf |
oops |
| 10:47 |
Megaf |
https://forum.minetest.net/viewtopic.php?p=159364 |
| 10:47 |
Megaf |
^ |
| 10:47 |
Megaf |
Zeno`: kahrl: |
| 10:48 |
Zeno` |
Megaf, I mentioned warnings I got from that same file |
| 10:49 |
Zeno` |
need hmmm to look (pretty sure it's related to his commit) |
| 10:49 |
Megaf |
Yep, but on OS X that will not let us to have a minetest version |
| 10:49 |
Megaf |
ok |
| 10:49 |
Zeno` |
yeah, I am 100% sure he will fix the warnings once he wakes up ;) |
| 10:49 |
|
CraigyDavi`` joined #minetest-dev |
| 10:50 |
Zeno` |
well, it's not a warning on OSX is it... hehe |
| 10:50 |
Megaf |
OS X is a little more strict |
| 11:07 |
Zeno` |
Is there any reason why -Wall is not included as a compiler option for release builds? |
| 11:08 |
Zeno` |
It's not as if it slows down the build (most slowdowns will be from -O3 and the warnings are probably part of that anyway) |
| 11:09 |
Zeno` |
even if it did slow things down I dunno if it's a great idea to omit -Wall just because it's a release build |
| 11:10 |
Zeno` |
by slow things down I mean the time it takes to build/compile (not related to execution speed) |
| 11:14 |
Megaf |
I rather have a slow build and fast binary than the oposite |
| 11:16 |
|
PenguinDad joined #minetest-dev |
| 11:45 |
|
CraigyDavi joined #minetest-dev |
| 11:58 |
|
zat joined #minetest-dev |
| 12:04 |
kahrl |
Zeno`: I think your warnings are unrelated to Megaf's problem |
| 12:05 |
kahrl |
to fix the warnings (and probably a memleak), emerge.cpp needs to #include "mg_decoration.h" and "mg_ore.h" |
| 12:05 |
Zeno` |
not my warnings |
| 12:06 |
Zeno` |
and... those are the warnings |
| 12:07 |
kahrl |
that's trivial enough that I'll push that change in 30 minutes if noone is against that |
| 12:09 |
Zeno` |
yeah, cool |
| 12:09 |
kahrl |
about Megaf's problem... tbh at first sight that looks like a compiler bug |
| 12:12 |
Zeno` |
well, more likely an incomplete build |
| 12:12 |
Zeno` |
i.e. not cleaned |
| 12:12 |
kahrl |
possibly |
| 12:12 |
kahrl |
why would that happen though? |
| 12:14 |
kahrl |
I wasn't aware of that: "I'm hoping for an influx of new OSX people now that Minetest has been sold to Microsoft." o.O |
| 12:14 |
kahrl |
from Megaf's link |
| 12:15 |
sol_invictus |
Why would apple users care? |
| 12:15 |
Zeno` |
precompiled headers |
| 12:15 |
Zeno` |
it used to be part of settings.h |
| 12:16 |
Zeno` |
I get these strange things even on linux occasionally |
| 12:17 |
Zeno` |
so for whatever reason Settings::setU64() is referencing the old one (inlined code) rather than the new one |
| 12:18 |
kahrl |
still seems like a build system bug if precompiled headers aren't remade when the .h changes |
| 12:18 |
Zeno` |
except it wasn't inlined... hmmm |
| 12:18 |
Zeno` |
that's true |
| 12:20 |
Zeno` |
But as I said... I've seen similar issues on linux and windows so I'm not 100% sure |
| 12:20 |
Zeno` |
actually Krock had a similar issue a few weeks ago |
| 12:20 |
Krock |
hmm? |
| 12:20 |
Zeno` |
where the .o was not recompiled when it should have been |
| 12:21 |
Zeno` |
I can't remember which .o (or .obj) file it was but maybe you can Krock :) |
| 12:21 |
Krock |
settings.obj IIRC, but this was caused due the CmakeList.txt change and the partwise incemental building |
| 12:21 |
Zeno` |
yeah, so maybe it's similar on OSX? |
| 12:23 |
kahrl |
https://github.com/mdoege/mtmake-osx/blob/master/make_mac.sh <-- seems like he does a make clean every time though |
| 12:26 |
Zeno` |
funny that it seems to be from the same file though :/ |
| 12:35 |
|
CraigyDavi joined #minetest-dev |
| 12:36 |
Zeno` |
http://irc.minetest.ru/minetest-dev/2014-09-27#i_3946464 |
| 12:37 |
Zeno` |
maybe there is something missing from the cmake lists? |
| 12:40 |
Krock |
I wasted 2 hours with it. I better had started from scratch |
| 12:50 |
|
GhostDoge joined #minetest-dev |
| 13:09 |
|
Amaz joined #minetest-dev |
| 13:10 |
Megaf |
I almost always have to make clean before building, not doing so will result in compilation errors |
| 13:11 |
kahrl |
weird. I never have to do that |
| 13:11 |
Megaf |
Krock: Yep, it happened be twice that I had to make a totally new build, including a fresh git pull |
| 13:12 |
Megaf |
git clone* |
| 13:14 |
Zeno` |
Megaf, do out-of-source builds :p |
| 13:18 |
|
CraigyDavi` joined #minetest-dev |
| 13:24 |
|
Du_Draig joined #minetest-dev |
| 13:38 |
|
CraigyDavi joined #minetest-dev |
| 13:39 |
|
CraigyDavi joined #minetest-dev |
| 13:39 |
|
CraigyDavi joined #minetest-dev |
| 14:17 |
Zeno` |
kahrl, #1783 |
| 14:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/1783 -- Cleanup and (mostly) document util/string.h and (very) minor refactoring by Zeno- |
| 14:18 |
Zeno` |
also moved that function from game.cpp into there |
| 14:19 |
|
zat joined #minetest-dev |
| 14:32 |
Megaf |
Zeno`: https://github.com/minetest/minetest/issues/1790#issuecomment-61408778 |
| 14:32 |
Megaf |
Can we merge #1732 ? |
| 14:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/1732 -- Add (optional) client-side saving of server map to disk by sfan5 |
| 14:34 |
|
iqualfragile joined #minetest-dev |
| 14:34 |
Zeno` |
I can't merge Megaf |
| 14:35 |
Megaf |
CraigyDavi has a good point there |
| 14:35 |
Megaf |
https://github.com/minetest/minetest/pull/1732#issuecomment-58743850 |
| 14:35 |
CraigyDavi |
Yep, I don't really want people making copies of the map easily |
| 14:35 |
Megaf |
I think is perfect if that is an optional option in both client side and server side |
| 14:36 |
PenguinDad |
Megaf: that would be a totally useless setting |
| 14:36 |
CraigyDavi |
I know it can already be done using a modified client but this just easily supporting it in the game |
| 14:36 |
sol_invictus |
I think private maps is bullshit |
| 14:36 |
PenguinDad |
sol_invictus: +1 |
| 14:37 |
Megaf |
yep, some server already make it possible for people to download the whole map |
| 14:37 |
sol_invictus |
there were enough server taking the worlds down |
| 14:37 |
Megaf |
I want to implement something like that in my server too |
| 14:38 |
Megaf |
and I lost an epic server myself once |
| 14:38 |
Megaf |
I would love is somebody else had a copy of it |
| 14:40 |
Megaf |
I got to go now, but I hope #1732 is merged soon, if it doesnt introduce load or bugs. cya |
| 14:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/1732 -- Add (optional) client-side saving of server map to disk by sfan5 |
| 14:43 |
Krock |
<3 ^ |
| 14:47 |
Amaz |
<3 ^^ |
| 14:47 |
PenguinDad |
<3 ^^^ |
| 14:49 |
Zeno` |
<3 ^^^^ |
| 14:50 |
|
Taoki[laptop] joined #minetest-dev |
| 15:01 |
|
zat joined #minetest-dev |
| 15:07 |
iqualfragile |
asking again: the timestamps on the saved blocks: when is it updated? |
| 15:07 |
iqualfragile |
documentation says on save, but when do they get saved? only on change or after they were loaded |
| 15:07 |
iqualfragile |
because if its only on change that would be usefull for caching |
| 15:17 |
|
AnotherBrick joined #minetest-dev |
| 15:31 |
Krock |
Comments please. #1791 |
| 15:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/1791 -- Add factor of maximal player transfer distance by SmallJoker |
| 15:35 |
Amaz |
+1 |
| 15:41 |
|
kaeza joined #minetest-dev |
| 15:44 |
|
hmmmm joined #minetest-dev |
| 15:50 |
|
Miner_48er joined #minetest-dev |
| 15:58 |
|
casimir joined #minetest-dev |
| 16:09 |
|
Megaf_ joined #minetest-dev |
| 16:21 |
|
Amaz joined #minetest-dev |
| 16:28 |
|
iqualfragile joined #minetest-dev |
| 16:40 |
|
DuDraig joined #minetest-dev |
| 16:46 |
|
iqualfragile joined #minetest-dev |
| 16:51 |
kahrl |
derp, I said I'd merge something and then walked away |
| 16:51 |
kahrl |
well nobody complained so merge incoming |
| 16:53 |
VanessaE |
oh shit! NOOOOOOoooooooooooooo! not THAT! you'll open wormholes or something! |
| 16:53 |
VanessaE |
:) |
| 16:55 |
Megaf_ |
Hi all |
| 16:55 |
Megaf_ |
New comment on #1770 |
| 16:55 |
kahrl |
I'd love to open wormholes, but sadly I'm bad at physics ;) |
| 16:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/1770 -- Remove wield item camera clipping. |
| 16:55 |
Megaf_ |
ops |
| 16:55 |
Megaf_ |
wrong number |
| 16:55 |
Megaf_ |
#1687 |
| 16:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/1687 -- OSX - 0.4.10 - Assertion failed |
| 16:55 |
Megaf_ |
that one |
| 16:57 |
Megaf_ |
+1 to 1791 |
| 17:04 |
Krock |
:) |
| 17:05 |
|
selat joined #minetest-dev |
| 17:05 |
|
Calinou joined #minetest-dev |
| 17:08 |
Krock |
eww. is there actually no way to get an error message when an internal function is called wrongly? |
| 17:09 |
Krock |
example: minetest.set_node(1234, {name="air"}) |
| 17:09 |
VanessaE |
Krock: assert() ? |
| 17:09 |
VanessaE |
http://www.lua.org/pil/8.3.html |
| 17:10 |
VanessaE |
provided the engine throws an error in the first place. |
| 17:10 |
Krock |
VanessaE, the engine must throw errors instead of crashing. that's te target |
| 17:10 |
Krock |
*the |
| 17:10 |
sol_invictus |
VanessaE: can you optimize textures in homedecor pack? |
| 17:10 |
VanessaE |
sol_invictus: wrong channel. |
| 17:10 |
VanessaE |
they have, however, been pngcrush'd at least once recently. |
| 17:11 |
Krock |
optipng? |
| 17:11 |
VanessaE |
Krock: well the thing is, what should the engine do after throwing the error? |
| 17:11 |
sol_invictus |
convert -strip |
| 17:11 |
sol_invictus |
I want also |
| 17:11 |
VanessaE |
optipng is for windows. |
| 17:11 |
Krock |
VanessaE, okay. it should crash AND sending an error. |
| 17:12 |
VanessaE |
sol_invictus: pngcrush already does that. |
| 17:12 |
VanessaE |
Krock: in which case, you just meant that the engine just fails to throw an error in that particular corner case? I don't see why it can't be made to do so. |
| 17:13 |
Calinou |
OptiPNG is for all OS |
| 17:13 |
Krock |
VanessaE, yeah. I meant there should be error messages if there are wrong arguments. |
| 17:14 |
Calinou |
http://optipng.sourceforge.net/ |
| 17:14 |
VanessaE |
Krock: I can certainly agree with that. in fact I'm surprised it doesn't already throw an error for that, along the lines of "table expected, got xxx" |
| 17:14 |
|
zat joined #minetest-dev |
| 17:14 |
VanessaE |
Calinou: hm, the home page only has builds for windows, source code, and no mentions of linux. no matter, pngcrush is adequate. |
| 17:15 |
Calinou |
I'm running it fine on Windows and GNU/Linux systems (Hg build) |
| 17:15 |
Calinou |
I use it to compress Carbone's textures and texture packs |
| 17:15 |
Calinou |
(-o6 -zm1-9 -strip all) |
| 17:20 |
|
iqualfragile joined #minetest-dev |
| 17:20 |
|
nore joined #minetest-dev |
| 17:20 |
|
kahrl joined #minetest-dev |
| 17:22 |
VanessaE |
sol_invictus: done. |
| 17:23 |
sol_invictus |
VanessaE: thanks |
| 17:25 |
sol_invictus |
I'm not sure but it looks like something went wrong |
| 17:25 |
kilbith |
yes indeed |
| 17:26 |
VanessaE |
yeah |
| 17:26 |
* VanessaE |
resets --hard and pushes -f |
| 17:26 |
VanessaE |
my script did something stupid. |
| 17:26 |
sol_invictus |
yeah, blame the script :D |
| 17:27 |
VanessaE |
no, I blame the dipshit who wrote it :) |
| 17:27 |
VanessaE |
why are we talking about this in here? |
| 17:27 |
VanessaE |
go over to #minetest |
| 17:28 |
sol_invictus |
it's empty anyway |
| 17:28 |
sol_invictus |
like someone is doing anything on the core |
| 17:29 |
kahrl |
sol_invictus: I was but freenode ate my messages :( |
| 17:29 |
VanessaE |
offtopic for here. |
| 17:29 |
kahrl |
good ol' netsplit |
| 17:30 |
sol_invictus |
okay, taking it back |
| 17:32 |
|
Warr1024 joined #minetest-dev |
| 17:49 |
|
jin_xi joined #minetest-dev |
| 17:55 |
|
zat joined #minetest-dev |
| 18:07 |
celeron55 |
http://fpaste.org/147260/51638141/ |
| 18:07 |
celeron55 |
any takers? |
| 18:08 |
Calinou |
how much does he have to buy us? |
| 18:08 |
celeron55 |
i don't even know what anyone could possibly answer to this; it's like "oh yes, we know this thing has at least 291 issues; could you possibly fix them instead of reporting new ones?" |
| 18:11 |
|
zat joined #minetest-dev |
| 18:14 |
celeron55 |
i can answer something like "Feel free to do whatever you like. Expect nobody to have time to help you though, and make sure you know of https://github.com/minetest/minetest/issues. Feel free to hang out on our IRC channels (http://minetest.net/IRC)." |
| 18:14 |
|
zat2 joined #minetest-dev |
| 18:17 |
Calinou |
“Expect nobody to have time to help you though†|
| 18:17 |
Calinou |
this is a problem |
| 18:17 |
Calinou |
and exactly why you should not expect more contributors |
| 18:17 |
celeron55 |
i posted this here so i can see if anyone wants to make use of this and do stuff with them |
| 18:18 |
celeron55 |
i'll wait until, say, tomorrow morning |
| 18:18 |
|
MinetestForFun joined #minetest-dev |
| 18:19 |
celeron55 |
i'm not going to answer them that someone will be assigned to help them if nobody actually is interested at all |
| 18:19 |
celeron55 |
because that would be lying and stupid |
| 18:24 |
hmmmm |
celeron, I got that same email but I was under the impression they were going to write back later |
| 18:24 |
hmmmm |
see the problem isn't that our process sucks, it's that we don't have anybody willing to do QA work |
| 18:25 |
hmmmm |
I know precisely what we need to do, but have no time to do it |
| 18:25 |
hmmmm |
i have a finite amount of time to work on minetest so I'd rather pay down my debt by working on the mapgen rather than writing tests for code |
| 18:27 |
Krock |
@the email, no comment. if they want to help to develop this project, they can do so. |
| 18:27 |
celeron55 |
so, really, we should ask them to figure out efficient ways to do QA in the long run |
| 18:28 |
celeron55 |
and to not really focus on any kind of "do huge amount of work to get every small bug fixed" thing, whatever that might be |
| 18:29 |
celeron55 |
and to consider these things in the context of a lazy open source organization like MT's |
| 18:29 |
hmmmm |
perhaps there should be a month where we put everything on hold and we just write unit tests |
| 18:29 |
hmmmm |
and/or documentation |
| 18:30 |
hmmmm |
we'll call it the "pay down technical debt release" |
| 18:31 |
|
Calinou joined #minetest-dev |
| 18:31 |
hmmmm |
could you please not do that |
| 18:32 |
Krock |
hmmmm, I thought I've sent MTB a !tell task and saw just now, that's you |
| 18:32 |
hmmmm |
the reason for the different nicknames is that "hmmmm" is a fine IRC nick but not too great for communication with real life people |
| 18:32 |
celeron55 |
what kind of unit tests do you expect there to be use for |
| 18:33 |
hmmmm |
mapgen shit. |
| 18:33 |
Krock |
whatever. my question was about adding the (no)ease parameter to the lua api |
| 18:33 |
hmmmm |
Krock: yes, all this within due time. |
| 18:33 |
Krock |
oke. |
| 18:33 |
celeron55 |
i mean, unit tests can be written for anything, but they don't make sense for everything, eg. for things that will not stay static in the long run |
| 18:33 |
hmmmm |
the current shim was to resurrect mapgen v5 without having to wait on me |
| 18:34 |
hmmmm |
celeron, one good unit test would be for noise |
| 18:34 |
hmmmm |
test to make sure bulk-calculation map functions == point value noise functions == some statically calculated known-good set of values |
| 18:34 |
celeron55 |
unit tests should be written for things that should stay the same, and are in the danger of easily accumulating hard-to-notice regressions |
| 18:35 |
hmmmm |
mapgen too |
| 18:35 |
celeron55 |
so, noise seems to be one for sure |
| 18:35 |
hmmmm |
hard code in a 3d chunk of expected content and make sure the thing is dynamically generated correctly |
| 18:35 |
hmmmm |
schematics |
| 18:35 |
hmmmm |
oh god, i need this horribly |
| 18:36 |
Krock |
please do not neglect the 3rd goal, Profit! |
| 18:36 |
Krock |
:3 |
| 18:36 |
hmmmm |
there are lots of things like formspec that desperately need testing but can't be automated easily at all |
| 18:38 |
hmmmm |
voxelmanip should have unit tests |
| 18:39 |
sfan5 |
travis-ci should run the existing testsw |
| 18:39 |
sfan5 |
-w |
| 18:39 |
sfan5 |
it would also be nice to have travis build win{32,64} using the buildbot scripts |
| 18:41 |
|
Miner_48er joined #minetest-dev |
| 18:46 |
|
Anchakor_ joined #minetest-dev |
| 18:54 |
Krock |
this is annoying. I'm getting server crashes and no error log. I think that's releated to the core lua functions |
| 19:00 |
hmmmm |
in any case I just responded to those people |
| 19:00 |
hmmmm |
tl;dr "we have a couple ideas on how to do this already, not enough manpower, etc." |
| 19:01 |
hmmmm |
"but we appreciate any help!" |
| 19:01 |
Calinou |
the problem is you expect perfect manpower |
| 19:01 |
Calinou |
you basically expect a distorted version of yourself |
| 19:04 |
hmmmm |
i already have a full time job |
| 19:04 |
hmmmm |
really wish I could clone our current development team |
| 19:06 |
Krock |
and both teams do the same at the same time and in the same speed |
| 19:09 |
PenguinDad |
Krock: no they work at the exact opposite time ;) |
| 19:17 |
|
iqualfragile joined #minetest-dev |
| 19:21 |
|
nore joined #minetest-dev |
| 19:26 |
celeron55 |
hmmmm: ok |
| 19:26 |
hmmmm |
huh?? |
| 19:26 |
celeron55 |
if you replied, i don't need to reply |
| 19:26 |
hmmmm |
oh oh. |
| 19:27 |
hmmmm |
man we should have a mailing list. |
| 19:29 |
Calinou |
lol… no |
| 19:29 |
Calinou |
mailing lists are a thing of the 90s |
| 19:29 |
hmmmm |
are you kidding? all the hip open source projects have mailing lists |
| 19:29 |
hmmmm |
and we'll spell our our email addresses like... kwolekr _AT_ minetest DOT net |
| 19:29 |
|
paramat joined #minetest-dev |
| 19:30 |
hmmmm |
lol |
| 19:30 |
hmmmm |
spell out our* |
| 19:30 |
hmmmm |
I still want to rename minetest to something that sounds better in english |
| 19:32 |
Calinou |
“the hip†|
| 19:32 |
Calinou |
mostly old stuff… |
| 19:32 |
Krock |
\o/ more issues! |
| 19:32 |
Calinou |
projects > 10 year sold |
| 19:32 |
Calinou |
mailing lists are a troll paradise too |
| 19:32 |
Calinou |
they're hard as hell to browse, unuser friendly |
| 19:32 |
Calinou |
we have forums for a reason |
| 19:32 |
Calinou |
which killed mailing lists |
| 19:32 |
Calinou |
and doesn't spam your e-mail inbox or has anti-spam issues all the time |
| 19:35 |
kilbith |
"forums" and mailing lists have always existed simultaneously, Calinou |
| 19:36 |
kilbith |
me, at least, i used internet during the 90s ;) |
| 19:37 |
paramat |
hmmmm, where in core mapgen code is perlinmap edge lengths set? can't find it. my method for fixing discontinuities at mapchunk borders is to use a perlinmap that extends 1+ nodes beyond the mapchunk |
| 19:37 |
PenguinDad |
I wasn't even alive in the 90s :D |
| 19:38 |
kahrl |
and already a dad? :O |
| 19:38 |
Calinou |
the dad of a penguin |
| 19:39 |
hmmmm |
huuh |
| 19:39 |
hmmmm |
the dimensions of the perlin noise map buffer? |
| 19:39 |
hmmmm |
you set those in the constructor |
| 19:39 |
hmmmm |
you can change them any time after creation with Noise::setSize() |
| 19:39 |
kahrl |
I do appreciate when a project has an -announce mailing list (e.g. I'm on the mediawiki-announce list so I know when to update) but other than that I don't use them |
| 19:39 |
paramat |
oh okay, must have missed that |
| 19:39 |
|
diemartin joined #minetest-dev |
| 19:41 |
PenguinDad |
kahrl: penguins have a shorter lifespan than humans :P |
| 19:43 |
paramat |
i guess the 'constructor' is 'MapgenV7::MapgenV7(int mapgenid, MapgenParams *params, EmergeManager *emerge)' and the line i missed was 'this->csize = v3s16(1, 1, 1) * params->chunksize * MAP_BLOCKSIZE;'. okay thanks! |
| 19:43 |
hmmmm |
I mean you pass the dimensions to the Noise cto |
| 19:43 |
hmmmm |
ctor |
| 19:44 |
hmmmm |
it just so happens that you create the noise objects in the mapgen ctor as well |
| 19:45 |
paramat |
okay |
| 19:53 |
jin_xi |
+1 for mailing list. Its a tool for developers, forum is for different conversations |
| 19:54 |
|
shadowzone joined #minetest-dev |
| 19:55 |
|
Miner_48er joined #minetest-dev |
| 20:12 |
kahrl |
since the the_game refactoring, Camera::wield is called every frame |
| 20:12 |
kahrl |
that's because update_wielded_item_trigger is now set to true every frame |
| 20:13 |
hmmmm |
whoops |
| 20:13 |
hmmmm |
that's not a performance hit or anything |
| 20:16 |
|
hintss joined #minetest-dev |
| 20:18 |
|
Chicken_shadow joined #minetest-dev |
| 20:21 |
kahrl |
seems Camera::wield is fast enough that it doesn't have any huge effect |
| 20:21 |
kahrl |
but then we could just get rid of update_wielded_item_trigger |
| 20:35 |
hmmmm |
reminds me of that Sony PS2 optimization guide that's pretty helpful for all game development |
| 20:36 |
hmmmm |
some things you think are 'optimizations', such as caching some calculation, turns out to actually be much slower overall due to cache misses and all that |
| 20:36 |
hmmmm |
crap you won't find without a profiler |
| 20:36 |
hmmmm |
i'm not saying Camera::wield() is fast enough to be called without caching since i never even looked at that function, i'm just saying it's possible. |
| 20:37 |
|
cg72 joined #minetest-dev |
| 20:41 |
|
blaaaaargh joined #minetest-dev |
| 20:43 |
celeron55 |
it's not surprising that understanding the computer architecture that we are using is required for making optimal stuff for it :P |
| 20:45 |
hmmmm |
it's impossible to understand the architecture we're using. it's too complex |
| 20:45 |
hmmmm |
experimentation seems to be the way to go |
| 20:46 |
celeron55 |
it seems like almost nothing else matters than the main memory cache |
| 20:46 |
celeron55 |
it makes such a large difference |
| 20:47 |
celeron55 |
so, the first rule of programming for anything more complex than a 8-bit MCU with static RAM is to make sure you aren't randomly accessing the RAM |
| 20:47 |
celeron55 |
which is, let's say, somewhat ironic |
| 20:47 |
celeron55 |
but anyway 8) |
| 20:50 |
hmmmm |
:/ |
| 20:50 |
hmmmm |
never mind optimizing |
| 20:50 |
hmmmm |
i need to focus on designing how this api is going to work |
| 20:51 |
kahrl |
huh, the mouse wheel no longer lets you scroll from the last hotbar item to the first |
| 20:52 |
|
shadowzone joined #minetest-dev |
| 20:53 |
kahrl |
was also introduced with the the_game refactoring |
| 20:55 |
kahrl |
https://gist.github.com/kahrl/c416594c2e20841e93f4 pushing in a few minutes |
| 20:56 |
hmmmm |
what about the camera wield |
| 20:57 |
kahrl |
hmmmm: will fix that together with introducing the WieldMeshSceneNode |
| 20:57 |
hmmmm |
ahh |
| 20:57 |
kahrl |
well, "fix" meaning Camera::wield will be even faster when item doesn't change |
| 20:57 |
hmmmm |
lol people on #minetest are crying about how mapgen v7 doesn't 'have' anything aside from stone |
| 20:57 |
kahrl |
heh |
| 20:57 |
hmmmm |
i had it hidden from the settings menu |
| 20:57 |
hmmmm |
but people used it anyway |
| 21:31 |
|
zat joined #minetest-dev |
| 21:32 |
|
CraigyDavi` joined #minetest-dev |
| 21:57 |
|
CraigyDavi joined #minetest-dev |
| 21:57 |
|
CraigyDavi joined #minetest-dev |
| 21:59 |
Megaf_ |
[18:07:23] <celeron55> any takers? |
| 21:59 |
Megaf_ |
we could talk to Zeno about that |
| 21:59 |
Megaf_ |
he is already improving minetest a lot |
| 22:01 |
Megaf_ |
anyway, a good reply to that email could be: "Feel free to fork our project, read the code and help us fix our issues." |
| 22:08 |
|
zat joined #minetest-dev |
| 22:15 |
|
paramat left #minetest-dev |
| 22:15 |
|
doublej472 joined #minetest-dev |
| 22:16 |
|
zat joined #minetest-dev |
| 22:30 |
|
shadowzone joined #minetest-dev |
| 23:08 |
|
shadowzone joined #minetest-dev |
| 23:13 |
|
Warr1024 left #minetest-dev |
| 23:13 |
|
Chicken_shadow joined #minetest-dev |
| 23:33 |
|
zat joined #minetest-dev |
| 23:52 |
|
iqualfragile joined #minetest-dev |
| 23:57 |
|
kaeza joined #minetest-dev |
| 23:58 |
|
CraigyDavi` joined #minetest-dev |
