Time |
Nick |
Message |
00:11 |
|
est31 joined #minetest |
00:15 |
QwertyDragon |
there are none :( |
00:16 |
QwertyDragon |
at least yet |
00:21 |
|
GreenDimond joined #minetest |
00:21 |
CalebDavis |
hi GD |
00:22 |
GreenDimond |
I am using placer:get_player_name in my mod, but I keep getting an attempt to call method 'get_player_name' (a nile value) error |
00:22 |
GreenDimond |
Any idea why? |
00:22 |
GreenDimond |
(this is inside a node def |
00:22 |
GreenDimond |
)* |
00:23 |
|
EinChan left #minetest |
00:23 |
Fixer |
suspicious |
00:23 |
Fixer |
hmmm |
00:23 |
CalebDavis |
the only reason that i can think of is a nil placer |
00:23 |
GreenDimond |
I am using it as `local player = placer:get_player_name()` inside on_place, after_place_node, and on_dig |
00:25 |
GreenDimond |
Also, the reason I have it is for `player:set_attribute`. |
00:26 |
GreenDimond |
When I use `local player = player:get_player_name()` then I get the error "attempt to call method 'get_attribute' (a nil value)" |
00:26 |
GreenDimond |
oh, I also have it for get_att (obviously) |
00:27 |
Fixer |
nil users... is this related in any way? https://github.com/minetest/minetest/pull/5819 |
00:28 |
GreenDimond |
I don't think so |
00:28 |
jas_ |
can you paste the code somewhere? maybe a gist or pastebin |
00:28 |
GreenDimond |
sure |
00:31 |
GreenDimond |
http://paste.ubuntu.com/25854950/ |
00:32 |
GreenDimond |
(jas_)^ |
00:33 |
jas_ |
also useful is the output of debug.txt |
00:33 |
GreenDimond |
aka useless |
00:33 |
GreenDimond |
but ill check |
00:33 |
jas_ |
player:set_attribute(has_placed_mynode, "true") <-- "has_placed_mynode" ? |
00:34 |
jas_ |
is there a `has_placed_mynode` variable? |
00:34 |
jas_ |
debug.txt is useful because i don't know the line numbers |
00:34 |
jas_ |
gotta shower glhf o/ |
00:35 |
GreenDimond |
wait.. |
00:35 |
GreenDimond |
I thought the has_placed_mynode was just an attribute name |
00:35 |
GreenDimond |
I can define it as whatever |
00:37 |
lumberJ |
i don't think the on_place function takes those parameters, GreenDimond |
00:37 |
lumberJ |
see the api: on_place = func(itemstack, placer, pointed_thing) |
00:38 |
GreenDimond |
The goal is to make it so the player can only place one of these nodes at a time |
00:38 |
lumberJ |
you mean, if one is placed anywhere, the player can't place another? |
00:38 |
GreenDimond |
correct |
00:39 |
GreenDimond |
and if it is dug, then they can place it again |
00:39 |
|
soloojos joined #minetest |
00:39 |
GreenDimond |
They can only have one existing at a time |
00:39 |
lumberJ |
maybe just set a variable outside the registry that takes a boolean value |
00:39 |
lumberJ |
or rather it might have to be a table that takes the players names and a boolean |
00:40 |
lumberJ |
if you are planning to use it on multiplayer server |
00:40 |
GreenDimond |
Yes I plan to use it on a multiplayer server |
00:40 |
GreenDimond |
I thought player attributes would work for that though |
00:41 |
lumberJ |
hmm, let me take a closer look at your code |
00:41 |
lumberJ |
but on_place = function(pos, player, placer, itemstack) |
00:41 |
GreenDimond |
there maybe extra stuff in the function() stuff |
00:41 |
GreenDimond |
I was just strying things |
00:41 |
GreenDimond |
trying* |
00:41 |
lumberJ |
probably won't work because those aren't the params that on_place takes |
00:42 |
GreenDimond |
well (itemstack, placer) is probly all I need |
00:43 |
GreenDimond |
what I dont get |
00:43 |
GreenDimond |
is that local owner = placer:get_player_name() works in the after_place_node |
00:46 |
lumberJ |
thats because you set that function up correctly, i would guess |
00:47 |
lumberJ |
it takes the params that you are passing to it |
00:48 |
GreenDimond |
but its the same params |
00:48 |
GreenDimond |
(pos, placer, itemstack) |
00:49 |
lumberJ |
also i think to reference the player attributes can access it directly via placer:get_attribute(attribute) |
00:49 |
lumberJ |
see the api though. after_placen_node and on_place don't take the same attributes like you have it in your code |
00:50 |
lumberJ |
on place only takes itemstack, placer, pointed thing |
00:50 |
lumberJ |
which is different from what you have in your code |
00:50 |
GreenDimond |
all I need is itemstack and placer though |
00:51 |
GreenDimond |
after_place_node = function(pos, placer, itemstack) |
00:51 |
GreenDimond |
the pos is used for other stuff in that function |
00:51 |
GreenDimond |
so the only other ones are placer and itemstack |
00:51 |
lumberJ |
so just change it to the proper function but only reference the values you need |
00:51 |
GreenDimond |
'proper function' |
00:51 |
GreenDimond |
? |
00:52 |
lumberJ |
the function is hard coded into the game engine so you have to use the params that called for in the api |
00:52 |
lumberJ |
but that doesn't mean you actually have to use them in the code that you put in the function |
00:52 |
GreenDimond |
alright, so I changed it to `function(placer, itemstack)` |
00:52 |
lumberJ |
but the values will get passed into the function regardless |
00:52 |
GreenDimond |
(for on_place) |
00:52 |
GreenDimond |
yet it still doesnt work |
00:53 |
GreenDimond |
I have also tried get_player_by_name(name) with no luck |
00:53 |
CalebDavis |
the placer is the player object |
00:53 |
lumberJ |
i think it will need to be: func(itemstack, placer, pointed_thing) |
00:53 |
lumberJ |
you just don't have to do anything with the pointed_thing value |
00:54 |
lumberJ |
so as for the player attribute thing |
00:54 |
GreenDimond |
so I still need `local player = placer:get_player_name()` yes? |
00:54 |
lumberJ |
there is the player object and player name |
00:54 |
lumberJ |
if i understand what the api says you need the player object, not the names |
00:54 |
lumberJ |
so in this case that is represented by placer |
00:54 |
GreenDimond |
oh... |
00:55 |
lumberJ |
so placer:set_attribute(attribute, value) should do it |
00:55 |
CalebDavis |
yes |
00:55 |
GreenDimond |
does attribute need to be in quotes? |
00:55 |
GreenDimond |
or just value? |
00:56 |
CalebDavis |
the atribute does the value can be anything |
00:56 |
GreenDimond |
well it is `if placer:get_attribute(has_placed_mynode, "true") then` |
00:56 |
GreenDimond |
(currently) |
00:56 |
lumberJ |
'get_attribute(attribute) — returns the value for the extra player attribute or nil if this attribute had not been set. The return value is always a string' |
00:57 |
GreenDimond |
so |
00:57 |
lumberJ |
i assume the attribute itself works kind of like a variable, the value is a string |
00:57 |
GreenDimond |
needs to be `if placer:get_attribute("has_placed_mynode", "true") then` |
00:57 |
GreenDimond |
right? |
00:57 |
CalebDavis |
right |
00:57 |
lumberJ |
but maybe someone with more experience using that feature can confirm |
00:58 |
CalebDavis |
it is inserting it nto a list usng the attribut as the key and keys must be strings |
00:58 |
lumberJ |
if it works like a key in a table that would probably work GreenDimond |
00:59 |
GreenDimond |
well |
00:59 |
GreenDimond |
supposedly it works |
00:59 |
GreenDimond |
but |
00:59 |
lumberJ |
agree with Caleb |
00:59 |
GreenDimond |
now I am getting an error in the on_dig |
00:59 |
CalebDavis |
what is the error |
00:59 |
lumberJ |
on_dig = func(pos, node, digger) |
01:00 |
CalebDavis |
is this case digger is the player object |
01:00 |
lumberJ |
placer:set_attribute |
01:00 |
lumberJ |
or sorry, yes digger:set_attribute |
01:00 |
GreenDimond |
oh ok |
01:01 |
GreenDimond |
why pos? |
01:01 |
CalebDavis |
that is the coords of the dug node |
01:01 |
lumberJ |
pos is just one of the params that function takes |
01:01 |
lumberJ |
if you don't need to use the value ignore it, but it still needs to be there, when you call the function |
01:03 |
rubenwardy |
placer:get_attribute(has_placed_mynode) means call the get_attribute function with the contents of the variable has_placed_mynode as a paramater |
01:03 |
rubenwardy |
the variable has_placed_mynode is likely to be undefined |
01:04 |
rubenwardy |
so the call is equivalent to placer:get_attribute(nil) |
01:06 |
GreenDimond |
Good news: No more crashes/errors. Bad news: Can't place node xD |
01:07 |
lumberJ |
rubenwardy, you mean under on_place, right? |
01:07 |
lumberJ |
there is should be 'set' not get_attribute, right? |
01:07 |
rubenwardy |
I'm copying the code they made |
01:07 |
CalebDavis |
ohh yea on_place has to call minetest.place_node(...) |
01:08 |
GreenDimond |
wait wat? |
01:08 |
lumberJ |
when you get a chance post a fresh copy, GreenDimond so we can see all the changes |
01:08 |
GreenDimond |
oki |
01:08 |
lumberJ |
that will make it easier |
01:09 |
|
EvergreenTree joined #minetest |
01:13 |
swift110 |
aww man |
01:14 |
GreenDimond |
lumberJ: http://paste.ubuntu.com/25855098/ |
01:14 |
lumberJ |
so i think under on_place you mean to set_attribute right? |
01:16 |
GreenDimond |
um |
01:16 |
GreenDimond |
no |
01:16 |
GreenDimond |
after_place |
01:16 |
GreenDimond |
on_place it checks if placer has placed node |
01:16 |
GreenDimond |
if place has, prevent. |
01:17 |
GreenDimond |
otherwise it moves on to after_place_node |
01:17 |
lumberJ |
ah, got you |
01:17 |
GreenDimond |
which changes the attribute |
01:17 |
GreenDimond |
but for some reason I cant place it now |
01:18 |
|
edisonbulb joined #minetest |
01:18 |
lumberJ |
maybe like rubenwardy said |
01:18 |
rubenwardy |
get_attribute only has one parameter |
01:19 |
rubenwardy |
and returns a string |
01:19 |
lumberJ |
so should be if pacler:get_attribute("has_placed_mynode") == "true" then |
01:20 |
rubenwardy |
you want something like local has_placed_mynode = placer:get_attribute("has_placed_mynode") if has_placed_mynode == "" or minetest.is_yes(has_placed_mynode) then |
01:20 |
rubenwardy |
ahh |
01:20 |
GreenDimond |
erm |
01:20 |
GreenDimond |
what |
01:20 |
GreenDimond |
which one do I use? |
01:20 |
rubenwardy |
you want something like if minetest.is_yes(placer:get_attribute("has_placed_mynode") or "true") then |
01:21 |
GreenDimond |
in which spot? |
01:21 |
GreenDimond |
after_place_node? |
01:21 |
rubenwardy |
when get_attribute returns nil, it'll use true instead |
01:21 |
rubenwardy |
in on_place |
01:21 |
GreenDimond |
oh |
01:21 |
rubenwardy |
then the same in after_place_node, but with or "false" |
01:22 |
GreenDimond |
wait |
01:22 |
GreenDimond |
wouldnt it be if minetest.is_yes(placer:get_attribute("has_placed_mynode", "true") or "true") |
01:22 |
rubenwardy |
no |
01:22 |
rubenwardy |
get_attribute only has one parameter |
01:22 |
rubenwardy |
what is the , "true" supposed to be? |
01:23 |
rubenwardy |
the or bit is for if the parameter isn't set |
01:24 |
rubenwardy |
minetest.is_yes(placer:get_attribute("has_placed_mynode", "true") or "false") will return true if has_placed_mynode is true, otherwise it'll return false (eg: if has_placed_mynode is false or isn't set) |
01:24 |
|
edisonbulb left #minetest |
01:25 |
rubenwardy |
looks like you only want it to place once |
01:25 |
GreenDimond |
well |
01:25 |
GreenDimond |
I want it to only be placed one at a time |
01:25 |
GreenDimond |
but you can place it multiple times |
01:25 |
GreenDimond |
but only one at once |
01:25 |
rubenwardy |
not sure what that means |
01:25 |
GreenDimond |
erm |
01:25 |
GreenDimond |
Say I place it |
01:25 |
rubenwardy |
you can only place one node at a time? |
01:26 |
GreenDimond |
I place it, now I cannot because it has been placed. |
01:26 |
GreenDimond |
Then I dig it |
01:26 |
GreenDimond |
now I can place it again |
01:26 |
GreenDimond |
even if I have 2 |
01:26 |
GreenDimond |
I can only place one |
01:26 |
rubenwardy |
https://gist.github.com/rubenwardy/0109290bbc4cd774c813074d16d3b12d |
01:26 |
rubenwardy |
oops |
01:26 |
rubenwardy |
reload it |
01:26 |
rubenwardy |
oops |
01:26 |
rubenwardy |
https://gist.github.com/rubenwardy/0109290bbc4cd774c813074d16d3b12d |
01:27 |
GreenDimond |
no on_dig? |
01:27 |
rubenwardy |
yeah, you'll need that too |
01:28 |
rubenwardy |
with placer:set_attribute("has_placed_mynode", "false") |
01:28 |
GreenDimond |
ok thats already there |
01:28 |
GreenDimond |
changing the other stuff.. |
01:29 |
GreenDimond |
still wont place |
01:29 |
rubenwardy |
code? |
01:30 |
rubenwardy |
ahh |
01:30 |
|
ThomasMonroe joined #minetest |
01:30 |
rubenwardy |
you need to call minetest.item_place in it if the return isn't reached |
01:30 |
GreenDimond |
in it |
01:31 |
GreenDimond |
in the on_place? |
01:31 |
rubenwardy |
I've updated the gist |
01:31 |
rubenwardy |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L4395 |
01:31 |
rubenwardy |
the documentation says "shall place the item, and return any lefover stack" |
01:32 |
GreenDimond |
now I can place more than one |
01:32 |
GreenDimond |
and cant dig it |
01:32 |
rubenwardy |
so you need to handle placing the node in that callback, which can be done by defering to that function |
01:32 |
rubenwardy |
code? |
01:34 |
GreenDimond |
http://paste.ubuntu.com/25855282/ |
01:35 |
GreenDimond |
afk for dinner.. ill read your answer when I get back |
01:55 |
|
turtleman joined #minetest |
01:55 |
GreenDimond |
back for a moment |
01:55 |
GreenDimond |
rubenwardy, anything? |
01:55 |
rubenwardy |
no, I need to sleep |
01:56 |
GreenDimond |
oh, alright. |
01:56 |
rubenwardy |
I suggest adding print statements |
01:56 |
rubenwardy |
seeing when each bit is being called |
01:58 |
GreenDimond |
k |
02:30 |
|
Hawk777 joined #minetest |
03:47 |
|
Digit left #minetest |
04:23 |
|
tiwake joined #minetest |
04:55 |
|
YuGiOhJCJ joined #minetest |
05:12 |
|
YuGiOhJCJ joined #minetest |
06:06 |
|
soloojos joined #minetest |
06:12 |
|
AlexYst joined #minetest |
06:25 |
|
soloojos joined #minetest |
06:29 |
|
ssieb joined #minetest |
07:03 |
|
nore joined #minetest |
07:55 |
|
Hackberry joined #minetest |
07:57 |
|
fusion44 joined #minetest |
08:07 |
|
Darcidride joined #minetest |
08:22 |
|
EinChan joined #minetest |
08:51 |
|
Hackberry joined #minetest |
09:00 |
|
twoelk|2 joined #minetest |
09:07 |
|
proller joined #minetest |
09:36 |
|
MarisaG joined #minetest |
09:36 |
|
nac joined #minetest |
09:49 |
|
tiwake joined #minetest |
10:02 |
|
loggingbot_ joined #minetest |
10:02 |
|
Topic for #minetest is now Welcome to #minetest, official Minetest channel | Latest version: 0.4.16 (2017-06-03) | Responses may take a while, be patient | Rules: http://wiki.minetest.net/IRC#Rules | Development: #minetest-dev | Server list: http://minetest.net/servers | IRC logs: http://irc.minetest.net/minetest/ |
10:03 |
|
Freejack joined #minetest |
10:03 |
|
xSmurf joined #minetest |
10:06 |
|
cyberarm joined #minetest |
10:06 |
|
xerox123 joined #minetest |
10:08 |
|
Sockbat joined #minetest |
10:08 |
|
Exagone313 joined #minetest |
10:09 |
|
thePalindrome joined #minetest |
10:20 |
|
asl97 joined #minetest |
10:37 |
|
Darcidride joined #minetest |
10:47 |
|
proller joined #minetest |
11:07 |
|
EvergreenTree joined #minetest |
11:58 |
|
Fixer joined #minetest |
12:12 |
|
ftugrul joined #minetest |
12:25 |
|
NathanS21 joined #minetest |
12:28 |
|
rafalcpp joined #minetest |
12:51 |
|
RobbieF joined #minetest |
12:51 |
|
RobbieF left #minetest |
12:52 |
|
CalebDavis joined #minetest |
12:55 |
|
rafalcpp joined #minetest |
12:57 |
|
_Enrico_ joined #minetest |
13:05 |
|
xerox123 joined #minetest |
13:21 |
|
Jordach joined #minetest |
13:24 |
|
ThomasMonroe joined #minetest |
13:37 |
|
antims joined #minetest |
13:41 |
|
nowhere_man joined #minetest |
13:44 |
|
Wuzzy joined #minetest |
13:46 |
|
nowhere_man joined #minetest |
13:55 |
|
ensonic joined #minetest |
14:05 |
|
bas080 joined #minetest |
14:09 |
|
lumberJ joined #minetest |
14:10 |
|
proller joined #minetest |
14:25 |
|
erstazi joined #minetest |
14:34 |
|
deltasquared joined #minetest |
14:37 |
|
soloojos joined #minetest |
15:16 |
|
draco_kun joined #minetest |
15:18 |
|
bas080 joined #minetest |
15:22 |
|
Jordach_ joined #minetest |
15:22 |
|
proller joined #minetest |
15:36 |
|
bigfoot548_ joined #minetest |
15:37 |
|
bigfoot548_ left #minetest |
15:50 |
|
est31 joined #minetest |
15:52 |
|
lumberJ joined #minetest |
15:52 |
|
numzero joined #minetest |
15:53 |
|
Sires joined #minetest |
15:54 |
Sires |
hello is anyone online |
15:56 |
|
AlexYst joined #minetest |
15:57 |
numzero |
me |
15:59 |
|
est31 joined #minetest |
15:59 |
|
numzero joined #minetest |
16:02 |
deltasquared |
I'm here though I'm usually sporadic at best |
16:06 |
Sires |
hi numzero |
16:07 |
Sires |
I would like if someone explain me something |
16:07 |
Sires |
about |
16:07 |
Sires |
https://github.com/minetest/minetest/issues/2670 |
16:07 |
Sires |
I was reading it and |
16:07 |
Sires |
raymoo said we need 4 bits for each colour channel(rgb) to make colored light |
16:08 |
Sires |
why 4 instead of 8 ? |
16:09 |
deltasquared |
Sires: well my guess would be that because we currently only have 16 light levels |
16:09 |
deltasquared |
lighting isn't going to be full 24-bit RGB here |
16:09 |
Sires |
oh |
16:09 |
deltasquared |
among other things it would increase memory requirements ;) |
16:10 |
Sires |
I tought that a colored light would be done with 256(if someone plans to try it one day...) |
16:10 |
Sires |
well, it does not increases so much the mapblock size I think |
16:12 |
Sires |
I tried reading a bit tile.cpp file but I'm not really good with c++, most of the stuff I read I understand the syntax but no so much the logic and where it came from(because to do that I would need to read lots of files) |
16:13 |
|
bas080 joined #minetest |
16:18 |
* deltasquared |
does some rough calculations |
16:18 |
deltasquared |
so let's say an active mapblock of 8, for the sake of calculation I'll assume a cube... |
16:19 |
|
sonicpp joined #minetest |
16:19 |
deltasquared |
right, so that's like 16777216 nodes max per player if no overlap. |
16:19 |
deltasquared |
(not including other overhead) |
16:20 |
deltasquared |
full rgb lighting with 8 bits per channel, depending on how you structured it, would either be 3 to 4 times that in bytes, so at worst an extra 64MB per player |
16:20 |
deltasquared |
that *could* get ouch depending on the size of the server |
16:21 |
Sires |
I mean the 4 bits |
16:21 |
Sires |
we already have 4 bits for the light intensity |
16:21 |
Sires |
we would use 16 bits |
16:21 |
Sires |
instead |
16:21 |
Sires |
making humm |
16:21 |
* Sires |
thinks |
16:22 |
Sires |
let-me do some calculations too :P |
16:22 |
deltasquared |
actually we'd only need an extra byte (2 * 4 = eight bits) per node |
16:22 |
deltasquared |
so it'd be 16MB per player |
16:22 |
deltasquared |
(in the worst case scenario) |
16:22 |
deltasquared |
+16MB rather, as that's extra over the memory already taken by nodes |
16:22 |
Sires |
one sec |
16:22 |
numzero |
don't forget there are 2 light banks |
16:23 |
deltasquared |
numzero: ... shet |
16:23 |
Sires |
what is a light bank? I'm not good at english |
16:23 |
deltasquared |
IIRC each node currently takes 32 bits of data - 16 bit internal node ID + 8-bit param1 + param2 values |
16:23 |
numzero |
yes |
16:23 |
numzero |
param1 stores 2 light values: |
16:23 |
numzero |
night and day light |
16:24 |
Sires |
oh ok |
16:24 |
deltasquared |
the game fades between them for sky-lit blocks during sunset I would guess |
16:24 |
deltasquared |
and sunrise. |
16:25 |
Sires |
so param2 values is 8 bits right ? |
16:25 |
deltasquared |
Sires: yep |
16:25 |
Sires |
hum |
16:25 |
deltasquared |
ok so you'd need an extra 2 bytes per node, so 32MB... I think it'd only be nice to access if it were stored as a sep. array in memory. Idk if the current node layout packs the node ID + param values together, but it would be 4 bytes so nicely aligned |
16:25 |
Sires |
why is param1 8 bit, isn't 4 bits enough for the light ? |
16:26 |
numzero |
Sires, there are 2 light values: |
16:26 |
Sires |
sory I'm new at this :P |
16:26 |
deltasquared |
Sires: see above, only one param value is used for both light levels |
16:26 |
numzero |
night light and day light |
16:26 |
numzero |
I just told that |
16:26 |
Sires |
I tough it was stored in param2 |
16:26 |
numzero |
no |
16:26 |
deltasquared |
the *other* 8-bit param value (I forget if it's param1 or param2) is used for whatever the node wants generally |
16:26 |
numzero |
param2 is used for other things, like node rotation |
16:26 |
numzero |
liquid level |
16:26 |
numzero |
etc |
16:26 |
Sires |
oh ok |
16:29 |
numzero |
deltasquared, what's your estimation of mapblocks loaded around a player? |
16:39 |
|
FreeFull joined #minetest |
16:40 |
deltasquared |
numzero: 16^3 |
16:40 |
deltasquared |
so this is like a beeeeefy server |
16:41 |
deltasquared |
I wanted to add in suitable margins as it were |
16:41 |
|
bas080 joined #minetest |
16:41 |
deltasquared |
if you were to do something saner like a radius of 6... hold on |
16:42 |
numzero |
so, 128 nodes apx. in each direction. reasonable, as that's amount of blocks in memory, not active blocks |
16:42 |
deltasquared |
numzero: right, so it wouldn't all be "hot" either |
16:42 |
deltasquared |
cache wise |
16:43 |
deltasquared |
... hrm, I might have screwed up a calculation somethere |
16:44 |
numzero |
actually we can only guess as long as we can't mesaure actual memory usage |
16:44 |
numzero |
the server should make such data available to the admin |
16:44 |
deltasquared |
numzero: true, I'm just assuming theoretical memory usage for a sane layout, given that MT should probably at least store it contigiously for speed |
16:44 |
deltasquared |
and compactness. |
16:45 |
deltasquared |
idk if the server actually stores a mapblock's nodes as one array |
16:45 |
numzero |
mapblock is stored contigiously in RAM |
16:45 |
deltasquared |
numzero: are the nodes packed? like ID + param1,2 interleaved |
16:46 |
deltasquared |
adding something like two extra bytes for colour channels would likely only be sane if it were a sep. array |
16:46 |
numzero |
of course the values are interleaved |
16:46 |
numzero |
it stores a plain array of MapNode's |
16:47 |
numzero |
serialized format is different AFAIK, but we're talking about RAM |
16:47 |
deltasquared |
numzero: perfectly fine, it's just that some data oriented programming techniques split things like than in certain cases. I wouldn't say either way without serious performance measurement which is *better* |
16:48 |
deltasquared |
considering that for the hypothetical RGB lighting it'd be an extra two bytes per node, it might be wiser to keep those in a sep. array as otherwise one node becomes 6 bytes, which wastes alignment space. |
16:48 |
deltasquared |
of course, this is kinda academic in any event |
16:48 |
deltasquared |
oh yeah, and I did goof that calculation, 128^3 * 2 bytes would need 4MB per player |
16:49 |
numzero |
er, 128 in each direction means 256^3 nodes |
16:49 |
deltasquared |
numzero: I was working with a *radius* of... ... o shet |
16:49 |
deltasquared |
erm |
16:49 |
numzero |
so you had a radis of 8 |
16:49 |
numzero |
mapblocks |
16:49 |
numzero |
thus 16^3 mapblocks |
16:49 |
deltasquared |
err I guess yah |
16:50 |
deltasquared |
so I was still kinda right? |
16:50 |
numzero |
thus your previous calculations seem right actually |
16:50 |
deltasquared |
ok, this time I won't do any substitution in my head |
16:50 |
deltasquared |
256 * 256 * 256 * 2 |
16:50 |
deltasquared |
32MB |
17:05 |
|
bas080 joined #minetest |
17:10 |
|
deltasquared joined #minetest |
17:15 |
|
Elronnd joined #minetest |
17:20 |
|
nac joined #minetest |
17:30 |
|
Krock joined #minetest |
17:41 |
|
ThomasMonroe joined #minetest |
17:43 |
|
proller joined #minetest |
17:47 |
|
tpe joined #minetest |
17:48 |
|
Taose joined #minetest |
18:08 |
|
nowhere_man joined #minetest |
18:10 |
|
ssieb joined #minetest |
18:28 |
MinetestBot |
[git] numberZero -> minetest/minetest: Rewrite rendering engine (#6253) 2884196 https://git.io/vFY4Z (2017-10-31T18:27:10Z) |
18:29 |
|
Telesight joined #minetest |
18:31 |
|
CWz joined #minetest |
18:55 |
|
redblade7 joined #minetest |
19:00 |
|
proller joined #minetest |
19:15 |
|
EvergreenTree joined #minetest |
19:20 |
|
numzero joined #minetest |
19:21 |
|
QwertyDragon joined #minetest |
19:27 |
|
AlexYst joined #minetest |
19:40 |
|
deltasquared joined #minetest |
20:10 |
|
troller joined #minetest |
20:18 |
|
Fixer_ joined #minetest |
20:28 |
|
troller joined #minetest |
20:45 |
|
troller joined #minetest |
20:45 |
|
nowhere_man joined #minetest |
20:51 |
|
Fixer joined #minetest |
21:25 |
|
deltasquared joined #minetest |
21:34 |
|
deltasquared joined #minetest |
21:51 |
MinetestBot |
[git] DS-Minetest -> minetest-mods/mesecons: Set is_ground_content to false (#386) ff0bd76 https://git.io/vFY7m (2017-10-31T21:50:39Z) |
21:55 |
|
deltasquared joined #minetest |
21:56 |
|
Loquendero joined #minetest |
22:01 |
|
numzero joined #minetest |
22:09 |
|
YuGiOhJCJ joined #minetest |
22:15 |
|
GreenDimond joined #minetest |
22:23 |
GreenDimond |
rubenwardy: So, I put those print statements, and nothing printed |
22:23 |
GreenDimond |
Which doesnt make any sense |
22:26 |
|
numzero1 joined #minetest |
22:28 |
GreenDimond |
For anyone that might know; I am trying to make a node that can only be placed per-player one at a time (desired behavior: Place the node, no longer can place any more of that node. Dig the node, now I can place another.) At the moment, I am unable to even place it. |
22:29 |
GreenDimond |
here is the code: https://gist.github.com/GreenXenith/659994b864e6e549043d11205e1b4d79 |
22:31 |
GreenDimond |
oh |
22:31 |
GreenDimond |
so maybe it is printing |
22:31 |
GreenDimond |
but not to the debug like I want it to |
22:34 |
asl97 |
GreenDimond: did you mean in on_dig? if my lua isn't rusty, can_dig is nil https://gist.github.com/GreenXenith/659994b864e6e549043d11205e1b4d79#file-init-lua-L88 |
22:35 |
asl97 |
it should automatically call it before calling on_dig, you shouldn't need to call it yourself |
22:35 |
GreenDimond |
can_dig https://gist.github.com/GreenXenith/659994b864e6e549043d11205e1b4d79#file-init-lua-L67 |
22:38 |
asl97 |
1. you aren't calling it, 2. I don't think you can actually call it since it is being define in the same object, i could be wrong on 2 though |
22:39 |
GreenDimond |
how would I check if can_place? |
22:39 |
GreenDimond |
can_dig* |
22:40 |
asl97 |
minetest should call it before calling on_dig |
22:41 |
GreenDimond |
hmmmm |
22:41 |
GreenDimond |
first I need to get it to be placeable |
22:41 |
GreenDimond |
I think I know why it isnt |
22:47 |
asl97 |
GreenDimond: check pm for more info on 2 |
22:54 |
orbea |
question: Is this different from the hemp in the farming redo mod? https://github.com/pithydon/hemp |
23:04 |
GreenDimond |
Progress :o |
23:04 |
GreenDimond |
So, apparently previous testing had caused the have_placed to be true, and wouldnt change because there was nothing to dig |
23:05 |
|
YuGiOhJCJ joined #minetest |
23:18 |
|
Tmanyo joined #minetest |
23:34 |
|
proller joined #minetest |