| Time |
Nick |
Message |
| 00:01 |
|
XeonSquared joined #minetest |
| 00:15 |
|
twoelk|2 joined #minetest |
| 00:40 |
|
bigfoot547 joined #minetest |
| 00:50 |
|
YangMame joined #minetest |
| 00:51 |
|
rubenwardy joined #minetest |
| 00:55 |
|
Tux[Qyou] joined #minetest |
| 01:04 |
|
guru joined #minetest |
| 01:07 |
rubenwardy |
bigfoot547, had some bot attacks |
| 01:08 |
rubenwardy |
the simple solution is to not run your bouncer as root |
| 01:08 |
lumberJ |
hey rubenwardy and bigfoot547 |
| 01:08 |
lumberJ |
bigfoot547 did you ever figure out your compiling issues from a few days ago? |
| 01:09 |
rubenwardy |
oh lol |
| 01:09 |
rubenwardy |
heh |
| 01:09 |
lumberJ |
hmm, thats unfortunate. |
| 01:10 |
lumberJ |
sorry i pooped out on you |
| 01:10 |
lumberJ |
might be worth a try |
| 01:11 |
lumberJ |
tomorrow is always tomorrow, isn't it? :) |
| 01:12 |
|
bigfoot547 joined #minetest |
| 01:27 |
|
illwieckz joined #minetest |
| 02:13 |
|
Taoki_1 joined #minetest |
| 02:17 |
|
xerox123_ joined #minetest |
| 02:18 |
|
AntumDeluge joined #minetest |
| 02:27 |
|
paramat joined #minetest |
| 02:27 |
|
Fuchs joined #minetest |
| 02:32 |
|
ThomasMonroe joined #minetest |
| 02:37 |
|
CBugDCoder joined #minetest |
| 03:16 |
|
Surfer2010 joined #minetest |
| 03:54 |
|
Mame joined #minetest |
| 04:14 |
|
torgdor joined #minetest |
| 04:14 |
|
YuGiOhJCJ joined #minetest |
| 05:05 |
|
YuGiOhJCJ joined #minetest |
| 05:57 |
|
handsome_pirate joined #minetest |
| 05:57 |
handsome_pirate |
Ahoy! |
| 05:57 |
handsome_pirate |
So, I'm on 0.4.16 |
| 05:57 |
handsome_pirate |
Carts and advtrains don't work |
| 05:57 |
handsome_pirate |
They no longer move |
| 05:57 |
handsome_pirate |
well, they no longer move unless I hit them (carts) |
| 05:58 |
handsome_pirate |
mesecon track no longer has any effect |
| 06:10 |
|
aheinecke joined #minetest |
| 06:32 |
|
torgdor joined #minetest |
| 06:45 |
|
behalebabo joined #minetest |
| 07:05 |
|
ashtrayoz joined #minetest |
| 07:11 |
|
ashtrayoz joined #minetest |
| 07:21 |
|
pitchum joined #minetest |
| 07:26 |
|
jluc joined #minetest |
| 07:35 |
|
passant joined #minetest |
| 07:43 |
|
CWz joined #minetest |
| 07:59 |
|
compunerd joined #minetest |
| 08:46 |
|
Darcidride joined #minetest |
| 08:58 |
|
YuGiOhJCJ joined #minetest |
| 09:08 |
|
ensonic joined #minetest |
| 09:13 |
|
Krock joined #minetest |
| 09:30 |
|
nowhere_man joined #minetest |
| 09:37 |
|
shivajiva joined #minetest |
| 09:38 |
|
Bobr2 joined #minetest |
| 09:42 |
|
Megaf joined #minetest |
| 09:46 |
|
cybercorn[m] left #minetest |
| 09:52 |
|
RoaryTiger joined #minetest |
| 10:11 |
|
Fritigern joined #minetest |
| 10:20 |
|
sooojos joined #minetest |
| 10:24 |
|
Fritigern joined #minetest |
| 10:27 |
|
Telesight joined #minetest |
| 10:51 |
|
Wuzzy joined #minetest |
| 11:03 |
|
CatButts joined #minetest |
| 11:04 |
|
CatButts left #minetest |
| 11:21 |
|
YuGiOhJCJ joined #minetest |
| 11:25 |
|
Fixer joined #minetest |
| 11:26 |
|
Jordach joined #minetest |
| 11:43 |
|
bas080 joined #minetest |
| 11:44 |
|
Krock joined #minetest |
| 11:58 |
|
jluc joined #minetest |
| 12:06 |
|
bas080 joined #minetest |
| 12:44 |
|
Krock joined #minetest |
| 13:00 |
|
Tux[Qyou] joined #minetest |
| 13:01 |
|
ThomasMonroe joined #minetest |
| 13:17 |
ashtrayoz |
Calinou: could you please have a look at moreblocks #87 and tell me if there is anything else needing to be done to it? |
| 13:29 |
|
bas080 joined #minetest |
| 13:48 |
Krock |
ashtrayoz, are you sure you can't put that into a nice looking loop? |
| 13:48 |
|
deltasquared joined #minetest |
| 13:48 |
Krock |
there seems to be a logic for these alias but that's very hard to see this way |
| 13:50 |
* deltasquared |
decides to look at the mentioned PR |
| 13:52 |
deltasquared |
Krock: hmm, yeah, I guess you could put that into a loop |
| 13:53 |
* deltasquared |
checks he understands which way round register_alias works |
| 13:54 |
Krock |
deltasquared, just remember this line: minetest.register_alias("mapgen_stone", "default:stone") and you'll do it right every time |
| 13:54 |
deltasquared |
Krock: oh cool, the mapgen uses aliases internally? neat |
| 13:54 |
deltasquared |
that kinda figures but still |
| 13:54 |
deltasquared |
I'll have to remember that one ;) |
| 13:54 |
Krock |
yes, because each subgame can define their own node names |
| 13:55 |
Krock |
and of course, mapgen_stone doesn't exist, that's why you replace/alias it |
| 13:56 |
deltasquared |
ashtrayoz: I concur with Krock, a for-loop over a list of prefixes would help avoid breaking the DRY rule and make it easier to spot mistakes. a comment along with it to explain the need for it wouldn't hurt either I guess... https://github.com/minetest-mods/moreblocks/pull/87/commits/4fc89c7d0d6674e6ac7a5d79d937009a7ae6c40d |
| 13:56 |
|
CBugDCoder joined #minetest |
| 13:56 |
Krock |
could reduced to about 8 lines, perhaps |
| 13:57 |
deltasquared |
I'm assuming the prefixes have a generated pattern, I haven't looked closely at the moreblocks code |
| 14:01 |
deltasquared |
meanwhile... |
| 14:01 |
deltasquared |
!mod advtrains |
| 14:01 |
MinetestBot |
deltasquared: Advanced Trains [advtrains] by orwell - https://forum.minetest.net/viewtopic.php?t=14726 |
| 14:04 |
deltasquared |
huh, it would appear my idea of using free-form entity rails has already been thought of. |
| 14:04 |
rubenwardy |
really wish advtrains had some more people working on it |
| 14:05 |
rubenwardy |
was quite buggy last time I tried, saw they've made some fixes though |
| 14:05 |
deltasquared |
I can't say I'm a fan of those train models. but I'll have a gander |
| 14:05 |
rubenwardy |
yeah, they're quite uggly |
| 14:05 |
rubenwardy |
mainly due to lighting and colors |
| 14:06 |
deltasquared |
to me it's more just the clash with the base MT art style. |
| 14:06 |
deltasquared |
though, glaring bright colours don't help much :P |
| 14:06 |
deltasquared |
also, a generic "assets" mod in the modpack, that could *never* clash with anything >_> |
| 14:08 |
rubenwardy |
lol |
| 14:08 |
rubenwardy |
that won't be present when you download the release zip |
| 14:09 |
rubenwardy |
you can also just delete it |
| 14:12 |
deltasquared |
ok, fine. just trying it out... that... actually works fairly well for a placement system |
| 14:16 |
* deltasquared |
tries unsuccesfully to get two bend turns to line up |
| 14:16 |
deltasquared |
work damnit |
| 14:18 |
deltasquared |
this is certainly a mildly frustrating exercise |
| 14:18 |
deltasquared |
I knew there'd be a caveat to trying to work with non-orthoganal connections on a cubic grid. |
| 14:23 |
deltasquared |
hrm, I think I might still give the entity-based approach a whirl at some point |
| 14:24 |
deltasquared |
on a sorta related note, is there any correspondence to the visual range for entities and the range at which their step callbacks are run? |
| 14:24 |
|
Fixer joined #minetest |
| 14:24 |
deltasquared |
(obv. they'd be independent because of the client/server split to a degree) |
| 14:29 |
|
antims joined #minetest |
| 14:34 |
|
rafalcpp joined #minetest |
| 15:06 |
|
Fixer joined #minetest |
| 16:06 |
|
AntumDeluge joined #minetest |
| 16:27 |
|
deltasquared joined #minetest |
| 16:27 |
deltasquared |
hrm, if you move a mod to a modpack the dependency ordering seems to break |
| 16:28 |
* deltasquared |
checks to see if depending on the modpack would set the ordering properly |
| 16:29 |
deltasquared |
... oh wai |
| 16:29 |
deltasquared |
I'm an idiot |
| 16:29 |
deltasquared |
it seems I was being a derp and had forgotten to set depends.txt for this particular mod |
| 16:31 |
|
Darcidride_ joined #minetest |
| 16:43 |
|
bas080 joined #minetest |
| 16:43 |
deltasquared |
might I suggest that to catch incidental ordering errors sooner, MT shuffles the starting order for mods being loaded? (still respecting dependency graphs of course) |
| 16:49 |
|
FreeFull joined #minetest |
| 16:50 |
|
nowhere_man joined #minetest |
| 16:52 |
|
AntumDeluge joined #minetest |
| 16:56 |
|
Akberid joined #minetest |
| 17:14 |
|
jimvideo joined #minetest |
| 17:28 |
|
Tux[Qyou] joined #minetest |
| 17:30 |
|
bas080 joined #minetest |
| 18:20 |
|
soloojos joined #minetest |
| 18:20 |
|
bas080 joined #minetest |
| 18:23 |
|
YuGiOhJCJ joined #minetest |
| 18:32 |
|
lumberJ joined #minetest |
| 18:47 |
|
CBugDCoder joined #minetest |
| 19:02 |
|
M6HZ_ joined #minetest |
| 19:08 |
|
ImNotHere joined #minetest |
| 19:11 |
|
ensonic joined #minetest |
| 19:18 |
Dargod |
How can I delay the execution of a function in mod before the completion of loading other mods? |
| 19:19 |
Krock |
sorry? "delay" and "before" for the same thing? please explain what you would like to do |
| 19:22 |
sofar |
you can delay it until *after* all mods are loaded. |
| 19:22 |
sofar |
minetest.after(0, function() print("after all mods") end) |
| 19:23 |
Dargod |
As I wrote earlier, I'm working on the function of filtering minetest.registered_nodes. however, the mods are loaded sequentially and the table does not have time to fill all the parameters |
| 19:23 |
sofar |
don't do that |
| 19:24 |
sofar |
unstead, depend on the mod that you want to remove nodes from, and then minetest.override() them |
| 19:25 |
Dargod |
no, I just need filtered copy of minetest.registered_nodes, I am not need remove or override |
| 19:28 |
sofar |
you just need a modified copy? |
| 19:28 |
Dargod |
thanks, I'll try minetest.after |
| 19:28 |
Dargod |
yes |
| 19:28 |
sofar |
yeah, just use the .after(0 method |
| 19:28 |
Dargod |
Only special nodes with all their parameters |
| 19:29 |
sofar |
a small optimized cache, essentially? |
| 19:30 |
Dargod |
hmm, its for additional sfinv creative tabs |
| 19:32 |
Dargod |
By default, only 3 tabs are offered, and this is not enough |
| 19:33 |
rubenwardy |
minetest.after is the right approach then |
| 19:39 |
|
bas080 joined #minetest |
| 19:40 |
|
guru joined #minetest |
| 19:59 |
|
ssieb joined #minetest |
| 20:00 |
|
ssieb joined #minetest |
| 20:04 |
|
bas080 joined #minetest |
| 20:36 |
|
deltasquared joined #minetest |
| 20:38 |
|
AntumDeluge joined #minetest |
| 20:42 |
|
swift110 joined #minetest |
| 20:47 |
|
Taose joined #minetest |
| 20:54 |
|
nowhere_man joined #minetest |
| 22:03 |
|
jluc joined #minetest |
| 22:18 |
|
Megaf joined #minetest |
| 22:30 |
|
nowhere_man joined #minetest |
| 22:41 |
|
blackGen joined #minetest |
| 22:42 |
blackGen |
How can implement tinting of the screen? |
| 22:42 |
blackGen |
For example like when player is submerged in water |
| 22:42 |
blackGen |
Just displaying 100% stretched texture? |
| 22:43 |
blackGen |
There is post_effect_color, but it only applies when player is inside the node |
| 23:02 |
|
redblade7 joined #minetest |
| 23:02 |
|
guru left #minetest |
| 23:17 |
blackGen |
Is it possible to execute something like on_step, but on player? |
| 23:18 |
blackGen |
or I need to register globalstep |
| 23:19 |
sfan5 |
you can just use on_globalstep and iterater over all players |
| 23:20 |
|
swift110 joined #minetest |
| 23:20 |
blackGen |
well it seems to be quite heavy |
| 23:21 |
blackGen |
I was hoping to spawn particles around player after he uses a certain item |
| 23:21 |
blackGen |
particles keep spawning for some time |
| 23:21 |
blackGen |
but it needs to follow player pos too |
| 23:25 |
sfan5 |
can't you attach a particlespawner to an object? |
| 23:27 |
blackGen |
ah well, haha, I guess I didn't look at the api reference close enough |
| 23:27 |
blackGen |
Never knew it's possible to attach particle spawners |
| 23:52 |
|
illwieckz joined #minetest |
