[Mod] lib_materials [lib_materials][git]

ThorfinnS
Member
 
Posts: 188
Joined: Mon Feb 25, 2019 22:05
GitHub: ThorfinnS

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

by ThorfinnS » Sat Oct 05, 2019 22:24

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.
Exactly.

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.

Thanks!

--Steph
 

ThorfinnS
Member
 
Posts: 188
Joined: Mon Feb 25, 2019 22:05
GitHub: ThorfinnS

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

by ThorfinnS » Sun Oct 06, 2019 03:17

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.
 

ThorfinnS
Member
 
Posts: 188
Joined: Mon Feb 25, 2019 22:05
GitHub: ThorfinnS

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

by ThorfinnS » Tue Oct 08, 2019 15:39

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.
 

ShadMOrdre
Member
 
Posts: 534
Joined: Mon Dec 29, 2014 08:07
Location: USA
GitHub: ShadMOrdre
In-game: shadmordre

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

by ShadMOrdre » Tue Oct 08, 2019 16:36

ThorfinnS,

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.


Shad
MY MODS: lib_ecology lib_materials lib_clouds lib_node_shapes ---- Inspired By: Open Source Virtual World Simulator Opensimulator.
 

ThorfinnS
Member
 
Posts: 188
Joined: Mon Feb 25, 2019 22:05
GitHub: ThorfinnS

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

by ThorfinnS » Tue Oct 08, 2019 18:43

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.

[EDIT]
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.
[/EDIT]

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.

[EDIT2]
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..
[/EDIT2]

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.
 

Red_King_Cyclops
Member
 
Posts: 269
Joined: Sun Jun 16, 2019 20:17
Location: Earth

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

by Red_King_Cyclops » Wed Oct 09, 2019 23:02

ShadMOrdre,
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)
My best mods: space_travel, time_travel, and rocket.
 

ShadMOrdre
Member
 
Posts: 534
Joined: Mon Dec 29, 2014 08:07
Location: USA
GitHub: ShadMOrdre
In-game: shadmordre

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

by ShadMOrdre » Sun Oct 13, 2019 07:25

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

ThorfinnS,

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.



Red-King_Cyclops,

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.
MY MODS: lib_ecology lib_materials lib_clouds lib_node_shapes ---- Inspired By: Open Source Virtual World Simulator Opensimulator.
 

ThorfinnS
Member
 
Posts: 188
Joined: Mon Feb 25, 2019 22:05
GitHub: ThorfinnS

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

by ThorfinnS » Fri Oct 25, 2019 15:34

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.
 

ShadMOrdre
Member
 
Posts: 534
Joined: Mon Dec 29, 2014 08:07
Location: USA
GitHub: ShadMOrdre
In-game: shadmordre

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

by ShadMOrdre » Sat Oct 26, 2019 04:59

ThorfinnS,

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.
MY MODS: lib_ecology lib_materials lib_clouds lib_node_shapes ---- Inspired By: Open Source Virtual World Simulator Opensimulator.
 

kestral
Member
 
Posts: 63
Joined: Mon Mar 27, 2017 21:56
GitHub: kestral246

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

by kestral » Thu Oct 31, 2019 16:13

Shad,

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.
https://github.com/kestral246/voronoi_biome_patch

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

Red_King_Cyclops
Member
 
Posts: 269
Joined: Sun Jun 16, 2019 20:17
Location: Earth
 

Previous

Return to WIP Mods



Who is online

Users browsing this forum: Norore and 5 guests