Luanti logo

IRC log for #minetest, 2022-07-04

| Channels | #minetest index | Today | | Google Search | Plaintext

All times shown according to UTC.

Enable nick filtering
Time Nick Message
5 more elements. Show/hide.
01:04 fluxionary just to make sure, there's no limit on item IDs like there is for node IDs, right?
01:04 MTDiscord <FatalError> I would imagine there is.
01:05 fluxionary well, outside of general things like memory usage
01:08 fluxionary i'm thinking about the framework for a tool enchanting system. the two existing tool enchanting systems use distinct item IDs, but they really should be using itemstack tool capabilities. but there's some things like "range" which might meaningfully affect the tool's capabilities, but which can't be customized per individual tool w/out new item ids
01:09 fluxionary i'm wondering whether blowing up the # of item ids combinatorially really matters for anything practical.
01:11 fling joined #minetest
01:11 fluxionary there's also hacky things you can do w/ a variety of customized hands and monoids to control them, but i feel like that wouldn't feel as nice, particularly in laggy environments
01:12 MTDiscord <FatalError> are you designing a mod or a game here
01:12 MTDiscord <FatalError> because if you're making a game
01:12 fluxionary hm. a framework?
01:12 fluxionary which i suppose is somewhere in between
01:12 fling joined #minetest
01:12 MTDiscord <FatalError> a framework for a game?
01:12 MTDiscord <FatalError> or a framework for a od
01:12 MTDiscord <FatalError> mod*
01:13 fluxionary it'd be a mod that's meant to be used as a library by other mods
01:13 fluxionary though i haven't written any of it yet.
01:13 MTDiscord <FatalError> ok, well you could always do something a bit more invasive
01:14 fluxionary i'm currently working on a way of allowing players to tweak the behavior of the player's hand, and got to thinking about enchanting again
01:14 MTDiscord <FatalError> you could re-register the on_use to basically use whatever range you want
01:14 MTDiscord <FatalError> using raycast
01:14 MTDiscord <FatalError> which is what on_use uses internally afaik
01:14 fluxionary that sounds terrible
01:15 fluxionary you wouldn't actually be "touching" the target node/object, it wouldn't be able to take advantage of any client-side predictions
01:15 MTDiscord <FatalError> what
01:15 fluxionary the range of a tool has hard-coded client-side behavior
01:15 fluxionary which helps w/ immersion and stuff
01:16 MTDiscord <FatalError> I mean, you could just put it at the maximum value it could be at
01:16 fluxionary sure you could just swing your pick at the air *towards* some rocks, and use raycasting to find and break things, but you wouldn't know what you were actually aiming at
01:16 fluxionary then you'd end up w/ the opposite problem. you think you're breaking something in the far distance but you're actually not
01:17 fluxionary honestly things like "range" should be part of the "tool_capabilities" definition, but i'm not quite at the point where i want to actually propose changing such things
01:17 fluxionary maybe i should
01:24 fluxionary i suppose being able to set a custom range for a "node" also makes sense though... hm.
02:10 MTDiscord <MisterE> attached is some log. Im trying to build minetest latest on manjaro linux (arch variation) its failing
02:10 MTDiscord <MisterE> https://cdn.discordapp.com/attachments/749727888659447960/993337887720472586/Untitled_Document_1
24 more elements. Show/hide.
08:03 sfan5 sounds like your build settings are messed up, `make clean && rm CMakeCache.txt` and try again
18 more elements. Show/hide.
13:36 Pexin 12353, when bros get mad about math
13 more elements. Show/hide.
16:10 MTDiscord <MisterE> Hey, thx sfan5. It worked
48 more elements. Show/hide.

| Channels | #minetest index | Today | | Google Search | Plaintext