| Time |
Nick |
Message |
| 00:21 |
|
sys4 joined #minetest |
| 00:47 |
|
erlehmann joined #minetest |
| 00:47 |
|
proller joined #minetest |
| 00:57 |
|
Alias2 joined #minetest |
| 02:13 |
|
delta23 joined #minetest |
| 02:20 |
|
delta23 joined #minetest |
| 03:28 |
|
queria joined #minetest |
| 03:34 |
|
queria joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:02 |
|
specing_ joined #minetest |
| 04:48 |
|
Elzington_ joined #minetest |
| 05:01 |
|
riff-IRC joined #minetest |
| 06:14 |
|
grouinos joined #minetest |
| 06:22 |
|
delta23 joined #minetest |
| 06:24 |
|
Hawk777 joined #minetest |
| 07:03 |
|
CWz joined #minetest |
| 07:18 |
|
grouinos joined #minetest |
| 07:19 |
|
TomTom joined #minetest |
| 07:32 |
MTDiscord |
<Kimapr> wait, if it's not possible, how did YOU do it? |
| 07:50 |
|
plainoldcheese joined #minetest |
| 08:05 |
|
hendursa1 joined #minetest |
| 09:43 |
|
est31 joined #minetest |
| 10:09 |
|
asdflkj_sh joined #minetest |
| 10:19 |
sfan5 |
good question |
| 10:20 |
sfan5 |
the answer is that someone once built the libraries in a working state (we just used those binaries) and the build scripts weren't in order to recreate that |
| 10:31 |
|
olliy joined #minetest |
| 10:32 |
erlehmann |
sounds like a “reflections on trusting trust” story |
| 10:45 |
|
AristotIe joined #minetest |
| 10:52 |
|
grouinos joined #minetest |
| 11:18 |
|
plainoldcheese joined #minetest |
| 11:27 |
|
grouinos joined #minetest |
| 11:41 |
|
calcul0n joined #minetest |
| 11:57 |
|
appguru joined #minetest |
| 12:25 |
|
tech_exorcist joined #minetest |
| 12:43 |
|
appguru joined #minetest |
| 12:53 |
|
grouinos joined #minetest |
| 12:57 |
|
proller joined #minetest |
| 13:33 |
|
absurb joined #minetest |
| 13:34 |
|
tech_exorcist joined #minetest |
| 13:35 |
|
definitelya joined #minetest |
| 14:21 |
|
kamdard joined #minetest |
| 14:56 |
|
tech_exorcist joined #minetest |
| 15:01 |
|
grouinos joined #minetest |
| 15:17 |
|
hlqkj joined #minetest |
| 15:19 |
|
Sven_vB joined #minetest |
| 15:29 |
|
fluxionary joined #minetest |
| 15:36 |
|
GNUHacker joined #minetest |
| 15:36 |
|
Fixer joined #minetest |
| 15:43 |
|
erlehmann joined #minetest |
| 15:54 |
|
Extex joined #minetest |
| 16:01 |
|
specing_ joined #minetest |
| 16:02 |
|
FreeFull joined #minetest |
| 16:11 |
|
plainoldcheese joined #minetest |
| 16:13 |
|
garywhite joined #minetest |
| 16:13 |
|
garywhite joined #minetest |
| 16:22 |
|
olliy joined #minetest |
| 16:23 |
|
hendursaga joined #minetest |
| 16:59 |
|
Verticen joined #minetest |
| 17:10 |
|
Talkless joined #minetest |
| 17:38 |
|
grouinos joined #minetest |
| 17:43 |
|
kamdard joined #minetest |
| 17:47 |
|
appguru1 joined #minetest |
| 18:03 |
|
___nick___ joined #minetest |
| 18:14 |
|
longerstaff13 joined #minetest |
| 18:26 |
|
plainoldcheese joined #minetest |
| 18:28 |
|
grouinos joined #minetest |
| 18:33 |
|
est31 joined #minetest |
| 18:36 |
|
Fixer_ joined #minetest |
| 18:39 |
definitelya |
I think I'm onto something, trying to push for the unthawing of MTG; Minetest is a non-universal game engine, it excels at simulating spaces like terrain, entities, and other features found IRL; |
| 18:40 |
definitelya |
it doesn't even need to be a game at all, though, it can just as well be an Earth simulator, upon which games, mods, maps and so on can be developed separately, by different devs than the core team. |
| 18:43 |
definitelya |
an external example are platforms like Neos VR; you can make subgames in it, but at it's core, it's a way to chat in VR. A solid ground what we need! |
| 18:43 |
definitelya |
is* |
| 18:48 |
definitelya |
Am I just boomer ranting 'cause I'm new? Do tell me. :) |
| 18:49 |
Ingar |
working for Meta ? |
| 18:49 |
definitelya |
Ingar hissssss lizerd |
| 18:50 |
Ingar |
sorry, I'm debugging spontaneous reboots :p |
| 19:00 |
MTDiscord |
<Lone_Wolf> MTG was pretty much frozen before they decided to make it official |
| 19:04 |
definitelya |
I mean it works as a simulator though, it just had no appeal as a game, which is way too much effort for MTG's case. |
| 19:12 |
MTDiscord |
<Lone_Wolf> Yeah, it's best as a modding base |
| 19:13 |
MTDiscord |
<Lone_Wolf> The codebase is geared away from that though |
| 19:17 |
definitelya |
I'm biased in that I don't see much issue with a clone of MTG; again, it's not a universal engine, so most customization will be just a different type of simulation. |
| 19:18 |
definitelya |
The takeaway from this to me is: a solid base simulator that works and is fun to use in multiplayer is worth sacrificing the oddball mods that try to shoot for the moon. |
| 19:19 |
definitelya |
that's just me tho |
| 19:19 |
definitelya |
*for |
| 19:26 |
|
moongaia joined #minetest |
| 19:34 |
Bombo |
hi, i'm trying to make a mob, with blender, it's working with one cube.b3d, one texture.png but now i have two cubes, how do i tell minetest to use cubetex1.png for the lower cube, cubetex2.png for the upper cube? |
| 19:37 |
|
grouinos joined #minetest |
| 19:42 |
MTDiscord |
<Lone_Wolf> IIRC: Use a seperate material for each cube, then supply both textures in your entity definition (textures = {"tex1.png", "tex2.png"},) |
| 19:43 |
Bombo |
oh that's what the second png is for |
| 19:43 |
Bombo |
trying that out |
| 19:44 |
MTDiscord |
<Lone_Wolf> Yeah, I think the textures array just maps to your b3d materials |
| 19:49 |
|
grouinos joined #minetest |
| 19:55 |
Bombo |
doesn't seem to work |
| 19:55 |
Bombo |
now the lower cube is black, the upper cube is white |
| 19:56 |
MTDiscord |
<Lone_Wolf> In blender? |
| 19:56 |
Bombo |
textures = { {'mobi_dings.png'}, {'mobi_bums.png'} }, |
| 19:56 |
Bombo |
in minetest |
| 19:57 |
Bombo |
when i just do textures = { {'mobi_dings.png'} }, the lower cube gets it' |
| 19:57 |
MTDiscord |
<Lone_Wolf> You don't need to put your textures in tables |
| 19:57 |
Bombo |
it's texture |
| 19:57 |
Bombo |
how do i do it then? |
| 19:58 |
MTDiscord |
<Lone_Wolf> textures = {"tex1.png", "tex2.png"}, |
| 19:59 |
Bombo |
oh i see |
| 19:59 |
Bombo |
well, now it works ;) |
| 20:00 |
Bombo |
thx Lone_Wolf |
| 20:01 |
Bombo |
so just ONE table not table in tables ;) |
| 20:01 |
Bombo |
{ } is table isn't it |
| 20:03 |
jonadab |
Or a list. I've never been quite sure if lua even makes a technical distinction between lists and tables. |
| 20:04 |
Bombo |
but if there were like 10 obj in blender it gets complicated i guess |
| 20:04 |
Bombo |
mkay |
| 20:14 |
|
Extex joined #minetest |
| 20:23 |
|
specing joined #minetest |
| 20:30 |
|
IceDragon joined #minetest |
| 20:33 |
Chompy |
Do you guys commonly use remesh to make your models a solid continuous mesh |
| 20:34 |
Chompy |
seems like if you dont then the side of the model facing you becomes invisible |
| 21:02 |
|
sys4 joined #minetest |
| 21:17 |
|
specing_ joined #minetest |
| 21:18 |
MTDiscord |
<x2048> Chompy: It does not look like minetest uses a single continuous mesh at all. Every material in every block or entity is rendered as a separate mesh. |
| 21:19 |
jonadab |
Isn't there a drawtype that does that? |
| 21:19 |
jonadab |
Or am I confusing the side facing you and the side facing away? |
| 21:23 |
|
FreeFull joined #minetest |
| 21:48 |
MTDiscord |
<luatic> That's not related to drawtype. Based on Chompy's description, it seems he is referring to backface culling, which can be turned off using an object property. The "side of the model facing" you is the frontface though and shouldn't be culled - most likely the mesh normals were calculated wrongly. Inverting them should fix the issue. |
| 21:49 |
Chompy |
Oh cool |
| 21:50 |
Chompy |
That makes sense, basically the mesh had two intersecting parts I thought that was the issue. |
| 22:11 |
|
olliy1or joined #minetest |
| 22:26 |
|
moongaia joined #minetest |
| 22:28 |
|
Sven_vB joined #minetest |
| 22:30 |
|
grouinos joined #minetest |
| 22:43 |
|
definitelya left #minetest |
| 22:44 |
|
proller joined #minetest |
| 23:00 |
|
Sven_vB joined #minetest |
| 23:13 |
|
Verticen joined #minetest |
| 23:14 |
|
kamdard joined #minetest |
| 23:25 |
|
asdflkj_sh joined #minetest |
