| Time |
Nick |
Message |
| 00:02 |
|
RealBadAngel joined #minetest-dev |
| 00:03 |
RealBadAngel |
sofar, indeed item meta data is the string. but the string can be serialized table -> so it can hold anything |
| 00:03 |
RealBadAngel |
check for example technic tools |
| 00:04 |
sofar |
RealBadAngel: "books" uses it too |
| 00:04 |
|
Fixer joined #minetest-dev |
| 00:05 |
RealBadAngel |
description in api is quite confusing |
| 00:06 |
sofar |
I've started to piece together a more coherent way of using it |
| 00:06 |
sofar |
I'm just going slow... little time here and there in between kids and work and sleep |
| 00:06 |
sofar |
but it's neat I can finally have books show up with their given title |
| 00:08 |
sofar |
RealBadAngel: you'd probably do it in a tenth of the time I could ;) |
| 00:16 |
RealBadAngel |
it could be done, but such item couldnt be stackable rather |
| 00:17 |
sofar |
I wouldn't want to to be stackable |
| 00:17 |
RealBadAngel |
name can be stored ofc in item's meta, theres no problem with it as with nodes (see #3166) |
| 00:17 |
sofar |
such named items are likely unique anyway |
| 00:18 |
|
nolsen joined #minetest-dev |
| 00:20 |
RealBadAngel |
it could be something like a modifier for textures |
| 00:20 |
RealBadAngel |
which will cause to read the name from specified location (meta) |
| 00:22 |
RealBadAngel |
or even a field in itemdef |
| 00:22 |
RealBadAngel |
that will cause less problems i think |
| 00:26 |
sofar |
RealBadAngel: while that sounds great, I'm really just looking at having the code display a different item name in any inventory view :) |
| 00:26 |
sofar |
the rest all needs client-side coding to handle each individual custom field to do overrides in metadata |
| 00:28 |
sofar |
the issue I see now is that we need a new serialization function in the l_item.cpp, and another deserialization in guiFormSpecMenu.cpp |
| 00:28 |
* sofar |
wraps head some more |
| 00:29 |
|
est31 joined #minetest-dev |
| 00:40 |
sofar |
how receptive are folks to stuff like this: https://github.com/minetest/minetest_game/pull/737 ? |
| 00:41 |
thePalindrome |
I would be more than okay with it, but I'm not sure if anyone else would have any objections |
| 00:42 |
sofar |
I have a stash of modifications that likely can go in to minetest_game, some are simple like this one... trying to get an idea whether upstreaming is worth it or not. |
| 00:43 |
sofar |
I see very little cosmetic tweaks in minetest_game |
| 01:21 |
|
H-H-H joined #minetest-dev |
| 02:41 |
|
asl97 joined #minetest-dev |
| 04:11 |
|
nolsen_ joined #minetest-dev |
| 06:07 |
|
Calinou joined #minetest-dev |
| 06:21 |
|
est31 joined #minetest-dev |
| 06:23 |
|
leat joined #minetest-dev |
| 06:53 |
|
Hunterz joined #minetest-dev |
| 07:07 |
sofar |
sometimes lua has me completely baffled |
| 07:07 |
sofar |
1) elseif node.name:sub(1, 16) == "doors:door_steel" then |
| 07:07 |
sofar |
works |
| 07:07 |
sofar |
2) if node.name:sub(18, 1) == "t" then |
| 07:08 |
sofar |
never works, node.name:sub(18,1) is always "" in this context |
| 07:12 |
VanessaE |
why would it? that's out past the end of the string |
| 07:12 |
sofar |
no |
| 07:12 |
VanessaE |
that 't' is at position 13.... |
| 07:12 |
sofar |
node.name is actually doors:doot_steel_t_1 |
| 07:12 |
VanessaE |
ah |
| 07:12 |
sofar |
doors:door_steel_t_1 |
| 07:13 |
sofar |
so it's 2 characters beyond the 16 |
| 07:13 |
sofar |
if I print "node.name" in the elseif, it's got the 20 character full name in it |
| 07:13 |
sofar |
but print(string.sub(node.name, 18, 1)) |
| 07:13 |
sofar |
prints nothing |
| 07:14 |
VanessaE |
that's because the third argument is an absolute position also. |
| 07:14 |
VanessaE |
so you'd want 18, 19 and "t_" for your test string |
| 07:14 |
sofar |
oh OF COURSE LUA DOES IT DIFFERENTLY |
| 07:14 |
VanessaE |
heheh |
| 07:14 |
sofar |
fuck me |
| 07:16 |
VanessaE |
it's just keeping you on your toes :) |
| 07:17 |
sofar |
ok so |
| 07:17 |
sofar |
I've just implemented *keys* to lockable doors, trapdoors and chests |
| 07:17 |
sofar |
you can craft skeleton keys |
| 07:17 |
sofar |
and if the owner of a locked item uses a skeleton key on a lockable thing |
| 07:17 |
sofar |
then they can give that key to other players to open the chest, door/trapdoor and get items from it |
| 07:18 |
VanessaE |
there...um |
| 07:18 |
VanessaE |
is a mod for that. |
| 07:18 |
sofar |
I looked at that and didn't like the implementation |
| 07:18 |
sofar |
it makes non-default chests |
| 07:18 |
VanessaE |
Soko is gonna hate you ;) |
| 07:18 |
sofar |
this mod works with default chests |
| 07:18 |
sofar |
and default doors |
| 07:18 |
sofar |
oh, and the keys are specific to the door or chest |
| 07:19 |
sofar |
if you break the door, and put a new one there, none of the old keys will fit |
| 07:19 |
sofar |
same with the chests |
| 07:19 |
sofar |
and the trapdoor |
| 07:19 |
VanessaE |
I like that idea |
| 07:19 |
VanessaE |
to a degree that is |
| 07:19 |
sofar |
of course, the default trapdoor is also a new addition |
| 07:19 |
VanessaE |
after all, surely keys that you've crafted should work on any door you put in a given location |
| 07:20 |
sofar |
nope, a key only ever fits on one thing |
| 07:20 |
VanessaE |
my house's front door locks disagree :D |
| 07:20 |
sofar |
well you can create many keys that open one door |
| 07:21 |
|
Kray joined #minetest-dev |
| 07:21 |
VanessaE |
I'm just saying you may have some trouble "selling" your idea -- I'm thinking specifically of the cost to recraft the keys. are they recyclable? |
| 07:21 |
sofar |
I was thinking of making a recycling option |
| 07:21 |
sofar |
right now I have them made out of 1 gold ingot |
| 07:22 |
sofar |
should be trivial to make that reversable |
| 07:22 |
sofar |
and yes, I'll probably do that |
| 07:22 |
sofar |
actually, I should make it smeltable :) |
| 07:22 |
VanessaE |
I suggest borrowing an idea from homedecor: split the ingot into strips (I think it's 6 per), use those to craft the keys |
| 07:22 |
sofar |
smelt it back in an oven |
| 07:23 |
sofar |
yeah, minecraft has nuggets |
| 07:23 |
VanessaE |
well homedecor does that with steel and copper ingots anyway |
| 07:23 |
VanessaE |
didn't realize MC had a similar idea |
| 07:23 |
sofar |
stuff like that should just go into default |
| 07:23 |
sofar |
it's way too useful |
| 07:23 |
VanessaE |
splitting of ingots into strips? |
| 07:24 |
sofar |
strips, nuggets, whatever you call it |
| 07:24 |
sofar |
still have to fix up the last thing to actually open doors (the rest is done) |
| 07:26 |
VanessaE |
I agree with that idea |
| 07:27 |
VanessaE |
lesse... steel, copper, bronze, gold, ...and I'm missing one I think |
| 07:27 |
|
asl97 joined #minetest-dev |
| 07:27 |
VanessaE |
so 4 or 5 new items. Of course you know they'll end up being kinda "ignored" like mese crystal fragments are :P |
| 07:29 |
sofar |
well mese is really just an odd material |
| 07:30 |
sofar |
I wouldn't add nuggets for iron or bronze. maybe just for gold initially |
| 07:30 |
VanessaE |
homedecor uses copper and steel strips pretty extensively actually |
| 07:30 |
VanessaE |
of course that's only one mod |
| 07:31 |
sofar |
btw you may also like https://github.com/minetest/minetest_game/pull/737 |
| 07:31 |
sofar |
and I'm working on an idea to have "named" itemstacks for single-itemstack-items |
| 07:32 |
VanessaE |
good idea about the book, but I wonder if a "belt and buckle" is the best indicator? |
| 07:32 |
VanessaE |
what about a bookmark sticking out one end? |
| 07:32 |
sofar |
my wife recognized it instantly |
| 07:32 |
VanessaE |
to me, "belt and buckle" applied to a book suggests "locked" as in a diary |
| 07:32 |
sofar |
make that one in your x32 texture pack ;) |
| 07:33 |
sofar |
it actually IS locked, to other players |
| 07:33 |
sofar |
they can only view it, not modify |
| 07:33 |
VanessaE |
hm |
| 07:33 |
VanessaE |
I'd forgotten about that. |
| 07:34 |
VanessaE |
looks good to me then |
| 07:34 |
VanessaE |
(but my vote doesn't count here :P ) |
| 07:37 |
|
Obani joined #minetest-dev |
| 07:48 |
|
nrzkt joined #minetest-dev |
| 08:40 |
|
jin_xi joined #minetest-dev |
| 08:44 |
|
Kray joined #minetest-dev |
| 09:08 |
|
Kray joined #minetest-dev |
| 09:39 |
|
Amaz joined #minetest-dev |
| 09:41 |
|
rubenwardy joined #minetest-dev |
| 09:54 |
|
harrison joined #minetest-dev |
| 10:23 |
|
celeron55 joined #minetest-dev |
| 10:29 |
|
rubenwardy joined #minetest-dev |
| 10:32 |
|
proller joined #minetest-dev |
| 10:44 |
|
RBA_ joined #minetest-dev |
| 11:39 |
|
proller joined #minetest-dev |
| 11:48 |
|
asl97 joined #minetest-dev |
| 11:59 |
|
hmmmm joined #minetest-dev |
| 12:00 |
|
Fixer joined #minetest-dev |
| 12:07 |
|
asl97 joined #minetest-dev |
| 12:31 |
|
behalebabo joined #minetest-dev |
| 13:21 |
|
PenguinDad joined #minetest-dev |
| 13:40 |
|
Darcidride joined #minetest-dev |
| 14:07 |
|
zat joined #minetest-dev |
| 14:33 |
|
luizrpgluiz joined #minetest-dev |
| 14:35 |
|
hmmmmm joined #minetest-dev |
| 14:38 |
|
alket joined #minetest-dev |
| 14:46 |
|
Darcidride joined #minetest-dev |
| 14:50 |
|
Darcidride joined #minetest-dev |
| 15:13 |
sofar |
so I find my test minetest server running overnight spewing these after ~1 hours of running: |
| 15:13 |
sofar |
2015-12-08 07:02:32: WARNING[Server]: active block modifiers took 845ms (longer than 200ms) |
| 15:14 |
sofar |
and I'm wondering if it's not cleaning up particle spawners that fire regularly that have expired |
| 15:18 |
sfan5 |
particle spawners cause no load on the server |
| 15:18 |
sfan5 |
(or at least they should, don't know how they're implemented) |
| 15:18 |
sofar |
then I need to hunt down why abm's are causing it to bog down |
| 15:19 |
sofar |
there's about 4-5 seconds in between that message being printed |
| 15:30 |
|
jin_xi joined #minetest-dev |
| 15:49 |
|
CraigyDavi joined #minetest-dev |
| 16:01 |
|
proller joined #minetest-dev |
| 16:33 |
|
proller joined #minetest-dev |
| 16:36 |
|
kahrl joined #minetest-dev |
| 16:38 |
|
DFeniks joined #minetest-dev |
| 16:38 |
|
johnnyjoy joined #minetest-dev |
| 16:42 |
|
Krock joined #minetest-dev |
| 16:52 |
|
alket joined #minetest-dev |
| 16:52 |
|
nrzkt joined #minetest-dev |
| 16:59 |
|
zupoman joined #minetest-dev |
| 16:59 |
|
zupoman joined #minetest-dev |
| 17:02 |
|
AnotherBrick joined #minetest-dev |
| 17:04 |
|
proller joined #minetest-dev |
| 17:16 |
|
Hunterz joined #minetest-dev |
| 17:18 |
|
Obani joined #minetest-dev |
| 17:26 |
|
luizrpgluiz left #minetest-dev |
| 17:50 |
|
rubenwardy joined #minetest-dev |
| 18:14 |
|
hawksuqawks joined #minetest-dev |
| 18:41 |
|
Supertanker2 joined #minetest-dev |
| 18:46 |
|
younishd joined #minetest-dev |
| 19:39 |
|
Supertanker2 joined #minetest-dev |
| 20:11 |
jin_xi |
sofar: there is something wrong with particle spawners, if a spawner has a set lifespan its ID number is never cleared when the spawner expires |
| 20:11 |
jin_xi |
minetest maintains a list of all spawners which keeps growing |
| 20:17 |
sofar |
yeah, that's exactly what my thought was |
| 20:17 |
sofar |
I added a particle with 0.1 time, I guess I should try 0 |
| 20:46 |
|
proller joined #minetest-dev |
| 21:57 |
|
nolsen joined #minetest-dev |
| 21:58 |
|
neoascetic joined #minetest-dev |
| 21:59 |
neoascetic |
Hi everyone. So, there is no such thing as force_load for entities anymore? https://github.com/minetest/minetest/pull/606 |
| 22:15 |
|
Kray joined #minetest-dev |
| 23:05 |
|
proller joined #minetest-dev |
| 23:09 |
|
younishd_ joined #minetest-dev |
| 23:18 |
|
Player2 joined #minetest-dev |
