| Time |
Nick |
Message |
| 00:24 |
|
DuDraig joined #minetest-dev |
| 00:52 |
|
Miner_48er joined #minetest-dev |
| 01:15 |
|
Zeno` joined #minetest-dev |
| 02:05 |
|
NakedFury joined #minetest-dev |
| 02:22 |
|
prozacgod joined #minetest-dev |
| 02:23 |
|
mos_basik joined #minetest-dev |
| 03:05 |
|
CraigyDavi` joined #minetest-dev |
| 03:19 |
|
rickmcfarley joined #minetest-dev |
| 03:45 |
|
Hunterz joined #minetest-dev |
| 04:50 |
|
kaeza joined #minetest-dev |
| 04:51 |
|
T4im joined #minetest-dev |
| 05:33 |
hmmmm |
ugh |
| 05:33 |
hmmmm |
you know what, I'm going to unify name resolution |
| 05:33 |
hmmmm |
the way it happens right now works but it's sloppy |
| 05:34 |
hmmmm |
have your data structure (biomes, decorations, schematics, whatever have you) include a std::string or a list of strings of the node name, then on emerge manager init, resolve them to the ID for each and every instance of these resources |
| 05:36 |
hmmmm |
i'm going to expand INodeDef to keep a list of strings to content_t *s, or std::vector<content_t> *s (if the node string name represents a group) and when the node registration finishes, that will carry out the assignments |
| 05:37 |
hmmmm |
this way, everything is unified, saves on the potentially huge space of extra std::strings that don't need to be maintained after name resolution, etc. |
| 05:42 |
|
rickmcfarley joined #minetest-dev |
| 05:43 |
VanessaE |
um guys? why are there still old "minetestc55" builds on the "daily-builds" and "stable" PPAs? |
| 05:43 |
VanessaE |
that build is horribly outdated |
| 05:45 |
|
Hunterz joined #minetest-dev |
| 05:48 |
hmmmm |
because obvs older software == more stable |
| 05:52 |
VanessaE |
older all the way back to Ubuntu Natty though? eh... |
| 05:55 |
|
OldCoder joined #minetest-dev |
| 05:57 |
Zeno` |
I'm having a problem: https://github.com/minetest/minetest/pull/1707 |
| 05:58 |
Zeno` |
I cannot *nicely* check that the destination slot is either contains the same item or is empty and not move(drop) if that's not true |
| 05:59 |
Zeno` |
mainly because I'd have to duplicate the first 6 lines in the next conditional or make those lines a function or do something else kind of messy (I think) |
| 06:02 |
Zeno` |
I suppose I could add another bool |
| 06:18 |
hmmmm |
wouldn't the modulo logic you already have be better expressed as a bool like "m_drop_item" |
| 06:18 |
hmmmm |
and then you just do m_drop_item = !m_drop_item instead of m_lmouse_move_mode = (m_lmouse_move_mode + 1) % 2; |
| 06:19 |
hmmmm |
and you say "first 6 lines in the next conditional" - where is that you're talking about? |
| 06:20 |
Zeno` |
Yeah I originally kept track of button releases as well, so maybe a bool with ! as you suggested is fine |
| 06:21 |
Zeno` |
in the main code (full file) |
| 06:21 |
Zeno` |
lines... |
| 06:21 |
Zeno` |
3146-3151 |
| 06:22 |
Zeno` |
I think |
| 06:23 |
kahrl |
or even, instead of a bool, a set of slots that the item has already been dropped into |
| 06:23 |
kahrl |
oh nvm |
| 06:23 |
hmmmm |
hmm |
| 06:23 |
kahrl |
thought you could initialize that with the initial slot but that would be ugly |
| 06:23 |
hmmmm |
Zeno`, code it up the 'messy' way and we'll see what we could do from there |
| 06:23 |
Zeno` |
kahrl, I was trying to mimic the MC behaviour where you can right drag around to evenly distribute the item but NOT swap with an item in a slot that contains a different item |
| 06:24 |
Zeno` |
ok I'll do it the messy way |
| 06:24 |
hmmmm |
I personally like the MC behavior |
| 06:24 |
hmmmm |
so +1 for that |
| 06:24 |
hmmmm |
you have my le upboat |
| 06:24 |
kahrl |
Zeno`: oh, in that case add the set I mentioned (maybe in addition to the bool/int/whatever) |
| 06:24 |
kahrl |
so every slot can only be dropped into once |
| 06:24 |
kahrl |
(that's how it works in MC) |
| 06:26 |
Zeno` |
I need to find the video someone showed me in that case :) searching logs |
| 06:27 |
kahrl |
I really think at this point the inventory handling in GUIFormSpecMenu has become way too overgrown |
| 06:27 |
kahrl |
it has been like that for a long while already |
| 06:27 |
kahrl |
it should be split into a separate class |
| 06:28 |
kahrl |
(but don't bother about it in this fix) |
| 06:28 |
hmmmm |
guys, what's the consensus on legacy hard-coded ABMs |
| 06:28 |
hmmmm |
never going to happen again? |
| 06:28 |
hmmmm |
what is the performance impact of growing grass from within Lua? |
| 06:28 |
VanessaE |
hard-coded in the engine? FUCK no |
| 06:29 |
hmmmm |
some things like growing grass might be better off in the engine though. |
| 06:29 |
VanessaE |
I have enough of an issue with ABMs in the default game; growing grass from Lua isn't that big of an impact. |
| 06:29 |
hmmmm |
that's not an issue |
| 06:30 |
hmmmm |
you could add a tiny knob in lua to turn that on or off |
| 06:30 |
VanessaE |
after all, you only hit that kind of code once every, what, 5 or 10 minutes? |
| 06:30 |
hmmmm |
that code gets hit very often |
| 06:30 |
VanessaE |
well wait, you mean the dirt <-> grass ABM? |
| 06:30 |
hmmmm |
yes |
| 06:30 |
VanessaE |
eh |
| 06:30 |
VanessaE |
that's not a big deal |
| 06:30 |
hmmmm |
but how do you knooow that |
| 06:31 |
VanessaE |
because Nostalgia game manages it without even a hiccup |
| 06:31 |
hmmmm |
erm.. whatever |
| 06:31 |
kahrl |
the probability is high enough that I don't see a problem |
| 06:31 |
kahrl |
err *low |
| 06:31 |
VanessaE |
I had to backport that change when that ABM was moved out of the engine and I saw no performance impact at all |
| 06:32 |
Zeno` |
kahrl, I was just talking about that to someone else heh |
| 06:33 |
hmmmm |
we want to stay envlocked for as short a period time as possible |
| 06:33 |
hmmmm |
going back and forth from native to lua thousands of times over and over is a hit |
| 06:33 |
hmmmm |
one that's definitely not necessary |
| 06:34 |
hmmmm |
you say it's not much of a hit, but have you tried to quantify it at all? |
| 06:34 |
hmmmm |
if we can save 10ms, that's awesome |
| 06:34 |
Zeno` |
messy way is pushed (I hate it) |
| 06:34 |
Zeno` |
I doubt it behaves exactly like MC, but it makes sense (well, to me anyway) |
| 06:35 |
VanessaE |
hmmmm: at the time, of course, there was no profiler, so I only had my CPU stats page to go by ( http://digitalaudioconcepts.com/vanessa/hobbies/minetest/stats.html ). Nostalgia was a very busy server then, and it barely registered on the CPU graph. |
| 06:35 |
kahrl |
hmmmm: would it be possible to only do the C++ -> Lua transition once for all registered ABMs? (per abmhandler.apply) |
| 06:36 |
hmmmm |
kahrl: wait, is that how it works?? |
| 06:36 |
kahrl |
hmmmm: not at the moment I don't think |
| 06:36 |
hmmmm |
yeah I figured as much |
| 06:36 |
hmmmm |
ugh |
| 06:36 |
kahrl |
hmmmm: but it could be done |
| 06:36 |
hmmmm |
UGHH |
| 06:36 |
hmmmm |
let's do it |
| 06:36 |
hmmmm |
as if the server step isn't slow enough already |
| 06:39 |
kahrl |
it was done this way so that the C++ code can ensure a later called ABM still has satisfied conditions after the earlier ones ran |
| 06:39 |
kahrl |
wonder how much would break if that wasn't done |
| 06:41 |
hmmmm |
'satisfied conditions'? |
| 06:42 |
kahrl |
i.e. node is in nodenames, certain neighbors exist, etc. |
| 06:43 |
kahrl |
oh and it recalculates the active object count if an ABM added any |
| 06:44 |
hmmmm |
yeah I saw that much |
| 06:45 |
hmmmm |
well look, ABMHandler's ctor calculates all the chances and trigger contents there |
| 06:46 |
hmmmm |
so aside from the active object count, it can't possibly do what you said it did before |
| 06:46 |
hmmmm |
the only thing it does in between ABMs is check the active object count |
| 06:47 |
hmmmm |
can that piece of logic be moved outside of each ABM call for that block?? |
| 06:48 |
kahrl |
oh you're right, it doesn't handle every case |
| 06:48 |
kahrl |
it rechecks the content after moving on to the next node though |
| 06:48 |
kahrl |
(the outer loop in apply()) |
| 06:49 |
kahrl |
but if a node changes and there are more ABMs for that node, it only rechecks the neighbors |
| 06:49 |
kahrl |
so I guess ABMs already have to deal with the chance the node might actually not be the node they were assuming it was |
| 06:50 |
kahrl |
how many ABMs actually use active_object_count/_wider? |
| 06:51 |
hmmmm |
not many... i can't think of any practical utility for that |
| 06:51 |
kahrl |
perhaps it could be removed entirely |
| 06:51 |
VanessaE |
kahrl: in my ABMs I've never actually done that unless I was checking for more than one kind of node |
| 06:51 |
VanessaE |
(chance of a node not being the one it's assumed to be) |
| 06:52 |
VanessaE |
I've never used the *object* features myself, but I'll bet sapier does. |
| 06:52 |
kahrl |
VanessaE: in most cases the player wouldn't notice anyway (as the two ABMs happen in the same server step, so it wouldn't matter) |
| 06:52 |
hmmmm |
hmmmmmmmmmmmm. |
| 06:52 |
kahrl |
VanessaE: but it could break something if node metadata is involved |
| 06:52 |
hmmmm |
kahrl, I'm thinking of a situation where two different mods would use something like a sapling |
| 06:52 |
hmmmm |
one would grow it into a certain kind of tree and one into another |
| 06:52 |
kahrl |
hmmmm: yeah, that too |
| 06:52 |
hmmmm |
well the result would be a hybrid |
| 06:54 |
hmmmm |
this is tough |
| 06:55 |
kahrl |
VanessaE: I think mobf uses way more complicated algorithms than checking active_object_count |
| 06:56 |
VanessaE |
kahrl: nope |
| 06:56 |
VanessaE |
he uses it |
| 06:56 |
hmmmm |
so I don't get it |
| 06:56 |
kahrl |
hrm |
| 06:57 |
VanessaE |
hm, seems I use it in moretrees' leaf decay too |
| 06:57 |
kahrl |
simplemobs does some stuff with it too |
| 06:57 |
VanessaE |
(likely as result of some copypasta from default) |
| 06:57 |
hmmmm |
if mods already assume their ABM nodes are really the ones they wanted, and we don't see breakage already, then what would the harm be? |
| 06:58 |
VanessaE |
vanessa rainbird:~/Minetest-related/mods$ grep -ir active_object_count *|wc |
| 06:58 |
VanessaE |
174 1216 20940 |
| 06:58 |
VanessaE |
I'm sure most of those are false positives. |
| 06:58 |
kahrl |
VargaD: add a grep -v function in there |
| 06:58 |
VanessaE |
heh |
| 06:58 |
kahrl |
oops, sorry |
| 06:58 |
kahrl |
VanessaE: * |
| 06:59 |
VargaD |
hi |
| 06:59 |
kahrl |
hi ;) |
| 07:00 |
VanessaE |
hmmmm: I can't say that there'd be any; don't most mods assume their ABMs will execute more or less independently? |
| 07:00 |
hmmmm |
they do yeah |
| 07:01 |
hmmmm |
no mod has a guarantee that another mod didn't change their node that had an ABM triggered on it. no mod has a guarantee that another ABM didn't change a neighboring node |
| 07:01 |
hmmmm |
well, the latter assertion isn't true right now, but i'd like that to be true so we could just do one lua call for every abm |
| 07:01 |
VanessaE |
that's what I figured. so then to fix it (so to speak) so that that assumption is in fact enforced shouldn't break anything at all |
| 07:02 |
VanessaE |
if some modder plays off the idea that their ABMs will magically occur at just the right moment, they're insane |
| 07:03 |
hmmmm |
indeed |
| 07:03 |
hmmmm |
these kinds of glitches that the way ABMs work right now to prevent are practically unavoidable |
| 07:03 |
hmmmm |
hrmm it's 3 AM |
| 07:03 |
hmmmm |
lol I thought I was going to get a commit in! |
| 07:03 |
hmmmm |
guess not |
| 07:03 |
kahrl |
heh |
| 07:04 |
VanessaE |
ok, ... |
| 07:04 |
VanessaE |
kahrl: he DOES use active_object_count. |
| 07:04 |
kahrl |
VanessaE: who's he? |
| 07:04 |
VanessaE |
sapier I mean. |
| 07:04 |
VanessaE |
just in one place though, in tracing.lua |
| 07:04 |
kahrl |
hmm ok |
| 07:05 |
hmmmm |
guys, what do you think about moving the declaration for CNodeDefManager out into nodedef.h |
| 07:05 |
kahrl |
hmmmm: why? |
| 07:06 |
hmmmm |
reduce a level of indentation |
| 07:06 |
hmmmm |
cleaner |
| 07:06 |
kahrl |
it does expose implementation details though and slows compilation |
| 07:07 |
hmmmm |
well |
| 07:07 |
Zeno` |
it only seems to be used in nodedef.cpp |
| 07:07 |
hmmmm |
I'll keep it in |
| 07:07 |
VanessaE |
kahrl: 12 pseudo-legit refs in my archives, after filtering out "action = function". |
| 07:07 |
hmmmm |
I get the whole opaque implementation of an abstract interface idea but I don't think it matters that much in practicality |
| 07:08 |
hmmmm |
it'd be a huge improvement to just get rid of that extra indentation by separating the method definitions and the class declaration, though. |
| 07:08 |
kahrl |
hmmmm: you could also split class declaration and function implementation but keep them both in nodedef.cpp |
| 07:08 |
Zeno` |
Well I pass by pointer or reference 99% of the time so I forward decls work fine. I think it's pretty much a muchness though |
| 07:08 |
hmmmm |
yeah that's just what i said. |
| 07:08 |
kahrl |
hmmmm: oh, thought you still meant moving it to nodedef.h |
| 07:10 |
kahrl |
86a3c8ce56 was a recent commit that did something like that |
| 07:19 |
hmmmm |
am I the only one who doesn't like crap like this |
| 07:19 |
hmmmm |
if (f->name == "default:water_source") |
| 07:19 |
hmmmm |
is_water_surface = true; |
| 07:20 |
VanessaE |
oh no.. |
| 07:20 |
VanessaE |
where are you finding that? |
| 07:20 |
hmmmm |
that is a target for api-ization once client side lua becomes a thing |
| 07:20 |
hmmmm |
VanessaE, CNodeDefManager::updateTextures() |
| 07:21 |
hmmmm |
it looks like the work of RBA |
| 07:21 |
hmmmm |
I don't blame him though, it's the least bad option available currently |
| 07:21 |
VanessaE |
I wouldn't touch that if I were you, he'll kick your ass ;) |
| 07:23 |
VanessaE |
hm |
| 07:24 |
VanessaE |
yeah. I haven't seen the code he's working on but if I guess it right, that glistening surface shader is gonna end up messing with this |
| 07:24 |
VanessaE |
he wants to keep the water node name hard-coded :-/ |
| 07:25 |
VanessaE |
*looks at clock* |
| 07:25 |
* VanessaE |
pokes RealBadAngel |
| 07:25 |
VanessaE |
and no, I don't like it either. |
| 07:25 |
VanessaE |
it should depend on some kind of flag/field in the node def |
| 07:26 |
hmmmm |
like I said though, it's the least bad option |
| 07:26 |
hmmmm |
given the restrictions and so on |
| 07:26 |
hmmmm |
but yeah. |
| 07:26 |
VanessaE |
I suppose so |
| 07:26 |
hmmmm |
client side lua couldn't come fast enough. |
| 07:26 |
hmmmm |
people would be able to distribute shaders with their mods |
| 07:26 |
VanessaE |
I guess it could be worse: it could be using a content ID instead. |
| 07:26 |
hmmmm |
so their special node can ACTUALLY be special |
| 07:27 |
VanessaE |
now THAT's a good idea |
| 07:27 |
hmmmm |
ehe |
| 07:27 |
hmmmm |
all this is a lot of talk though |
| 07:27 |
VanessaE |
talking helps plan things out :) |
| 07:27 |
hmmmm |
I'd be able to do half this crap if I take a vacation from work |
| 07:27 |
kahrl |
I don't know if client side lua would actually mean mod-defined shaders... |
| 07:27 |
hmmmm |
or maybe I just need to double down on coding |
| 07:28 |
kahrl |
remember all the security issues webgl had? |
| 07:28 |
hmmmm |
yeah |
| 07:28 |
kahrl |
and still has probably |
| 07:28 |
VanessaE |
kahrl: good point. a shader API then? |
| 07:28 |
kahrl |
VanessaE: maybe |
| 07:28 |
hmmmm |
that was fixed up at the driver level though |
| 07:28 |
VanessaE |
I mean, a sandbox, you know |
| 07:29 |
hmmmm |
I don't think web browsers did anything to secure webgl |
| 07:29 |
kahrl |
http://security.stackexchange.com/questions/13799/is-webgl-a-security-concern#13840 |
| 07:29 |
hmmmm |
it's certainly a DoS concern |
| 07:29 |
kahrl |
that post is a bit old though |
| 07:30 |
hmmmm |
yeah but |
| 07:30 |
hmmmm |
mods can't steal information this way because it wouldn't be able to recontact the server with the data |
| 07:30 |
hmmmm |
that'd be very non-trivial, anyway |
| 07:31 |
hmmmm |
also minetest servers have a slightly higher degree of trust than a random webserver |
| 07:31 |
|
ImQ009 joined #minetest-dev |
| 07:32 |
VanessaE |
hmmmm: that's debatable ;) but your point stands |
| 07:33 |
|
proller joined #minetest-dev |
| 08:47 |
|
ImQ009 joined #minetest-dev |
| 08:47 |
|
jin_xi joined #minetest-dev |
| 09:03 |
jin_xi |
shader security concerns? im curious, because thats what i did (local hack): make shaders per nodedef passable/possible |
| 09:04 |
|
BlockMen joined #minetest-dev |
| 09:05 |
BlockMen |
going to merge https://github.com/minetest/minetest/pull/1694 in an hour |
| 09:06 |
kahrl |
BlockMen: have you settled the disagreement with SN over whether to remove the preload items cb? |
| 09:07 |
kahrl |
jin_xi: well, if it's a local hack then it's not much of a security concern :3 |
| 09:08 |
BlockMen |
kahrl, he said "Nah, that's O.K." |
| 09:10 |
kahrl |
I see it now |
| 09:10 |
jin_xi |
surely not. its just never ocurred to me that security is an issue with shaders |
| 09:10 |
|
exio4 joined #minetest-dev |
| 09:10 |
jin_xi |
or can be |
| 09:11 |
kahrl |
BlockMen: is the case in nodedef supposed to fall-through? |
| 09:11 |
kahrl |
BlockMen: (if it is, it definitely needs a comment) |
| 09:12 |
kahrl |
I mean this: https://github.com/minetest/minetest/pull/1694/files#diff-70868aa6d6b96c0c1623c761500d23c4R670 |
| 09:14 |
BlockMen |
oh, i missid adding content_mapbloc.cpp |
| 09:14 |
BlockMen |
its handled like with allfaces_optional |
| 09:15 |
Zeno` |
if that's the case that's not what it's doing |
| 09:18 |
BlockMen |
kahrl, updated |
| 09:19 |
|
edlothiol joined #minetest-dev |
| 09:22 |
kahrl |
Zeno`: what do you mean? |
| 09:23 |
kahrl |
BlockMen: connected_glass should be in minetest.conf.example |
| 09:28 |
BlockMen |
kahrl, added |
| 09:29 |
kahrl |
BlockMen: I think it's good to go then |
| 09:29 |
kahrl |
merge it |
| 09:30 |
Zeno` |
Is is being handled by NDT_ALLFACES or NDT_ALLFACES_OPTIONAL ? |
| 09:30 |
kahrl |
BlockMen: wait, the case is back to fall-through |
| 09:31 |
BlockMen |
Zeno`, no? |
| 09:31 |
BlockMen |
what make you think that? |
| 09:31 |
Zeno` |
because of the missing break; it looks like it's handled by NDT_ALLFACES |
| 09:33 |
Zeno` |
(handled in part) |
| 09:33 |
BlockMen |
wtf, indeed |
| 09:34 |
kahrl |
huh, I thought for sure you fixed it in the earlier update |
| 09:34 |
kahrl |
am I just imagining things? |
| 09:35 |
BlockMen |
maybe it got lost with a rebase i did |
| 09:35 |
BlockMen |
idk |
| 09:36 |
BlockMen |
ok, everyone look again plz |
| 09:36 |
BlockMen |
updated |
| 09:37 |
kahrl |
BlockMen: looks good now |
| 09:41 |
BlockMen |
im waiting for travis and then push it |
| 09:42 |
|
rickmcfarley left #minetest-dev |
| 09:58 |
|
kaeza joined #minetest-dev |
| 10:03 |
|
Salbei left #minetest-dev |
| 10:04 |
Zeno` |
going to merge https://github.com/minetest/minetest/pull/1707 in one hour |
| 10:26 |
|
kaeza joined #minetest-dev |
| 10:29 |
|
proller joined #minetest-dev |
| 10:38 |
|
ninnghazad joined #minetest-dev |
| 10:40 |
ninnghazad |
anybody else noticed that minetest.* functions that rely on getScriptApiBase do not work properly when called from a coroutine within lua? wondering if this might be intentional |
| 10:40 |
ninnghazad |
getScriptApiBase returns a different stack (?) when called from a coroutine, and that seems to mess up the functions, as they read/write on the wrong indices then. |
| 10:42 |
RealBadAngel |
BlockMen, for glasslike framed you will need different glass textures |
| 10:42 |
RealBadAngel |
its frames are regular 3d boxes |
| 10:42 |
RealBadAngel |
holes there looks terrible |
| 10:43 |
BlockMen |
RealBadAngel, imo not but if more will complain it will be changed |
| 10:43 |
RealBadAngel |
i suggest using wood and obsidian textures for frames and separate glass surface texture |
| 10:44 |
RealBadAngel |
like so: https://github.com/minetest-technic/framedglass/blob/master/init.lua#L39 |
| 10:45 |
|
dirkk0 joined #minetest-dev |
| 10:45 |
|
dirkk0 left #minetest-dev |
| 10:46 |
RealBadAngel |
BlockMen, theres already an issue posted bout it |
| 10:46 |
RealBadAngel |
https://github.com/minetest/minetest/issues/1695 |
| 10:47 |
|
kaeza joined #minetest-dev |
| 10:47 |
BlockMen |
RealBadAngel, he claims it should be rotated different |
| 10:47 |
BlockMen |
not that there are gaps at all |
| 10:49 |
RealBadAngel |
hes wrong |
| 10:49 |
RealBadAngel |
i just closed that issue |
| 10:49 |
RealBadAngel |
box is solid. needs separate texture, so you do too |
| 10:50 |
|
proller joined #minetest-dev |
| 10:54 |
RealBadAngel |
wise is to bound wood and obsidian textures to it, when user will modify textures for them corresponding glass will also change |
| 10:55 |
RealBadAngel |
and btw, it cannot be rotated different way |
| 10:56 |
RealBadAngel |
rotations are the same for all the boxes |
| 10:56 |
RealBadAngel |
and no matter how you will rotate it there will always be a gap |
| 10:57 |
RealBadAngel |
texture is made so |
| 10:57 |
BlockMen |
^ you should add that to the closed issue ;) |
| 10:58 |
RealBadAngel |
adding irc log link |
| 10:58 |
|
ImQ009 joined #minetest-dev |
| 10:58 |
|
Amaz joined #minetest-dev |
| 11:00 |
BlockMen |
k |
| 11:09 |
RealBadAngel |
BlockMen, but imho you should change game usage of it |
| 11:09 |
RealBadAngel |
the way i mentioned already |
| 11:10 |
RealBadAngel |
in my mod you can find rdy textures |
| 11:10 |
|
proller joined #minetest-dev |
| 11:13 |
Zeno` |
Ok, I am now merging the commit |
| 11:13 |
RealBadAngel |
otherwise some1 is gonna open similar issue again |
| 11:13 |
Zeno` |
Ok, I think I found a problem |
| 11:14 |
Zeno` |
I don't have permissions |
| 11:14 |
RealBadAngel |
Zeno`, what commit? |
| 11:14 |
Zeno` |
1707 |
| 11:15 |
Zeno` |
and yes there is a yucky part in that... but hmmmm suggested I do it the yucky way |
| 11:15 |
ninnghazad |
create #1709 for the problem with coroutines/minetest.*/stack |
| 11:17 |
RealBadAngel |
Zeno`, how it behaves when both stacks sum is greater than max ammount? |
| 11:17 |
Zeno` |
it should behave the same way as before |
| 11:18 |
Zeno` |
I didn't change that logic |
| 11:20 |
RealBadAngel |
if so im ok with it |
| 11:26 |
RealBadAngel |
also im about to close all open issues/prs made by me |
| 11:27 |
RealBadAngel |
all the code will be aviable only in my fork |
| 11:27 |
RealBadAngel |
mt is free to take it |
| 11:27 |
RealBadAngel |
but i wont be making any single pr again |
| 11:28 |
RealBadAngel |
im done with that |
| 11:28 |
|
kaeza joined #minetest-dev |
| 11:29 |
kahrl |
2015: every (ex-)minetest dev has their own fork |
| 11:29 |
Amaz |
XD |
| 11:30 |
RealBadAngel |
whatever. making your code into core takes more time than coding actually |
| 11:30 |
RealBadAngel |
and is extremaly frustrating |
| 11:30 |
kahrl |
eh, mine take months to be merged as well but I don't rage quit |
| 11:30 |
|
PilzAdam joined #minetest-dev |
| 11:30 |
RealBadAngel |
im not quitting |
| 11:30 |
kahrl |
essentially you are |
| 11:31 |
Zeno` |
I don't think it would be good losing your PRs |
| 11:31 |
Zeno` |
sigh |
| 11:31 |
RealBadAngel |
if you will decide to pick up my code i can help |
| 11:31 |
RealBadAngel |
but i wont be begging for it anymore |
| 11:32 |
ninnghazad |
understandable |
| 11:32 |
kahrl |
well, I don't beg for mine getting merged either |
| 11:33 |
RealBadAngel |
i just want my own code be up to date all the time |
| 11:33 |
RealBadAngel |
without constanly need for rebasing |
| 11:33 |
RealBadAngel |
which started to be just sick |
| 11:34 |
kahrl |
if you intend to merge changes from minetest you will have to fix those conflicts instead |
| 11:34 |
kahrl |
so it doesn't really help |
| 11:34 |
RealBadAngel |
there are no conflicts here |
| 11:34 |
kahrl |
so what's the problem with rebasing? |
| 11:35 |
RealBadAngel |
i am coding new things based on previous changes |
| 11:35 |
kahrl |
just say in the pull request, "depends on #xxxx" |
| 11:36 |
RealBadAngel |
mapblock mesh in its current state is unusable for me |
| 11:36 |
kahrl |
I've done that often actually and it worked out fine |
| 11:37 |
RealBadAngel |
i tried to change it step by step |
| 11:37 |
RealBadAngel |
but all my changes are blocked |
| 11:38 |
kahrl |
blocked? more like no one's around I think |
| 11:38 |
RealBadAngel |
for weeks? |
| 11:38 |
kahrl |
yeah, I don't know why |
| 11:38 |
RealBadAngel |
lately i had 2 weeks off |
| 11:38 |
kahrl |
I suggested the weekly meeting but it never happened |
| 11:39 |
RealBadAngel |
planned to spent that time for coding |
| 11:39 |
RealBadAngel |
i havent managed to get a single pull merged |
| 11:40 |
RealBadAngel |
yesterday i was just pissed off |
| 11:40 |
RealBadAngel |
today im calm |
| 11:40 |
RealBadAngel |
but im moving with my toys |
| 11:41 |
kahrl |
I do agree that someone else should client/audiovisuals maintainer because c55 is barely around these days |
| 11:41 |
kahrl |
should be* |
| 11:42 |
RealBadAngel |
nobody is takin care of it |
| 11:42 |
RealBadAngel |
in fact the project is slowly dying |
| 11:42 |
kahrl |
open an issue about it on github and ping every dev to comment on it |
| 11:43 |
RealBadAngel |
theres no progress at all |
| 11:43 |
RealBadAngel |
and all the good things are shut down at pr stage |
| 11:44 |
kahrl |
judging by the page hits recently posted I don't think it's dying |
| 11:45 |
RealBadAngel |
you think prs changing spelling or mouse behaviour are progress? |
| 11:45 |
kahrl |
why not? |
| 11:45 |
RealBadAngel |
its stagnation |
| 11:46 |
kahrl |
polishing a game is actually often more work than coding the first prototype |
| 11:46 |
kahrl |
but necessary to make a good game (or engine) |
| 11:46 |
RealBadAngel |
ofc but only when actively coding |
| 11:46 |
RealBadAngel |
otherwise we end up like mojang did |
| 11:47 |
kahrl |
I don't think microsoft would be interested in us |
| 11:47 |
RealBadAngel |
with fireworks as new shiny feature |
| 11:47 |
RealBadAngel |
or new kind of wood |
| 11:47 |
RealBadAngel |
its called dead end elsewhere |
| 11:48 |
proller |
changing fetchresult to fetch_result was very important feature. |
| 11:49 |
kahrl |
if the engine is already powerful enough that good progress (in your sense) can be done in mods, I don't see the problem |
| 11:50 |
RealBadAngel |
kahrl, its not |
| 11:52 |
|
diemartin joined #minetest-dev |
| 11:52 |
kahrl |
I see at least a couple dozen new mods release in the last few weeks |
| 11:53 |
kahrl |
of course, if you see any individual mod as progress is up to you, but those are the numbers |
| 11:53 |
RealBadAngel |
thats just an effect of mojangs actions |
| 11:54 |
RealBadAngel |
for a short period of time we will be able to see folks trying to contribute |
| 11:54 |
RealBadAngel |
but it will end as usual |
| 11:54 |
kahrl |
and your fork will help this how? |
| 11:55 |
RealBadAngel |
i just want to code, its my hobby |
| 11:55 |
RealBadAngel |
and i will do that all the time |
| 11:55 |
|
hintss joined #minetest-dev |
| 11:55 |
RealBadAngel |
i just dont want anymore crawling and begging for it |
| 11:55 |
RealBadAngel |
its pointless |
| 11:56 |
kahrl |
again, just don't beg for it and it will be less frustrating |
| 11:56 |
RealBadAngel |
its gone too far |
| 11:57 |
kahrl |
RealBadAngel: part of the problem is that there are 91 open pulls requests. how are devs supposed to randomly pick yours to comment on? |
| 11:57 |
kahrl |
pull* |
| 11:58 |
RealBadAngel |
just grep the logs and see how many times i asked for comments on my pulls |
| 11:58 |
|
jp_ joined #minetest-dev |
| 12:00 |
ninnghazad |
still, having to look at large pulls is time-consuming at least. and the guys having to do those probably also just want to code, and not have to read other people's code. |
| 12:01 |
ninnghazad |
i'd say don't take it personally |
| 12:01 |
RealBadAngel |
so the development style just suck balls |
| 12:01 |
kahrl |
RealBadAngel: how often do you merge pull requests of others? |
| 12:02 |
kahrl |
I don't keep logs but I don't think I've often seen you do that |
| 12:02 |
kahrl |
so look in the mirror please |
| 12:02 |
RealBadAngel |
actually i do that quite often |
| 12:02 |
RealBadAngel |
ask zefram_fysh |
| 12:03 |
RealBadAngel |
hes a main contributor for technic last days |
| 12:03 |
jp_ |
RBA : sent you a PM |
| 12:04 |
RealBadAngel |
i just trust him and his code |
| 12:04 |
RealBadAngel |
and hes doing great job |
| 12:04 |
|
blaaaaargh joined #minetest-dev |
| 12:04 |
kahrl |
RealBadAngel: well, I'm not talking about technic |
| 12:04 |
RealBadAngel |
its the same |
| 12:05 |
RealBadAngel |
technic mod is one of the biggest mods for mt out there |
| 12:05 |
ninnghazad |
when he breaks something that you've missed to spot, and BILLIONS of angry miners come at you for it, you shall change your mind! |
| 12:05 |
|
jp_ left #minetest-dev |
| 12:06 |
RealBadAngel |
thats the point |
| 12:06 |
ninnghazad |
all like "oh noes, why didn't i spend 27 hours checking those PRs..." |
| 12:06 |
RealBadAngel |
code needs to be verified |
| 12:06 |
RealBadAngel |
by players |
| 12:06 |
ninnghazad |
hm, well... no... yes... also maybe but not primarily i think |
| 12:06 |
RealBadAngel |
our current model of development seems to forget bout it |
| 12:07 |
RealBadAngel |
whats important for devs are whitespaces |
| 12:07 |
RealBadAngel |
or style issues |
| 12:07 |
RealBadAngel |
but not the features |
| 12:07 |
proller |
and hyper compare in player save |
| 12:07 |
ninnghazad |
well that sucks. sounds like coding @work ;) |
| 12:08 |
kahrl |
so me complaining about a missing "break;" is about style issues? |
| 12:08 |
RealBadAngel |
lol |
| 12:08 |
RealBadAngel |
you know what im talkin about |
| 12:09 |
RealBadAngel |
and missing break is not a style issue but a bug |
| 12:09 |
RealBadAngel |
lately i pointed missing break too |
| 12:10 |
RealBadAngel |
in firelike drawtype |
| 12:18 |
ninnghazad |
which PR are you waiting on btw? |
| 12:20 |
blaaaaargh |
since we are talking about drawtypes, I wish modders could specify per-cuboid textures for nodeboxes |
| 12:21 |
kahrl |
https://github.com/minetest/minetest/issues/1710 see, I even wrote this issue for you RBA |
| 12:21 |
kahrl |
(any dev welcome to comment on that.) |
| 12:21 |
kahrl |
anyone else of course too |
| 12:22 |
Zeno` |
I'd support RBA |
| 12:22 |
Amaz |
↑ |
| 12:23 |
RealBadAngel |
blaaaaargh, no need for that with mesh drawtype aviable |
| 12:24 |
RealBadAngel |
that makes literally nodebox drawtype obsolete |
| 12:26 |
|
indriApollo joined #minetest-dev |
| 12:28 |
kaeza |
probably. nodeboxes are easier to "edit" though, if you don't have experience with 3D modelling software |
| 12:28 |
Amaz |
↑ |
| 12:29 |
kahrl |
fun fact: we could simply stop supporting nodebox |
| 12:29 |
kahrl |
"nodebox -- See below. EXPERIMENTAL" -- lua_api.txt, Oct 2014 |
| 12:29 |
kahrl |
"Please note that this is still experimental, and may be incompatibly changed in the future." |
| 12:30 |
kaeza |
or simply s/EXPERIMENTAL//, etc |
| 12:30 |
kaeza |
it has been "EXPERIMENTAL" for what, 2 years? |
| 12:30 |
kahrl |
heh yeah I didn't think of that |
| 12:30 |
kahrl |
yes, sounds right |
| 12:33 |
|
ninnghazad2 joined #minetest-dev |
| 12:35 |
|
ninnghazad_mobil joined #minetest-dev |
| 12:37 |
|
ninnghazad_mobil joined #minetest-dev |
| 12:38 |
|
ninnghazad_mobil joined #minetest-dev |
| 12:40 |
|
proller joined #minetest-dev |
| 12:40 |
|
ninnghazad_mobil joined #minetest-dev |
| 12:45 |
|
ninnghazad_mobil joined #minetest-dev |
| 12:47 |
|
ImQ009 joined #minetest-dev |
| 12:59 |
|
shadowzone joined #minetest-dev |
| 13:02 |
|
indriApollo joined #minetest-dev |
| 13:44 |
|
Taoki[mobile] joined #minetest-dev |
| 14:00 |
|
diemartin joined #minetest-dev |
| 14:14 |
|
ninnghazad_ joined #minetest-dev |
| 14:15 |
|
blaaaaargh joined #minetest-dev |
| 14:19 |
|
zat joined #minetest-dev |
| 14:38 |
|
ninnghazad1 joined #minetest-dev |
| 14:45 |
|
hmmmm joined #minetest-dev |
| 14:53 |
|
ninnghazad_ joined #minetest-dev |
| 14:56 |
|
ninnghazad1 joined #minetest-dev |
| 15:02 |
Megaf_ |
kahrl: Are you there? |
| 15:04 |
Megaf_ |
kahrl: are do you mean by Build taker? |
| 15:06 |
|
ninnghazad joined #minetest-dev |
| 15:06 |
|
ninnghazad_ joined #minetest-dev |
| 15:07 |
|
ninnghazad1 joined #minetest-dev |
| 15:07 |
Megaf_ |
so, is there a plan to make oficial builds? |
| 15:07 |
Amaz |
Official builds for what? |
| 15:07 |
Megaf_ |
^ sfan5 |
| 15:08 |
sfan5 |
Megaf_: for what? |
| 15:08 |
Megaf_ |
https://github.com/minetest/minetest/issues/1710#issue-44679910 |
| 15:08 |
Megaf_ |
Item 4 |
| 15:08 |
|
ninnghazad_ joined #minetest-dev |
| 15:08 |
sfan5 |
Megaf_: "Build" is the building system, not minetest builds |
| 15:08 |
sfan5 |
Megaf_: btw: I already do the MinGW release builds |
| 15:08 |
sfan5 |
the msvc ones are done by BlockMen |
| 15:09 |
Megaf_ |
oh, I see |
| 15:09 |
Megaf_ |
I could make minetest builds... |
| 15:10 |
sfan5 |
why would you? |
| 15:10 |
sfan5 |
there are enough |
| 15:10 |
sfan5 |
for windows at least |
| 15:11 |
|
diemartin joined #minetest-dev |
| 15:14 |
Megaf_ |
I'd like to make a generic Linux build |
| 15:15 |
sfan5 |
then make a static build |
| 15:15 |
sfan5 |
that however doesn't work because some glibc functions need that version of glibc at runtime |
| 15:16 |
sfan5 |
"warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking" |
| 15:17 |
|
ninnghazad joined #minetest-dev |
| 15:19 |
|
ninnghazad_ joined #minetest-dev |
| 15:43 |
|
blaaaaargh joined #minetest-dev |
| 15:58 |
|
PenguinDad joined #minetest-dev |
| 15:59 |
|
ninnghazad joined #minetest-dev |
| 16:01 |
|
mos_basik joined #minetest-dev |
| 16:08 |
|
Calinou joined #minetest-dev |
| 16:12 |
|
rubenwardy joined #minetest-dev |
| 16:20 |
|
BlockMen joined #minetest-dev |
| 16:21 |
|
blaaaaargh joined #minetest-dev |
| 16:24 |
|
dulrich left #minetest-dev |
| 16:26 |
|
MinetestForFun joined #minetest-dev |
| 16:32 |
BlockMen |
sfan5, you need to update your builds. -> https://forum.minetest.net/viewtopic.php?p=156409#p156409 |
| 16:32 |
kaeza |
I noticed there's no documentation about the "long" version of `drop` in lua_api.txt |
| 16:32 |
|
indriApollo joined #minetest-dev |
| 16:32 |
kaeza |
https://github.com/kaeza/minetest/commit/c68c83a5f8398ed8168bc73a7b6848a9f429e804 |
| 16:36 |
|
indriApollo joined #minetest-dev |
| 16:40 |
kaeza |
eh this one instead: https://github.com/kaeza/minetest/commit/44b10eb2cb6452b633f20e6e804f62ef702987a9 |
| 16:44 |
BlockMen |
kaeza, s/same node/node itself ? |
| 16:44 |
|
diemartin joined #minetest-dev |
| 16:46 |
sfan5 |
BlockMen: do you manually add minetest_game to your builds? |
| 16:47 |
BlockMen |
yes |
| 16:47 |
|
zat joined #minetest-dev |
| 16:47 |
sfan5 |
BlockMen: I just use the default install scripts |
| 16:47 |
diemartin |
BlockMen, maybe |
| 16:47 |
sfan5 |
that means jungles are broken for everyone that uses "make install" |
| 16:47 |
BlockMen |
seems it misses something then? |
| 16:48 |
sfan5 |
apparently |
| 16:49 |
RealBadAngel |
string of the drop cannot hold the ammount? |
| 16:50 |
RealBadAngel |
im not sure but i think it was able to do so |
| 16:51 |
PilzAdam |
sfan5, BlockMen, https://github.com/minetest/minetest/blob/master/CMakeLists.txt#L150-153 |
| 16:53 |
sfan5 |
who had that stupid idea? |
| 16:53 |
sfan5 |
just install the whole game folder |
| 16:55 |
diemartin |
RealBadAngel, looks like nope |
| 16:55 |
RealBadAngel |
<George> Hi everyone I'm having trouble with mods not showing in games, hjow do I get then working? |
| 16:56 |
RealBadAngel |
disabling mods by default is not a good idea |
| 16:59 |
|
Hunterz joined #minetest-dev |
| 17:00 |
PilzAdam |
RealBadAngel, enabling mods by default isn't either; it would apply to already created worlds without the user noticing it |
| 17:00 |
PilzAdam |
a (IMO) good solution would be to show the "Configure" dialog in (or after) world creation |
| 17:00 |
|
indriApollo left #minetest-dev |
| 17:00 |
|
NakedFury joined #minetest-dev |
| 17:00 |
BlockMen |
or enabled mods by default for new worlds |
| 17:00 |
BlockMen |
*only |
| 17:01 |
PilzAdam |
BlockMen, if you do that then please add a setting to disable that behavior; I have tons of mods and don't want to have them all enabled by default |
| 17:02 |
BlockMen |
PilzAdam, it was just a suggestion... ;) |
| 17:03 |
PilzAdam |
world creation could be "1) Choose a name, 2) Choose a game, 3) Choose a seed and mapgen (maybe games should be able to skip that step?), 4) Choose mods" |
| 17:07 |
BlockMen |
^ should games also be albe to skip that aswell? |
| 17:07 |
BlockMen |
(4) |
| 17:08 |
PilzAdam |
maybe mods could hint which games they work well on; and then theres a checkbox in 4) that says "Show mods that may not work with this game" |
| 17:10 |
BlockMen |
no, not another cb |
| 17:10 |
BlockMen |
the configuration menu is already messy |
| 17:10 |
PilzAdam |
like "suggested_games = minetest_game, carbone" or "suggested_game = *all" in game.conf |
| 17:12 |
PilzAdam |
BlockMen, redesign it then |
| 17:12 |
BlockMen |
lel |
| 17:13 |
PilzAdam |
don't limit your ideas to the current state ;-) |
| 17:14 |
BlockMen |
im just try to limit making things worse ;) |
| 17:16 |
PilzAdam |
there are only a few things that are worse than the current menu |
| 17:19 |
BlockMen |
PilzAdam, everything can get worse |
| 17:20 |
BlockMen |
but back to serious dev talk |
| 17:20 |
BlockMen |
comments on https://github.com/minetest/minetest/pull/1690? |
| 17:22 |
PilzAdam |
1) why is it builtin? 2) I would prefer a /die with an extra priv |
| 17:23 |
BlockMen |
why an extra priv for dying? |
| 17:24 |
BlockMen |
you can also jump 3 times from a high place (in most cases) |
| 17:24 |
PilzAdam |
imagine a grief_penalty mod that puts you in a 1x2x1 prison |
| 17:26 |
BlockMen |
ok, but then the interact priv should be enough |
| 17:35 |
|
sol_invictus joined #minetest-dev |
| 17:52 |
|
Miner_48er joined #minetest-dev |
| 17:57 |
BlockMen |
is that ok? https://github.com/BlockMen/minetest/commit/835f2fa84a9c62ef28e5b5969ccad44c2f898433 |
| 18:08 |
|
GrimKriegor joined #minetest-dev |
| 18:51 |
Megaf_ |
PilzAdam: we have a jail in my server |
| 18:51 |
Megaf_ |
made out of unbreakable nodes |
| 18:52 |
Megaf_ |
and even if the user manages to escape it will teleport it back |
| 18:52 |
Megaf_ |
PilzAdam: maybe this grief mod could use something like it |
| 18:59 |
|
diemartin joined #minetest-dev |
| 19:35 |
|
BlockMen left #minetest-dev |
| 19:35 |
|
alexxs joined #minetest-dev |
| 19:53 |
|
Amaz joined #minetest-dev |
| 20:06 |
|
shadowzone joined #minetest-dev |
| 20:20 |
|
EvergreenTree joined #minetest-dev |
| 20:20 |
hmmmm |
http://www.wired.com/2014/10/code-published-for-unfixable-usb-attack/ |
| 20:27 |
ShadowNinja |
diemartin: The -- <...> should be ommited, simce it's not in a list and there's nothing obvious to go there. Also, lua_api.txt isn't meant to be valid Lua, so you can remove the block comment notation. Otherwise seems good. |
| 20:29 |
diemartin |
ShadowNinja, https://github.com/kaeza/minetest/commit/69476475a419777f9f6ed267ab4f4b553b6e0f44 |
| 20:30 |
diemartin |
actually, umm |
| 20:30 |
ShadowNinja |
diemartin: Missing comma after items.items list, and spaces in {}. I can fix that locally though. hmmmm: Any comments? |
| 20:31 |
hmmmm |
huh? I'm confused |
| 20:32 |
shadowzone |
So did the vote to ban/quiet prolloer go or not? |
| 20:34 |
diemartin |
ShadowNinja, fixed https://github.com/kaeza/minetest/commit/b8f9a98c61fe9c95daf333dbc3011ccfcccc14f5 (forgot a block) |
| 20:34 |
shadowzone |
*proller |
| 20:34 |
ShadowNinja |
shadowzone: Nothing's been done yet. I'll check #minetest and notify ops here though. |
| 20:34 |
shadowzone |
Okay. |
| 20:35 |
ShadowNinja |
hmmmm: kaeza's patch ^. |
| 20:35 |
Megaf_ |
ShadowNinja: the error message is as helpful as 99,9% of all minetest error messages! |
| 20:35 |
Megaf_ |
https://github.com/minetest/minetest/issues/1697#issuecomment-57692540 |
| 20:35 |
Megaf_ |
I a system admin, not a bloody developer |
| 20:35 |
Megaf_ |
system admins should be given meaning full error messages |
| 20:36 |
Megaf_ |
not error messages that even developers can understand themselves |
| 20:36 |
Megaf_ |
That's the first thing that should change in minetest |
| 20:36 |
Megaf_ |
s/meaning full/meaningful |
| 20:37 |
ShadowNinja |
Megaf_: I know that it's an error with memory management, but I need valgrind or GDB for details. |
| 20:39 |
hmmmm |
ah |
| 20:40 |
hmmmm |
no, no comments shadowninja |
| 20:40 |
hmmmm |
LGTM |
| 20:46 |
ShadowNinja |
diemartin: Actually it's already mentioned, see line 2424. I'll replace it though. |
| 20:47 |
Megaf_ |
Is this a bug on my mod, on pipeworks or a minetest bug? https://github.com/Megaf/more_chests/commit/4aa321957497512ea012736aa2b594818d328dd4 |
| 20:47 |
diemartin |
ShadowNinja, oh, didn't notice that one |
| 20:47 |
ShadowNinja |
diemartin: (I'm fixing it locally) |
| 20:47 |
diemartin |
ok, thanks |
| 20:50 |
ShadowNinja |
kaeza: https://github.com/minetest/minetest/commit/5baf379f40537060a1d5111905c7702d4563ee5c |
| 20:51 |
kaeza |
and even with a better commit message :D |
| 20:52 |
Megaf_ |
VanessaE: https://github.com/VanessaE/pipeworks/issues/74#issuecomment-57704547 |
| 20:52 |
|
rmilan joined #minetest-dev |
| 20:53 |
|
srifqi joined #minetest-dev |
| 20:53 |
|
srifqi left #minetest-dev |
| 20:56 |
|
shadowzone joined #minetest-dev |
| 20:56 |
|
shadowzone joined #minetest-dev |
| 20:57 |
|
kaeza joined #minetest-dev |
| 21:07 |
|
proller joined #minetest-dev |
| 21:31 |
|
Nerotic joined #minetest-dev |
| 21:31 |
|
Nerotic left #minetest-dev |
| 21:35 |
|
casimir joined #minetest-dev |
| 22:07 |
|
chchjesus joined #minetest-dev |
| 22:07 |
|
eeew joined #minetest-dev |
| 22:27 |
|
shadowzone joined #minetest-dev |
| 22:27 |
|
shadowzone joined #minetest-dev |
| 22:29 |
|
rickmcfarley joined #minetest-dev |
| 22:33 |
|
paramat joined #minetest-dev |
| 23:06 |
ShadowNinja |
Calling those modpack-with-menu-things "Games" seems to be causing real confusion: https://forum.minetest.net/viewtopic.php?f=3&t=10254 |
| 23:07 |
ShadowNinja |
"Subgames" seems to be the best suggestion so far. |
| 23:14 |
paramat |
Who cares about confused newbies? they'll soon learn, too much spoonfeeding ... the engine is not a game, subgames are not sub-, they are games =) |
| 23:18 |
|
rickmcfarley joined #minetest-dev |
| 23:19 |
rickmcfarley |
I've had to explain the difference to a few new comers |
| 23:20 |
rickmcfarley |
I wish there was a launcher to view/add games |
| 23:21 |
rickmcfarley |
I was thinking about making a simple python script, but figured there was already such a thing |
| 23:25 |
|
AnimalMachine joined #minetest-dev |
| 23:35 |
|
paramat left #minetest-dev |
| 23:48 |
|
rickmcfarley joined #minetest-dev |
| 23:52 |
|
Weedy joined #minetest-dev |
| 23:55 |
|
SmugLeaf joined #minetest-dev |
