Mod proposal (compression)

[The4codeblocks]

Repository: The4codeblocks/compression cDB: Compression Dependency: The4codeblocks/compression_api

Made for conversation here.

[SwissalpS]

maybe I don't understand this... but how does compressing ice, stone and similar make any sense? Especially obsidian.

[The4codeblocks]

maybe I don't understand this... but how does compressing ice, stone and similar make any sense? Especially obsidian.

You can comment those out after install. They're in a table.

[S-S-X]

Did take a look at code, there seems to be some issues like at least polluting global namespace and overriding table.copy with implementation that yields different results.

Should at least fix that but yeah I'm not sure I get it, is it at its core supposed to be like storage expansion for selected nodes or is there more?

I mean there should be some good reason to install it as it is going to register some new nodes, depending on conf but seems like some 10 per type or so by default.

[The4codeblocks]

Did take a look at code, there seems to be some issues like at least polluting global namespace and overriding table.copy with implementation that yields different results.

Should at least fix that but yeah I'm not sure I get it, is it at its core supposed to be like storage expansion for selected nodes or is there more?

I mean there should be some good reason to install it as it is going to register some new nodes, depending on conf but seems like some 10 per type or so by default.

I used the table in table.copy to kinda merge it with lua's default table table.

[The4codeblocks]

Issues should be fixed now.

[S-S-X]

I used the table in table.copy to kinda merge it with lua's default table table.

Main issue here is the fact that Minetest already provides its own table.copy implementation and overriding it might one day cause some pretty confusing bugs (in other mods) if use is only compatible with engine's implementation whatever it ends up to be.

If there's some really good reason to override common / universal utility functions it should be done in a way that is very visible, preferably with dedicated mod that does nothing else. Like engine bug fix mod / security issue workaround mod / some other good reason mod.

[The4codeblocks]

I used the table in table.copy to kinda merge it with lua's default table table.

Main issue here is the fact that Minetest already provides its own table.copy implementation and overriding it might one day cause some pretty confusing bugs (in other mods) if use is only compatible with engine's implementation whatever it ends up to be.

If there's some really good reason to override common / universal utility functions it should be done in a way that is very visible, preferably with dedicated mod that does nothing else. Like engine bug fix mod / security issue workaround mod / some other good reason mod.

I replaced it.

[SwissalpS]

You can comment those out after install. They're in a table.

Even if that was how things are done, commenting out of the table would still leave a couple items hard-coded in there (stone, coal ...)

I'm still trying to understand what problem this is solving or what use the addition is providing.

From what I read, it is providing new items/nodes with various compression levels and adding a darkening overlay to change the looks.

So I'm imagining having my inventory now filled with e.g. compressed cobble level 1 through 10 and I can't stack them onto each other ~~or convert them unless I cook them And after cooking I of course don't have cobble anymore but stone~~(I see now there are reverse craft recipes added). Did I understand that right so far?

[The4codeblocks]

You can comment those out after install. They're in a table.

Even if that was how things are done, commenting out of the table would still leave a couple items hard-coded in there (stone, coal ...)

I'm still trying to understand what problem this is solving or what use the addition is providing.

From what I read, it is providing new items/nodes with various compression levels and adding a darkening overlay to change the looks.

So I'm imagining having my inventory now filled with e.g. compressed cobble level 1 through 10 and I can't stack them onto each other ~or convert them unless I cook them And after cooking I of course don't have cobble anymore but stone~(I see now there are reverse craft recipes added). Did I understand that right so far?

Yes.

The reverse recipes were there since the very beginning.

Those "hardcoded" ones are to prevent problems with duplicate compressed materials. The mod adds plenty of levels to however much you want, and moreblocks adds one level. 2 recipes making the same thing override, and it's not a good compression mod if many are inaccessible.

[OgelGames]

I've had experience with the Minecraft version of this (compressium), and they are quite useful to store bulk materials, but only if you don't have a better way of storing them, because crafting and uncrafting the blocks can be a pain. Besides that the only other real use is in craft recipes.

On pandorabox we have drawers, which are a much better way to store bulk materials, so that mostly negates the main benefit of compressed blocks. (even more so once wrench gets updated, allowing you to pick up the drawers)

Also, I find it weird that this is two separate mods. Why not just have the API as part of the compression mod?

[The4codeblocks]

Also, I find it weird that this is two separate mods. Why not just have the API as part of the compression mod?

compression_api handles the generation, compression handles the content. Also, it's in case some mod wants to make compressed versions of their own nodes. Also, so the main content mod is detachable.

[The4codeblocks]

I've had experience with the Minecraft version of this (compressium), and they are quite useful to store bulk materials, but only if you don't have a better way of storing them, because crafting and uncrafting the blocks can be a pain. Besides that the only other real use is in craft recipes.

On pandorabox we have drawers, which are a much better way to store bulk materials, so that mostly negates the main benefit of compressed blocks. (even more so once wrench gets updated, allowing you to pick up the drawers)

Also, I find it weird that this is two separate mods. Why not just have the API as part of the compression mod?

I got it. It's so that the thing that does the compression generation has no dependencies.

[OgelGames]

compression_api handles the generation, compression handles the content. Also, it's in case some mod wants to make compressed versions of their own nodes. Also, so the main content mod is detachable.

It can still do both. And if you really want to provide the option not to automatically register nodes, then you could add a setting.

It's so that the thing that does the compression generation has no dependencies.

The only dependency compression has is compression_api, so if they were one mod, there would be no dependencies.

[S-S-X]

For end user managing installed mods might be simpler than using configuration system, mostly because installing mod is somewhat more obvious than reading docs and changing configuration. This makes sense because configuration is what is supposed to contain a lot of options but it also makes debate about mods vs. configuration pretty much opinion based.

In my opinion multiple mods over configuration mostly makes sense for registering persistent stuff like nodes, tools or mobs. I think what exact conditions should be used to decide between those two depends a lot on projects future plans. For example is there going to be 10 other mods that depend on this library mod and is it likely that just few of them will be enabled at once. Or is there some core stuff that is very likely required with library implementation, like stuff for mtg if library is originally primarily made for mtg.

There's subjective arguments for both ways and not really solid arguments against either which pretty much makes this all opinion based and subjective.

Some like to include example implementations, like in this case some compressed nodes, with their library mod while others like to make library strictly only provide API to do stuff instead of doing it for you.

Just few thoughts, best to make decisions based on your actual goals.

[OgelGames]

There is a third option too, have the API and content mods be combined in a modpack, which could be a good idea if adding support for other mods or games is planned.

[S-S-X]

Well yeah, fourth option: both. As modpacks are just package for multiple mods it can be offered without even combining. One simple way to do so is to just create modpack repo with modpack meta data and add each mod as a git submodule.

[The4codeblocks]

One simple way to do so is to just create modpack repo with modpack meta data and add each mod as a git submodule.

Nice idea.

[SwissalpS]

I don't like that idea unless the code-base of each submodule is considerably larger than what minetest mods tend to be.

Edit: Reasoning: A few hundred kb extra data installed but not activated is a lot easier to manage than needing to pull submodules.

[The4codeblocks]

Well yeah, fourth option: both. As modpacks are just package for multiple mods it can be offered without even combining. One simple way to do so is to just create modpack repo with modpack meta data and add each mod as a git submodule.

Done! The4codeblocks/compression_pack

[S-S-X]

I don't like that idea unless the code-base of each submodule is considerably larger than what minetest mods tend to be.

Edit: Reasoning: A few hundred kb extra data installed but not activated is a lot easier to manage than needing to pull submodules.

Remeber that modpack built using submodules gives you both options, you can choose to either use direct repos for mods or submodule modpack however you like. Modpack and bare mods work the same, bare mods just allows picking exactly what you want.

So when done with modpack it does not introduce similar issues what emerges from having parts of the mod through submodules (how sound api does). ContentDB is also nowdays able to pack submodule repos for distribution.

[The4codeblocks]

The issue has gone stale with all criticism taken care of. Any other ideas?

[SwissalpS]

some trivial things:

• add readme to compression_pack
• https://github.com/The4codeblocks/compression_api/blob/9586b9552c6d7999a98ab91e1d0796e81c342636/init.lua#L15-L16 is still using _ as a variable
• many occurences of operators without spaces around them (also comas without following spaces)
• you could split up mtg default nodes and moreblocks into separate mods, now that you chose to go the modpack way.

[The4codeblocks]

some trivial things:

• add readme to compression_pack Done
• https://github.com/The4codeblocks/compression_api/blob/9586b9552c6d7999a98ab91e1d0796e81c342636/init.lua#L15-L16 is still using _ as a variable Fixed.
• many occurences of operators without spaces around them (also comas without following spaces) Done!
• you could split up mtg default nodes and moreblocks into separate mods, now that you chose to go the modpack way. Well..... The features are interconnected.

[S-S-X]

The issue has gone stale with all criticism taken care of. Any other ideas?

I believe main issue for inclusion is that it is still unclear if this would offer something besides:

• additional storage
• many clones of few basic nodes with slightly adjusted texture

Mod that adds new nodes (or any items) isn't as easy to just try out and remove because cleanup can't really be done efficient way. That's probably main reason why ppl want to be sure about it before actually trying it out on live server.

[SwissalpS]

• The features are interconnected.

Yes, I was suggesting that it would be possible to remove the interconnection :D

It doesn't really matter much, because the way I see it, servers who do implement this, are most likely only going to activate the api and then add their own mod with their own set of nodes and levels that balance their understanding of how this kind of compression makes sense to their games.

I agree with SX, we still don't have any answers as to how this would make sense on pandorabox. Personally compressing more than once doesn't seem logical and compressing items like ice and obsidian (without aplying magic) is hard to imagine.

[The4codeblocks]

slightly adjusted texture

Like all other compression mods. I made mine (darken_tiles(tiles, count)) procedural.

[Klaranth]

The4spaceconstants I remember making a compression mod. Might be a time to bring that up again. The sieves just make inflation a big issue

[Klaranth]

wf13 add a recipe to craft compressed cobble with stone instead please The4spaceconstants compressed stone? it's as easy as just "make compressed stone until compression 1" if you have the right library wf13 I need it to easily turn stone into cobble lol bc I turn dessert stone into normal stone and want to use it into lava but cant without breaking it : / The4spaceconstants digiline pipeworks. MCLV make stone: place stone using deployer, break stone using nodebreaker with pickaxe inside.