| Time |
Nick |
Message |
| 00:00 |
est31 |
ah this is weird stuff |
| 00:00 |
est31 |
(again) |
| 00:00 |
est31 |
I am counting six attachement events in total |
| 00:01 |
est31 |
first two to *somewhere* |
| 00:01 |
est31 |
then two events for the wielditem I guess |
| 00:01 |
est31 |
then two again to somewhere |
| 00:02 |
est31 |
those two for the wielditem stick out because their position isn't "0,0,0" |
| 00:02 |
est31 |
but 0.2,5.5,3 |
| 00:02 |
est31 |
and because the m_is_local_player field is set for the parent object |
| 00:03 |
est31 |
so the weird thing is that when I count the m_children map for the local player, |
| 00:03 |
est31 |
(when the f7 key is pressed) |
| 00:03 |
est31 |
I dont find any wielditem sao |
| 00:03 |
est31 |
cao* |
| 00:03 |
est31 |
only two caos with 0,0,0 |
| 00:04 |
est31 |
true chaos |
| 00:07 |
est31 |
whats even weirder is that m_is_player is true both for the playercao object and the object we attach the wielditem to |
| 00:09 |
est31 |
and m_is_local_player too |
| 00:10 |
kahrl |
are they different objects? |
| 00:11 |
est31 |
one has id 1 the other has id 2 |
| 00:11 |
kahrl |
huh. |
| 00:16 |
est31 |
my theory is that it has two caos one that gets set by the server and one local one |
| 00:16 |
est31 |
but its only a theory without any proof |
| 00:28 |
|
NakedFury joined #minetest-dev |
| 00:31 |
kahrl |
another weird thing... why the hell is there an m_id in GenericCAO? that shadows the m_id that already exists in the base class ActiveObject? |
| 00:32 |
est31 |
this seriously needs some cleanup |
| 00:48 |
est31 |
ok sorry there is only one cao |
| 00:48 |
est31 |
(for the player) |
| 01:00 |
est31 |
finally |
| 01:00 |
est31 |
https://github.com/est31/minetest/commit/40226e52747156cbdc5128a416480b226e498fff |
| 01:23 |
VanessaE |
est31: works. |
| 01:24 |
est31 |
https://github.com/est31/minetest/commit/ccdf4805664c650c81e420fdbccca80e5ba1f498 |
| 01:24 |
est31 |
pushing in 5 minutes |
| 01:24 |
est31 |
VanessaE, still I wonder how xanadu server did it |
| 01:25 |
est31 |
because there is a small bug with this mod: when a player walks, the wielded item isn't shown at the hand |
| 01:25 |
est31 |
but when the player walks + mouse is pressed, then it works again |
| 01:27 |
VanessaE |
it used to be that if you moved fast, the entity would "lag behind" the player |
| 01:27 |
est31 |
perhaps I add the m_id removal to |
| 01:27 |
VanessaE |
but it would catch up at least. |
| 01:27 |
est31 |
that shouldnt be |
| 01:27 |
* VanessaE |
checks it |
| 01:28 |
VanessaE |
oh weird |
| 01:28 |
VanessaE |
this might be a bug in wield3d, but the wielded item switches hands when you walk backward |
| 01:29 |
VanessaE |
or forward. |
| 01:29 |
est31 |
yes this is what I thought too |
| 01:29 |
est31 |
xanadu doesnt have that bug though |
| 01:29 |
VanessaE |
no apparent movement lag though |
| 01:29 |
est31 |
ask tenplus1 how he did it :) |
| 01:29 |
VanessaE |
so that particular bug is fixed |
| 01:29 |
est31 |
no it isnt |
| 01:29 |
VanessaE |
? |
| 01:29 |
est31 |
I've checked and yes there was lag |
| 01:29 |
VanessaE |
odd, I don't see it here |
| 01:29 |
est31 |
its larger when you enable fast |
| 01:30 |
VanessaE |
oh now I see it |
| 01:31 |
est31 |
which part of "attached to" doesnt it understand |
| 01:31 |
VanessaE |
doesn't happen with a pick, but it does when wielding a block |
| 01:31 |
est31 |
does the server really send all "move object X which is atttached to Y to position Z, where Y is" |
| 01:32 |
VanessaE |
I believe so. |
| 01:32 |
est31 |
thats horribly stupid |
| 01:35 |
VanessaE |
well the packet stream increases greatly when moving, anyways |
| 01:35 |
VanessaE |
way more than I'd expect for just simple player movement in a singleplayer world |
| 01:37 |
VanessaE |
you should see the packet stream if I roll my mouse wheel back and forth across a full hotbar. |
| 01:41 |
est31 |
and pushing too: https://github.com/minetest/minetest/pull/2806 |
| 01:41 |
VanessaE |
the wielded entity flipping to the other side while moving must be client-side. it reacts too fast to be server-side. |
| 01:42 |
est31 |
yup |
| 01:42 |
VanessaE |
wait, |
| 01:42 |
est31 |
flipping and moving |
| 01:42 |
VanessaE |
isn't there a flag that causes an entity to automatically flip directions when it moved? |
| 01:42 |
VanessaE |
moves* |
| 01:43 |
est31 |
? |
| 01:43 |
VanessaE |
automatic_face_movement_dir = 0.0, |
| 01:43 |
VanessaE |
in the entity def. |
| 01:44 |
VanessaE |
("offset in degrees; false to disable") |
| 01:45 |
VanessaE |
that flag is not set in this mod |
| 01:45 |
est31 |
yes with reasons |
| 01:45 |
est31 |
or not |
| 01:45 |
est31 |
? |
| 01:45 |
VanessaE |
I'm not sure; the API doesn't actually say what the default state is. |
| 01:45 |
est31 |
because its flipping not just in its "real" movement direction |
| 01:45 |
VanessaE |
(I assume it is "0.0" as implied) |
| 01:46 |
est31 |
but rather in its "around the shoulder" movement direction |
| 01:46 |
VanessaE |
right |
| 01:46 |
est31 |
e.g. if you walked sideways it would flip sideways too |
| 01:46 |
est31 |
which is bad |
| 01:47 |
VanessaE |
it doesn't do that in this case though |
| 01:47 |
VanessaE |
it just does a 180 rotate around to the "back" side of the model on any kind of movement, even sideways |
| 01:48 |
est31 |
but xanadu has somehow managed to avoid this |
| 01:51 |
* VanessaE |
shrugs |
| 01:54 |
VanessaE |
it's also notable that the entity is displayed upside down if it doesn't have a custom property in location.lua (probably a mod bug) |
| 01:55 |
VanessaE |
this mod actually DOES set the location of the entity as the player moves |
| 01:55 |
VanessaE |
that would explain the lag. |
| 01:59 |
VanessaE |
hm, nope. doesn't explain me |
| 01:59 |
VanessaE |
s/me/it/ |
| 01:59 |
* VanessaE |
shrugs |
| 01:59 |
hmmmm |
https://github.com/est31/minetest/commit/40226e52747156cbdc5128a416480b226e498fff#diff-722710b5ecd9db42e7dd785dd517e186R733 |
| 01:59 |
hmmmm |
why do you do this |
| 02:00 |
hmmmm |
isn't it a rule |
| 02:00 |
hmmmm |
iterators need to be pre-incremented unless it's actually necessary (i.e. delete-element-while-iterating idiom) |
| 02:00 |
hmmmm |
also why use an iterator for std::vector |
| 02:00 |
hmmmm |
array bracket[i] notation is preferred there |
| 02:00 |
hmmmm |
much more natural |
| 02:02 |
est31 |
you mean ++c?? |
| 02:03 |
est31 |
how is that more natural |
| 02:03 |
hmmmm |
no, std::array foobar; foobar[i] = 5; |
| 02:04 |
hmmmm |
++c is faster |
| 02:04 |
est31 |
why that |
| 02:05 |
est31 |
but noted next time I use size_t |
| 02:05 |
est31 |
or whatever type a vector size has |
| 02:07 |
kahrl |
also shouldn't getId() be removed from m_children of the previous parent? |
| 02:09 |
kahrl |
wait not there |
| 02:09 |
est31 |
but near here you mean: |
| 02:09 |
kahrl |
I mean in the GENERIC_CMD_SET_ATTACHMENT handler, of course |
| 02:09 |
est31 |
https://github.com/minetest/minetest/commit/dd91b3d6fbc3a0b4b18b36b14864d703213dd622#diff-722710b5ecd9db42e7dd785dd517e186R1671 |
| 02:10 |
est31 |
yea perhaps |
| 02:10 |
est31 |
also not removed when the entity is deleted or how thats called |
| 02:10 |
kahrl |
yeah |
| 02:11 |
hmmmm |
est31: postincrementing an iterator makes a copy of the iterator |
| 02:11 |
kahrl |
I guess that wasn't necessary before since every loop over m_children checked if the child's actual parent id == getId() |
| 02:12 |
kahrl |
but setChildrenVisible doesn't |
| 02:12 |
hmmmm |
pre or post incrementing an iterator on the other hand is just as fast in nearly all circumstances |
| 02:12 |
hmmmm |
an integr* |
| 02:12 |
hmmmm |
integer** |
| 02:12 |
est31 |
hmmmm, does it do the copy also when the copied iterator isnt used then? |
| 02:12 |
hmmmm |
yes |
| 02:12 |
est31 |
also if the compiler isnt stupid? |
| 02:13 |
est31 |
(== optimizeds) |
| 02:13 |
est31 |
-d |
| 02:13 |
hmmmm |
the compiler can't be un-stupid because it's a function call |
| 02:13 |
hmmmm |
operator overloading and all that goood stuff |
| 02:13 |
est31 |
ah |
| 02:13 |
est31 |
yea |
| 02:29 |
|
paramat joined #minetest-dev |
| 02:31 |
paramat |
https://github.com/minetest/minetest/pull/2805 'Mapgen objects: Enable heatmap, humidmap for all biome api mapgens' is fixed and will push soon |
| 03:13 |
paramat |
now pushing |
| 03:21 |
paramat |
complete |
| 04:21 |
|
Hijiri joined #minetest-dev |
| 04:48 |
paramat |
https://github.com/minetest/minetest/pull/2789 'Mgv7: Edit noise parameters' my suggestion for further improvement, might push later if acceptable, back later |
| 04:48 |
|
paramat left #minetest-dev |
| 05:49 |
|
Robby joined #minetest-dev |
| 05:55 |
est31 |
gonna push #2807 if building succeeds |
| 05:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/2807 -- Android: use loop inside makefile to spare repetition by est31 |
| 05:55 |
est31 |
already built locally |
| 06:06 |
|
NakedFury joined #minetest-dev |
| 06:07 |
|
Calinou joined #minetest-dev |
| 06:34 |
VanessaE |
will someone PLEASE fix copy&paste on linux?? |
| 06:34 |
VanessaE |
(particularly, pasting into minetest from the outside) |
| 06:36 |
|
Krock joined #minetest-dev |
| 06:37 |
est31 |
you mean this http://sourceforge.net/p/irrlicht/bugs/247/ |
| 06:38 |
VanessaE |
"closed-fixed"... |
| 06:39 |
VanessaE |
and noting this was allegedly fixed a year ago, why isn't MT using whatever function it is that's needed? |
| 06:39 |
est31 |
the last stable release of irrlicht was 2013 |
| 06:40 |
VanessaE |
yeah but check the dates: 2009-06-24, marked as fixed |
| 06:40 |
est31 |
i guess this is one of the "wait for 1.9 whenever that will be" bugs |
| 06:40 |
|
nore joined #minetest-dev |
| 06:43 |
VanessaE |
what I'm saying is those dates imply that this was fixed long before the most recent stable release of irrlicht |
| 06:51 |
VanessaE |
(I got "a year ago" from the header of the bug report) |
| 06:57 |
|
nore joined #minetest-dev |
| 06:57 |
est31 |
VanessaE, do you have kde? |
| 06:58 |
VanessaE |
nope. |
| 06:58 |
VanessaE |
xfce here |
| 06:58 |
est31 |
it works when you paste from konsole ctrl+shift+c |
| 06:58 |
est31 |
but only on the second time |
| 06:59 |
|
cheapie joined #minetest-dev |
| 07:03 |
VanessaE |
there was one really obscure way I was able to paste into minetest, once, ages ago. |
| 07:03 |
VanessaE |
forgot what it was though |
| 07:03 |
est31 |
I just dont know how it can be our fault |
| 07:04 |
est31 |
VanessaE, try adding printf( "char: %s \r\n", p); to intlGuieditbox.cpp line 388 |
| 07:04 |
est31 |
you will see it will be empty when pasting from outside |
| 07:05 |
VanessaE |
I believe you - but that doesn't answer the question of *why* it's empty.. |
| 07:05 |
est31 |
VanessaE, thats an irrlicht-internal function call |
| 07:05 |
est31 |
I've traced it down to some x11 voodoo |
| 07:30 |
VanessaE |
oh and fwiw I do recall last time I *really* needed it, I also tried using a clipboard manager. |
| 07:30 |
VanessaE |
didn't work |
| 07:30 |
VanessaE |
and now that I think about it, what I thought DID work was probably not an xfce feature (might have been gnome or something) |
| 07:31 |
VanessaE |
and I've read that for those people that are able to use it, it sometimes causes the program that supplied the text (e.g. an editor or terminal) to crash when you paste. |
| 07:33 |
est31 |
the real problem is the people using programs along minetest |
| 07:33 |
est31 |
"thou shalt not have a program beside be" |
| 07:33 |
VanessaE |
well not really |
| 07:33 |
est31 |
me* |
| 07:34 |
VanessaE |
think of it more like using gedit to manage a large code snippet to be used in mesecons Lua Controller |
| 07:34 |
VanessaE |
or copying/pasting from a web page into a LuaC. |
| 07:34 |
est31 |
just stopping copyright infringement! |
| 07:34 |
VanessaE |
heh |
| 07:46 |
nore |
I was wondering... since it's only on Linux that it doesn't work, what about adding some X11 magic if it is compiled to Linux instead of using Irrlicht? |
| 07:46 |
VanessaE |
that's what I was wondering |
| 07:51 |
est31 |
irrlichts (failing) x11 magic is done here http://code.metager.de/source/xref/irrlicht/source/Irrlicht/CIrrDeviceLinux.cpp |
| 07:51 |
est31 |
CIrrDeviceLinux::getTextFromClipboard() |
| 07:52 |
est31 |
and can be "patched" from inside minetest from the code I've spoken before |
| 07:52 |
est31 |
intlGuieditbox.cpp line 387 |
| 07:52 |
est31 |
good luck |
| 08:01 |
est31 |
arrgh |
| 08:01 |
|
Yepoleb_ joined #minetest-dev |
| 08:01 |
est31 |
I'm planing on to add a new inventory action to make shift-click moving fast |
| 08:01 |
est31 |
but now I see I have to do rollback handling for this too |
| 08:01 |
est31 |
grr |
| 08:01 |
est31 |
r |
| 08:01 |
est31 |
r |
| 08:02 |
est31 |
rrr |
| 08:04 |
|
Hunterz joined #minetest-dev |
| 08:27 |
|
selat joined #minetest-dev |
| 08:52 |
|
CraigyDavi joined #minetest-dev |
| 09:26 |
est31 |
ok again one of those "make life easy for modders vs give modders flexibility question" |
| 09:26 |
est31 |
there is the allow_metadata_inventory_move callback |
| 09:26 |
est31 |
it has a to_index parameter |
| 09:26 |
est31 |
dunny why but it has one |
| 09:26 |
est31 |
now I want to add a "add to somewhere" action |
| 09:26 |
est31 |
I'm stuck in middle |
| 09:27 |
est31 |
question: |
| 09:27 |
est31 |
should I leave the to_index param |
| 09:27 |
est31 |
and make calls for every single of the possible indexes |
| 09:27 |
est31 |
(where it makes sense) |
| 09:27 |
est31 |
so simulating current behaviour |
| 09:28 |
est31 |
(just without network lag) |
| 09:28 |
est31 |
or should I make "one big" interaction |
| 09:28 |
est31 |
setting to_index simply to nil, or something |
| 09:31 |
nore |
I'd say that while we have no client-side code, just one per list would be enough |
| 09:33 |
est31 |
how would that change with client side code? |
| 09:36 |
est31 |
I guess ill put it in a loop |
| 09:37 |
nore |
wait, you don't mean client prediction? |
| 09:37 |
est31 |
no |
| 09:37 |
nore |
I thought it was client prediction for actions like shift+click that would need it... |
| 09:38 |
nore |
hm... |
| 09:39 |
est31 |
yea putting it in a loop is the best thing |
| 09:39 |
est31 |
because after the move we have all these "report" methods |
| 09:39 |
est31 |
and rollback |
| 09:39 |
est31 |
and so on |
| 09:40 |
est31 |
so the report methods will definitely want to have the to_index |
| 09:40 |
est31 |
otherwise they start guessing |
| 09:40 |
est31 |
and thats bad |
| 09:40 |
est31 |
because I want to be abled to change behaviour in future |
| 09:40 |
est31 |
and not break mods :) |
| 09:40 |
nore |
guessing is always bad :) |
| 10:00 |
est31 |
ahhh kde 5 i like you when you freeze kate when you reload a window for a file that is also opened in another tab and has changed from that tab |
| 10:00 |
est31 |
weirdly that freezing stops after some time |
| 10:19 |
|
Amaz joined #minetest-dev |
| 10:31 |
|
Amaz joined #minetest-dev |
| 10:57 |
est31 |
nore, can you have a look at https://github.com/est31/minetest/commit/0facaf106589f0e4526d45e3fd83f9f6bd607741 |
| 11:00 |
est31 |
ahhh no |
| 11:00 |
est31 |
its bad |
| 11:00 |
est31 |
because what if we have creative inventory |
| 11:00 |
est31 |
man this is more complicated than i thought |
| 11:00 |
Hunterz |
it is like shift click in the minecraft? |
| 11:01 |
est31 |
yes basically |
| 11:01 |
Hunterz |
it is very useful |
| 11:03 |
est31 |
its already there |
| 11:04 |
est31 |
but mods have to support it |
| 11:04 |
est31 |
nore, better look at https://github.com/minetest/minetest_game/pull/542 |
| 11:05 |
est31 |
the other commit is not reay yet |
| 11:05 |
est31 |
but I wont finish it today |
| 11:05 |
est31 |
will make a PR with a todo list |
| 11:23 |
|
MinetestForFun joined #minetest-dev |
| 12:09 |
|
LittleJoe joined #minetest-dev |
| 12:44 |
|
OldCoder joined #minetest-dev |
| 12:53 |
|
Puma_rc joined #minetest-dev |
| 13:22 |
|
Amaz joined #minetest-dev |
| 13:25 |
|
NakedFury joined #minetest-dev |
| 13:40 |
|
Puma_rc joined #minetest-dev |
| 14:12 |
|
JZTech101 joined #minetest-dev |
| 14:13 |
|
JZTech101 joined #minetest-dev |
| 15:11 |
|
Puma_rc joined #minetest-dev |
| 15:29 |
|
H-H-H joined #minetest-dev |
| 15:32 |
|
zat joined #minetest-dev |
| 16:13 |
VanessaE |
[06-18 20:40] <RealBadAngel> https://github.com/minetest/minetest/blob/master/client/shaders/nodes_shader/opengl_vertex.glsl#L38 |
| 16:13 |
VanessaE |
[06-18 20:40] <RealBadAngel> delete this line and test |
| 16:13 |
VanessaE |
(refers to textures being vertically misaligned) |
| 16:13 |
VanessaE |
this worked for me. can someone please push that to upstream? |
| 16:14 |
|
Amaz joined #minetest-dev |
| 16:24 |
|
est31 joined #minetest-dev |
| 16:29 |
|
Amaz- joined #minetest-dev |
| 16:38 |
|
hmmmm joined #minetest-dev |
| 17:08 |
|
Puma_rc joined #minetest-dev |
| 18:08 |
|
Warr1024 joined #minetest-dev |
| 18:18 |
|
ElectronLibre joined #minetest-dev |
| 19:00 |
Krock |
btw, updated #1731 |
| 19:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/1731 -- Extend the allowed protocol versions of strict servers by SmallJoker |
| 19:30 |
|
RealBadAngel joined #minetest-dev |
| 19:36 |
RealBadAngel |
VanessaE, i can ;) |
| 19:37 |
RealBadAngel |
also i think i found the reason for Taoki issues |
| 19:37 |
|
est31 joined #minetest-dev |
| 19:37 |
Taoki |
RealBadAngel: Normal maps not generating randomly? |
| 19:37 |
est31 |
Krock, what are the usecases? |
| 19:38 |
est31 |
also, btw what are the usecases for strict checking thefirst place |
| 19:38 |
RealBadAngel |
Taoki, thats pretty weird. worldPosition seems to be working randomly |
| 19:38 |
Taoki |
Ah |
| 19:38 |
Taoki |
That might be it, yeah |
| 19:38 |
RealBadAngel |
atm it works for me in minimal game but stopped to work in mt game |
| 19:38 |
VanessaE |
rewok |
| 19:38 |
Krock |
est31, it extends the allowed server version range |
| 19:38 |
VanessaE |
RealBadAngel: ok ** |
| 19:39 |
RealBadAngel |
i suspect its something related to camera offset |
| 19:39 |
Krock |
est31, something between strict and backwards compatibility |
| 19:40 |
RealBadAngel |
fix for that within shaders is easy, but doesnt solve the issue on engine side |
| 19:41 |
RealBadAngel |
in shaders camera position is always 0,0,0 - i dont need to know where in the world its located |
| 19:42 |
est31 |
Krock, it extends the server version range if you limit it first |
| 19:42 |
est31 |
but why limit the first place |
| 19:43 |
Krock |
Are you talking about the current strict_protocol_version_checking behavior? |
| 19:44 |
est31 |
Krock, it defaults to false |
| 19:44 |
est31 |
https://github.com/minetest/minetest/blob/43fcfbfe05578d7471d40c8c087fd04e24b264b5/src/defaultsettings.cpp#L232 |
| 19:44 |
Krock |
I see, false would be 0, right? |
| 19:45 |
est31 |
"false" would be "dont check at all, check if it works" |
| 19:47 |
|
zat joined #minetest-dev |
| 19:47 |
est31 |
also I dont see how it would work if its set to a negative value |
| 19:47 |
RealBadAngel |
usually, a kind of magic ;) |
| 19:49 |
est31 |
so when it has been "true" before, its now "-1" |
| 19:49 |
est31 |
and false is now 0 |
| 19:50 |
RealBadAngel |
btw, ice texture sucks big time imho |
| 19:51 |
RealBadAngel |
it could be used for some kind of glass but not for the ice |
| 19:53 |
RealBadAngel |
https://imgrush.com/ezvxyP09xAIp.png |
| 19:53 |
RealBadAngel |
i can see just squares everywhere |
| 19:53 |
Krock |
est31, fixed |
| 19:57 |
est31 |
Krock, that issue is fixed now but another popped up |
| 19:57 |
est31 |
now you have a bias of 1 |
| 19:57 |
est31 |
with this >= thing |
| 19:57 |
est31 |
also do >= 0 |
| 19:58 |
Krock |
>= 0 isn't required if >= is changed to > |
| 19:58 |
Krock |
but 0 means disable |
| 19:58 |
est31 |
"maximal protocol version difference" |
| 19:59 |
est31 |
so whats when you say that you dont allow any other version from connecting? |
| 20:00 |
Krock |
there's a offset of -1: "maximal protocol version difference" are not the correct words |
| 20:01 |
est31 |
yea depending on how you put it |
| 20:01 |
Krock |
I mean, setting it to 1 will block any other version |
| 20:01 |
Krock |
but 1 is not the maximum difference, 0 is it. |
| 20:02 |
est31 |
so you should update the docs |
| 20:02 |
est31 |
and perhaps do a ->getBool too |
| 20:02 |
est31 |
if that returns true, set it to 1 or 0 or whatever |
| 20:03 |
est31 |
if that returns false, do the number check |
| 20:03 |
RealBadAngel |
fuzzy logic? ;) |
| 20:03 |
Krock |
^ |
| 20:03 |
RealBadAngel |
1 , 0 or whatever? :) |
| 20:03 |
est31 |
heh |
| 20:03 |
est31 |
no I've thought he gets what I mean |
| 20:03 |
Krock |
gawd, I btter close that pull again, it ain't gonna be better |
| 20:05 |
est31 |
if it returns true it should act like the maximum difference were 0 |
| 20:05 |
|
harrison joined #minetest-dev |
| 20:05 |
est31 |
so that we have backwards compatiblity |
| 20:05 |
est31 |
blity lol |
| 20:05 |
est31 |
bility* |
| 20:05 |
|
hmmmmm joined #minetest-dev |
| 20:06 |
est31 |
and a doc change |
| 20:06 |
RealBadAngel |
ah i got it, "whatever" is backwards compability ;) |
| 20:06 |
est31 |
those are my points |
| 20:06 |
|
Garth joined #minetest-dev |
| 20:06 |
Krock |
"doc change", as in editing minetest.conf.example or what? |
| 20:07 |
est31 |
the setting was a boolean before, so people who set it to true shouldnt have a bad suprise |
| 20:07 |
est31 |
for whichever reason they activated |
| 20:07 |
RealBadAngel |
hi hmmmm |
| 20:07 |
est31 |
Krock, if you say its not the maximum version, then doc shouldnt state that |
| 20:07 |
Krock |
if true is counted as 1, it won't be a problem |
| 20:07 |
Krock |
est31, please suggest a correct description. my head's empty |
| 20:07 |
est31 |
Krock, true is counted as 0 as well as false |
| 20:08 |
est31 |
or "strawberry" |
| 20:08 |
Krock |
oh great <.< |
| 20:08 |
est31 |
http://www.cplusplus.com/reference/cstdlib/atoi/ |
| 20:08 |
est31 |
^ thats the function that gets called at the end of the day |
| 20:09 |
|
Yepoleb_ joined #minetest-dev |
| 20:09 |
Krock |
if (end of the day () != false) call(atoi); |
| 20:09 |
Krock |
you were right, true is 0 |
| 20:10 |
est31 |
heh |
| 20:11 |
|
Robby_ joined #minetest-dev |
| 20:11 |
|
exoplanet joined #minetest-dev |
| 20:12 |
|
Eivel_ joined #minetest-dev |
| 20:14 |
est31 |
bye |
| 20:15 |
RealBadAngel |
ouch :) |
| 20:15 |
RealBadAngel |
est31 ended the party ;) |
| 20:18 |
|
proller joined #minetest-dev |
| 20:24 |
|
geheimni1 joined #minetest-dev |
| 20:24 |
|
technoma` joined #minetest-dev |
| 20:25 |
|
rom1504_ joined #minetest-dev |
| 20:25 |
RealBadAngel |
https://imgrush.com/EZx9X29mdqAp vs https://imgrush.com/FoYpSUN9P7sV |
| 20:25 |
RealBadAngel |
what do you think? |
| 20:27 |
RealBadAngel |
VanessaE, ? |
| 20:27 |
VanessaE |
nice |
| 20:27 |
|
nolsen joined #minetest-dev |
| 20:28 |
|
Robby_ joined #minetest-dev |
| 20:28 |
|
exoplanet joined #minetest-dev |
| 20:28 |
RealBadAngel |
shall we make PR with it? |
| 20:28 |
|
VargaD_ joined #minetest-dev |
| 20:30 |
VanessaE |
I guess so |
| 20:33 |
|
nore joined #minetest-dev |
| 20:34 |
|
Aaron1011 joined #minetest-dev |
| 20:34 |
|
Aaron1011 joined #minetest-dev |
| 20:39 |
|
rom1504 joined #minetest-dev |
| 20:39 |
RealBadAngel |
VanessaE, Taoki https://github.com/minetest/minetest/pull/2810 |
| 20:39 |
RealBadAngel |
can you test it? |
| 20:40 |
Taoki |
I might, not sure |
| 20:40 |
|
celeron55_ joined #minetest-dev |
| 20:41 |
RealBadAngel |
celeron55, hi |
| 20:42 |
RealBadAngel |
Taoki, that should fix your issue |
| 20:42 |
Taoki |
Ah, it's only a few lines. I'll add them manually then |
| 20:42 |
RealBadAngel |
Taoki, you dont even need to recompile :) |
| 20:43 |
Taoki |
yep |
| 20:44 |
|
VargaD_ joined #minetest-dev |
| 20:45 |
Taoki |
RealBadAngel: Confirming that it seems to be working perfectly now. The fix is good |
| 20:46 |
RealBadAngel |
good |
| 20:47 |
RealBadAngel |
kahrl, nore ? i need some votes in order to merge it |
| 20:52 |
|
ShadowBot` joined #minetest-dev |
| 20:53 |
|
Megaf_ joined #minetest-dev |
| 20:53 |
|
cvtsx joined #minetest-dev |
| 20:53 |
|
celeron55 joined #minetest-dev |
| 20:54 |
|
Anchakor joined #minetest-dev |
| 20:54 |
|
Fritigern joined #minetest-dev |
| 20:56 |
|
Lunatrius` joined #minetest-dev |
| 20:56 |
|
kilb joined #minetest-dev |
| 21:00 |
|
Teckla_ joined #minetest-dev |
| 21:05 |
|
JeDa_ joined #minetest-dev |
| 21:15 |
|
realbadangel__ joined #minetest-dev |
| 21:16 |
|
rom1504 joined #minetest-dev |
| 21:16 |
|
Ritchie_ joined #minetest-dev |
| 21:17 |
|
Kray_ joined #minetest-dev |
| 21:20 |
|
Amaz joined #minetest-dev |
| 21:20 |
|
CraigyDavi joined #minetest-dev |
| 21:21 |
|
nore joined #minetest-dev |
| 21:21 |
|
Taoki joined #minetest-dev |
| 21:24 |
|
Sokomine joined #minetest-dev |
| 21:25 |
realbadangel__ |
nore, here? |
| 21:25 |
realbadangel__ |
Vanessa, here? |
| 21:28 |
|
dzho_ joined #minetest-dev |
| 21:29 |
realbadangel__ |
gosh, everybody is sleeping or what? :) |
| 21:33 |
Taoki |
I'm here |
| 21:34 |
|
msantana` joined #minetest-dev |
| 21:36 |
|
TheWild joined #minetest-dev |
| 21:36 |
TheWild |
hello there |
| 21:36 |
realbadangel__ |
czesc |
| 21:36 |
TheWild |
o czesc |
| 21:37 |
realbadangel__ |
it has crashed without any additional info? |
| 21:37 |
TheWild |
yes |
| 21:37 |
realbadangel__ |
what was the code you have used? |
| 21:37 |
TheWild |
no dumps, no stack trace... nothing |
| 21:38 |
TheWild |
minetest.get_player_by_name('singleplayer'):get_inventory():set_lists() |
| 21:39 |
realbadangel__ |
ok, will remind est31 that |
| 21:48 |
|
ElectronLibre left #minetest-dev |
| 21:51 |
|
chchjesus_ joined #minetest-dev |
| 22:10 |
|
Teckla_ left #minetest-dev |
| 22:15 |
RealBadAngel |
Taoki, you can update your sources |
| 22:15 |
Taoki |
ok |
| 22:16 |
RealBadAngel |
btw, http://www.minecraftforum.net/forums/mapping-and-modding/resource-packs/resource-pack-discussion/1256343-a-texture-artists-guide-to-mcpatchers-features |
| 22:16 |
RealBadAngel |
these are real connected textures |
| 22:17 |
RealBadAngel |
please take a look on screenshots with grass made with that |
| 22:17 |
RealBadAngel |
simply awesome |
| 22:17 |
RealBadAngel |
http://i.imgur.com/HQVRgl.jpg |
| 22:23 |
Taoki |
On another note: I just finished fixing conflicts and rebasing this. Can it be merged please? https://github.com/minetest/minetest/pull/2372 |
| 22:24 |
Taoki |
It contains a fix for the animation system, plus support for non-looped animations. I tested it again and it works fine |
| 22:25 |
|
TheWild left #minetest-dev |
| 22:31 |
Taoki |
RealBadAngel: Can you take a look at that and merge it perhaps? |
| 22:33 |
RealBadAngel |
some of the lines are way too long, please break them |
| 22:35 |
Taoki |
Which exactly, and how should I format them? |
| 22:35 |
RealBadAngel |
hold on |
| 22:35 |
RealBadAngel |
http://pastebin.com/0SGrMcJN |
| 22:35 |
RealBadAngel |
like that for example |
| 22:36 |
RealBadAngel |
function call in one line, break and params with a tab |
| 22:36 |
RealBadAngel |
if params are still too long you can break them again |
| 22:37 |
Taoki |
RealBadAngel: All others are the same way though. It will look disproportional to do it only for this function |
| 22:37 |
Taoki |
I think it was suggested before, I didn't because the others were as long too |
| 22:37 |
RealBadAngel |
if youre around break them too |
| 22:38 |
RealBadAngel |
im known of making long liners but yours are even longer than mine :) |
| 22:38 |
Taoki |
I'd rather not format random code, probably not for me to do. I'll only do the break you mentioned |
| 22:38 |
Taoki |
It looks good actually. |
| 22:39 |
Taoki |
Done, pushed |
| 22:39 |
RealBadAngel |
just take a look at github web interface |
| 22:40 |
RealBadAngel |
some of the lines doesnt even fit in there, you have to scroll the code to read them |
| 22:40 |
Taoki |
Some lines are longer than mine. So someone else probably needs to fix code formatting in general, separately though. |
| 22:41 |
Taoki |
I only fixed the break you mentioned for this commit. Is it ok now? |
| 22:41 |
Taoki |
(in both places) |
| 22:41 |
RealBadAngel |
https://imgrush.com/651etFK62mc5 |
| 22:42 |
* Taoki |
sighs |
| 22:42 |
Taoki |
There are longer lines everywhere though. I don't really understand |
| 22:43 |
RealBadAngel |
if somethings is badly formatted around doesnt mean you have to follow it |
| 22:43 |
RealBadAngel |
otherwise SN or hmmmmm will eat you ;) |
| 22:44 |
Taoki |
Ok... I will fix that one too... |
| 22:46 |
Taoki |
RealBadAngel: Done, updated the commit. Is it ok now? |
| 22:46 |
Taoki |
If there are more, I will go take a cold shower with my clothes on :P |
| 22:47 |
RealBadAngel |
hehe, will take a look at it in 10 minutes, going out for a moment |
| 22:47 |
Taoki |
ok. Still around for over 2 hours, so let me know |
| 23:02 |
RealBadAngel |
back |
| 23:05 |
RealBadAngel |
it looks better now |
| 23:06 |
RealBadAngel |
whats the possible range of m_animation_loop ? |
| 23:08 |
RealBadAngel |
is it boolean only? |
| 23:08 |
RealBadAngel |
+* `set_animation({x=1,y=1}, frame_speed=15, frame_blend=0, frame_loop=true)` |
| 23:09 |
RealBadAngel |
here formatting should apply too |
| 23:10 |
RealBadAngel |
set_animation({x = 1, y = 1}, frame_speed = 15, frame_blend = 0, frame_loop = true)` |
| 23:10 |
RealBadAngel |
reads way better |
| 23:11 |
Taoki |
It can be any two frames |
| 23:12 |
RealBadAngel |
i see |
| 23:13 |
RealBadAngel |
change that api.txt line and youre done with me |
| 23:13 |
Taoki |
I switched away from the branch now and recompiled. But formatting matches the exact same surrounding functions really |
| 23:13 |
Taoki |
ok |
| 23:13 |
RealBadAngel |
note that i only checked formatting, not the funcionality |
| 23:14 |
RealBadAngel |
im not familiar with that |
| 23:14 |
Taoki |
Um... what should I change? |
| 23:14 |
Taoki |
It's exactly the same as all others |
| 23:14 |
RealBadAngel |
see above |
| 23:14 |
Taoki |
If I remove the * that will look ugly. All functions should do it at once |
| 23:14 |
RealBadAngel |
i know, we have shit all around |
| 23:15 |
Taoki |
I'd really like to keep that one as is please. If someone wants to remove them, it needs to be done for all functions IMO |
| 23:15 |
Taoki |
That would look very very ugly |
| 23:15 |
Taoki |
That branch only aims to implement a bugfix and a needed feature, not to clean the formatting of the entire code |
| 23:16 |
RealBadAngel |
so your next PR should be clean the surroundings |
| 23:16 |
RealBadAngel |
since you were the one who stepped into this particular shit ;) |
| 23:17 |
Taoki |
I only wanted to fix the animation function, not a whole craze about formatting :P |
| 23:17 |
RealBadAngel |
i know that feeling |
| 23:17 |
RealBadAngel |
i can feel that many times |
| 23:18 |
RealBadAngel |
just wear that flashy uniform, grab the shovel and clean it ;) |
| 23:18 |
RealBadAngel |
next time you visit this function it will be nice and clean |
| 23:18 |
Taoki |
I think things should be kept separate still. Perhaps someone should look into that |
| 23:19 |
Taoki |
Anyway, can it be merged as is? |
| 23:19 |
RealBadAngel |
havent tested it, just bugged you bout formatting |
| 23:20 |
RealBadAngel |
so you should get another dev vote too |
| 23:21 |
RealBadAngel |
btw, i feel good that I bugged some1 bout codestyle instead of me being bugged ;) sorry Taoki :) |
| 23:21 |
Taoki |
Eh... it's ok I guess :P |
| 23:22 |
Taoki |
Though when I deal with a code, I want to deal with that code... not fix formatting. I did what the lines above and below mine did. If formatting is bad, someone should fix it for everything at once. |
| 23:22 |
RealBadAngel |
me too |
| 23:22 |
RealBadAngel |
functionality is more important |
| 23:23 |
RealBadAngel |
but keeping your working place clean is indeed good habit |
| 23:23 |
RealBadAngel |
even if mess is not made by you |
| 23:23 |
Taoki |
True too. |
| 23:24 |
Taoki |
But a separate task |
| 23:24 |
RealBadAngel |
thats questionable |
| 23:24 |
RealBadAngel |
if youre here, who and when will "visit" this particular code next time? |
