| Time |
Nick |
Message |
| 00:03 |
|
leat1 joined #minetest-dev |
| 00:17 |
|
cvtsx1 joined #minetest-dev |
| 00:21 |
|
zat joined #minetest-dev |
| 00:30 |
|
VargaD_ joined #minetest-dev |
| 00:31 |
|
dzho_ joined #minetest-dev |
| 00:31 |
|
Anchakor_ joined #minetest-dev |
| 00:31 |
|
Brains__ joined #minetest-dev |
| 00:31 |
|
pozzoni_ joined #minetest-dev |
| 00:31 |
|
cvtsx1 joined #minetest-dev |
| 00:36 |
|
proller joined #minetest-dev |
| 00:38 |
|
Floris joined #minetest-dev |
| 00:42 |
|
OldCoder joined #minetest-dev |
| 00:44 |
|
everamzah joined #minetest-dev |
| 00:49 |
|
ShadowNinja joined #minetest-dev |
| 01:01 |
|
ShadowNinja joined #minetest-dev |
| 01:06 |
|
ShadowNinja joined #minetest-dev |
| 01:14 |
|
Player_2 joined #minetest-dev |
| 01:16 |
|
ShadowNinja joined #minetest-dev |
| 01:21 |
|
ShadowNinja joined #minetest-dev |
| 01:26 |
|
leat1 joined #minetest-dev |
| 01:29 |
hmmmm |
https://github.com/kwolekr/minetest/commit/527ddd6d0677e7c2c61ee7daaea46af31d951294 PTAL |
| 01:34 |
|
Tesseract joined #minetest-dev |
| 01:35 |
|
zat joined #minetest-dev |
| 01:37 |
|
ShadowNinja joined #minetest-dev |
| 02:05 |
|
book` joined #minetest-dev |
| 02:37 |
|
leat1 joined #minetest-dev |
| 02:44 |
|
Siva joined #minetest-dev |
| 03:19 |
|
Player_2 joined #minetest-dev |
| 03:51 |
|
paramat joined #minetest-dev |
| 03:52 |
paramat |
from the code looks like a much improved sheet ore, i'd like to see a screenshot |
| 04:00 |
paramat |
perhaps it would be better to add nmin.Y to mapseed instead of randomising seed per chunk, so that the sheets are not chopped at mapchunk borders |
| 04:04 |
paramat |
afaik sheet ore is chopped at borders because of that, that looks bad to me |
| 04:05 |
paramat |
lol that email c55 posted |
| 04:13 |
|
Fritigern joined #minetest-dev |
| 04:23 |
paramat |
perhaps we can deprecate sheet ore now |
| 04:46 |
|
Siva joined #minetest-dev |
| 04:46 |
* paramat |
eats a bowl of ore puffs |
| 04:50 |
hmmmm |
nah they're different uses |
| 04:50 |
hmmmm |
you can't avoid the discontinuity without defining clear altitudes at which this kind of ore generates |
| 04:50 |
hmmmm |
unfortunately |
| 04:53 |
|
cvtsx joined #minetest-dev |
| 04:56 |
paramat |
ah i see i misunderstood |
| 04:58 |
hmmmm |
sheet ore is supposed to replicate this stratus ore i saw in a mod that looked cool |
| 04:59 |
hmmmm |
it had the same jaggy edges and everything |
| 04:59 |
hmmmm |
then my thought process was like |
| 04:59 |
hmmmm |
well what if, instead of modulating the height of these columns by uniform randomness, i use noise instead |
| 04:59 |
hmmmm |
so i'd just add another noise + this noise |
| 05:00 |
hmmmm |
but that always created concave shapes because of noise_threshhold being positive |
| 05:00 |
hmmmm |
so i separated the threshhold noise which defines the size/shape from the displacement noises |
| 05:00 |
hmmmm |
one for the top and one for the bototm |
| 05:00 |
hmmmm |
here's the result: http://i.imgur.com/T6a4JGd.png |
| 05:02 |
* paramat |
looks |
| 05:07 |
|
paramat left #minetest-dev |
| 05:24 |
|
Warr1024 joined #minetest-dev |
| 05:39 |
|
Hunterz joined #minetest-dev |
| 05:56 |
|
VanessaE joined #minetest-dev |
| 06:21 |
|
leat1 joined #minetest-dev |
| 06:49 |
|
kaeza joined #minetest-dev |
| 06:49 |
|
leat1 joined #minetest-dev |
| 07:30 |
|
leat1 joined #minetest-dev |
| 08:06 |
|
T4im joined #minetest-dev |
| 08:35 |
|
leat1 joined #minetest-dev |
| 08:40 |
|
leat1 joined #minetest-dev |
| 08:49 |
|
cvtsx joined #minetest-dev |
| 09:11 |
|
Amaz joined #minetest-dev |
| 09:42 |
|
julienrat joined #minetest-dev |
| 09:44 |
|
julienrat left #minetest-dev |
| 10:07 |
|
Darcidride joined #minetest-dev |
| 10:16 |
|
cvtsx joined #minetest-dev |
| 10:23 |
|
FR^2 joined #minetest-dev |
| 10:32 |
|
leat joined #minetest-dev |
| 10:33 |
|
leat joined #minetest-dev |
| 10:43 |
|
leat joined #minetest-dev |
| 10:53 |
|
leat joined #minetest-dev |
| 10:56 |
|
H-H-H joined #minetest-dev |
| 11:34 |
|
leat joined #minetest-dev |
| 11:51 |
|
VanessaE joined #minetest-dev |
| 11:53 |
|
casimir joined #minetest-dev |
| 12:15 |
|
lisacvuk joined #minetest-dev |
| 12:38 |
|
Taoki[mobile] joined #minetest-dev |
| 12:38 |
|
ElectronLibre joined #minetest-dev |
| 12:56 |
|
cd2 joined #minetest-dev |
| 13:04 |
|
johnnyjoy joined #minetest-dev |
| 13:12 |
|
est31 joined #minetest-dev |
| 13:48 |
|
EvergreenTree joined #minetest-dev |
| 13:49 |
VanessaE |
that last commit kinda went bonkers: http://pastebin.com/qPbDyraL and http://pastebin.com/qMRHne0q |
| 13:50 |
est31 |
VanessaE, do you know the player name? |
| 13:50 |
VanessaE |
one sec. |
| 13:50 |
|
twoelk joined #minetest-dev |
| 13:51 |
VanessaE |
... |
| 13:51 |
VanessaE |
2015-09-16 08:01:13: ACTION[Server]: nomohakon digs default:dirt at (-2634,-697,263) |
| 13:51 |
VanessaE |
2015-09-16 08:01:17: ERROR[Server]: ServerEnvironment::addActiveObjectRaw(): object position outside maximum range |
| 13:51 |
VanessaE |
minetestserver: /home/minetest/minetest_core/src/server.cpp:1865: void Server::SendMovePlayer(irr::u16): Assertion `player' failed. |
| 13:51 |
VanessaE |
... |
| 13:51 |
est31 |
but we have a stack trace |
| 13:51 |
est31 |
lemme see whats causing it |
| 13:55 |
|
leat1 joined #minetest-dev |
| 14:02 |
est31 |
VanessaE, whats the playerfile spawnpos for player Winslow? |
| 14:02 |
VanessaE |
position = (-36254.6,295,-41411.7) |
| 14:03 |
VanessaE |
(divide by 10 on those I think) |
| 14:03 |
est31 |
is it indeed 10 times as large... |
| 14:03 |
est31 |
or ten times as small |
| 14:05 |
est31 |
ahh |
| 14:05 |
|
leat1 joined #minetest-dev |
| 14:05 |
est31 |
well, then that's the problem |
| 14:08 |
VanessaE |
meanwhile, I'm gonna head off to bed. |
| 14:08 |
VanessaE |
been up all night getting dac.com restored. |
| 14:08 |
est31 |
night |
| 14:08 |
VanessaE |
night |
| 14:08 |
est31 |
thx for the stacktrace |
| 14:09 |
VanessaE |
yw |
| 14:19 |
est31 |
gonna push in 10 mins https://github.com/est31/minetest/commit/7614259178a1c0c9e3981d4159d28903d1733f98 |
| 14:20 |
est31 |
dangit |
| 14:20 |
est31 |
it has to be multiplied |
| 14:38 |
|
DFeniks joined #minetest-dev |
| 14:39 |
|
troller joined #minetest-dev |
| 14:55 |
|
ShadowNinja joined #minetest-dev |
| 14:56 |
|
Guest37386 joined #minetest-dev |
| 15:03 |
|
hmmmm joined #minetest-dev |
| 15:10 |
|
Darcidride_ joined #minetest-dev |
| 15:17 |
|
leat1 joined #minetest-dev |
| 15:36 |
est31 |
hmmmm, can't really judge your mapgen patch |
| 15:36 |
est31 |
idk mapgen :) |
| 15:37 |
|
Zeitgeist_ joined #minetest-dev |
| 15:37 |
est31 |
okay, now this patch should fix VE's crash: https://github.com/est31/minetest/commit/7220b1a11fddf5a6c125f64fc4f35854abcdeac8 |
| 15:37 |
est31 |
pushing in 10 minutes |
| 15:39 |
hmmmm |
you should make map_gen_limit_bs into a float |
| 15:39 |
|
Amaz joined #minetest-dev |
| 15:39 |
hmmmm |
in theory it should save a few comparisons |
| 15:39 |
est31 |
ok |
| 15:39 |
hmmmm |
err i mean conversions |
| 15:39 |
hmmmm |
anyway optimizers are really not as smart as you probably think they are :-) |
| 15:40 |
est31 |
they do optimize i++ for iterators |
| 15:40 |
est31 |
okay can I push https://github.com/est31/minetest/commit/6c81be51ffd26ec7dee1ecb887a8743a8b6a6ce4 |
| 15:43 |
|
Robert_Zenz joined #minetest-dev |
| 15:44 |
hmmmm |
sure. |
| 15:49 |
|
julienrat joined #minetest-dev |
| 15:49 |
|
julienrat left #minetest-dev |
| 15:49 |
|
Darcidride joined #minetest-dev |
| 15:50 |
|
Hunterz joined #minetest-dev |
| 16:05 |
|
Calinou joined #minetest-dev |
| 16:53 |
|
troller joined #minetest-dev |
| 16:56 |
|
Taoki[mobile] joined #minetest-dev |
| 17:02 |
|
julienrat joined #minetest-dev |
| 17:07 |
|
leat1 joined #minetest-dev |
| 17:13 |
|
nrzkt joined #minetest-dev |
| 17:13 |
|
julienrat left #minetest-dev |
| 17:17 |
|
leat1 joined #minetest-dev |
| 17:27 |
|
Taoki[mobile] joined #minetest-dev |
| 17:32 |
|
Taoki[mobile] joined #minetest-dev |
| 17:33 |
|
cvtsx joined #minetest-dev |
| 17:45 |
|
cvtsx1 joined #minetest-dev |
| 17:46 |
|
Taoki[mobile]_1 joined #minetest-dev |
| 17:48 |
|
Krock joined #minetest-dev |
| 17:53 |
|
MinetestForFun joined #minetest-dev |
| 17:56 |
|
cvtsx joined #minetest-dev |
| 18:00 |
|
red1 joined #minetest-dev |
| 18:06 |
|
cvtsx1 joined #minetest-dev |
| 18:40 |
|
Puma_rc joined #minetest-dev |
| 18:52 |
|
est31 joined #minetest-dev |
| 19:01 |
|
ShadowBot joined #minetest-dev |
| 19:27 |
|
julienrat joined #minetest-dev |
| 19:28 |
|
julienrat left #minetest-dev |
| 19:31 |
|
julienrat1 joined #minetest-dev |
| 19:41 |
est31 |
about translating nodedefs into different languages for different users |
| 19:41 |
est31 |
the protocol already supports it, we just need to send the language, and expose the feature somehow over the lua API |
| 19:41 |
est31 |
what would be a good way to do that? |
| 19:42 |
est31 |
formspecs and other metadata can come later |
| 19:42 |
VanessaE |
you mean translating the descriptions? |
| 19:42 |
est31 |
descriptions, item names yes |
| 19:43 |
VanessaE |
hm. that could get....messy |
| 19:47 |
est31 |
the harder problem is really metadata |
| 19:47 |
est31 |
because its stored in the map |
| 19:47 |
est31 |
we can't just send different versions of the map to different clients |
| 19:48 |
VanessaE |
it'll have to be translated in realtime then |
| 19:48 |
est31 |
I mean we can, but this would overthrow MANY assumptions in the engine |
| 19:49 |
est31 |
and doing that in a backwards compatible way... had. |
| 19:49 |
est31 |
hard* |
| 19:50 |
est31 |
(regarding realtime translations) |
| 19:51 |
est31 |
if we did that we could let server owners decide whether to turn on that feature |
| 19:51 |
est31 |
and lose backwards compat |
| 19:52 |
est31 |
ah |
| 19:52 |
est31 |
it is possible to do in a backwards compatible way |
| 19:52 |
VanessaE |
well what mods do is use intllib, but you knew that |
| 19:52 |
VanessaE |
(I think that's the name of it) |
| 19:53 |
est31 |
yea |
| 19:53 |
est31 |
I mean the actual feature we are talking about is that different clients can have different languages |
| 19:53 |
est31 |
everything else mods can do |
| 19:53 |
kahrl |
The cleanest solution is to get rid of formspec-in-metadata when client side scripting is added |
| 19:53 |
est31 |
they already can do one language per server start |
| 19:53 |
est31 |
nobody stops them |
| 19:54 |
VanessaE |
I can't help wondering if'n that's the best way; when client-side modding is done, update intllib to do it |
| 19:54 |
VanessaE |
^ kahrl :) |
| 19:55 |
est31 |
yea I guess that is an option |
| 19:55 |
est31 |
a good idea |
| 19:55 |
kahrl |
the downside is of course that client side scripting is vaporware for now :) |
| 19:56 |
VanessaE |
heh |
| 19:56 |
est31 |
and some people will want to overthrow formspecs altogether |
| 19:56 |
est31 |
which will spawn lots of discussions of how to do them right |
| 19:56 |
VanessaE |
formspecs as a client-side function is a nice idea though |
| 19:56 |
VanessaE |
having that crap stored in metadata just plain sucks at times |
| 19:57 |
|
julienrat1 left #minetest-dev |
| 20:07 |
est31 |
yea and it takes away storage |
| 20:08 |
est31 |
you just store the same thing over and over again |
| 20:08 |
est31 |
pretty bad |
| 20:09 |
est31 |
(but in differing mapblocks, which means differing compression contexts) |
| 20:09 |
est31 |
which gets us to the next topic |
| 20:10 |
est31 |
I think that if we increased the number of mapblocks compressed at a time we would get better compression ratios |
| 20:10 |
est31 |
I have done some tests that point towards that direction |
| 20:10 |
est31 |
but nothing actually reliable |
| 20:11 |
VanessaE |
I'm not even concerned about storage per se - I just hate users having to dig/re-place nodee just to update the stored formspec. |
| 20:11 |
VanessaE |
nodes* |
| 20:11 |
est31 |
thats not required |
| 20:11 |
VanessaE |
it is, for some things. |
| 20:11 |
est31 |
they should just interact with the node |
| 20:11 |
est31 |
eg put into inventory |
| 20:12 |
VanessaE |
I agree, it should just update when the user opens the formspec |
| 20:13 |
est31 |
clientside scripting... right now there even isnt a consensus about which thread to run the script in |
| 20:14 |
VanessaE |
by all means, a separate dedicated thread. |
| 20:18 |
VanessaE |
the server should be able to tell the client to launch a chunk of lua code in a thread so that it can, for example, distort the screen or something but without interfering with the player's ability to do stuff normally |
| 20:18 |
VanessaE |
(where that thread is of course shared by all other client-side Lua on that client) |
| 20:19 |
est31 |
the problem of a thread approach is that it isn't immediate |
| 20:19 |
VanessaE |
but there REALLY needs to be some kind of C or C++ interface on the client-side |
| 20:19 |
est31 |
there is always a small lag |
| 20:19 |
est31 |
just look at the lag in singleplayer |
| 20:19 |
VanessaE |
(something the client will compile on receipt) |
| 20:19 |
VanessaE |
true enough |
| 20:19 |
est31 |
between client and server |
| 20:20 |
VanessaE |
but think of some effect like an earthquake or tornado. the server needs to be able to control that |
| 20:20 |
VanessaE |
(while the client executes it) |
| 20:21 |
est31 |
so? |
| 20:21 |
VanessaE |
so? |
| 20:21 |
est31 |
the advantage of doing these things in the main thread would be the reduced lag |
| 20:21 |
est31 |
but lets try hmmmm's approach of a separate thread first |
| 20:21 |
VanessaE |
this is the same main thread that also controls player movement/actions, no? |
| 20:21 |
est31 |
yea |
| 20:21 |
hmmmm |
are you kidding |
| 20:21 |
hmmmm |
it NEEDS to be in a separate thread |
| 20:22 |
hmmmm |
we're not making the same mistake twice, and especially in a place where any lag is extremely noticable |
| 20:22 |
est31 |
if you want to do things like custom player physics |
| 20:22 |
est31 |
you cant wait for the thread to work down the queue |
| 20:22 |
est31 |
you need the result of the movement computation NOW. |
| 20:23 |
|
Siva_Machina joined #minetest-dev |
| 20:23 |
hmmmm |
celeron and I were actually talking about custom physics |
| 20:23 |
hmmmm |
that could be a custom case |
| 20:23 |
hmmmm |
the physics handlers would need to be extremely lightweight though |
| 20:23 |
est31 |
yea ofc |
| 20:23 |
est31 |
its the server's fault in that case |
| 20:24 |
|
Wayward1 joined #minetest-dev |
| 20:25 |
est31 |
of course, things like formspecs can run in a separate thread |
| 20:25 |
est31 |
or on dig actions |
| 20:25 |
est31 |
things like that |
| 20:30 |
est31 |
but dont make a ONMOUSEMOVE callback to that thread, otherwise some oversmart mod creator tries to program camera movement with the mouse themselves |
| 20:30 |
est31 |
in that separate thread ofc |
| 20:31 |
VanessaE |
haha |
| 20:31 |
VanessaE |
I could see someone actually trying to do that. |
| 20:31 |
est31 |
I guess there will be a legitimate reason for them to do it |
| 20:31 |
est31 |
e.g. forbid to look into a direction |
| 20:32 |
est31 |
or that you can rotate into every direction indefinitely |
| 20:32 |
est31 |
but instead of waiting for the engine to support it they will just abuse our API |
| 20:32 |
est31 |
and then the players say its laggy |
| 20:32 |
est31 |
and the mod creator says yeah thats because minetest is shit |
| 20:32 |
VanessaE |
well, treat it like any other mod - if it's a shitty implementation of something, people won't use it anyway |
| 20:33 |
est31 |
our active object implementation is shit at many places |
| 20:33 |
|
ElectronLibre left #minetest-dev |
| 20:33 |
est31 |
people still use it because there is no alternative |
| 20:33 |
VanessaE |
true. |
| 20:34 |
est31 |
well gonna go |
| 20:34 |
est31 |
bye |
| 20:34 |
VanessaE |
I hate when he does that :P |
| 20:35 |
|
red1 joined #minetest-dev |
| 20:38 |
|
MinetestForFun joined #minetest-dev |
| 20:40 |
Sokomine |
those seem to be quite diffrent issues. rotation handled clientside would be good - for mobs. larger beasts turning on the spot looks extremly odd. what we currently have works fine for small animals like chicken and rats. but once they get bigger (cows, for example; or even those dionsaurs someone planned to implement), and still rotate on the spot, immersion is uttlerly ruined |
| 20:42 |
|
est31 joined #minetest-dev |
| 20:43 |
est31 |
one thing came to my mind |
| 20:43 |
est31 |
hmmmm, we do agree that the thread should have no real lock to the clientenv or anything else "vital"? |
| 20:44 |
est31 |
e.g. you do minetest.set_node(...) on the client lua, and then it puts a SETNODE_ETCETC into a queue |
| 20:44 |
est31 |
and that queue is emptied by the main client thread every render or so |
| 20:44 |
hmmmm |
yeah basically |
| 20:44 |
hmmmm |
the whole thing is event-based |
| 20:44 |
hmmmm |
asynchronous is the future~ |
| 20:45 |
est31 |
great |
| 20:45 |
hmmmm |
I have not forgotten about client side lua, btw, just been busy with work |
| 20:45 |
hmmmm |
we're getting close to release time and there's never been more reported BSoDs than ever |
| 20:45 |
hmmmm |
ugh |
| 20:45 |
est31 |
no complaint from me |
| 20:46 |
est31 |
this is a free time project :) |
| 20:46 |
|
Robert_Zenz joined #minetest-dev |
| 20:46 |
est31 |
just client side scripting became topic as kahrl mentioned it :) |
| 20:47 |
|
red1 joined #minetest-dev |
| 20:54 |
|
red1 joined #minetest-dev |
| 21:12 |
|
red1 joined #minetest-dev |
| 22:21 |
|
Player_2 joined #minetest-dev |
| 22:25 |
|
Soni joined #minetest-dev |
| 22:40 |
|
sloantothebone joined #minetest-dev |
| 22:40 |
|
sloantothebone joined #minetest-dev |
| 22:43 |
|
Darcidride joined #minetest-dev |
| 22:45 |
Soni |
let's talk about mods |
| 22:46 |
VanessaE |
that's for #minetest |
| 22:46 |
Soni |
hmm ok wait |
| 22:46 |
Soni |
let's talk about the mod system |
| 22:46 |
Soni |
yeah that sounds better :> |
| 22:47 |
Soni |
so currently all we have are "plugins". |
| 22:48 |
Soni |
can we add "softmods" and "hardmods"? |
| 22:48 |
VanessaE |
soft? |
| 22:48 |
Soni |
(well technically just "hardmods" because "softmods" would be provided by a "hardmod" known as "Lua") |
| 22:48 |
VanessaE |
so you mean programming language plugins |
| 22:48 |
Soni |
nope! |
| 22:49 |
Soni |
not at all! |
| 22:49 |
Soni |
ok so what's currently called "mods" would be "plugins" under my proposed system |
| 22:51 |
Soni |
now, before I talk about "softmods" I need to talk about "hardmods" |
| 22:55 |
Soni |
so "hardmods" can do everything "plugins" can do but also a lot more, like dynamic renderers, add new GUI elements, etc; basically they run both on the server and on the client (altho they may declare themselves optional on either side - more on that later) |
| 22:56 |
VanessaE |
well if and when client-side modding happens, well, we'll see :) |
| 22:56 |
Soni |
now, "softmods" are a very limited subset of "hardmods". like with hardmods, they support custom packet handling, but unlike hardmods they have no file I/O, FFI, dynamic code loading, etc |
| 22:57 |
VanessaE |
hmmmm: *poke* |
| 22:58 |
Soni |
"softmods" run on both the client and the server, but, and here's what's important: they're allowed the exact same things on both sides. |
| 22:58 |
Soni |
so if a softmod tries to do file I/O on the server it won't work. |
| 22:59 |
Soni |
"hardmods" can declare themselves either client-side-required or server-side-required, or both. and they can do anything and everything |
| 23:00 |
Soni |
the caveat with hardmods is that they rely on the user to manually install them |
| 23:00 |
Soni |
so, back to softmods... |
| 23:01 |
Soni |
softmods can register packet handling |
| 23:01 |
Soni |
plugins can use softmods' registered packet handling features if they want to, and then they depend on the softmod |
| 23:01 |
Soni |
but the plugin doesn't need to be synced over |
| 23:02 |
Soni |
(well, both softmods and hardmods would be able to register packet handling, but all 3 kinds of mods would be able to use registered custom packets) |
| 23:04 |
|
AnotherBrick joined #minetest-dev |
| 23:05 |
Soni |
altho softmods can't directly use file I/O they can register a server-side-only hardmod (or a plugin) to handle their client->server packets and server-side stuff |
| 23:05 |
Soni |
and now comes the subject of submods |
| 23:06 |
Soni |
"submods" would be nice to group a set of plugins, softmods and hardmods together |
| 23:08 |
|
Siva joined #minetest-dev |
| 23:10 |
Soni |
so instead of having 1 folder for each plugin, softmod and hardmod, you'd have 1 folder for the "main mod", and some subfolders for each submodule of the mod. e.g. the plugin part and the softmod part (ps: if you're using/making a hardmod you don't need any of the other 2 kinds of mods, altho it might still be nice to split your mod into various "feature sets": e.g. "ores", "decoration", "machines", etc) |
| 23:10 |
Soni |
VanessaE, what do you think? |
| 23:10 |
Soni |
(also did that last message go thru ok? or did it cut off?) |
| 23:11 |
VanessaE |
the whole message came through |
| 23:11 |
VanessaE |
but seems a little complicated |
| 23:14 |
Soni |
only a little |
| 23:15 |
Soni |
"softmods" are sandboxed & synced "hardmods" (and the files must be plain old .lua not .luac or w/e) |
| 23:16 |
Soni |
so it's basically just adding some features and debug hooks |
| 23:16 |
Soni |
bbiab |
| 23:22 |
Soni |
(actually softmods and plugins wouldn't really exist, they'd be more like abstraction layers on top of hardmods) |
| 23:30 |
|
kahrl joined #minetest-dev |
| 23:45 |
Soni |
(I mean, hardmods can do anything, including send code over the internet) |
| 23:54 |
Soni |
VanessaE, also did I mention no bytecode? |
