| Time |
Nick |
Message |
| 00:24 |
|
Lesha_Vel joined #minetest |
| 01:14 |
|
smk joined #minetest |
| 02:42 |
|
Izaya left #minetest |
| 03:05 |
|
YuGiOhJCJ joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:16 |
|
diceLibrarian2 joined #minetest |
| 04:46 |
|
Lesha_Vel joined #minetest |
| 04:47 |
|
qqq joined #minetest |
| 05:37 |
|
s20 joined #minetest |
| 06:27 |
|
calcul0n joined #minetest |
| 06:55 |
|
lemonzest joined #minetest |
| 07:00 |
|
BuckarooBanzai joined #minetest |
| 07:06 |
|
calcul0n_ joined #minetest |
| 07:22 |
|
est31 joined #minetest |
| 07:49 |
|
s20 joined #minetest |
| 07:57 |
|
lissobone joined #minetest |
| 07:58 |
lissobone |
Frankly speaking, rangedweapons is the most mysterious mod in the history of minetest. |
| 07:59 |
lissobone |
It has left me wondering how did davidthecreator manage to construst such mighty erection not even knowing how do tables work in lua. |
| 07:59 |
|
xBarkDog joined #minetest |
| 07:59 |
lissobone |
hi |
| 07:59 |
lissobone |
bye |
| 08:00 |
lissobone |
I am currently modifying it so that it would work with TechAge: firearms would not be magically manufactured by hand with mese, but with special machinery (TA3-TA5). I believe this would greatly increase the degree of immersion in industrialization. |
| 08:02 |
|
xBarkDog joined #minetest |
| 08:04 |
lissobone |
I will share the results of my hacking once I am done. |
| 08:11 |
|
TomTom joined #minetest |
| 08:11 |
|
liceDibrarian joined #minetest |
| 08:52 |
|
dridron joined #minetest |
| 09:02 |
|
json joined #minetest |
| 09:05 |
|
appguru joined #minetest |
| 09:09 |
lissobone |
Digtron needs some adaptations, too. It would be ridiculous to ride a steel boring machine in iron age as if it's 2050. |
| 09:25 |
calcul0n_ |
the techage survival server has these, digtron parts require ta4 machines |
| 09:25 |
calcul0n_ |
i think you can find the code in joe's repositories |
| 09:30 |
calcul0n_ |
here probably : https://github.com/joe7575/digtron |
| 09:59 |
lissobone |
yo thanks |
| 10:01 |
lissobone |
that doesn't look like it, though |
| 10:02 |
lissobone |
the default digtron does interact with techage by beinng able to be charged |
| 10:17 |
|
MTDiscord1 joined #minetest |
| 10:46 |
|
Zambyte joined #minetest |
| 11:01 |
|
s20 joined #minetest |
| 12:04 |
erle |
consider the following https://git.minetest.land/erlehmann/tga_encoder/pulls/1/files |
| 12:11 |
|
qqq joined #minetest |
| 13:14 |
lissobone |
At this point we'll soon have Doom running in minetest as a rendered texture. |
| 13:30 |
|
appguru joined #minetest |
| 14:28 |
|
s20 joined #minetest |
| 14:32 |
|
jaca122 joined #minetest |
| 14:42 |
|
definitelya joined #minetest |
| 15:07 |
|
vampirefrog joined #minetest |
| 15:09 |
|
kamdard joined #minetest |
| 15:21 |
|
witsie joined #minetest |
| 15:28 |
|
mrkubax10 joined #minetest |
| 15:34 |
erle |
lissobone i did already look for a doom implementation in lua but did not find one. |
| 15:35 |
erle |
lissobone is löve2d pure lua lol? |
| 15:36 |
erle |
lissobone my end goal is, as always, better handheld maps |
| 15:37 |
erle |
lissobone with the change that rubenwardy made so that items can hold their own textures, you can now, finally have a map item that looks like itself in a normal inventory. |
| 15:37 |
erle |
which means it's time to update xmaps soon for “craft several maps into a new map” ig |
| 16:03 |
|
json joined #minetest |
| 16:12 |
copygirl |
Is it possible to detect an empty-hand sneak-rightclick on a node? |
| 16:13 |
|
jaca122 joined #minetest |
| 16:18 |
calcul0n_ |
an on_rightclick handler where you check sneak key and wielded item? |
| 16:19 |
copygirl |
Yeah, global or per node, I do not mind, I just want to handle sneak-rightclick on certain blocks while not holding anything. |
| 16:23 |
copygirl |
Can I override on_place of `""` item or something? |
| 16:25 |
|
definitelya joined #minetest |
| 16:41 |
Krock |
copygirl: override minetest.item_place |
| 16:42 |
Krock |
more specifically, back up the function in a separate variable, overwrite the minetest.item_place value with your own function and call the old function from within |
| 16:43 |
copygirl |
Yeah that would work, though I believe it would not work since NodeCore does already override empty hand on_place, so I think I gotta do what you suggest, except with that function. |
| 16:44 |
copygirl |
(It implements its "climbing" feature that way.) |
| 16:48 |
|
Trifton joined #minetest |
| 16:49 |
copygirl |
Thank you <3 |
| 16:52 |
MTDiscord |
<warr1024> You can override an existing override by (1) waiting until the existing override has already been registered (i.e. depend on the mod that makes that change) and then (2) creating a "wrapper" for it, i.e. read the old on_place from the item registration, then create your own wrapper that can do your own logic, and call the old one as a fallback (close around it) and then override_item to apply your wrapped version. |
| 16:53 |
MTDiscord |
<warr1024> If you're doing nodecore specifically, there's actually this whole "register_on_register" system designed for intercepting both past (with "retroactive" flag) and future registrations and making changes to the definitions that's intended to help with this sort of thing ... but it's a bit arcane so I can't make a defnite recommendation whether or not to prefer that route. |
| 16:55 |
copygirl |
"depend on the mod that makes that change" That's what I'm doing here. |
| 16:55 |
copygirl |
(And it does work.) |
| 17:00 |
|
Talkless joined #minetest |
| 17:01 |
MTDiscord |
<warr1024> 👍 |
| 17:09 |
erle |
copygirl where is the mod you are making? |
| 17:09 |
erle |
i wonder now |
| 17:09 |
erle |
nodecore stuff is always interesting |
| 17:09 |
erle |
though i must say i have not seen something more evil than nodecore skyhell in a while hehe |
| 17:11 |
|
witsie joined #minetest |
| 17:18 |
jonadab |
Default digtron's ability to run on charged energy crystals is intended to work with Technic, I think. |
| 17:19 |
jonadab |
A lot of things assume the "standard trifecta" of tech mods: mesecons, technic, pipeworks. |
| 17:19 |
jonadab |
Or are at least designed to optionally support them. |
| 17:23 |
jonadab |
I experimented briefly with NodeCore but decided that if I want to be unable to progress without downloading a ton of spoilers into my brain, I'll play NetHack, which is way easier on system resources and also more fun. |
| 17:28 |
copygirl |
erle: https://git.mcft.net/copygirl/nc_extended_rotating |
| 17:29 |
erle |
oh you are making a better screwdriver |
| 17:29 |
erle |
i had so much fun with the screwdriver in mineclone2 some time back |
| 17:29 |
erle |
it could rotate a bunch of things that were not meant to be rotated |
| 17:29 |
erle |
e.g. portals |
| 17:29 |
|
s20 joined #minetest |
| 17:30 |
copygirl |
The "screwdriver" is just going to allow you to rotate things that can already be rotated, just in a more straightforward (to me) way, including HUD preview to show you how you'll rotate stuff. |
| 17:30 |
copygirl |
It'll override the nodes' rightclick and empty hand rightclick (so sneaking with empty hand can invert rotation). |
| 17:30 |
jonadab |
Ah. So less trial and error then? |
| 17:32 |
jonadab |
Standard screwdriver's left-click action works very intuitively if you haven't right-clicked; but once you start right-clicking, it can be confusing, and some nodes are worse in this regard than others. |
| 17:32 |
jonadab |
In principle it's all logical and deterministic and stuff, but human intuition doesn't necessarily work that way. |
| 17:33 |
jonadab |
Just makingj it flash a visual indication of which face is the new "top" face for half a second after each right-click, would be an improvement, honestly. |
| 17:34 |
copygirl |
I have no idea how the screwdriver works. In NodeCore, nodes that can be rotated just cycle through all their states. But yeah this mod will allow various additional, and hopefully more intuitive ways to rotate them. |
| 17:34 |
copygirl |
(Correction: Not additional, I do replace the default.) |
| 17:34 |
jonadab |
Oh, NOdecore, I don't think I've really used a screwdriver in that. |
| 17:34 |
jonadab |
I was thinking in MTG terms. |
| 17:35 |
copygirl |
I mean if someone wants to grab some of the logic and use it in a more generic mod they may feel free to. |
| 17:35 |
copygirl |
I think the biggest problem is the inability to know a node's valid rotations. |
| 17:36 |
copygirl |
If it's `facedir`, it can theoretically turn all sorts of ways. |
| 17:38 |
jonadab |
Right, it's the nodes with three degrees of rotational freedom that get confusing. |
| 17:39 |
erle |
you say confusing, i say fun |
| 17:40 |
jonadab |
Now is probably when I admit that I've been known to wish for an additional degree of rotational freedom on slabs and stairs, that rotates the texture independently of the node box. |
| 17:40 |
jonadab |
So that e.g. upside-down stairs can have their texture line up with adjacent blocks. |
| 17:41 |
jonadab |
As a developer, I understand why that's not gonna happen. Doesn't stop me, as a builder, from wanting it. |
| 17:41 |
MTDiscord |
<greenxenith> They can, if they use world aligned textures |
| 17:42 |
jonadab |
Ok, but then you can't do things like a parquet floor where every other node has its wood texture rotated 90 degrees. |
| 17:43 |
MTDiscord |
<greenxenith> This is true. Tradeoffs :] |
| 17:43 |
jonadab |
Indeed. |
| 17:43 |
erle |
upside down stair texture alignment still a tihng |
| 17:45 |
copygirl |
Wait why do you think it won't happen as a developer? |
| 17:45 |
MTDiscord |
<warr1024> A tricky thing about rotations in NodeCore is that many nodes have "duplicate" rotations, and NodeCore only "allows" access to one facedir out of each set that is functionally duplicate (it's assumed that different texture alignments for those materials are irrelevant). It will work with any facedir, but it generally avoids creating nodes with certain facedirs. So if you want a rotation system that's a functionally equivalent |
| 17:45 |
MTDiscord |
alternative to the base game, that's a consideration. |
| 17:45 |
jonadab |
copygirl: It would complicate things too much. Not least the UI. |
| 17:46 |
MTDiscord |
<warr1024> NodeCore's vanilla textures are designed to be close to indistinguishable by rotation, sort of on purpose. While texturepacks may introduce directionality to isotropic textures, that's not a thing that the game really supports. For example, plain planks don't facedir. |
| 17:46 |
copygirl |
jonadab: Oh you weren't talking about rotating the textures? Because that's easily doable. |
| 17:46 |
jonadab |
copygirl: Well, the screwdriver's two actions are already used for rotating the node itself. |
| 17:47 |
jonadab |
I suppose there could be a separate texture-rotate tool, but ugh. |
| 17:47 |
jonadab |
The last thing this game needs is one more thing every builder needs to have in their inventory all the time. |
| 17:47 |
|
imi joined #minetest |
| 17:47 |
copygirl |
Oh I mean for certain nodes, textures should just be "world-fixed". If you want a "vertical plank stair" then I guess you do have to add an extra block for that. I dunno if the engine can do that degree of freedom. |
| 17:48 |
jonadab |
If you're willing to register separate nodes for each texture rotation, then sure, the engine can handle that, but it would make your recipe book and inventory completely nightmarish. |
| 17:49 |
jonadab |
That's worse than registering a separate texture-rotation tool. |
| 17:49 |
* copygirl |
laughs in NodeCore, where we don't have such silly things. |
| 17:52 |
erle |
<jonadab> The last thing this game needs is one more thing every builder needs to have in their inventory all the time. |
| 17:52 |
erle |
make it the hand |
| 17:52 |
erle |
magic hand mod |
| 17:53 |
jonadab |
copygirl: Nodecore _sort of_ has inventory, but it's even more nightmarish than usual. |
| 17:53 |
MTDiscord |
<warr1024> NodeCore's rotations are all driven by right-click, it's tool-agnostic, so it's not even actually dependent on having an open slot to access a plain hand. |
| 17:54 |
copygirl |
My solution to "too many building blocks" is to have materials and a shape-building system. You have plank items in your inventory and can build blocks, stairs, slabs, fences, .. things that make sense for that material. |
| 17:54 |
MTDiscord |
<warr1024> But if you can place a node in different rotations without using a tool, then it seems reasonable you should be able to change between those rotations without the use of a tool similarly. |
| 17:54 |
copygirl |
Stone brick blocks might require brick and mortar, cobblestone blocks: stones and clay, .. etc |
| 17:55 |
copygirl |
A block may require 4 planks to create, a stair 3, a slab 2, etc .. and you get the materials back when breaking the block. |
| 17:55 |
copygirl |
That would be my approach to this. I tried modding this into Vintage Story once but .. not sure why I didn't continue? |
| 17:55 |
MTDiscord |
<warr1024> Minetest system limitations: all nodes must be registered at startup time (you can't dynamically create new shapes at runtime) and there are a total of 32k possible node registrations (and you'll want to preserve significant overhead for mods that add "xyz version of every existing node" and effectively double your registrations). |
| 17:56 |
copygirl |
Yeah I'd move to a palette implementation. In theory that should allow practically infinite different nodes, and maybe even registering them at runtime. |
| 17:56 |
jonadab |
I mean, if we're willing to change large aspects of how the game works, then the real solution for slabs and stairs is to eliminate them, and make all nodes 1-foot cubes (instead of 1-yard or 1-meter, same difference), i.e., make the player 5-6 blocks high instead of almost-2, and able to easily walk up 1-block steps. |
| 17:56 |
MTDiscord |
<warr1024> As far as I know there are no mods that literally double every registration, but there are some already (like etching concrete, stone bricks, and "efficient full stack rendering" hacks) that double a non-trivial subset of them. |
| 17:57 |
copygirl |
jonadab: Then how do you align things in the center of your now 2x finer grid? |
| 17:57 |
MTDiscord |
<warr1024> IIRC OpenBlox experimented with the "make the player bigger, effectively making the nodes smaller" thing and it would kind of work from an "add more detail" level, but it also increases the amount of work you need to do significantly to build things player-scale. |
| 17:58 |
copygirl |
I think for the sake of having furnaces, chests, pipes, etc, a 1m^3 grid is fitting. |
| 17:58 |
copygirl |
And you get problems with all sorts of other decoration blocks. |
| 17:58 |
jonadab |
copygirl: Arguably, things like pipes and walls would be better with the smaller grid size. Chests, admittedly, are probably more realistic-looking at the current size. |
| 17:59 |
copygirl |
If you wanna go that route I'd just go with an arbitrary level-of-detail voxel engine like for example CUBE or so. |
| 17:59 |
jonadab |
But imagine if you could use different wall colors in different rooms of your house, without making all the walls 2 meters thick? |
| 17:59 |
copygirl |
I'd solve that by mixing and matching panels in a single block space. |
| 17:59 |
erle |
what if make the player so big |
| 17:59 |
erle |
that nodes are like legos |
| 17:59 |
jonadab |
Also imagine if you could walk up a h ill without jumping. |
| 17:59 |
erle |
entire world is legos |
| 18:00 |
erle |
massive effort to even build a house |
| 18:00 |
copygirl |
With your system you'd still run into the problem of having to decide on SOME material in an outer corner. Is it the material of the room? Or the hallway? |
| 18:00 |
copygirl |
erle: Take damage constantly when walking on any small protusion? |
| 18:00 |
jonadab |
The downside is that large structures would require a lot more nodes, yes. (27 times as many, theoretically; in practice more like 10 times as many, because most structures aren't solid.) |
| 18:00 |
erle |
copygirl yes lol |
| 18:01 |
erle |
copygirl i have a fancy palette trick to get 4096 color options with 16 nodes https://git.minetest.land/erlehmann/tga_encoder/src/commit/aad231f5e406a7c1eaafe6595a64b9c55f230692/colormap_generator.lua |
| 18:02 |
copygirl |
But yeah, RedPower 2 did this in the past, and I'd do it by "registering" a new type of node for each actually used combination of "multipart". |
| 18:03 |
copygirl |
So you can combine a pipe with a frame, put covers on sides, fill it with concrete and wait it to harden, paint the outside, put some wood paneling on the inside, .... stuff like that. |
| 18:04 |
erle |
i think i may have made a minetest concrete mod way back |
| 18:04 |
erle |
bucket of concrete was just a fluid that hardened |
| 18:04 |
copygirl |
Registering stuff at runtime is also important for my dream engine because I want it to be moddable while playing. |
| 18:05 |
copygirl |
Anyway, getting off track. Better go back to coding. |
| 18:05 |
jonadab |
Technic has concrete. |
| 18:12 |
MTDiscord |
<warr1024> Some things can be registered at runtime, like nodecore recipes. Some things can't, like nodes. We have a lot of workarounds for this sort of thing, though, like using things whose appearance is fully runtime-dynamic (like entities or particles) to render things, or using invisible nodes with metadata to store dynamic info (like the way NodeCore "stack nodes" can present in various different ways but they're all a single node |
| 18:12 |
MTDiscord |
registration). |
| 18:18 |
MinetestBot |
[git] Desour -> minetest/minetest: Warn only once about positional stereo sounds (#13895) 6026003 https://github.com/minetest/minetest/commit/602600350875ca0b1dbad6a096167f711e3740f0 (2023-10-18T18:16:45Z) |
| 18:18 |
MinetestBot |
[git] JosiahWI -> minetest/minetest: Extract updatePauseState from Game::run (#13893) 62eb6cf https://github.com/minetest/minetest/commit/62eb6cfed0fadf497930e76530db6bb7e6a4c516 (2023-10-18T18:17:30Z) |
| 18:21 |
MinetestBot |
[git] grorp -> minetest/minetest: Clean up and improve mainmenu theme / game theme code (#13885) b1dec37 https://github.com/minetest/minetest/commit/b1dec37adb16f7ccd21209cbdd8381865cdfb5ca (2023-10-18T18:18:50Z) |
| 19:19 |
|
sparky4 joined #minetest |
| 19:29 |
|
sparky4 joined #minetest |
| 19:41 |
|
fling joined #minetest |
| 19:41 |
|
Trifton joined #minetest |
| 19:58 |
|
gxt joined #minetest |
| 21:12 |
|
witsie joined #minetest |
| 21:13 |
|
Alnotz joined #minetest |
| 21:15 |
|
cation joined #minetest |
| 22:32 |
|
panwolfram joined #minetest |
| 22:36 |
|
appguru joined #minetest |
| 23:08 |
|
Lesha_Vel joined #minetest |
| 23:08 |
|
peterz joined #minetest |
| 23:15 |
|
peterz joined #minetest |
| 23:23 |
|
peterz joined #minetest |
| 23:26 |
|
liceDibrarian joined #minetest |
