| Time |
Nick |
Message |
| 00:12 |
|
FrostRanger joined #minetest |
| 00:43 |
|
ANAND joined #minetest |
| 00:55 |
|
catspar joined #minetest |
| 00:59 |
|
Lone_Wolf joined #minetest |
| 01:35 |
|
fruitsnack joined #minetest |
| 01:49 |
|
calcul0n joined #minetest |
| 01:58 |
|
Cornelia joined #minetest |
| 03:17 |
|
puzzlecube joined #minetest |
| 04:20 |
|
Hawk777 joined #minetest |
| 04:23 |
|
Ruslan1 joined #minetest |
| 04:43 |
|
MistahDarcy joined #minetest |
| 04:55 |
|
Lone_Wolf joined #minetest |
| 05:28 |
|
fruitsnack joined #minetest |
| 07:07 |
|
CWz_ joined #minetest |
| 07:14 |
|
fruitsnack joined #minetest |
| 07:23 |
|
Norore joined #minetest |
| 07:24 |
|
Volgaar joined #minetest |
| 07:44 |
fruitsnack |
hey guys, why the engine doesn't respect param1 probability of schematic type decoration nodes? It's not implemented or I'm doing something wrong |
| 07:45 |
fruitsnack |
all nodes are always placed unless the probability is 00 |
| 08:15 |
|
Markow joined #minetest |
| 08:45 |
|
Krock joined #minetest |
| 09:52 |
|
nepugia joined #minetest |
| 10:05 |
|
Scarecrow joined #minetest |
| 10:19 |
|
Krock joined #minetest |
| 10:19 |
|
Cornelia joined #minetest |
| 10:40 |
|
LMD joined #minetest |
| 11:20 |
|
Pie-jacker875 joined #minetest |
| 11:55 |
|
Fixer joined #minetest |
| 12:57 |
|
scr267 joined #minetest |
| 13:03 |
|
cdde joined #minetest |
| 13:56 |
|
Pie-jacker875 joined #minetest |
| 14:10 |
|
Volgaar joined #minetest |
| 14:11 |
|
Pie-jacker875 joined #minetest |
| 14:21 |
lllI1I |
are there plans for / would anyone be opposed to the ability to keep some node and item definitions "in reserve" so that not all node and itemdefs are sent at start, and some might be sent on a "need-to-know" basis to prevent e.g. spoilers maybe? |
| 14:24 |
nepugia |
Registering items after start makes sense certainly to me |
| 14:25 |
Krock |
interests: yes, plans: no. |
| 14:29 |
lllI1I |
how does one get to brainstorming something like that |
| 14:29 |
lllI1I |
I'm guessing (99% sure) it'd need a protocol update |
| 14:30 |
lllI1I |
and probably won't get in until minetest 6.0 |
| 14:31 |
lllI1I |
though maybe it just so happens that the protocol is vague enough about this point that it just so happens that every implementation would support it |
| 14:31 |
lllI1I |
but I doubt that |
| 14:34 |
|
turtleman joined #minetest |
| 14:35 |
lllI1I |
could also save on initial connection time if there are loads of mods on the server |
| 14:36 |
lllI1I |
probably would need to classify definitions as "likely" or "unlikely" to appear commonly |
| 14:36 |
lllI1I |
e.g. good chance "default:stone" or "default:dirt_with_grass" will be encountered |
| 14:37 |
|
Pie-jacker875 joined #minetest |
| 14:38 |
lllI1I |
less likely "supertools:megadiamond_pingspoofer" will show up, so less of a problem if there's a tiny "loading texture" texture for a fraction of a second when it gets found |
| 14:39 |
lllI1I |
guessing default would be assume it's common, more rare stuff (thus being sent later) can be flagged as such |
| 14:43 |
|
pauloue joined #minetest |
| 14:45 |
|
Pie-jacker875 joined #minetest |
| 14:47 |
nepugia |
I'd just mark stuff as to be downloaded, or initiate downloads specifically inside mods |
| 14:49 |
nepugia |
This would probably work best in tandem with clientside mods |
| 14:49 |
nepugia |
(i.e some code might be there already, but meshes or textures only get send over once they become relevant) |
| 14:57 |
|
jluc joined #minetest |
| 14:59 |
Krock |
lllI1I: it would work without a proto bump. Older clients would then just not receive the new content |
| 15:00 |
nepugia |
Krock: that doesn't sound like "working" to me |
| 15:00 |
|
Lone_Wolf joined #minetest |
| 15:01 |
nepugia |
in any case, some clients simply not supporting functionality that is expected to work seams to be undesirable, so to me a protocol bump makes sense |
| 15:01 |
Krock |
it works for clients that support it |
| 15:01 |
Krock |
don't expect forwards compat in old clients |
| 15:01 |
Krock |
how even |
| 15:02 |
nepugia |
you *can't* make it compatible with old clients |
| 15:02 |
nepugia |
which is exactly why you should bump the protocol version... |
| 15:03 |
Krock |
oh. I wasn't clear there. It requires a proto bump, but not an entire backwards incompatible one (i.e. not v6.0) |
| 15:04 |
Krock |
protocol version bump * |
| 15:04 |
Krock |
older clients would then see unknown items and unknown nodes |
| 15:05 |
Krock |
or such with outdated properties |
| 15:06 |
nepugia |
Krock: dynamic textures when? :( |
| 15:07 |
Krock |
how dynamic? |
| 15:07 |
nepugia |
allow me to place *any* texture on my block, no matter when i made it |
| 15:07 |
nepugia |
on any side i want :) |
| 15:07 |
Krock |
nodemeta-specified texturing would skip PLENTY of drawing optimizations |
| 15:08 |
Krock |
since metadata is never read in the render |
| 15:08 |
nepugia |
i never sais nodemeta-specified |
| 15:08 |
Krock |
how else? |
| 15:08 |
nepugia |
but justifying not implementing something with how the design is now is flawed logic |
| 15:08 |
nepugia |
of course it doesn't do a different usecase perfectly to the one it is ment to do now |
| 15:08 |
nepugia |
it doesn |
| 15:09 |
nepugia |
't matter how it is specified really |
| 15:09 |
nepugia |
if you want you could do it based on adjacent blocks too |
| 15:09 |
nepugia |
point is that that should be supported, even if it would be in the nodemeta |
| 15:09 |
Krock |
it matters because somehow this data has to be stored in the map database |
| 15:09 |
nepugia |
same for dynamically adjusting voluminocity of objects |
| 15:09 |
nepugia |
sure, but how it gets stored is of no consequence to me :) |
| 15:09 |
nepugia |
and matters little at runtime |
| 15:09 |
Krock |
apparently. |
| 15:11 |
nepugia |
in any case, the node swap thing seems like a bad hack to me |
| 15:11 |
nepugia |
don't want to register 16 versions of a block just for a texture or voluminocity change |
| 15:13 |
Krock |
how so? it's just a loop |
| 15:13 |
|
Volgaaar joined #minetest |
| 15:13 |
nepugia |
it's putting all my code 16 times in ram for no reason at all |
| 15:13 |
nepugia |
say, what if my block should do like a rainbow animation, rgb like |
| 15:14 |
nepugia |
that would need 256* 256 *256 copies of the code to do that |
| 15:14 |
Krock |
if you want animations, don't use swap_node. Use tile animations |
| 15:14 |
nepugia |
if i want arbitrary ones i have to use swap |
| 15:15 |
nepugia |
in any case, swap_node sucks :P, doesn't matter to me whether you like the api interface or not, programtically there should be no difference between a lit furnace and a non-lit furnace, the code is pretty much the same for both |
| 15:15 |
nepugia |
just that it may play some animations, or change the ligting |
| 15:43 |
|
Pie-jacker875 joined #minetest |
| 15:48 |
|
Lone_Wolf joined #minetest |
| 15:48 |
|
Lone_Wolf joined #minetest |
| 15:52 |
|
Pie-jacker875 joined #minetest |
| 15:54 |
|
ANAND_ joined #minetest |
| 16:00 |
|
Pie-jacker875 joined #minetest |
| 16:05 |
lllI1I |
"API interface..." |
| 16:06 |
lllI1I |
unless you mean an interface to get the API or through which the API goes, etc |
| 16:07 |
lllI1I |
like an ATM machine would produce ATMs |
| 16:10 |
nepugia |
bah, my mistake |
| 16:10 |
nepugia |
accept my cincerest apology for this grammatical error |
| 16:10 |
|
puzzlecube joined #minetest |
| 16:11 |
|
Copenhagen_Bram joined #minetest |
| 16:37 |
|
DS-minetest joined #minetest |
| 16:39 |
|
nerzhul joined #minetest |
| 16:42 |
|
Tux[Qyou] joined #minetest |
| 16:49 |
MinetestBot |
[git] acmgit -> minetest/minetest_game: Remove stack_max from bucket:bucket_empty 83fb6fe https://git.io/fjXGv (2019-07-13T16:47:45Z) |
| 17:00 |
|
Pie-jacker875 joined #minetest |
| 17:15 |
|
Markow joined #minetest |
| 17:21 |
|
DS-minetest joined #minetest |
| 17:27 |
|
Pie-jacker875 joined #minetest |
| 17:28 |
|
GreenDimond joined #minetest |
| 17:36 |
|
Pie-jacker875 joined #minetest |
| 17:45 |
|
awell joined #minetest |
| 17:51 |
|
illwieckz joined #minetest |
| 17:54 |
|
Pie-jacker875 joined #minetest |
| 18:02 |
|
Piejacker875 joined #minetest |
| 18:07 |
|
Tux[Qyou] joined #minetest |
| 18:12 |
|
Pie-jacker875 joined #minetest |
| 18:14 |
|
DS-minetest joined #minetest |
| 18:22 |
|
Pie-jacker875 joined #minetest |
| 18:30 |
|
Pie-jacker875 joined #minetest |
| 18:42 |
|
Pie-jacker875 joined #minetest |
| 18:53 |
|
Pie-jacker875 joined #minetest |
| 19:01 |
|
Pie-jacker875 joined #minetest |
| 19:16 |
|
Miner_48er joined #minetest |
| 19:20 |
|
Pie-jacker875 joined #minetest |
| 19:33 |
|
Pie-jacker875 joined #minetest |
| 19:45 |
|
grumble joined #minetest |
| 19:51 |
|
Pie-jacker875 joined #minetest |
| 19:58 |
|
Pie-jacker875 joined #minetest |
| 20:05 |
|
Piejacker875 joined #minetest |
| 20:09 |
|
Pie-jacker875 joined #minetest |
| 20:15 |
|
Pie-jacker875 joined #minetest |
| 20:16 |
DS-minetest |
can I compare a macro with a char in a preprocessor #if? |
| 20:16 |
DS-minetest |
(I want code only be executed if DIR_DELIM is not "/") |
| 20:19 |
Krock |
only if that's a macro too |
| 20:19 |
Krock |
integer comparison works, so why not string too? *shrug* |
| 20:19 |
DS-minetest |
and if the "/" is a constant? |
| 20:20 |
Krock |
it has to be known to the compiler before the actual code is parsed |
| 20:20 |
DS-minetest |
ah, I see |
| 20:20 |
Krock |
it's not a macro? weird, it should be. |
| 20:26 |
DS-minetest |
meh, that doesn't work: |
| 20:26 |
DS-minetest |
#define SLASH "/" |
| 20:26 |
DS-minetest |
#if DIR_DELIM != SLASH |
| 20:26 |
DS-minetest |
... |
| 20:26 |
DS-minetest |
#endif |
| 20:26 |
DS-minetest |
#undef SLASH |
| 20:26 |
lllI1I |
that doesn't sound like a job for the prepocessor |
| 20:26 |
DS-minetest |
(I hope, it wasn't too long for irc) |
| 20:27 |
DS-minetest |
should I use #ifdef _WIN32? |
| 20:27 |
lllI1I |
is it a compiletime check or a runtime check? |
| 20:27 |
DS-minetest |
a compiletime check I guess |
| 20:28 |
DS-minetest |
it should compile different code based on whether DIR_DELIM is "/" or not |
| 20:28 |
lllI1I |
I guess it would help if we knew what it was you were trying to do |
| 20:28 |
|
Pie-jacker875 joined #minetest |
| 20:29 |
DS-minetest |
I want to send a path via network to another computer, which might use a different DIR_DELIM |
| 20:29 |
DS-minetest |
so, I always send with "/"s |
| 20:30 |
* DS-minetest |
will just compare at runtime and hope that the compiler will optimize |
| 20:30 |
lllI1I |
yeah I wouldn't worry too much about optimizing until and unless it becomes an issue |
| 20:37 |
* DS-minetest |
ended up using #ifdef _WIN32 because of warnings and errors |
| 20:41 |
|
Unit193 joined #minetest |
| 20:42 |
|
Pie-jacker875 joined #minetest |
| 20:51 |
|
Pie-jacker875 joined #minetest |
| 20:59 |
|
jluc joined #minetest |
| 21:05 |
|
Sketch2 joined #minetest |
| 21:06 |
lllI1I |
where is the best description of the network protocol |
| 21:07 |
DS-minetest |
in networkprotocol.h? |
| 21:07 |
DS-minetest |
clientface.h might be interesting, too |
| 21:08 |
lllI1I |
yeah I looked at that first, wanted to know the more lower level to get a better understanding and then forgot about it |
| 21:08 |
lllI1I |
thanks |
| 21:11 |
Lone-Star |
say im creating a fence node, with the fixed post being wood and connected nodes to be steel. how would i define the textures of the connecting nodes? |
| 21:12 |
DS-minetest |
you can't |
| 21:12 |
DS-minetest |
only the boxes change |
| 21:12 |
DS-minetest |
the tiles are applied like to every other nodebox |
| 21:21 |
|
pauloue joined #minetest |
| 21:23 |
|
pauloue joined #minetest |
| 21:44 |
lllI1I |
TYPE_ORIGINAL seems under documented |
| 21:45 |
lllI1I |
I'm seeing a lot of those packets in wireshark and no idea what they are meant to be |
| 21:46 |
lllI1I |
wait I might be dumb |
| 21:48 |
lllI1I |
yeah 00 01 is server's peer id, not channel 00, type 01 |
| 21:56 |
lllI1I |
why does my client appear to send TOSERVER_INIT before receiving a peer id, only to resend it with the peer id after? |
| 21:59 |
lllI1I |
sorry if there's a better channel to ask these questions in |
| 21:59 |
epoch_ |
lllI1I: what are you wanting to do with the network protocol? |
| 22:03 |
DS-minetest |
does the client even know its peer_id? |
| 22:04 |
DS-minetest |
(probably yes, sorry, I wish there was a way to add [off] afterwards) |
| 22:06 |
lllI1I |
at this point, it doesn't know its peer id |
| 22:06 |
lllI1I |
epoch_: thinking of making special "NPC" clients for my server |
| 22:08 |
lllI1I |
not just using a mod because I want to keep CPU cycles low on the server, so in case the "NPC"s are doing a lot of calculations it won't slow the server down |
| 22:09 |
epoch_ |
that'd be neat. |
| 22:09 |
epoch_ |
like IRC bots |
| 22:09 |
lllI1I |
and I can add more NPC's with more VPS's at no computational cost to the server |
| 22:10 |
lllI1I |
well the reason I used quotes is because I'm thinking of offloading quite a bit to these clients |
| 22:10 |
DS-minetest |
haha, multithreading in minetest |
| 22:10 |
lllI1I |
so that they don't have to even be loaded on the server's memory when players aren't present in the area |
| 22:10 |
DS-minetest |
=outsourcing |
| 22:11 |
|
Norore joined #minetest |
| 22:11 |
epoch_ |
I was looking into the protocol a while ago because I was wanting a little program that'd tell me what version the server was running |
| 22:11 |
lllI1I |
yes it works |
| 22:11 |
epoch_ |
so I could point the little program at any minetest server and the proper version would get launched. |
| 22:11 |
lllI1I |
really the only thing that's tripping me up is 1 undocumented byte |
| 22:11 |
lllI1I |
actually 2 I think |
| 22:15 |
epoch_ |
are you working on a wireshark dissector for minetest packets? |
| 22:18 |
DS-minetest |
(I'll leave this here: https://github.com/minetest/minetest/blob/master/util/wireshark/minetest.lua) |
| 22:19 |
epoch_ |
oh boy. |
| 22:19 |
lllI1I |
thought about writing a wireshark plugin for it, but I didn't understand the protocol |
| 22:19 |
lllI1I |
but if I learn the protocol I wouldn't need the plugin shfkksv |
| 22:32 |
lllI1I |
plugin works, thanks DS-minetest |
| 22:34 |
lllI1I |
oh I see now |
| 22:35 |
|
jluc joined #minetest |
| 22:35 |
MinetestBot |
[git] paramat -> minetest/minetest_game: New lighter, greyer permafrost texture 3bca295 https://git.io/fjXnx (2019-07-13T22:35:25Z) |
| 23:00 |
|
Pie-jacker875 joined #minetest |
| 23:04 |
|
illwieckz joined #minetest |
| 23:06 |
|
Cornelia joined #minetest |
| 23:09 |
|
norkle joined #minetest |
| 23:11 |
|
ssieb joined #minetest |
| 23:47 |
|
YuGiOhJCJ joined #minetest |
