| Time |
Nick |
Message |
| 00:33 |
RealBadAngel |
ha! |
| 00:33 |
RealBadAngel |
using mapblock_mesh for rendering minimap blocks has advantages |
| 00:35 |
RealBadAngel |
celeron55, thx for the idea on that :) |
| 00:36 |
RealBadAngel |
i gained lotsa time to work on the map itself |
| 00:36 |
VanessaE |
ah you're here |
| 00:36 |
VanessaE |
good timing. |
| 00:37 |
RealBadAngel |
just wondered if that could be useful to add lua function to get minimap mapblock? |
| 00:37 |
RealBadAngel |
hi VE |
| 00:37 |
VanessaE |
your latest patches caused a texture misalign error |
| 00:37 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/random/Screenshot%20-%2006182015%20-%2008%3a37%3a37%20PM.png |
| 00:38 |
RealBadAngel |
damn grass :) |
| 00:38 |
VanessaE |
happens on all drawtypes, and I am not using bumpmapping etc here. |
| 00:38 |
RealBadAngel |
yeah i know, will revert that line |
| 00:38 |
VanessaE |
ok. |
| 00:38 |
RealBadAngel |
it was a hack to get grass better lookin |
| 00:39 |
VanessaE |
it failed ;) |
| 00:39 |
RealBadAngel |
but it failed i suppose ;) |
| 00:39 |
VanessaE |
it affects textures on all nodes, all drawtypes. |
| 00:40 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/client/shaders/nodes_shader/opengl_vertex.glsl#L38 |
| 00:40 |
RealBadAngel |
delete this line and test |
| 00:40 |
VanessaE |
yeah, that looks about consistent with the screenshot. |
| 00:40 |
VanessaE |
can't, busy on other stuff right now |
| 00:41 |
RealBadAngel |
but thats 110% the cause |
| 00:41 |
VanessaE |
well I'll try it |
| 00:41 |
RealBadAngel |
i need to re-add that later depending on eye vector and parallax offset, not fixed value |
| 00:42 |
RealBadAngel |
btw, i just found great app for makin normal maps |
| 00:42 |
RealBadAngel |
open source |
| 00:42 |
VanessaE |
cool |
| 00:42 |
RealBadAngel |
https://github.com/kmkolasinski/AwesomeBump |
| 00:42 |
VanessaE |
already got that. |
| 00:43 |
RealBadAngel |
its simply awesome |
| 00:43 |
VanessaE |
there's a gimp plugin for it somewhere too I think |
| 00:43 |
RealBadAngel |
app is way better |
| 00:43 |
VanessaE |
no strike that - InsaneBump has the gimp plugin |
| 00:43 |
RealBadAngel |
spent one day to learn it |
| 00:43 |
RealBadAngel |
its way more powerfull |
| 00:44 |
VanessaE |
anyway I've played with it. |
| 00:44 |
VanessaE |
it's hard to use :-/ |
| 00:44 |
VanessaE |
terrible UI |
| 00:44 |
RealBadAngel |
hehe indeed |
| 00:44 |
VanessaE |
ok, deleting that line did fix the texture misalignment. |
| 00:45 |
RealBadAngel |
before i learned how to got rid of its logo in textures it was like ages ;) |
| 00:45 |
RealBadAngel |
and when i got that it was *facepalm* |
| 00:46 |
RealBadAngel |
btw, a few weeks ago he made public new version, 4.0 |
| 00:46 |
VanessaE |
already got it. :) |
| 00:47 |
RealBadAngel |
you know what makes me laugh about this app? |
| 00:47 |
RealBadAngel |
he develops shaders here, bumpmapping, parallax etc |
| 00:48 |
RealBadAngel |
he is actually makin phd on that |
| 00:48 |
VanessaE |
cool |
| 00:48 |
|
Taoki joined #minetest-dev |
| 00:48 |
RealBadAngel |
maybe i should too ;) |
| 00:49 |
RealBadAngel |
this app is for his phd, wonder if they would accept mt ;) |
| 00:49 |
RealBadAngel |
lol |
| 00:52 |
RealBadAngel |
VanessaE, btw, ive doubled scan height for minimap, its 256 by now |
| 00:52 |
VanessaE |
I was wondering if you were gonna extend that |
| 00:52 |
RealBadAngel |
so you can see the ground even from cloud level |
| 00:53 |
RealBadAngel |
thx to mapblock meshes i could do that |
| 00:53 |
RealBadAngel |
and its faster than before |
| 00:54 |
RealBadAngel |
number of nodes (minimap pixels checked) when generating map is reduced by 16 times now |
| 00:56 |
VanessaE |
sounds good |
| 00:56 |
RealBadAngel |
good for fps |
| 00:57 |
RealBadAngel |
minimap runs the same fps as whole world now, no visible lags at all |
| 00:57 |
RealBadAngel |
even at 512x256 size |
| 01:21 |
RealBadAngel |
https://imgrush.com/CEHEj_468DEb.png |
| 01:21 |
RealBadAngel |
paramat, hmmmm ^^^ |
| 01:21 |
VanessaE |
impresive. |
| 01:21 |
RealBadAngel |
i think thats something you should fix ;) |
| 01:21 |
VanessaE |
+s |
| 01:21 |
VanessaE |
(well the minimap is ;) ) |
| 01:23 |
RealBadAngel |
floating parts of dungeons are also kinda impressive ;) |
| 01:37 |
|
Taoki joined #minetest-dev |
| 01:52 |
|
zat joined #minetest-dev |
| 01:59 |
|
RealBadAngel joined #minetest-dev |
| 02:33 |
|
paramat joined #minetest-dev |
| 02:33 |
paramat |
actually there's now a setting to disable floating dungeons |
| 02:38 |
paramat |
hmmmm, https://github.com/minetest/minetest/pull/2805 'Mapgen objects: Enable heatmap, humidmap for mgv5 and any biome api mapgen' works but game crashes when exiting to menu or OS |
| 02:40 |
hmmmm |
ohh |
| 02:40 |
hmmmm |
hrmm |
| 02:41 |
hmmmm |
paramat, you're copying pointers around |
| 02:42 |
hmmmm |
otherwise looks good |
| 02:42 |
hmmmm |
double free |
| 02:42 |
paramat |
yes im cargo culting |
| 02:43 |
hmmmm |
remove the delete[] humidmap/delete[] heatmap[] from the dtors |
| 02:44 |
paramat |
okay |
| 02:44 |
|
Wayward_Tab joined #minetest-dev |
| 02:45 |
hmmmm |
do you understand why it's crashing and why removing the deletes fixes it? |
| 02:45 |
paramat |
i copied the implementation of heightmap and biomemap, but there must be some way heat/humidmaps are different |
| 02:45 |
hmmmm |
so in otherwords, no |
| 02:46 |
hmmmm |
if you don't understand why something works, please ask.. |
| 02:46 |
paramat |
correct |
| 02:46 |
paramat |
yes i'd like to know, just feel bad bothering you |
| 02:47 |
hmmmm |
i would feel a lot better if you did bother me so you can actually know how to do these things in the future |
| 02:47 |
hmmmm |
Noise::result is a pointer to memory allocated by the Noise object, belonging to the Noise object |
| 02:47 |
paramat |
i appreciate your help and patience |
| 02:48 |
hmmmm |
what you did was declare pointers to arrays of floating point numbers |
| 02:48 |
hmmmm |
ah |
| 02:48 |
hmmmm |
and then in the mapgen ctors you did initialize them to a buffer |
| 02:49 |
hmmmm |
and then after calculating the noise, you throw away pointers to the memory you actually allocated, and replaced them with a copy of the pointers to the internal noise object results |
| 02:50 |
hmmmm |
what you actually meant to do here probably is do a deep copy of all the values in the noise_heat->result array to the heatmap array |
| 02:50 |
hmmmm |
so you could fix this one of two ways |
| 02:50 |
hmmmm |
change heatmap = noise_heat->result to memcpy(heatmap, noise_heat->result, csize.X * csize.Z * sizeof(float)) |
| 02:50 |
hmmmm |
or |
| 02:51 |
hmmmm |
set this->heatmap = NULL in the constructor and then remove the delete[] in the destructor |
| 02:51 |
hmmmm |
the latter is best because it's zero-copy |
| 02:51 |
paramat |
yes i wanted to copy the noise_heat values to heatmap |
| 02:51 |
paramat |
thanks |
| 02:51 |
hmmmm |
you are able to get away with it because right now, the way biome heat and humidity is implemented in these mapgens only involves a single layer of perlin noise |
| 02:52 |
hmmmm |
if you are copying the pointer, then you need to ensure it does not get deleted twice |
| 02:52 |
hmmmm |
as you were with delete[] heatmap; |
| 02:53 |
hmmmm |
that piece of memory already got deleted on the line "delete noise_heat;"! |
| 02:53 |
paramat |
oh duh! |
| 02:53 |
hmmmm |
and moreover, you also leaked that buffer you originally allocated for it with ... = new float[...] in the ctor |
| 02:53 |
hmmmm |
think of the variable "heatmap" as a piece of paper |
| 02:54 |
hmmmm |
with that "new float[..]" line, you built a house at some location, and the result of that operator new is the address of that new house |
| 02:54 |
hmmmm |
so you write down the address of your new house on the piece of paper that is the variable "heatmap" |
| 02:54 |
hmmmm |
134 main st. |
| 02:55 |
hmmmm |
when you get to calculateNoise(), and you set heatmap to noise_heat->result, that's like taking an eraser to your piece of paper, erasing the address you currently have there, and then writing "554 foobar rd." |
| 02:55 |
hmmmm |
your program still has that house at 134 main st, but it has no way to talk about that house anymore because it doesn't know the address to it |
| 02:55 |
hmmmm |
does it make sense at all? |
| 02:56 |
paramat |
i will reread and ponder, sometimes it takes a while |
| 02:56 |
paramat |
i'm sure it will, thanks |
| 02:57 |
paramat |
i need to study about pointers and so many other things |
| 02:57 |
hmmmm |
if it doesn't, please tell me so |
| 02:57 |
paramat |
okay |
| 03:33 |
paramat |
hmmmm because i will be adding 'this->heatmap = NULL' to the mgv5/v7 constructors, should i remove some lines i added to mapgen.cpp and mapgen.h? |
| 03:33 |
hmmmm |
no |
| 03:34 |
paramat |
okay |
| 03:51 |
|
paramat left #minetest-dev |
| 05:13 |
|
crazyR_ joined #minetest-dev |
| 05:13 |
|
crazyR_ joined #minetest-dev |
| 05:38 |
|
Megaf joined #minetest-dev |
| 05:48 |
|
Hunterz joined #minetest-dev |
| 06:15 |
|
err404 joined #minetest-dev |
| 06:59 |
|
nore joined #minetest-dev |
| 07:06 |
|
chchjesus_ joined #minetest-dev |
| 07:37 |
|
err404 joined #minetest-dev |
| 07:52 |
|
selat joined #minetest-dev |
| 08:02 |
|
err404 joined #minetest-dev |
| 08:03 |
|
Amaz joined #minetest-dev |
| 08:05 |
|
Yepoleb joined #minetest-dev |
| 08:51 |
|
blaze joined #minetest-dev |
| 08:53 |
|
H-H-H joined #minetest-dev |
| 09:19 |
|
twoelk joined #minetest-dev |
| 09:20 |
|
NakedFury joined #minetest-dev |
| 09:53 |
|
proller joined #minetest-dev |
| 10:00 |
crazyR_ |
hey guys just a quick one. if i was to "minetest.write_json()" the "minetest.auth_table" table would it have any adverse affects, ie: messing up the passwords? |
| 10:53 |
|
twoelk joined #minetest-dev |
| 11:29 |
|
Niebieski joined #minetest-dev |
| 11:34 |
|
proller joined #minetest-dev |
| 11:44 |
|
selat joined #minetest-dev |
| 12:03 |
|
err404 left #minetest-dev |
| 12:31 |
|
RealBadAngel joined #minetest-dev |
| 12:59 |
|
blaze joined #minetest-dev |
| 13:28 |
|
LittleJoe joined #minetest-dev |
| 14:05 |
|
proller joined #minetest-dev |
| 14:30 |
|
CraigyDavi joined #minetest-dev |
| 14:40 |
|
Amaz joined #minetest-dev |
| 14:41 |
|
zat joined #minetest-dev |
| 15:16 |
|
hmmmm joined #minetest-dev |
| 15:25 |
|
Calinou joined #minetest-dev |
| 15:42 |
|
Hunterz joined #minetest-dev |
| 16:04 |
|
twoelk|2 joined #minetest-dev |
| 16:48 |
|
Krock joined #minetest-dev |
| 17:41 |
|
kilbith joined #minetest-dev |
| 17:53 |
|
Krock joined #minetest-dev |
| 18:02 |
|
ElectronLibre joined #minetest-dev |
| 18:34 |
|
SopaXT joined #minetest-dev |
| 18:55 |
|
Krock joined #minetest-dev |
| 19:16 |
|
jordan4ibanez joined #minetest-dev |
| 19:59 |
|
est31 joined #minetest-dev |
| 20:02 |
|
VargaD joined #minetest-dev |
| 20:07 |
VanessaE |
any devs here that care to address the issue of attached entities not showing in 3rd-person-view (F7) mode? |
| 20:08 |
est31 |
regression? |
| 20:08 |
VanessaE |
must be. |
| 20:08 |
VanessaE |
doesn't work in current HEAD, stu says it doesn't work for him either |
| 20:08 |
VanessaE |
(wield3d mod for example) |
| 20:10 |
VanessaE |
I only found it out by trying to get wield3d working in singleplayer -- it DOES work, you just can't see the attached entity (but apparently someone else signing in can) |
| 20:10 |
VanessaE |
so at first I thought it didn't work |
| 20:15 |
est31 |
wield3d mod is a hack |
| 20:16 |
est31 |
but yea they should be visible in 3rd person view |
| 20:16 |
est31 |
I guess they are hidden because you dont want to see them in 1st person |
| 20:16 |
est31 |
so only thing I have to do is add a check whether we are in 3rd person view |
| 20:17 |
|
kilbith joined #minetest-dev |
| 20:19 |
kilbith |
3darmor is indeed an hack, it's saner and more reliable to use a different player's model with a dedicated plane on the hand for the wielded items |
| 20:19 |
kilbith |
such as : https://github.com/stujones11/minetest-3d_armor/tree/master/3d_armor |
| 20:20 |
kilbith |
and no attached entities |
| 20:21 |
kilbith |
s/3darmor/wield3d |
| 20:24 |
|
H-H-H joined #minetest-dev |
| 20:26 |
VanessaE |
kilbith: the problem with that is you then can't rely on the extruded shape of the wielded item |
| 20:26 |
VanessaE |
the *proper* solution of course is to just handle it client-side |
| 20:33 |
|
proller joined #minetest-dev |
| 21:54 |
est31 |
gonna push a fix for that bug |
| 21:55 |
VanessaE |
yay! |
| 22:02 |
|
ElectronLibre left #minetest-dev |
| 22:07 |
est31 |
man this is a weird setup |
| 22:07 |
VanessaE |
? |
| 22:08 |
est31 |
why are genericcao and clientactiveobject separate? |
| 22:08 |
est31 |
stupid OOP |
| 22:31 |
est31 |
VanessaE, could you test https://github.com/est31/minetest/commit/477261c326520adb2dd81a7dbb62d6a69cd08658 |
| 22:31 |
VanessaE |
one moment... |
| 22:32 |
* VanessaE |
compiles... |
| 22:37 |
VanessaE |
no good. |
| 23:04 |
|
zat joined #minetest-dev |
| 23:19 |
est31 |
I've got to the point now to get it always display |
| 23:19 |
est31 |
but i dont really understand what the code does |
| 23:19 |
est31 |
every genericCAO has a vector children |
| 23:19 |
est31 |
so I'd think that children should contain ids of attached objects |
| 23:19 |
est31 |
but it doesnt contain anything |
| 23:21 |
est31 |
so i really dont know what "attached to" really means |
| 23:22 |
* VanessaE |
shrugs ... You understand that mess better than I ever could :) |
| 23:25 |
|
Aaron1011 joined #minetest-dev |
| 23:25 |
|
Aaron1011 joined #minetest-dev |
| 23:26 |
est31 |
I think I'll rename some structures |
| 23:29 |
kahrl |
on a semi-related note... all the arrays of size USHRT_MAX should probably be of size USHRT_MAX + 1 |
| 23:30 |
est31 |
ah I see |
| 23:30 |
kahrl |
that applies to ClientEnvironment::m_attachements and to getBlockNodeIdMapping_mapping in mapblock.cpp |
| 23:30 |
est31 |
yup |
| 23:31 |
est31 |
first of all why is an m_ prefix for m_attachements |
| 23:31 |
est31 |
second why "attachements" |
| 23:31 |
kahrl |
there shouldn't be a prefix, especially since it's part of the public interface |
| 23:31 |
VanessaE |
kahrl: stopping buffer overflows aside, what would that accomplish? |
| 23:32 |
kahrl |
VanessaE: well it's mostly about that |
| 23:32 |
est31 |
its basically mapping ids of attachemed objects to the parent ids |
| 23:32 |
VanessaE |
oh ok. :) |
| 23:32 |
est31 |
so it should perhaps be called "attachement_parent_ids" |
| 23:32 |
est31 |
and the second thing GENERIC_CMD_SET_ATTACHMENT |
| 23:32 |
kahrl |
est31: also s/attachement/attachment |
| 23:33 |
est31 |
should perhaps be GENERIC_CMD_ATTACH_TO |
| 23:33 |
est31 |
or "GENERIC_CMD_SET_ATTACHED_TO" |
| 23:33 |
est31 |
ok |
| 23:33 |
kahrl |
..._ATTACH_TO sounds good to me |
| 23:34 |
kahrl |
um, does m_children actually contain the "list" of parent ids? |
| 23:34 |
est31 |
I wonder too what puropse m_children |
| 23:34 |
est31 |
serves |
| 23:34 |
est31 |
my theory is that its a list of children ids |
| 23:34 |
kahrl |
I'm pretty sure if was retrofitted at some point, but not very thoroughly |
| 23:34 |
kahrl |
s/if/it |
| 23:35 |
est31 |
and the population near "else if(cmd == GENERIC_CMD_SET_ATTACHMENT) {" is a bug |
| 23:35 |
kahrl |
the attachment code used to loop over *all* attachments in the scene almost all the time |
| 23:35 |
kahrl |
which was a huge time waster |
| 23:36 |
est31 |
ok |
| 23:38 |
est31 |
but what does that have to do with m_children |
| 23:38 |
est31 |
the only code I see where m_children is accessed I see that it is actually used as "list of object ids we are attached to" |
| 23:39 |
kahrl |
the idea, I think, was: if you need to unparent all the children temporarily, just loop through m_children, not through the environments' m_attachements |
| 23:39 |
est31 |
what is a "child" in this context? |
| 23:39 |
kahrl |
like in GenericCAO::step |
| 23:39 |
est31 |
something we are attached to or something attached to us |
| 23:40 |
kahrl |
I've wondered that too |
| 23:40 |
est31 |
the name indicates to the second meaning |
| 23:40 |
VanessaE |
I'd have expected the latter |
| 23:42 |
est31 |
next thing I wonder about: are all CAOs except genericcao dead? |
| 23:42 |
est31 |
as in deprecated |
| 23:42 |
est31 |
pretty weird you only can attach to a genericcao |
| 23:42 |
kahrl |
yeah |
| 23:43 |
kahrl |
actually... ItemSAO doesn't even exist anymore in current servers, but ItemCAO might still be there for compatibility with older servers |
| 23:43 |
VanessaE |
how old is "older" though? |
| 23:43 |
est31 |
or maps? |
| 23:44 |
kahrl |
not maps, since they go through the server part first |
| 23:44 |
est31 |
ah |
| 23:44 |
kahrl |
which just deletes stored ItemSAOs IIRC |
| 23:45 |
kahrl |
finding out when the server was made to do that would answer VanessaE's question |
| 23:45 |
VanessaE |
commit f0678979b1ed5c70095a48820a8110eb631ed74d |
| 23:45 |
VanessaE |
Author: Perttu Ahola <celeron55 gmail.com> |
| 23:45 |
VanessaE |
Date: Mon Jun 11 22:10:48 2012 +0300 |
| 23:45 |
VanessaE |
Add comment about ItemSAO being deprecated |
| 23:46 |
est31 |
is that redcrab server still online? |
| 23:46 |
est31 |
or other ultra-old server? |
| 23:46 |
est31 |
s |
| 23:46 |
VanessaE |
est31: that server is down. |
| 23:48 |
kahrl |
the commit that actually removed ItemSAO was f8d5af753617d502920556cff88f451ef670c210 by nerzhul (Feb 16 2015) |
| 23:48 |
VanessaE |
saw that. |
| 23:49 |
est31 |
btw whats correct coding style |
| 23:49 |
est31 |
GenericCAO* ClientEnvironment::getGenericCAO(u16 id) |
| 23:49 |
est31 |
or |
| 23:49 |
est31 |
GenericCAO *ClientEnvironment::getGenericCAO(u16 id) |
| 23:50 |
est31 |
(* position) |
| 23:50 |
kahrl |
I honestly don't care :P |
| 23:51 |
VanessaE |
I think I've seen it argued that the second way is better |
| 23:55 |
|
chchjesus_ joined #minetest-dev |
