Page 2 of 2

Re: [Mod] lib_materials [lib_materials][git]

Posted: Sat Oct 05, 2019 22:24
by ThorfinnS
ShadMOrdre wrote:I grew tired of so many mod interdependencies, conflicts, or just outright duplicity.
Duplication? Or do you think duplicity is involved?
ShadMOrdre wrote:I also wanted to consolidate what I considered to be the best of the available content into a single package. I would ultimately have to install up to 15 other mods, some of which just do not work with each other, to have the content that lib_materials alone provides. An additional 20 or so mods for the content packaged in lib_ecology, also coming from source mods that cleared decorations, or overrode some other mod, or were written for MT 0.4.09, and the only updates they've seen are to ensure continued functionality, but not updated to use the new engine features. This list goes on.
Ambitious goal. It's just very beefy. On some of the older school machines, lib_ecology and lib_materials takes a couple minutes to load, and a couple of them with not much RAM actually crash. Adding in lib_shapes is completely out of the question. The crashing can be dealt with by disabling some aspects (making variant water and variant shapes optional in a massive settingtypes.txt, for example) but that may not speed load times very much.
ShadMOrdre wrote:Having read through the last page of UnifiedInvs thread, and knowing that the mod author, RBA, is no longer with us, I assume that Unified Inventory will probably not get updated anytime soon. There may be forks of the mod that have been updated, but again, as I do not use the mod, I am not sure of this.
It's been subsumed into the minetest-mods crew, and there are updates from this year.
ShadMOrdre wrote:I still can't see how lib_materials forces Unified Inventory to change values in that way, unless the above mentioned limit is sending text instead of integers.
ShadMOrdre wrote:I notice that you have both Toolranks and lib_trm, which should not be.
Right. When I'm testing out lib_trm, I disable toolranks. But because lib_trm is giving errors, I've been disabling that, and enabling toolranks. One or the other, never both.
ShadMOrdre wrote:There are other mods that also work with inventory. Can you ensure that the only mods loading are MTG, Unified Inv, and lib_materials. Make sure that the MTG game folder is fresh, and had no additional mods aside from those included in the download. If this continues, can you run this mod setup using sfinv? I run mod heavy, perhaps quite a bit heavier than the mod list you've shown, but I do not use Unified Inv.
Of course. I did all that before mentioning anything.I unzipped it to a new directory, then git cloned the two, and only the two. It does not throw the problem unless I enable UI. But some of the kids vastly prefer Unified, so a couple of the servers we're running use that.

Think I'll throw in some debugging statements and see if I can figure out exactly which are being stored as strings.

Later this evening when I get to a good internet connection, I'll see if your pushes are live.



Re: [Mod] lib_materials [lib_materials][git]

Posted: Sun Oct 06, 2019 03:17
by ThorfinnS
OK, here's what I'm getting. Brand new download of everything, minetest (sfan5's latest build), unified inventory, unified inventory plus, lib_ecology, lib_materials. Enable all. Start MTG.

The line I added to Unified Inventory was

Code: Select all

				if type(max_items_left) == "string" then minetest.log(name..'*'..max_items_left..'*') break end
Debug.txt shows:

Code: Select all

2019-10-05 21:48:51: [Server]: lib_ecology:coral_brain**
2019-10-05 21:48:51: [Server]: lib_ecology:coral_brown**
2019-10-05 21:48:51: [Server]: lib_ecology:coral_dragon_eye**
2019-10-05 21:48:51: [Server]: lib_ecology:coral_orange_01**
2019-10-05 21:48:51: [Server]: lib_ecology:coral_sponge**
2019-10-05 21:48:51: [Server]: lib_ecology:plant_pineapple_plant**
2019-10-05 21:48:51: [Server]: lib_ecology:plant_weed_eye**
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_bamboo*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_brown*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cold*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_humid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_humid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_humid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_humid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_semiarid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_semiarid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_semiarid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_semiarid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_semihumid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_semihumid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_semihumid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_semihumid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_temperate_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_temperate_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_temperate_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_cool_temperate_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_crystal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_dry*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_fiery*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_gray*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_green*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_grove*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_humid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_humid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_humid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_humid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_semiarid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_semiarid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_semiarid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_semiarid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_semihumid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_semihumid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_semihumid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_semihumid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_temperate_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_temperate_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_temperate_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_hot_temperate_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_jungle_01*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_mushroom*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_prairie*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_humid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_humid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_humid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_humid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_semiarid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_semiarid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_semiarid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_semiarid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_semihumid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_semihumid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_semihumid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_semihumid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_temperate_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_temperate_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_temperate_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_temperate_temperate_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_humid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_humid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_humid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_humid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_semiarid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_semiarid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_semiarid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_semiarid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_semihumid_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_semihumid_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_semihumid_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_semihumid_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_temperate_coastal*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_temperate_highland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_temperate_lowland*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_grass_warm_temperate_shelf*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_litter_coniferous*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_litter_fungi*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_litter_leaf_01*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_litter_leaf_02*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_litter_rainforest*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_litter_stones*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_litter_vine*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_snow*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_soil*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_soil_wet*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_stone*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_stone_cobble*1*
2019-10-05 21:48:51: [Server]: lib_materials:dirt_peat_with_stone_desert_cobble*1*
2019-10-05 21:48:51: [Server]: lib_materials:ore_quartz_with_gold**
2019-10-05 21:48:51: [Server]: lib_materials:ore_stone_with_aluminum**
2019-10-05 21:48:51: [Server]: lib_materials:ore_stone_with_copper**
2019-10-05 21:48:51: [Server]: lib_materials:ore_stone_with_gold**
2019-10-05 21:48:51: [Server]: lib_materials:ore_stone_with_iron**
2019-10-05 21:48:51: [Server]: lib_materials:ore_stone_with_lead**
2019-10-05 21:48:51: [Server]: lib_materials:ore_stone_with_silver**
2019-10-05 21:48:51: [Server]: lib_materials:ore_stone_with_tin**
2019-10-05 21:48:51: [Server]: lib_materials:sand_with_rocks**
2019-10-05 21:48:51: [Server]: lib_materials:stone**
2019-10-05 21:48:51: [Server]: lib_materials:stone_basalt_01*1*
2019-10-05 21:48:51: [Server]: lib_materials:stone_chalk**
2019-10-05 21:48:51: [Server]: lib_materials:stone_desert**
2019-10-05 21:48:51: [Server]: lib_materials:stone_gneiss_01*1*
2019-10-05 21:48:51: [Server]: lib_materials:stone_gravel*1*
2019-10-05 21:48:51: [Server]: lib_materials:stone_rhyolitic_tuff*1*
2019-10-05 21:48:51: [Server]: lib_materials:stone_sandstone_desert**
2019-10-05 21:48:51: [Server]: lib_materials:stone_sandstone_desert_block**
2019-10-05 21:48:51: [Server]: lib_materials:stone_sandstone_desert_brick**
2019-10-05 21:48:51: [Server]: lib_materials:stone_sandstone_old_red**
2019-10-05 21:48:51: [Server]: lib_materials:stone_sandstone_old_red_block**
2019-10-05 21:48:51: [Server]: lib_materials:stone_sandstone_old_red_brick**
2019-10-05 21:48:51: [Server]: lib_materials:stone_sandstone_white**
2019-10-05 21:48:51: [Server]: lib_materials:stone_sandstone_white_brick**
2019-10-05 21:48:51: [Server]: lib_materials:stone_savanna**
2019-10-05 21:48:51: [Server]: lib_materials:stone_savanna_with_ore_coal**
2019-10-05 21:48:51: [Server]: lib_materials:stone_savanna_with_ore_iron**
2019-10-05 21:48:51: [Server]: lib_materials:stone_slate_01**
2019-10-05 21:48:51: [Server]: lib_materials:stone_tuff*1*
As you see, only a small fraction of the nodes you add (127 out of whatever) had strings for that field. In most cases, the string was "1", but there are a small minority of zero length strings. I spent time going through your code trying to see where these were getting defined and made no progress. I thought they were being built by parsing your nodes.csv file, but since the base name of the node in that file would appear to be "dirt_with_grass_pete_moss" (note spelling) while the node shows up as "dirt_peat_with_grass", (rearranged and spelling corrected) I'm guessing that must be what you were talking about making it easy to add future node types.

Anyway, I thought you could probably look at the list and say, "Oh, I know what those things have in common."

Incidentally, I played that for a bit in creative mode, gave myself a stack of buckets, and was unable to fill one with what sure looked and acted and sounded like water. I'll attach a screenshot if you would like, but since this is still seriously WIP, you most likely already know that.

Re: [Mod] lib_materials [lib_materials][git]

Posted: Tue Oct 08, 2019 15:39
by ThorfinnS
ThorfinnS wrote:It's just very beefy. On some of the older school machines, lib_ecology and lib_materials takes a couple minutes to load, and a couple of them with not much RAM actually crash. Adding in lib_shapes is completely out of the question. The crashing can be dealt with by disabling some aspects (making variant water and variant shapes optional in a massive settingtypes.txt, for example) but that may not speed load times very much.
Had a thought.

Your long-range plan is to use the csv files to load all the node data, right? That might be a good way to select groups of nodes. For example, all the nodes that come with MTG could be grouped into nodes_mtg.csv. The ones you added from ethereal could be in nodes_ethereal.csv. Or since ethereal is so vast in the first place, maybe it's broken up into nodes_mushroom.csv etc. That way, settingtypes.txt could be used to enable groups of related nodes as desired. It would be reasonably easy to design a world to your tastes that meets your machine requirements.

Second, what are you using to create the .csv? I'm no expert, but I don't see how to tell LibreOffice (for instance) how to use the piping character (|) as the delimiter. A spreadsheet would be a lot easier to maintain than counting a bunch of vertical bars, hoping you get the field you want in the right spot.

Re: [Mod] lib_materials [lib_materials][git]

Posted: Tue Oct 08, 2019 16:36
by ShadMOrdre

One of my To Do's for this project, was to get the .csv file into a better structured format, that could accommodate essentially all node definitions. I only need to move data into an already formatted new .csv file, and then update the node_registration.lua file to reflect the changes. This won't take long, I just hadn't planned on doing it yet.

In the process of this, I wanted to simply add some fields into the .csv that would be used internally in a manner you describe, wherein I can choose the "default" set, the "ethereal" set, the "moretrees" set, and so forth. This change would also be made to lib_ecology, for the same purpose.

You are absolutely correct in seeing the potential of the .csv format for loading, not just node defs, but all defs. It is all data, data that currently has been locked into the respective mods, but that could be just as easily handled from a spreadsheet, or even a database app.

I use Lubuntu 18, but have never gotten around to installing one of the office apps. So for a spreadsheet, I use Gnumeric. After years of MS Excel, and having to configure text output options on a variety of databases, I am actually enjoying the simplicity of Gnumeric, in that I can set the output options when I export the data.

I prefer to use the pipe, ( | ), character simply because it is not frequently used in general, whereas many text fields include quotation marks, either single or double. Commas and semicolons also appear with enough frequency in a variety of datasets as to make them rather unusable as a delimiter. However, if you notice, they get great use within fields as delimiters, allowing fields within fields, if you will.

One of the things I did implement, was settings to enable the rivers, water_dynamics, and other processing heavy code. One of my goals has been to enable this in an efficient enough way to allow older PCs to build worlds with these mods in a game enjoyable timeframe. I set my view distance to 80m - 120m, so that as I walk around, the world is generated without waiting. I'm also patient enough, (not really), to walk slow enough to allow that. I use older PCs, and I want decent frame rates and little lag. I also have to leave enough room for mods like mesecons, pipeworks, advtrains, and all the mobs_redo mobs, which are quite heavy in themselves.

That was one of the motivations in preferring to use the .csv format. All the code, and data, that was being loaded into RAM, leaving less and less available to actually use at runtime. While server start might be a little slower, and client loading times are unaffected by this, there is certainly more RAM available for all the other heavy mods to continue processing. As such, I'm extending this concept to all of my mods, using .csv files for data input, thus removing all the associated code previously being loaded.

As a side tip, I prefer not to run MT as a single server/client instance. I typically run a server in a terminal window, and use a separately installed client to access the server. The client has no games or mods installed, and the server has no interface overhead, so performs slightly better. This also splits the processing into world_gen, and client rendering. In a single server/client instance, you only get a single core to do all the processing, so on a multi core chip, there is unused potential. By running a standalone server, even on a client PC for singleplayer, I can force the setup to use at least 2 cores. Mapgen is faster, as is client rendering. Just a tip.

In short, I plan to restructure the .csv file, to include full node def properties, and for internal fields such as defining and enabling node "sets", as you have outlined.

This will take me a little time to accomplish, and at the moment, time is a little short. I hope to have this completed soon, as this is essentially the final piece to actually releasing lib_materials and lib_ecology as a nonWIP mod and to put it on the CDB.

Thank you for your input, feedback, testing, breaking, and all the other stuff you've been assisting with. The suggestions have been useful.


Re: [Mod] lib_materials [lib_materials][git]

Posted: Tue Oct 08, 2019 18:43
by ThorfinnS
ShadMOrdre wrote:In the process of this, I wanted to simply add some fields into the .csv that would be used internally in a manner you describe, wherein I can choose the "default" set, the "ethereal" set, the "moretrees" set, and so forth. This change would also be made to lib_ecology, for the same purpose.
Only reason I suggested separate files is minimizing errors, i.e., typing "m0retrees" or "moretreees" instead of "moretrees" and reducing processing time, i.e., instead of parsing a data file with potentially thousands of entries when you just want the default set, you'd parse only those files you want.

My thinking was that for the basic type of mod, adding nodes, recipes, etc., it would be no more involved than dropping a few .csv files into the directory. It wouldn't involve splicing together nodes.csv and newnodes.csv, for example.
ShadMOrdre wrote:You are absolutely correct in seeing the potential of the .csv format for loading, not just node defs, but all defs. It is all data, data that currently has been locked into the respective mods, but that could be just as easily handled from a spreadsheet, or even a database app.
Saw that. I was trying to decide if I had the time to do something similar for recipes, but using rubenwardy's new crafting mod. texmex has already done the heavy lifting -- I think I could pretty easily output a file using an on load mod with all the recipes texmex pulled, including base mod, for either a field in the csv or a filename, depending on overall vision of the project. I'm leaning towards the latter, because adding new stuff becomes a matter of adding new files rather than modifying existing ones. There's no reason you would even have to edit "settingtypes.txt' -- simply parsing the directory would let you rewrite "settingtypes.txt", either enabling or disabling the new files depending on what your base option you had chosen.

I'm still hashing through the details in my head. My thought was if one loads his mod, rubenwardy's crafting,, texmex's crafting_recipes, and the hypothetical crafting_recipes_csv mod, then exit, you should be left with a file or files ready to drop into your lib_materials mod, or whatever you end up calling it when it's fully integrated..
ShadMOrdre wrote:...Gnumeric...
Got that on my old laptop. I'll have to look.

ShadMOrdre wrote:As a side tip, I prefer not to run MT as a single server/client instance...
Oh, I do that too, with running games. With testing, I find its faster to load from the launcher, and as I add mods to check compatibility, it's easier to see the dependencies and optional dependencies.

Re: [Mod] lib_materials [lib_materials][git]

Posted: Wed Oct 09, 2019 23:02
by Red_King_Cyclops
I'm wondering if you would be interested in adding in another fluid to lib_materials. My mods space_travel and rocket together add in the following liquids:
  • Rocket fuel
  • Liquid hydrocarbon
  • Sulfuric acid
  • Cryolava
  • Two kinds of coloured, extraterrestrial water (due to bacteria and/or reflected light)
These liquids are also included, but they are not exactly new:
  • Oil (borrowed from lib_materials)
  • Europa water (looks identical to normal water, only included for a technical purpose)
  • Space lava (looks identical to normal lava, only included for a technical purpose)

Re: [Mod] lib_materials [lib_materials][git]

Posted: Sun Oct 13, 2019 07:25
by ShadMOrdre
UPDATE: 2019 - 10 - 12
Trimmed the number of nodes available in creative.
Disabled rivers, water_dynamics, waterfalls by default.
Added additional vessels, glass jug, jar, mug, others.
Updated mapgen aliases.
Created aliases between shapes and stairs / slabs


As I thought about the idea for a while, I realized, it wouldn't make sense to use only sets of nodes, as that would essentially require a rework of biomes, ores, ecosystems, and would wreak havoc on lib_ecology.

As an alternative, and something I should have already done, I've simply removed the bulk of the nodes from creative. All of the grass covers multiplied by all the dirts, meant a large number of nodes. Now, just the basic dirt types, and the basic ground cover grasses. The shaped nodes should be craftable using the shapes, instead of being available in creative. These two changes greatly reduced the number of nodes showing up in creative. I have not tested with unified_inventory, but I'm thinking that UI manages in such a way that it imposes the limit on the number of nodes, or simply can't handle the shear volume of nodes. This maybe should be investigated from that end, since lib_materials only crashes when that mod is enabled.

Please let me know if my updates have any affect, either way.

Again, thank you for your feedback.


Let me take a look at them. The rocket fuel, liquid hydrocarbon, sulfuric acid all sound like good additions. I'm willing to consider any other liquids you create for the space mods, like liquid nitro, hydrogen, etc.

Re: [Mod] lib_materials [lib_materials][git]

Posted: Fri Oct 25, 2019 15:34
by ThorfinnS
I'd have taken this to PM, but you must have disabled that.

How is the csv thing working out? The group I'm mentoring wants to do some major work re: farming, and it seems to me this would be a really good way to add new stuff. My question is what kind of things have come up that you needed to work around? How would you do it differently knowing what you know now? Suggestions re: variable records, like variable numbers of drops? Etc.

Re: [Mod] lib_materials [lib_materials][git]

Posted: Sat Oct 26, 2019 04:59
by ShadMOrdre

Using .csv files to load the data actually works better than expected. Again, simply removing all the node defs from code, and funneling the .csv data through a well vetted function seems to have improved performance, in general. But this could be subjective to my own opinion/experience.

For dealing with things like drops, I preferred to only store the actual values used, and then inputting those values in a predefined "drops" definition. The same is true for liquid textures, and some other fields, where the particular definition for that node property is variable.

This same idea can be extended to even allow customizable functions. How? Like this.

In the .csv file, in the appropriate field, (for example, let's use the on_punch definition). For the on_punch code, I simply use a dofile, calling the appropriate on_punch lua file. You'll end up with lua files for each unique "on_punch" definition, but because the code is store single in a lua file, you can set the name of the file to call in the .csv file, in the on_punch field.

When my function reads the .csv file, for each record, it will call the named lua file, for the corresponding event. For each node, this will mean each "event" will have to reside singularly in a lua file. While I could also embed the actual function, or a function name, I have not yet figured out how to call a function from a text string. However, the dofile statement accepts a text string file name, making events still "programmable" from data loaded from a .csv file.

I hope that doesn't sound too confusing. I've not actually yet implemented the 'event' code, mainly because most of the nodes I define use rather generic, modular functions, that accommodates my use cases. However, I am working on other mods, where this functionality will be more apparent.

I have intended to add farming, xocean, australia, and aoteara mods to lib_ecology, and have laid most of the groundwork for this already, in lib_materials. You'll see, in the most recent update, that aoteara, australia, and farming nodes are already included across the two mods.

Re: [Mod] lib_materials [lib_materials][git]

Posted: Thu Oct 31, 2019 16:13
by kestral

An update on my voronoi biome experiments.

I did upload my voronoi_biome_patch. I'd like to get it to read the minetest.conf, but I haven't been successful so far. Right now any changes require editing the source code and recompiling.

I also uploaded my display_biome mod. This gives a HUD that displays temperature, humidity, and biome name (using text though rather than gages).

Re: [Mod] lib_materials [lib_materials][git]

Posted: Sun Nov 03, 2019 17:09
by Red_King_Cyclops
I found some slime liquids in a mod called underch: viewtopic.php?f=11&t=20384

Re: [Mod] lib_materials [lib_materials][git]

Posted: Tue Feb 18, 2020 20:08
by twoelk
crashes with Minipeli
some hidden dependency?

Re: [Mod] lib_materials [lib_materials][git]

Posted: Thu Feb 20, 2020 20:32
by ShadMOrdre

It would be helpful if you provided more info. paramat's very new minipelli minimal game might be missing something also. There can be no expectation that an older published mod that works, is compatible with a game that was just released in the last few days.

Having said that, what, specifically is happening? Does it crash out? Or do the biomes not show? If crashing, please provide the debug.txt output, and if missing biomes, ensure that minipelli isn't clearing biomes.

Please let me know, since lib_mat / lib_eco, with most of the content of minipelli and modified by me, are essentially what I am currently using.

I resorted, long ago, to what I believe is burlis' discection of default, into player_api, gui, hands, and other mods, just as what minipelli seems to now be doing.


Re: [Mod] lib_materials [lib_materials][git]

Posted: Sun Apr 19, 2020 00:57
by pilcrow
I tried with Minipeli too, and it's a confusing issue. The server segfaults shortly after a player joins, with no error messages before-hand or any notable information in debug.txt; the last entry is "Pilcrow [] joins game. List of players: Pilcrow" followed immediately by a segmentation fault.

I'm running Minetest 5.2.0 stable, compiled from source. Minipeli (unmodified) works flawlessly by iteself, but adding just lib_materials (also unmodified) into the 'mods' folder and configuring a brand new world to use it causes the segfault (which only happens after a player joins -- the server seems to run perfectly fine with no players). Looks like it happens after the first chunk is generated, at least; when I log in I can see lib_materials:dirt_permafrost_with_snow, some water, and various rocks around me before the client times out.

Note that I'm running the server and client separately for testing purposes, and using "Minipeli" as the seed. I can provide more information (irrlicht version, my OS, system specs, etc) if needed.

EDIT: Looks like the behavior is identical when using MiniBASE as well.

EDIT2: Looks like lib_materials does work fine with Minetest Game, though I notice that there's not actually very many lib_materials nodes in the environment; the stone is lib_materials:stone, but the surface nodes are default:dirt_with_grass, default:sand, etc.

Re: [Mod] lib_materials [lib_materials][git]

Posted: Sat Nov 14, 2020 04:23
by TheFourthPlace

Re: [Mod] lib_materials [lib_materials][git]

Posted: Fri Nov 20, 2020 21:09
by ShadMOrdre
Updated for efficiency. Includes minimal new content.