| Time |
Nick |
Message |
| 00:00 |
|
Kimapr joined #minetest |
| 00:05 |
|
Eragon joined #minetest |
| 00:49 |
|
chilledfrogs joined #minetest |
| 01:25 |
|
garywhite joined #minetest |
| 01:46 |
|
diceLibrarian2 joined #minetest |
| 02:20 |
|
diceLibrarian2 joined #minetest |
| 02:53 |
|
SwissalpS joined #minetest |
| 03:17 |
|
silverwolf73828 joined #minetest |
| 03:20 |
|
squeaktoy joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:06 |
|
AntumDeluge joined #minetest |
| 05:35 |
|
est31 joined #minetest |
| 05:37 |
|
CRISPR joined #minetest |
| 06:22 |
|
rodrigo-` joined #minetest |
| 08:03 |
|
jluc joined #minetest |
| 08:06 |
|
whosit joined #minetest |
| 08:56 |
|
Kimapr joined #minetest |
| 09:28 |
|
tarsovbak joined #minetest |
| 09:51 |
|
bodiccea joined #minetest |
| 10:42 |
|
MacroFaxSax joined #minetest |
| 10:58 |
|
gregon joined #minetest |
| 11:24 |
|
CRISPR joined #minetest |
| 11:28 |
|
Blockhead256 joined #minetest |
| 12:06 |
|
Desour joined #minetest |
| 12:14 |
|
jaca122 joined #minetest |
| 12:23 |
|
MacroFaxSax joined #minetest |
| 12:45 |
|
guest52 joined #minetest |
| 13:09 |
|
erstazi joined #minetest |
| 13:15 |
|
TheCoffeMaker joined #minetest |
| 14:24 |
|
shaft joined #minetest |
| 14:27 |
shaft |
I have a question: Often it is unclear whether an entity is supposed to movable by other mods or not and checking whether it's an animal or item or player or is mesecons unmov feels like a hack. Why not make it an engine feature or declare an official variable hey_you_may_unconditionally_move_this_object_however_you_want |
| 14:27 |
shaft |
? |
| 14:28 |
shaft |
Or the other way around |
| 14:28 |
shaft |
like DO_NOT_MOVE |
| 14:28 |
shaft |
or a function |
| 14:31 |
shaft |
maybe it was too generalistic |
| 14:37 |
|
shaft joined #minetest |
| 14:43 |
Blockhead256 |
travelnets are the ugliest node ever invented in Minetest |
| 14:43 |
Blockhead256 |
they don't even do a good job of representing a german telephone box either |
| 14:45 |
MTDiscord |
<luatic> shaft: not engine business as far as i am concerned. that's game and mod business, they can set conventions here. if a ubiquitous convention emerges, documenting it can be considered. |
| 14:54 |
MTDiscord |
<warr1024> Probably the best scope to define conventions like that would be at the game level. An influential enough mobs framework could also offer the flag and try to get it to catch on. |
| 14:54 |
erle |
if an ubiquitous convention emerges, it will be deprecated *cough* air_equivalent :D |
| 14:55 |
erle |
movable entities are funny. there was a time when you could use pistons to move enchantment table books away from the enchantment table! |
| 14:55 |
erle |
(the book is floating above the table) |
| 14:55 |
erle |
i think it may have also been possible to move entities out of item frames (in case of some item frame mods) using pistons |
| 14:56 |
erle |
and i once created banner entities that were not bound to an actual node with pistons too |
| 14:56 |
Desour |
there was also once a conveyor belt mod, with which you could move the item entitiy out of an itemframe, which then after a short time produces a new one, that also gets moved out |
| 14:56 |
erle |
dupe machines are real? xD |
| 14:57 |
MTDiscord |
<warr1024> The air_equivalent convention is "deprecated" in the sense that the engine will no longer flag air with it itself (though any game/mod still can override to add it) and will no longer assign meaning to it. You can still use the convention though. |
| 14:57 |
erle |
Warr1024 the issue here is that air and ignore *have* to have it. also, air_equivalent would be very good for various structure spawning emptiness checks. maybe it should have been a group in the first place. |
| 14:58 |
MTDiscord |
<warr1024> tbh rather than specifically flagging entities as "should be affected by X", I've mostly used heuristics. Things that are not physical and not static_save are probably just visual ents, while physical+static_save things are probably real tangible objects and should be affected by wind and pistons and whatever. |
| 14:58 |
erle |
shaft you are thinking in purely mechanical terms. however, entity movability depends on a lot of things. for example, you might want to move items in water. you might want to have a magnetic beam that only attracts iron. |
| 14:58 |
MTDiscord |
<warr1024> and yes it should have been a group |
| 14:58 |
MTDiscord |
<warr1024> and the engine could reinstate it as a pure convention as such |
| 14:59 |
erle |
shaft also you might want to have material that can only be moved with enough force. |
| 14:59 |
MTDiscord |
<warr1024> If your magnet only attracts magnetic things, you'll have a hard time finding out whether they're ferromagnetic, paramagnetic, or diamagnetic, tbh 😄 |
| 15:00 |
erle |
nodecore magnets when |
| 15:00 |
erle |
though knowing nodecore it would be optically powered magnets that generate particle effects and you have to build a big U shaped structure to levitate a single entity |
| 15:00 |
MTDiscord |
<warr1024> I'm not even really sure if lode is actually magnetic; I think in practice it's an alloy. Like the way not all steels are magnetic. |
| 15:01 |
erle |
also kimapr would find a way to make me hate magnets by putting them in the skyhell starting block and making them ruin my day |
| 15:01 |
MTDiscord |
<warr1024> Actually making certain materials strongly diamagnetic might be more interesting, so you use magnets to push instead of pull. |
| 15:01 |
Kimapr |
hello |
| 15:01 |
erle |
Kimapr i am still amazed that the island is radioactive |
| 15:02 |
MTDiscord |
<warr1024> Kimapr would find a way to make magnets flammable |
| 15:02 |
Kimapr |
TRUE |
| 15:02 |
erle |
kimapr would find a way to make flames magnetic |
| 15:02 |
erle |
colored fire in nodecore when? |
| 15:03 |
erle |
i have thought about runes and i think “write runes written down in a place to teleport to that place” feels magical, but not necessarily nodecorian. but what is nodecorian? is there a writeup of the core issues? |
| 15:03 |
erle |
also i am afk bamboo farming |
| 15:04 |
erle |
1. bamboo grows. 2. an observer is triggered. 3. pistons harvest bamboo, sugarcane, melon. 4. loot falls into water. 5. a hopper puts them into a barrel. |
| 15:04 |
erle |
very wasteful because the items sometimes drop on the plants. but fully automated. |
| 15:04 |
erle |
providing food and wood |
| 15:09 |
erle |
Warr1024 btw do you know/have a list of automation systems in block games? so far i have seen: mesecons/technic style (on/off, needs physical connection), redstone style (16 states, decays distance, needs physical connection), (lua)controller style (pass messages, do whatever), insidethebox style (limited automation, no physical connection necessary), nodecore (on/off/focus line-of-sight light-based logic) |
| 15:09 |
erle |
redstone … decays *with* distance |
| 15:09 |
erle |
i ate a word |
| 15:13 |
MTDiscord |
<warr1024> interesting, I haven't really thought about automation systems that way. Like rather than the type of signal carrying, I tend to think about abstraction levels. There are raw systems like nodecore or classic redstone that are turing tarpits, then there are "menagerie" systems like mesecons and modern redstone where you have all sorts of logic gates and crap, and then there are like "microcontroller" systems where you just plop down one |
| 15:13 |
MTDiscord |
node and all the programming is internalized. |
| 15:42 |
|
Desour_ joined #minetest |
| 15:55 |
|
TheCoffeMaker joined #minetest |
| 15:56 |
|
tarsovbak joined #minetest |
| 16:10 |
|
ireallyhateirc joined #minetest |
| 16:58 |
|
Talkless joined #minetest |
| 16:58 |
|
chilledfrogs joined #minetest |
| 16:59 |
|
CRISPR joined #minetest |
| 17:31 |
|
tarsovbak1 joined #minetest |
| 18:11 |
|
SwissalpS joined #minetest |
| 18:39 |
|
jaca122 joined #minetest |
| 18:42 |
|
SFENCE joined #minetest |
| 18:46 |
|
SwissalpS joined #minetest |
| 18:50 |
|
SFENCE joined #minetest |
| 19:29 |
|
tarsovbak joined #minetest |
| 19:31 |
MinetestBot |
[git] appgurueu -> minetest/minetest: Restore `.x` models to working state (#15550) a37bdbf https://github.com/minetest/minetest/commit/a37bdbf8b7778336c6740f994164097ebb4129e6 (2024-12-18T19:29:35Z) |
| 19:33 |
|
diceLibrarian2 joined #minetest |
| 19:36 |
|
diceLibrarian2 joined #minetest |
| 19:42 |
|
liceDibrarian joined #minetest |
| 19:42 |
|
tarsovbak1 joined #minetest |
| 20:26 |
erle |
Warr1024 what is the difference between classic and modern redstone? making a flip flop with a copper blub vs making a flip flop with redstone torches? |
| 20:33 |
|
___nick___ joined #minetest |
| 20:37 |
|
___nick___ joined #minetest |
| 20:43 |
|
shaft joined #minetest |
| 20:43 |
shaft |
how do i stop a particle from following the player? (facing to the camera) |
| 20:45 |
shaft |
I need to set it to a certain rotation |
| 20:58 |
shaft |
PLEASE HELP ME |
| 20:59 |
ireallyhateirc |
vertical = false, |
| 20:59 |
ireallyhateirc |
-- If true faces player using y axis only |
| 20:59 |
ireallyhateirc |
hmmm but that's just for one axis |
| 21:01 |
shaft |
That makes it face the player at any direction. Vertical = true makes it rotate around Y |
| 21:02 |
shaft |
Do I really have to abuse entities for particles? |
| 21:02 |
sfan5 |
particles always face the player |
| 21:02 |
shaft |
But I want my bulletholes from my fork of rangedweapons to face away from the node. |
| 21:03 |
shaft |
Is using particles for that bad in general? |
| 21:04 |
sfan5 |
its kind of not the intention but I can think of way worse uses of particles |
| 21:04 |
sfan5 |
so you want to be able to choose the normal vector of the particle? |
| 21:04 |
shaft |
Yes |
| 21:05 |
shaft |
I want my decals to look right. Whether with particles or any other way |
| 21:05 |
shaft |
Wouldn't an entity be more expensive than particles? |
| 21:06 |
sfan5 |
yes |
| 21:07 |
shaft |
So can I do that or not? |
| 21:07 |
sfan5 |
no, but I suggest opening a feature request |
| 21:08 |
shaft |
Why not implement decals? |
| 21:08 |
shaft |
Too expensive? |
| 21:08 |
shaft |
Or would be the same. The particle would probably need to hover slightly above the node but it's probably the same with a decal. Am I wrong? |
| 21:12 |
sfan5 |
dunno |
| 21:13 |
sfan5 |
the thing is decals are a whole new feature while adjusting particle direction is a tiny change |
| 21:16 |
shaft |
https://github.com/minetest/minetest/issues/15574 |
| 21:18 |
shaft |
If it's a tiny change then I expect it done in 5.11! |
| 21:18 |
shaft |
:) |
| 21:25 |
MTDiscord |
<warr1024> erle: "classic" redstone to me would be the initial design of it, i.e. dust and torches, plus the "terminal" stuff like buttons, levers, touchplates, doors, etc. It had everything you needed for a turing-complete system, though I think there may have been a bit of an issue making delays of odd lengths or something. |
| 21:36 |
shaft |
can a particle have a color? |
| 21:37 |
shaft |
Would be useful for blood splatter because it has different blood colors |
| 21:37 |
shaft |
Or do you need a whole animation for each different animal? |
| 21:43 |
shaft |
According to the documentation probably not. |
| 22:04 |
|
Lunatrius` joined #minetest |
| 22:34 |
|
Verticen joined #minetest |
| 22:34 |
|
nopjmp_ joined #minetest |
| 23:00 |
|
jaca122 joined #minetest |
| 23:33 |
|
panwolfram joined #minetest |
