| Time |
Nick |
Message |
| 00:37 |
|
Emerald2 joined #luanti |
| 00:37 |
|
sofar joined #luanti |
| 01:05 |
|
Eragon joined #luanti |
| 01:15 |
|
SFENCE joined #luanti |
| 01:29 |
|
___nick___ joined #luanti |
| 01:32 |
|
___nick___ joined #luanti |
| 01:58 |
|
SFENCE_arch joined #luanti |
| 02:21 |
|
SFENCE joined #luanti |
| 03:33 |
|
SFENCE joined #luanti |
| 03:48 |
|
SFENCE joined #luanti |
| 04:00 |
|
MTDiscord joined #luanti |
| 04:50 |
|
SFENCE joined #luanti |
| 04:58 |
|
tzenfore joined #luanti |
| 04:58 |
|
SFENCE_ joined #luanti |
| 05:01 |
|
SFENCE joined #luanti |
| 05:07 |
|
SFENCE_ joined #luanti |
| 05:13 |
|
SFENCE joined #luanti |
| 05:18 |
|
SFENCE_ joined #luanti |
| 05:23 |
|
SFENCE joined #luanti |
| 05:26 |
|
SFENCE_ joined #luanti |
| 05:43 |
|
SFENCE joined #luanti |
| 05:47 |
repetitivestrain |
rubenwardy: and Xeno333, if you're listening, regarding: https://github.com/luanti-org/luanti/issues/16240 |
| 05:49 |
repetitivestrain |
"What to do if a game contains a mapgen mod? I guess it's required, or we need to have the ability to disable certain game mods? Yes it would have to be required, all game mods are required." |
| 05:49 |
repetitivestrain |
is not true in the least--mcl_levelgen, mineclonia's lua mapgen, is always enabled, but only when the current mapgen is singlenode, and can be disabled through a global setting, or an option in map_meta.txt. the mod itself cannot be disabled as it also provides structure generation for the built-in mapgens |
| 05:50 |
repetitivestrain |
what games would benefit from the most would be the ability to define their own create new world dialogs, but absent that, the next most ideal solution would be the ability to define custom mapgen settings for singlenode in particular |
| 05:53 |
repetitivestrain |
btw, for the present, i think mapgen mods will all of them be completely game-specific, and it would be a profound misuse of time to attempt to support game-agnostic map generator mods in the create world dialog |
| 05:54 |
|
SFENCE joined #luanti |
| 05:54 |
repetitivestrain |
at the moment they tend only to support MTG and its derivatives |
| 05:55 |
repetitivestrain |
and obviously there's not a snowball's chance in hell that my map generator, which was initially designed by mojang for minecraft, will function independently of mineclonia, but i digress |
| 06:08 |
|
jaca122 joined #luanti |
| 06:27 |
|
sparky4 joined #luanti |
| 06:32 |
|
FeXoR joined #luanti |
| 07:06 |
[MatrxMT] |
<birdlover32767> by meshes i meant drwatype="mesh" nodes |
| 07:37 |
|
Talkless joined #luanti |
| 08:22 |
|
Warr1024 joined #luanti |
| 08:25 |
|
SwissalpS joined #luanti |
| 08:41 |
|
YuGiOhJCJ joined #luanti |
| 08:47 |
|
Warr1024 joined #luanti |
| 09:20 |
|
mrkubax10 joined #luanti |
| 10:43 |
|
SFENCE joined #luanti |
| 11:15 |
|
mrkubax10 joined #luanti |
| 11:38 |
|
turtleman joined #luanti |
| 12:06 |
|
Meli joined #luanti |
| 12:30 |
|
mrkubax10 joined #luanti |
| 12:37 |
|
PoochInquisitor joined #luanti |
| 13:04 |
|
wallabra joined #luanti |
| 13:41 |
[MatrxMT] |
<Blockhead256> I hope someone ports it to MTG, for teh lulz |
| 13:41 |
[MatrxMT] |
<birdlover32767> you can copy the lua file and alias the nodes and by then you just have 30 mins of debugging left |
| 13:42 |
[MatrxMT] |
<Blockhead256> hahah, well, if it's so simple, I'm sure you can handle it |
| 13:42 |
repetitivestrain |
it's far more involved than that |
| 13:42 |
repetitivestrain |
the entire game must observe discipline wrt handling un-postprocessed mapblocks |
| 13:42 |
[MatrxMT] |
<birdlover32767> so you're saying it would be easier to remake minetest game with the mapgen? |
| 13:43 |
repetitivestrain |
which is to say, all features must be modified not to alter mapblocks till mcl_levelgen.is_protected_chunk returns false |
| 13:43 |
repetitivestrain |
i don't understand what you're asking |
| 13:43 |
repetitivestrain |
sorry |
| 13:44 |
repetitivestrain |
but my point is that for this lua mapgen to work in other games, those games, and all of their mods, would also need to be modified not to register any on_generated callbacks of their own, or do anything whatever that might be disturbed by sudden asynchronous modifications to locked mapblocks |
| 13:45 |
[MatrxMT] |
<birdlover32767> would entirely remaking all of minetest game's content be easier than awkwardly patching everything to not alter generating chunks |
| 13:45 |
repetitivestrain |
i don't know |
| 13:45 |
repetitivestrain |
i patched mineclonia in the span of a few weeks |
| 13:45 |
[MatrxMT] |
<birdlover32767> i mean... there is only a handful of stuff that do that (trees, fire, and few abms) |
| 13:46 |
repetitivestrain |
liquid transformations |
| 13:46 |
repetitivestrain |
... |
| 13:46 |
repetitivestrain |
that one was the most difficult |
| 13:46 |
[MatrxMT] |
<birdlover32767> just copy the mineclonia liquid lua file and awkwardly patch it again |
| 13:47 |
repetitivestrain |
yeah, that won't suffice |
| 13:48 |
repetitivestrain |
even the initialization code itself requires cooperation from mcl_init |
| 13:48 |
repetitivestrain |
but what i wanted to illustrate was that mapgen mods are generally game-specific, in that everything now available only supports a single game (or family of games, such as MTG and its derivatives) |
| 13:49 |
[MatrxMT] |
<birdlover32767> just co- oh wait this is just copying stuff from mineclonia until mtg becomes mineclonia |
| 13:49 |
repetitivestrain |
yes |
| 13:50 |
[MatrxMT] |
<birdlover32767> i mean the at least what you could do is change the textures and remove some stuff (copper, amethyst) and call it "lightly modded mtg" |
| 13:50 |
repetitivestrain |
and consequently game-specific mods should be the focus of any proposal for a extensible map generation configuration dialog |
| 13:50 |
repetitivestrain |
interesting trivia of the day: mineclonia is actually MTG-based |
| 13:50 |
repetitivestrain |
i am told that it was forked from a very early 0.4.x release of minetest game, which was long before my time |
| 13:50 |
[MatrxMT] |
<birdlover32767> mineclonia <- mineclone 2 <- mineclone <- mtg |
| 13:51 |
repetitivestrain |
yes |
| 13:51 |
repetitivestrain |
well Mineclone 2 is VoxeLibre now |
| 13:52 |
[MatrxMT] |
<birdlover32767> voxelibre is technically just a branch off of mineclone 2 |
| 13:52 |
[MatrxMT] |
<birdlover32767> just like how luanti is technically a branch of mtg |
| 13:52 |
Krock |
wat |
| 13:53 |
Krock |
there is no Luanti game |
| 13:53 |
repetitivestrain |
yeah, what lol |
| 13:53 |
repetitivestrain |
for an extensible map generation configuration dialog* |
| 13:53 |
[MatrxMT] |
<birdlover32767> luanti <- minetest <- minetest with mtg <- minetest with hardcoded mtg |
| 13:53 |
Krock |
https://i.kym-cdn.com/entries/icons/facebook/000/026/618/ZEBxqIA.jpg |
| 13:54 |
Krock |
hardcoded mtg? 0.3.x had hardcoded nodes and items, but that wasn't called MTG |
| 13:55 |
[MatrxMT] |
<birdlover32767> well it would be weird to say minetest: the engine with minetest: the game hardcoded in |
| 13:55 |
Krock |
minetest with hardcoded content |
| 13:56 |
[MatrxMT] |
<birdlover32767> that's better |
| 13:56 |
repetitivestrain |
anyway, would someone forward the response i posted to #16240 before the conversation segued onto the subject of porting mineclonia mods to MTG? |
| 13:56 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16240 -- Add lua defined mapgens, as true mapgens in game.conf and world creation |
| 13:58 |
repetitivestrain |
> depends = mcl_init, mcl_util, mcl_worlds, mcl_player, mcl_liquids, mcl_mapgen_models |
| 13:58 |
repetitivestrain |
it'd be a tough cookie to port, that's for certain |
| 13:58 |
repetitivestrain |
certainly not a matter of defining aliases and twenty minutes of hacking |
| 13:59 |
|
qqe joined #luanti |
| 14:01 |
Krock |
mapgen = true in mod.conf would make sense |
| 14:02 |
repetitivestrain |
maybe, but what purpose would it serve? game-provided mods are _always_ enabled, but clearly many games will provide options elsewhere to disable their custom map generators |
| 14:03 |
repetitivestrain |
so what would be most immediately useful would be a facility enabling such mods to define additions to the mapgen options menu |
| 14:03 |
repetitivestrain |
rather than an option designating a mod as a mapgen mod which is exclusive of all other mods of the same type and which takes effect whenever it is enabled |
| 14:10 |
user333_ |
i don't see a point in 'mapgen mods' that are their own type of mod, however there should be ways to register a mapgen more easily without overriding singlenode |
| 14:13 |
MTDiscord |
<wsor4035> https://github.com/luanti-org/luanti/issues/16240#issuecomment-3419700542 |
| 14:14 |
smk |
I have a question, is this error due to some misconfiguration/ engine generated ? it looks like someone is flooding the server ~ i am running 5.14.0 release |
| 14:14 |
smk |
2025-10-19 13:20:46: WARNING[ConnectionSend]: con(4/1) Packet quota used up for peer_id=45134, was 128 pkts |
| 14:14 |
repetitivestrain |
wsor4035: thank you |
| 14:14 |
smk |
there are over 50-60 entries per second |
| 14:14 |
smk |
with different peer_id |
| 14:14 |
MTDiscord |
<wsor4035> you probably have some mod sending a flood of hud instructions or something else that needs to be sent to the client |
| 14:15 |
smk |
packets sizes is not constant, it started with 75, 128, 170 now |
| 14:15 |
smk |
each different times of day |
| 14:19 |
smk |
it could be a mod, i have recently added bunch of updated mesecons and digilines stuff |
| 14:21 |
user333_ |
mesecons are very resource-intensive |
| 14:52 |
smk |
yep true, especially technic pipes |
| 14:59 |
MTDiscord |
<tx_miner> See my response on GitHub, but in addition about games and such, I think we would want to add a lua-mapgen = false To game conf to allow games to block them from appearing in the world creation menu. Default to true, or we could do the inverse and only allow lua-mapgens in games that allow it. |
| 15:02 |
|
mrkubax10 joined #luanti |
| 15:04 |
repetitivestrain |
tx_miner: how is it possible to define a game-agnostic mapgen mod when there's no means of providing mapgen objects to games? |
| 15:05 |
MTDiscord |
<tx_miner> There is though |
| 15:05 |
repetitivestrain |
How? |
| 15:06 |
MTDiscord |
<tx_miner> Some are shared by the Engine during load time |
| 15:06 |
MTDiscord |
<tx_miner> And the rest are defined by the Engine in both environments |
| 15:06 |
repetitivestrain |
the problem is that you cannot modify mapgen objects handed to you by the engine |
| 15:06 |
repetitivestrain |
and modifications would never be transferred across environments |
| 15:06 |
MTDiscord |
<tx_miner> I made V8 on my PR I had made to demonstrate it |
| 15:07 |
MTDiscord |
<tx_miner> They are by the Engine |
| 15:07 |
repetitivestrain |
but on a more apposite note, you appear to have misunderstood the heart of my objection, i.e., that there are instances where a game-supplied mapgen mod, which _MUST_ be enabled but are toggled by other game-provided means |
| 15:07 |
repetitivestrain |
https://github.com/Xeno333/v8/blob/main/mapgen.lua? |
| 15:07 |
repetitivestrain |
can you inform me where your mapgen provides a heightmap object |
| 15:07 |
MTDiscord |
<tx_miner> Ok so where they are disabled ? |
| 15:08 |
repetitivestrain |
are you speaking of mapgen objects or game-supplied mapgen mods? |
| 15:08 |
MTDiscord |
<tx_miner> In which reply? |
| 15:08 |
repetitivestrain |
"ok so where are they disabled?" |
| 15:08 |
repetitivestrain |
... provides a heightmap object ... which is to say, where it computes a heightmap in on_generated and provides it to on_generated callbacks in the main lua environment? |
| 15:10 |
repetitivestrain |
IMNSHO, the issue facing all game-agnostic mapgen mods is that the engine is simply not there yet as regards enabling lua mapgens to communicate the same information to games, mods, and engine facilities by the same means as built-in mapgens |
| 15:10 |
MTDiscord |
<tx_miner> Ok so, first data can be shared between environments during load time, we already do this a lot. Second most of that is setting based which can be read from the mapgen environment. Eg in 1042 I load the mapgen API into both environments so that I can use for both mapgen and for Spawning |
| 15:11 |
repetitivestrain |
heightmaps are returned by core.get_mapgen_object |
| 15:11 |
MTDiscord |
<tx_miner> Sure it's not perfect |
| 15:11 |
repetitivestrain |
as far as i am aware, it is _not possible_ to alter values yielded by this function |
| 15:11 |
MTDiscord |
<tx_miner> But the function isn't even needed and can be overriden anyway |
| 15:11 |
repetitivestrain |
and, to give another example, you can't provide gennotifies other than those of `custom' type |
| 15:12 |
repetitivestrain |
the function might not be required by minetest game, but it is by mineclonia |
| 15:12 |
MTDiscord |
<tx_miner> That is the Biggest problem |
| 15:12 |
repetitivestrain |
no it's not |
| 15:12 |
MTDiscord |
<tx_miner> What changes would break mineclonia? |
| 15:13 |
repetitivestrain |
there would be no heightmap object, and mineclonia would fail to generate certain types of structures or decorations |
| 15:13 |
repetitivestrain |
you can't call a mapgen "game-agnostic" if it only functions with game X and game Z whose common characteristic is that they refrain from availing themselves of all the facilities provided by the engine |
| 15:13 |
MTDiscord |
<tx_miner> There would still be a hightmap |
| 15:13 |
|
kamdard__ joined #luanti |
| 15:14 |
repetitivestrain |
core.get_mapgen_object ("heightmap") returns nil on singlenode, if i'm not mistaken |
| 15:14 |
repetitivestrain |
and even if it didn't, its contents would be all zeros |
| 15:14 |
MTDiscord |
<tx_miner> And? |
| 15:14 |
MTDiscord |
<tx_miner> Don't use singlenode |
| 15:14 |
repetitivestrain |
and? generation failures or crashes would ensue |
| 15:14 |
MTDiscord |
<tx_miner> Just mark it as disallowed |
| 15:14 |
repetitivestrain |
then you'll get an incorrect heightmap from whatever mapgen was enabled before your lua map generator overwrote its terrain |
| 15:15 |
MTDiscord |
<tx_miner> No I'm saying disallow lua mapgen if you can't support singlenode |
| 15:16 |
repetitivestrain |
and how does that comport with your assertion of "game-agnostic map generators are already possible?" |
| 15:16 |
MTDiscord |
<tx_miner> Some games areapgen specific |
| 15:16 |
repetitivestrain |
which is not qualified with the condition, "only in cases of games that rely on a limited selection of engine facilities" |
| 15:18 |
repetitivestrain |
tx_miner: no, these games are perfectly capable of supporting any mapgen the engine has to offer |
| 15:18 |
MTDiscord |
<tx_miner> Some games are tied to mapgen in the engine, that's not my fault. Any game that would function with any of the Engine provided mapgen a would work |
| 15:18 |
repetitivestrain |
then it's not truly "game-agnostic," in the sense that has been established by the engine generators |
| 15:18 |
MTDiscord |
<tx_miner> If singlenode is allowed then a lua-mapgen would run fine |
| 15:19 |
repetitivestrain |
no, games go out of their way to DISABLE critical functionality when singlenode is enabled |
| 15:19 |
MTDiscord |
<tx_miner> The mapgen is but the games aren't all mapgen agnostic that's my point |
| 15:19 |
MTDiscord |
<tx_miner> Not all, so.e just reimplement it |
| 15:19 |
repetitivestrain |
in the expectation that this functionality will be pointless because the world will be nothing but air |
| 15:20 |
MTDiscord |
<tx_miner> Ye again this would be why it's a NEW feature |
| 15:20 |
repetitivestrain |
such a new feature would be totally pointless with the present condition of the engine |
| 15:20 |
MTDiscord |
<tx_miner> And yes if you want to use it you would have to improve your code in games. But it doesn't break things on its own, we could even make it so games have to allow it |
| 15:21 |
MTDiscord |
<tx_miner> The only way to change the present condition is to improve the engine |
| 15:22 |
repetitivestrain |
then it should be improved first (by enabling mapgen mods to reuse the engine biome and decoration system, generate heightmaps, and non-custom gennotifies) before functionality is exposed to users in a condition that is impaired by these outstanding deficiencies |
| 15:23 |
repetitivestrain |
when it is impossible to define a game-agnostic lua map generator that is capable of substituting for an engine map generator in its entirety, such map generators must not be represented as having the same precedence as the engine ones |
| 15:24 |
repetitivestrain |
as i said, mineclonia's lua map generator will only support mineclonia, the islands mapgen mtg, LOTT's mapgen LOTT, and unter null is too rudimentary to be considered in this context at all, as it doesn't so much as support biomes |
| 15:25 |
repetitivestrain |
but all of these extant mapgens stand to benefit greatly from the ability to interpose their own options into the map generator options menu |
| 15:26 |
MTDiscord |
<tx_miner> V8 is mapgen agnostic |
| 15:27 |
repetitivestrain |
and reading that thread from the beginning, i see that sfan5 has also made the same observations |
| 15:27 |
repetitivestrain |
https://github.com/luanti-org/luanti/issues/16240#issuecomment-2972506052 |
| 15:27 |
repetitivestrain |
tx_miner: how can it be, when it does _not_ provide a heightmap, which every engine mapgen does and mods have every right to expect from a mapgen advertised as an equal of the built-in map generators? |
| 15:28 |
MTDiscord |
<tx_miner> Yes, though noone else IS working on exposing mapgen mods more |
| 15:28 |
repetitivestrain |
Hmm? |
| 15:28 |
MTDiscord |
<redundantcc> repetitivestrain: how would you want the single node height map to be calculated? Single node by design does not add anything to the map, and height maps are contingent on the type of world generation being used to generate the world. To put it in a way that sounds more straightforward, a height map for a super flat is going to look different then height map for an extreme hills. As a result the height map for single note is literally 0 |
| 15:28 |
MTDiscord |
everywhere at best, which isn't even technically correct since there aren't blocks at that position either? |
| 15:28 |
MTDiscord |
<tx_miner> Singlenode does. Provide one I think but it is fixed the thing is bc a mapgen mod loads in both environments partly it allows it to override the engine definition |
| 15:29 |
MTDiscord |
<tx_miner> I think it just returns 0 for all coords |
| 15:29 |
repetitivestrain |
redundantcc: i do not want singlenode to calculate a heightmap, but for lua mapgens executing after singlenode to compute one from their own terrain |
| 15:29 |
MTDiscord |
<redundantcc> You want access to the perlin noise generator? |
| 15:29 |
repetitivestrain |
and be allowed to provide this through the usual mapgen object facilities to mods |
| 15:29 |
repetitivestrain |
? |
| 15:29 |
MTDiscord |
<tx_miner> But again it can be overriden by redefining it in the mapgen mod |
| 15:29 |
repetitivestrain |
i have my own perlin noise generator |
| 15:30 |
repetitivestrain |
it doesn't work, as mods cache core.get_mapgen_object |
| 15:30 |
MTDiscord |
<redundantcc> Then why can't you generate your own height map? |
| 15:30 |
MTDiscord |
<redundantcc> Just override the function |
| 15:30 |
MTDiscord |
<redundantcc> If you want to provide support for it |
| 15:30 |
repetitivestrain |
redundantcc: ^^^ for the reasons aforesaid |
| 15:30 |
MTDiscord |
<tx_miner> Ilbut at load time mapgenwould be given priority and override before the calls are placed |
| 15:30 |
repetitivestrain |
i cannot force mods to depend on mine |
| 15:31 |
sfan5 |
you can with first_mod, in a game, tho |
| 15:31 |
repetitivestrain |
Hmm |
| 15:31 |
sfan5 |
but the bigger problem with this is that you need to override the function in both the mapgen envs and the normal env and then keep that in sync |
| 15:31 |
MTDiscord |
<tx_miner> But in my PR I already gave mapgen mods priority |
| 15:31 |
MTDiscord |
<redundantcc> Isn't the async environment unavailable for overriding? |
| 15:31 |
sfan5 |
the engine should just provide this as a feature instead of inviting increasingly complicated workarounds |
| 15:31 |
MTDiscord |
<tx_miner> But I defined them to load on both which was my point |
| 15:32 |
MTDiscord |
<tx_miner> No |
| 15:32 |
repetitivestrain |
but a game can only handle its own lua mapgen(s), which just drives my initial point home |
| 15:32 |
MTDiscord |
<tx_miner> I agree |
| 15:32 |
MTDiscord |
<tx_miner> No it doesn't |
| 15:32 |
MTDiscord |
<tx_miner> Bc they can be agnostic how I impimented before |
| 15:33 |
repetitivestrain |
namely that currently, game-agnostic map generators are a chimera, and so any effort towards defining custom mapgen options should proceed from the needs of games |
| 15:33 |
MTDiscord |
<redundantcc> Wait when you spawn an async environment for map generation it copies whatever metadata is overwritten from the core.* API including changes? I thought it spawned a separate process or thread and reinstanced Lua? |
| 15:33 |
MTDiscord |
<tx_miner> I can add the hight map overridea to V8 |
| 15:33 |
repetitivestrain |
tx_miner: and i'm as i said, your approach is not yet capable of supporting as broad a selection of games as the engine map generators |
| 15:33 |
repetitivestrain |
and therefore can't be properly called "mapgen-agnostic" |
| 15:33 |
sfan5 |
no, nothing overridden from core.* is copied |
| 15:34 |
MTDiscord |
<tx_miner> But bc of the overrides all I have to do is dofile(overrides.lua) in both environments |
| 15:34 |
MTDiscord |
<redundantcc> Oh that's what I thought |
| 15:34 |
MTDiscord |
<tx_miner> I'll do it later and show u what I mean |
| 15:34 |
MTDiscord |
<redundantcc> You don't control other mods and can't force them to override the core environment if they provide async map generation separately from you. This just needs to be an engine feature. |
| 15:35 |
repetitivestrain |
exactly |
| 15:35 |
MTDiscord |
<tx_miner> No I'm saying the mapgen mod has to override them |
| 15:35 |
MTDiscord |
<tx_miner> If it wants to be agnostic |
| 15:35 |
repetitivestrain |
and before such a feature exists there's little purpose in giving custom mapgen mods equal status to engine ones |
| 15:35 |
MTDiscord |
<tx_miner> Which is possible |
| 15:35 |
MTDiscord |
<tx_miner> Engine mapgen don't even make sense though |
| 15:36 |
repetitivestrain |
also, it's not, as there are numerous instances in the engine where heightmaps are directly accessed from Mapgen objects |
| 15:36 |
MTDiscord |
<tx_miner> But they can be overrideen in lua |
| 15:37 |
repetitivestrain |
not necessarily the heightmap i mean, but mapgen objects in general |
| 15:37 |
MTDiscord |
<redundantcc> It would honestly be cool if map generators were implemented via something like a main menu mod, that way you could change the main menu and implement significant changes to the API before that API is copied to spin off new generator threads. But that requires an entire menu system and changes to cdb to support a new content type, and with how many releases get put out a year it's probably not going to happen for a while. |
| 15:37 |
repetitivestrain |
which cannot be overridden |
| 15:37 |
repetitivestrain |
as the accesses are performed in C++ |
| 15:38 |
MTDiscord |
<tx_miner> We do need main menu mods |
| 15:38 |
repetitivestrain |
e.g., accesses to the biomemap in core.generate_decorations |
| 15:38 |
MTDiscord |
<tx_miner> I meant the lua API calls for them |
| 15:38 |
MTDiscord |
<redundantcc> Though if map generators were implemented in Lua in a way similar to how mods are, it would force the core developers to run into the same issues we would and it would get implemented pretty quickly since they would hit all the edge cases before releasing. |
| 15:38 |
repetitivestrain |
tx_miner: how would you wrap core.generate_decorations so that a user-specified substitute biomemap is consulted in place of the mapgen object's? |
| 15:38 |
MTDiscord |
<redundantcc> But that's a lot to expect, free implementing World Generation isn't something I would wish on a bully let alone people I actually like. |
| 15:39 |
MTDiscord |
<tx_miner> By reimplementing a customer definition and using mapgen defined parameters in both mapgen and mod environments |
| 15:39 |
MTDiscord |
<tx_miner> I've done it before |
| 15:40 |
repetitivestrain |
the decoration system is implemented in C++ |
| 15:40 |
MTDiscord |
<tx_miner> Not with that function but in general |
| 15:40 |
repetitivestrain |
but at that point it's no longer game-agnostic |
| 15:40 |
repetitivestrain |
as games have every reason to assume core.generate_decorations to be mapgen-agnostic |
| 15:40 |
MTDiscord |
<tx_miner> But the call can be overriden to use mapgen provided version |
| 15:40 |
|
silverwolf73827 joined #luanti |
| 15:40 |
MTDiscord |
<tx_miner> It is still game agnostic |
| 15:40 |
repetitivestrain |
which is where, exactly |
| 15:41 |
MTDiscord |
<tx_miner> What? |
| 15:41 |
repetitivestrain |
when has anyone implemented and kept constantly up to date all of mg_decoration.cpp? |
| 15:41 |
sfan5 |
can't you compile wasm to lua? :^) |
| 15:41 |
repetitivestrain |
not even biomegen's implementation is a drop-in replacement, and its age is also showing |
| 15:41 |
repetitivestrain |
possibly, i wouldn't know |
| 15:42 |
MTDiscord |
<tx_miner> They don't have to match the engine bc it's a mapgen custume version |
| 15:42 |
repetitivestrain |
then it's not game-agnostic... |
| 15:42 |
MTDiscord |
<tx_miner> That doesn't even make sense |
| 15:42 |
MTDiscord |
<tx_miner> All mapgen are different |
| 15:43 |
repetitivestrain |
redundantcc: i am actually quite satisfied with the state of facilities involved in creating custom map generators in general, though #16429 would be nice to have in 5.15 |
| 15:43 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16429 -- Allow mapgen chunk size to be non-cubic by sfan5 |
| 15:43 |
MTDiscord |
<tx_miner> They are supposed to be. The idea of lua-mapgen is to make a custome type |
| 15:43 |
sfan5 |
repetitivestrain is arguing for a mapgen that supports (optionally) reusing the engine's biome, decoration and similar facilities |
| 15:43 |
repetitivestrain |
your custom implementation will still need to parse decoration definitions and suchlike |
| 15:44 |
repetitivestrain |
as i said, the engine is not yet ready to support these use cases |
| 15:44 |
repetitivestrain |
yes |
| 15:44 |
MTDiscord |
<tx_miner> I agree, but they would have to be reimplemented I lua due to how singlenode works |
| 15:44 |
MTDiscord |
<tx_miner> Yes it is, they are shared already |
| 15:44 |
sfan5 |
no they don't? |
| 15:44 |
MTDiscord |
<tx_miner> I do this in v8 |
| 15:44 |
MTDiscord |
<tx_miner> Yes they are |
| 15:44 |
sfan5 |
I don't see what prevents singlenode from having biomes and decorations |
| 15:45 |
MTDiscord |
<tx_miner> Guys, I did it all in v8 already |
| 15:45 |
repetitivestrain |
and till they are, i don't think it's justified to represent lua mapgens as anything remotely akin to equals of the engine's map generators |
| 15:45 |
MTDiscord |
<tx_miner> Decorating and all |
| 15:45 |
MTDiscord |
<tx_miner> Bruh, I already did it |
| 15:45 |
sfan5 |
what is this v8 thing |
| 15:45 |
repetitivestrain |
v8's decorations won't respect the biomemap (which yours truly fixed in 5.14) |
| 15:45 |
repetitivestrain |
https://github.com/Xeno333/v8/blob/main/mapgen.lua |
| 15:45 |
repetitivestrain |
sfan: judge for yourself |
| 15:46 |
repetitivestrain |
sfan5: judge for yourself* |
| 15:46 |
repetitivestrain |
and the ores still won't |
| 15:46 |
MTDiscord |
<tx_miner> But I can override biome map if I want in v8 and the. It will |
| 15:46 |
MTDiscord |
<tx_miner> Or at least the game can't tell the difference |
| 15:46 |
sfan5 |
a lua mapgen that does its own biome-respecting terrain gen? |
| 15:46 |
repetitivestrain |
almost |
| 15:47 |
MTDiscord |
<tx_miner> Yes |
| 15:47 |
MTDiscord |
<tx_miner> Mostly |
| 15:47 |
repetitivestrain |
v8's biomes are not reported as mapgen objects and cannot affect ore generation |
| 15:47 |
sfan5 |
switching to a partial lua reimplementation isn't the solution to engine flexibility problems |
| 15:47 |
MTDiscord |
<tx_miner> Ye but I can fix it, it was only there as a proof of concept anyway |
| 15:48 |
MTDiscord |
<tx_miner> I agree but no one wants to fix the engine |
| 15:48 |
repetitivestrain |
tx_miner: your ores will not respect the biome map, and you _cannot_ fix this without reimplementing all of core.generate_ores in lua, or modifying C++ |
| 15:48 |
MTDiscord |
<tx_miner> Ye i know, that's why I would reimplement it, that's what I said |
| 15:48 |
repetitivestrain |
and that's really a fool's errand |
| 15:48 |
MTDiscord |
<tx_miner> Lol |
| 15:49 |
sfan5 |
if "no one" will fix the engine you are free to keep stacking more workarounds |
| 15:49 |
repetitivestrain |
which no one will actually attempt |
| 15:49 |
sfan5 |
but it's still not the right solution |
| 15:49 |
MTDiscord |
<tx_miner> Luanti dev is in general |
| 15:50 |
MTDiscord |
<tx_miner> I agree |
| 15:50 |
repetitivestrain |
so, in the meantime, all i'm asking is, don't let's add a main menu feature that not only will not serve the requirements of the lua mapgens that actually exist and work correctly, but will also deceive users and developers alike as regards lua mapgen compatibility in general |
| 15:50 |
MTDiscord |
<tx_miner> Fair enough |
| 15:50 |
MTDiscord |
<tx_miner> We do need game defined menu mods tho |
| 15:50 |
MTDiscord |
<tx_miner> And per world settings |
| 15:51 |
repetitivestrain |
because, in mineclonia, i have an 83,000 loc Lua map generator, and i have been pulling my hair out since day one over its user interface aspects |
| 15:52 |
MTDiscord |
<tx_miner> Lol |
| 15:52 |
repetitivestrain |
while this proposal (#16240) doesn't address its concerns at all |
| 15:52 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16240 -- Add lua defined mapgens, as true mapgens in game.conf and world creation |
| 15:52 |
MTDiscord |
<tx_miner> 83k is crazy |
| 15:52 |
MTDiscord |
<tx_miner> Fair we probably need per world settings first |
| 15:52 |
repetitivestrain |
not very much, i think |
| 15:52 |
repetitivestrain |
https://codeberg.org/mineclonia/mineclonia/pulls/3419 |
| 15:52 |
MTDiscord |
<tx_miner> Ig that's what I'll do for a while |
| 15:52 |
repetitivestrain |
sure, thanks |
| 15:53 |
MTDiscord |
<tx_miner> Aye aye |
| 15:55 |
MTDiscord |
<tx_miner> 1042 is like < 1000 lines of mapgen I think |
| 15:55 |
MTDiscord |
<tx_miner> Maybe a bit more but around that |
| 15:56 |
|
mrkubax101 joined #luanti |
| 15:57 |
repetitivestrain |
tx_miner: i do envy you haha, your game is considerably simpler than minecraft |
| 15:58 |
MTDiscord |
<tx_miner> Ye tho I think Minecraft tries to over complicate life |
| 15:58 |
repetitivestrain |
the density functions alone, which are the fundamental units of a minecraft map generator definition, require >2000 lines of code to implement |
| 16:00 |
MTDiscord |
<tx_miner> No way |
| 16:00 |
MTDiscord |
<tx_miner> I bet I could get that down to 1800 |
| 16:00 |
MTDiscord |
<tx_miner> XD |
| 16:01 |
MTDiscord |
<tx_miner> Ur lead dev of mineclonia? |
| 16:01 |
MTDiscord |
<tx_miner> That's actually crazy how complex they try and make stuff |
| 16:02 |
MTDiscord |
<tx_miner> And they still have no end update |
| 16:03 |
MTDiscord |
<tx_miner> I am deeply sorry for you |
| 16:22 |
[MatrxMT] |
<repetitivestrain> No, but I've been developing plenty of features for it lately |
| 16:25 |
[MatrxMT] |
<repetitivestrain> https://codeberg.org/mineclonia/mineclonia/src/branch/main/mods/MAPGEN/mcl_levelgen/density_funcs.lua |
| 16:25 |
[MatrxMT] |
<repetitivestrain> Go ahead, I'd be grateful of it |
| 16:28 |
|
mrkubax10 joined #luanti |
| 16:56 |
MTDiscord |
<redundantcc> Minecraft World Generation isn't that slow, it's just poorly optimized. If I remember correctly, someone got a decent server running on a cheap microcontroller. |
| 16:56 |
MTDiscord |
<redundantcc> Found it: https://youtu.be/p-k5MPhBSjk |
| 17:00 |
Krock |
can Luanti run on a toothbrush? |
| 17:01 |
user333_ |
only one way to find out |
| 17:02 |
user333_ |
"Can it run DOOM" -> "Can it run Luanti" |
| 17:05 |
MTDiscord |
<redundantcc> Better question, can luanti run Doom? || Probably, if you used a hudspec Library you could get a decent approximation|| |
| 17:06 |
MTDiscord |
<redundantcc> Sad part is you could never post it on cdb due to licensing so it'll never get made. |
| 17:07 |
user333_ |
can luanti run luanti |
| 17:08 |
user333_ |
the closest thing i've found to that is someone who ported a web browser to luanti, you could go to the web MT client and play on that |
| 17:10 |
|
fluxionary joined #luanti |
| 17:20 |
MTDiscord |
<tx_miner> I think imma make a new mine is and try to port games ONTO it |
| 17:21 |
MTDiscord |
<tx_miner> Ye sure I'll take a look |
| 17:42 |
|
___nick___ joined #luanti |
| 17:46 |
|
kamdard_ joined #luanti |
| 17:46 |
|
Trifton_ joined #luanti |
| 17:51 |
MTDiscord |
<nathan4220776> It's important to mention that it's not real minecraft. |
| 17:51 |
MTDiscord |
<nathan4220776> And the terrain generation is much worse because of the hardware constraints. |
| 17:52 |
MTDiscord |
<nathan4220776> Never say never. A person could probably make a "xonotic" mod, and then someone could make a doom mod for the xonotic mod. ;) |
| 17:54 |
MTDiscord |
<redundantcc> What's a xonot? I'm talking about the licensing of the original textures, the code itself is doable but you can't port something if from a legal perspective making it look the same isn't allowed? |
| 17:56 |
|
cx384 joined #luanti |
| 17:59 |
MTDiscord |
<nathan4220776> Xonotic is a Quake-like open-source fps game. |
| 17:59 |
MTDiscord |
<nathan4220776> And there are quake-like and doom-like mod packs available for it. |
| 18:00 |
MTDiscord |
<nathan4220776> So while the original doom textures may or may not be safely usable in a minetest mod, you could probably use stuff from Xonotic instead. |
| 18:01 |
MTDiscord |
<nathan4220776> On some servers, you can do some silly things like using quake-style weapons on a minecraft-themed map while playing as Duke Nukem. |
| 18:01 |
MTDiscord |
<redundantcc> Isn't using a separate engine cheating, I mean if you're going to circumvent the need for this specific engine why not just get Doom running on a pregnancy test? |
| 18:02 |
MTDiscord |
<redundantcc> Oh come on I was joking! https://youtu.be/D5NTJSfUWDE |
| 18:23 |
[MatrxMT] |
<birdlover32767> either make a toothbrush turing machine or fiddle with android |
| 18:24 |
MTDiscord |
<et086> ||i don't think luanti can run doom well sadly|| |
| 18:42 |
[MatrxMT] |
<birdlover32767> mineos did it |
| 18:52 |
MTDiscord |
<tx_miner> what happend to mineos? |
| 18:52 |
MTDiscord |
<tx_miner> did it get taken of contentdb? |
| 18:52 |
MTDiscord |
<wsor4035> its author removed it |
| 18:52 |
MTDiscord |
<tx_miner> ah |
| 18:52 |
MTDiscord |
<tx_miner> imma make a new one |
| 18:53 |
[MatrxMT] |
<birdlover32767> i think there is a web version |
| 18:53 |
MTDiscord |
<tx_miner> i prob have a copy somewhere |
| 18:53 |
[MatrxMT] |
<birdlover32767> on minetest.dustlabs.io ? |
| 18:53 |
MTDiscord |
<wsor4035> iirc mineos git repo still exists |
| 18:53 |
MTDiscord |
<tx_miner> imma just make my own |
| 18:53 |
MTDiscord |
<tx_miner> Doors 95 |
| 18:53 |
MTDiscord |
<wsor4035> will need to use a different name |
| 18:54 |
MTDiscord |
<tx_miner> lol ye ik |
| 18:56 |
MTDiscord |
<tx_miner> Doors 25 with Watery Solid Silicon |
| 18:56 |
MTDiscord |
<tx_miner> https://tenor.com/view/bubble-buddy-spongebob-gif-6154100559256696215 |
| 18:57 |
MTDiscord |
<tx_miner> not the same |
| 18:57 |
MTDiscord |
<tx_miner> oh sry i just realised that the gifs dont work on irc |
| 18:57 |
MTDiscord |
<wsor4035> you have an erroneous gl in that gif |
| 18:57 |
MTDiscord |
<wsor4035> they do, they just have to click on the link |
| 18:58 |
MTDiscord |
<tx_miner> alr not to bad ig |
| 19:20 |
|
simon816 joined #luanti |
| 19:31 |
|
SFENCE joined #luanti |
| 19:51 |
|
Pokey joined #luanti |
| 19:53 |
|
wsor40351 joined #luanti |
| 19:54 |
|
bgstack15 joined #luanti |
| 19:56 |
|
sknebel joined #luanti |
| 19:56 |
|
pgimeno joined #luanti |
| 19:58 |
|
SFENCE joined #luanti |
| 19:59 |
|
pgimeno joined #luanti |
| 20:01 |
|
pgimeno joined #luanti |
| 20:04 |
|
pgimeno_ joined #luanti |
| 20:06 |
|
pgimeno_ joined #luanti |
| 20:29 |
|
bgstack15 left #luanti |
| 20:52 |
|
qqe joined #luanti |
| 21:03 |
MTDiscord |
<tx_miner> why is local ipairs = ipairs the firsxt line?? |
| 21:05 |
|
wsor4035 joined #luanti |
| 21:07 |
MTDiscord |
<tx_miner> THAT CODE IS CURSED |
| 21:07 |
MTDiscord |
<tx_miner> ahh |
| 21:07 |
MTDiscord |
<tx_miner> new project for me to work on tho XD |
| 21:38 |
user333_ |
i've seen code worse than that in a MT mod.... `local s = function(S) return S end` |
| 21:38 |
|
SwissalpS joined #luanti |
| 21:39 |
MTDiscord |
<warr1024> That's a hack called localization. It causes some Lua implementations to cache the location of that function instead of looking it up in _G each time, so can apparently make repeated use a tiny bit faster. |
| 21:39 |
MTDiscord |
<warr1024> It's a microoptimization, but snce it doesn't really cause any semantic difference in the meaning of the code, people tend to do it even though the impact is small. |
| 21:40 |
user333_ |
allright then... what about `local core = core or minetest` |
| 21:40 |
MTDiscord |
<warr1024> yeah, same thing |
| 21:40 |
cheapie |
user333_: I've seen things like that back in the days of intllib and whatever, they'd set up S() as a no-op and then if intllib is installed overwrite it with the actual localization code |
| 21:42 |
MTDiscord |
<tx_miner> no thats not what was crazy, its the rest of the code that is cursed, but that first line threw me bc they dont need it localized in this case from what i can tell |
| 21:44 |
MTDiscord |
<warr1024> Localization isn't a question of whether you need the thing localized in the file or not, it'a question of whether the file's localization need differs from the standard applied to all files. |
| 21:44 |
user333_ |
`local p = q[qi]; qi = qi + 1` |
| 21:44 |
user333_ |
why just 'q'... rip readability |
| 21:44 |
MTDiscord |
<tx_miner> exactly, and it doesnt thats why i dont get it |
| 21:45 |
MTDiscord |
<warr1024> What does "don't need it localized in this case" mean, and what does "doesn't differ from the other files" mean? |
| 21:45 |
MTDiscord |
<tx_miner> https://tenor.com/view/words-trump-gif-10343307 |
| 21:46 |
MTDiscord |
<tx_miner> i mean ipairs is pretty universal and the uses are pretty standard |
| 21:46 |
MTDiscord |
<warr1024> Are they not using ipairs in that file? |
| 21:46 |
MTDiscord |
<tx_miner> they are |
| 21:47 |
MTDiscord |
<tx_miner> but localizing it |
| 21:47 |
MTDiscord |
<warr1024> Then what makes you think that they need it not to be localized? |
| 21:47 |
MTDiscord |
<tx_miner> i dont see the need, but not rly a problem, i was just wondering why they did it |
| 21:48 |
MTDiscord |
<warr1024> If you need it localized in that file then you localize it. If you need it NOT to be localized then you don't localize it. If you don't need it to be either localized or not, and either case would work, then you make the decision based on factors that are not local to the file. |
| 21:48 |
MTDiscord |
<tx_miner> fair |
| 21:48 |
MTDiscord |
<tx_miner> ive never had a need to locolize a standard call like ipairs tho |
| 21:49 |
MTDiscord |
<warr1024> This is why you will see ipairs localized in every file in most of my projects: the tools that handle automatic localization just look for it present in the file and outside of a string literal. That can lead to some unnecessary over-localization, but so far nobody has ever shown any evidence that I should care about that. |
| 21:50 |
MTDiscord |
<tx_miner> alr |
| 21:50 |
MTDiscord |
<warr1024> In practice stuff like localization only matters in hotspots, which will be like less than 1% of actual code. When it come to microoptimizations though, you can save yourself the work of finding where they contribute to hotspots by just applying them everywhere. |
| 21:51 |
MTDiscord |
<warr1024> IIRC LuaJIT actually does this to some degree. The localization is only really a factor in PUC Lua. |
| 21:51 |
MTDiscord |
<tx_miner> alr |
| 21:52 |
MTDiscord |
<warr1024> local x = x is actually a real thing in other cases, even if x originally was a local in a higher scope. In that case you're not actually changing the performance behavior, but creating a shadow identifier that holds a copy of the value, but changes independently from the original. |
| 21:54 |
MTDiscord |
<warr1024> Shadowing is generally not nice behavior though as it makes the same name refer to different things in different but often adjacent places and can be confusing, so if you'd have done local x2 = x that would have been better. Sometimes it's done though in the case where you used to have aliasing and had to break it, and didn't feel like rewriting a whole bunch of code (or where there's actually risk of renaming the wrong things and making |
| 21:54 |
MTDiscord |
the bug even worse) |
| 21:55 |
MTDiscord |
<tx_miner> i tend to do x2 or lx or something like that |
| 21:56 |
MTDiscord |
<warr1024> Arguably if your scopes are complex enough that you're doing local x = x then neither x should have had that short of a name in the first place, but naming things is hard. |
| 21:57 |
MTDiscord |
<warr1024> something like local origx = x might work though |
| 21:57 |
MTDiscord |
<nathan4220776> ecks |
| 21:58 |
MTDiscord |
<warr1024> X is ecks. / and \ are just one eck each. |
| 22:00 |
user333_ |
short variable names like n, i, _, x, y, and z are fine in certain cases; n, i, and _ are used in loops a lot, and x/y/z refer to coordinates most often |
| 22:03 |
MTDiscord |
<tx_miner> hey i was just wondering, does it seem better to do an OS with a hud display or formspec? |
| 22:03 |
MTDiscord |
<tx_miner> like i can compute "mouse" locations by using look direction with huds |
| 22:04 |
user333_ |
i would assume a formspec if you wanted to make a CLI OS, but you could just use chat for that |
| 22:04 |
user333_ |
for a full GUI.... probably HUD because you can have a mouse |
| 22:05 |
MTDiscord |
<tx_miner> idk |
| 22:05 |
MTDiscord |
<tx_miner> i think imma mix them, so like HUD for GUI and a sort of formspecs for allowing text input |
| 22:06 |
user333_ |
port MS-DOS to luanti... it's partially open-source, you just have to translate the x86 assembly to lua :P |
| 22:06 |
MTDiscord |
<tx_miner> honeslty it cant be to hard |
| 22:06 |
cheapie |
I've considered making some kind of emulator for something in a Luacontroller, not for x86 though :P |
| 22:07 |
MTDiscord |
<tx_miner> x86 isnt that complex on the older ones due to the limits |
| 22:07 |
user333_ |
true, but most people don;t know x86 assembly (including me) |
| 22:07 |
cheapie |
8080 emulator in a Luacontroller would be fun, build a working Altair 8800 in-game |
| 22:07 |
MTDiscord |
<tx_miner> i do |
| 22:07 |
cheapie |
I know a bit |
| 22:07 |
MTDiscord |
<tx_miner> but its been a while since ive done the old 16bit code |
| 22:08 |
MTDiscord |
<tx_miner> the bios would be the pain |
| 22:08 |
user333_ |
just steal code from an open-source 16-bit VM |
| 22:09 |
cheapie |
You could probably use an off-the-shelf BIOS, GLaBIOS or whatever |
| 22:09 |
MTDiscord |
<tx_miner> or just write it as a clone in lua and handel the biose as just a lua "API" |
| 22:10 |
MTDiscord |
<tx_miner> but unless u emulate the hardwear u cant get the old dos viruses |
| 22:14 |
cheapie |
FWIW if you want to play around with an emulated processor in-game, the various vm16-based mods (pdp13 and beduino) are fun |
| 22:15 |
cheapie |
Over on C-Techage I have some Beduinos controlling some machines, running programs I wrote in vm16 assembly: https://gist.github.com/cheapie/61c62576890b4f384019fe0a60ddbd2f |
| 22:33 |
|
panwolfram joined #luanti |
| 22:39 |
Noisytoot |
can you emulate a CPU capable of running linux in luanti and then run luanti inside luanti? |
| 22:41 |
cheapie |
In theory, yes. In practice, I'm not crazy enough to try that :P |
| 22:42 |
* user333_ |
wonders if you can run an x86_64 VM on x86 |
| 22:43 |
cheapie |
user333_: Given enough memory and time, you can emulate any processor on any other processor |
| 22:44 |
user333_ |
hmm..... /me installs QEMU x86_64 on his x86 PC |
| 22:44 |
cheapie |
Linux supported running on amd64 before any amd64 processors were available for purchase, emulation would have been a big part of that |
| 22:45 |
user333_ |
well tbf amd64 is backwards-compatible with x86_64 so any x86_64 programs/OSes will run on amd64 (iirc) |
| 22:46 |
cheapie |
amd64 and x86_64 are the same thing |
| 22:46 |
user333_ |
why cant they just call it x86_64... same with arm64 and aarch64 |
| 22:47 |
cheapie |
Because AMD made it and they (at least initially) called it AMD64 |
| 22:48 |
user333_ |
too many CPU types for me ;-; |
| 22:50 |
|
kamdard joined #luanti |
| 23:22 |
|
turtleman joined #luanti |
