[gd2shoe]

I’m sorry, but I’m having trouble parsing.

I’m not familiar with the unicode bugs, but no, it isn’t.

Isn’t what? Isn’t a unicode bug? Isn’t incomplete unicode support in Minetest? Isn’t something else?

• Your description seems like a bug in unicode support. At best, the font doesn’t support unicode. At worst, there’s a lack of unicode support in the server or render client.
• A search for “unicode” at contentdb currently shows 2 mods, both uploaded or updated recently. Both of them use tga_encoder to push a texture to the client. This doesn’t sound like Minetest unicode support to me, but a workaround.
• You seem to know how to change fonts in Minetest in a mod, and that has me curious. The api seems to only accept ‘normal’ and ‘mono’. It looks like a game might be able to ship with a replacement font and reference it in minetest.conf, but I haven’t played with this. BEWARE font licenses!

Beside, coffeeScryer did the same thing as i did but the words were displayed correctly.

I’m not familiar with whatever coffeeScryer may have done, and I don’t see it after a few searches. I’m not sure what you’re referring to, and I can’t compare yours and his to see what’s different.

To address your initial questions directly:

• “Should san-serif be added?” — Purely a matter of opinion. I say yes, but have no strong feelings. At low res, I think sans-serif is generally better.
• “Should the unicode character set be supported?” — If you feel like dedicating the effort to it. I think it would be better to insist that the Minetest platform adopt unicode support. This is under my belief that it doesn’t. I’d be happy to be wrong about this.
• “Should the standard colors be supported?” — Yes. Aren’t they? I haven’t compared terminal colors to the colors offered by Minetest, but text coloring is one of the things that the engine and rederer do support. Of course, if you go the tga_encoder route, then you’ll either be at the mercy of the encoder, or you’ll need to inject color yourself (before or after the encode phase).
• “Should the encoding of content be UTF-8?” — Preferably, yes. It’s the most common unicode encoding, and English is normally searchable even if it’s being read by a program that only understands ASCII. Any unicode text editor that can’t deal with UTF-8 is sorely lacking. (UTF-16 is annoying, and I’ve never seen UTF-32 in the wild.)

[gd2shoe]

For maximum effect, empty out anything you have in your voidchest, log out, and back in again.  Things stuck in the old namespace will only move during log-in, and only if there’s room for them.  Anything not moved in the first log-in will stick around, so don’t panic if you’ve already recovered part of what you had.

My turn to be crass.  I’m actually looking forward to new bug submissions.  (Please don’t throw things at me!)

[gd2shoe]

Are they still having issues with unicode?

Is unicode desirable?  Yes.  Should you put in the effort to design a weird gimmicky texture hack to get around unicode bugs?  I don’t think so.

[gd2shoe]

Eww.  There might actually be a fair bit of work related to this.  It looks to me like most damage dealt by mods don’t register a reason.  I’m confronting this indirectly at the moment with bees.  For the time being, bees are also going to damage armor. ☹️

There should probably be an ‘ignore_armor’ field recognized by 3d armor.  Getting 3d armor to recognize it will be trivial, but finding all the many places where damage is dealt and adding appropriate flags may be a real bear.

[gd2shoe]

Status update and some questions

———————————————————————

I’ve got the proposed recipes working.  I think I’ve got listring (shift-click) working properly.  I’ve fixed 2 preexisting bugs, and found 2 spots that are probably also bugs.

I need to draw a texture for wax in water… unless someone volunteers.  I still have to update pipeworks support (didn’t know it was in there).  I need to write LBMs to update any worlds loaded with the new mod so that they’ll play nice (new node inventory structure).

I would like to implement swarming and hive splitting, but that’s going to need to be a whole project on its own.  I note that bees help flowers grow, but do nothing for crop yields.  That might be something to look into.

———————————————————————

Question 1

How expensive should wax rendering be (boiling wax)?  I currently have it set to 10 seconds, which is more than most recipes.  The real process takes hours, but so do a lot of the things that a furnace will spit out in seconds.  For reference, 10 seconds cost fuel to the tune of 1 charcoal, 1/4 coal lump, or about 1/2 a log of tree (depending on the tree).  I think most recipes take 3 seconds.

Question 2

The bees mod uses very small stacks comparatively.  I’ve already increased the queen bee stack size from 1 to 8, which is still irrationally small.  Bottles of honey are limited to 12, while juice bottles go to 99 (same bottle).  Frames are limited to 12 full or 24 empty.  Comparing these to stone, that suggests either that frames have a volume of 4 cubic meters, or weigh 13 metric tons apiece.  Absurd.

I’m inclined to lift the stack size restrictions.  There can still be a limit to the number of frames inserted into an extractor, if desired.  But what does everyone else think?  I don’t see any good reason for the current state, and I don’t think it’s a game balance issue, but I don’t want to just assume there is no reason at all.

[gd2shoe]

Not a thorough analysis by any stretch of the imagination, but I have a working hypothesis about the armor bit.

It looks like 3d armor checks the reason for the HP change before deciding how to intervene.  If reason.type is “drown” or reason.hunger exists, then it skips the rest of the callback.

hbhunger, on the other hand, calls player:set_hp without passing a reason.  It’s not mandatory for the minetest engine, but if it doesn’t give a reason, then other mods (like 3d armor) can’t react appropriately.

[gd2shoe]

I think the default blueberries (by whatever name) do provide an interesting change to other crops.  I like to plant a few in hedge rows.  Harvesting them is a pleasant change of pace from soil based crops.  My opinion, it’s just the name conflict that’s at issue.  Though I would be potentially interested in another hedge based fruit or two.  I’m guessing it wouldn’t be hard.

It does seem that far too many crop foods pop up on the same biomes, though.  Typically, you find grassland with one food crop, and you have most of them, along with most farm animals.  It seems unbalanced strongly in favor of players spawned in this biome, and strongly biased against players spawned elsewhere.

There are a few other name conflicts I’ve encountered.  “Fiber” is a big one.  It’s intrinsic in a system of haphazard modification.  But it would help game cohesion to polish some of the rough edges.

[gd2shoe]

I don’t have any hands-on experience with bees.  I know more about the topic than I have any reason to, but I’m certainly no expert.

The above recipes should be a piece of cake.  That doesn’t mean that they will be, per se.  I think it’s just a matter of fixing the names, inserting the recipes, and testing the thing.

I will probably go back to tinkering with bees soon then.  I was trying to get listring (shift-click) working, and it was proving to require a more extensive alteration than I anticipated.  That, frankly, should be seen as mandatory for nodes that require semi-frequent removal and insertion of items.  I’ve got it most of the way, but I want to make sure I’m not introducing new bugs before submitting it.

(I hate making code uglier in order to make it functional, but the api leaves me no choice.  It’s a limitation of listring.  I don’t understand why this is in the formspec and not handled as an action.  The render client doesn’t need to know where items are going; the server has to move the items anyway; and there’d be more flexibility if handling the shift-click event it was taken out of the DDL and moved into a callback.  [end rant])

I’m OK with candles burning out, but they should also offer something more unique than torches if they are to be included. I haven’t figured this one out.

Touché.  Near as I can tell, candles are currently very expensive torches that don’t burn out.  All I’m really proposing to do is make them somewhat less expensive (but still much more costly than torches), and make them accessible earlier in the game.  I agree with your sentiment, but I don’t have a good answer yet, either.

Oh, and bottles of honey crunch when you eat them.  Enjoy…  😆

[gd2shoe]

(removed)

[gd2shoe]

I’m long overdue to play with magic stuff.  I’m pretty sure that’s mana.

[gd2shoe]

Hey, you got desert!  I usually get tundra.

The game tends to be sparse on mobs the first night, especially if you keep moving.  tends to be…

You should be able to find villages.  They’re easier to see at night (except in the desert?)  You’ve probably walked past half a dozen of them or more without realizing it.

I play singleplayer (I add and remove mods as I please).  And the more I play, the more I realize MeseCraft is intended for multiplayer servers.  If you find you can’t enjoy singleplayer, you might want to check out the servers.

(I find that early game MeseCraft is probably harder than it ought to be.  IMO)

[gd2shoe]

I realize I’m resurrecting’s an old thread, but adolfo brought up an interesting point that I agree with.  Beekeeping shouldn’t just be for mid game and later.  Beekeeping was a low-tech artform for millennia before electricity was invented.  Honey extractors are a very recent invention.  But basic beehive tech is fundamentally low tech.  It also helps address the lighting issue.

The empty frames displayed are “foundationless frames”.  This makes good sense, but it also indicates that these frames are designed for low-tech, artisanal use, not high tech honey extractors.  Even with a dull wooden knife, you can easily cut the honeycomb off of the frame.  And wax is typically made (artisanally) by rendering it — aka, boiling comb in water.  Honey can be extracted by pressing and filtering through a cloth.

I think that the honey extractor should be the easiest and fastest way to extract honey and wax.  I don’t think it should be cut from the game.  But I do think that other recipes for wax and honeycomb should be included.  I would propose something akin to:

(Please note that I have not verified item names.  I’m guessing wildly; they’re definitely wrong.  Syntax typos likely.)

• Recipe for honeycomb:
  full frame ==> empty frame + honey comb
  { type = “shapeless”, output = “bees:comb”, recipe = { “bees:full_frame”, },replacements = {“bees:full_frame”, “bees:empty_frame”}, }
• Recipes for wax:
  water bucket + honey comb ==> wax in water
  wax in water -> in a furnace ==> wax + empty bucket
  { type = “shapeless”, output = “bees:wax_in_water”, recipe = { “default:water_bucket”, “bees:comb”, }}
  { type = “cooking”, output = “bees:wax”, recipe = “bees:wax_in_water”, cooktime = 15.0, replacements = {“bees:wax_in_water”, “default:empty_bucket”}}
• (I’m not including a recipe for honey from a juice press because I haven’t looked into the juice press yet… and I suspect that might be a bit of a headache to implement or maintain.)

This should be easy enough to use to provide some early wax, but finicky enough to encourage players to invest in an extractor, or look to other sources of lighting.

If there’s any interest, I may tinker with this at some point.  I haven’t written any replacement style recipes yet, so I don’t know where the pitfalls are.  But the API document indicates that you can do replacements when cooking… so… if furnaces support the feature, it should work. [fingers crossed]

Also, candles should burn out.  I personally don’t like the idea.  I don’t like that torches burn out… or that they burn out so fast.  But if torches do, then candles should too.  Candles seem expensive (2 wax+cotton), Maybe candles should last longer than torches?  Or you should get more of them per recipe?  [shrug]

[gd2shoe]

Ok, I’ve submitted a pull request.  Fingers crossed.  Let’s see what the dev team does with it.  Several unrelated bugs that keep the unstable branch from running, a fix for pre-existing buggy chests…  It’s been a bit of a journey.  I stuck to mostly bronze and steel stuff, seeds, with a few goodies thrown in.  No Mese, no magic materials.  You can find rare lightposts in ruins on the surface, for example, so I don’t feel bad about that.

Numbers are maximums.  The average will be about half that.  Average 16 item stacks.  I expect someone will pare this back a bit before it gets merged in.  The goal is to get players to hesitate before skipping past Geomoria.  Chests in Geomoria aren’t that common, though there are hidden chests if you already know where to look.

loot_table = {
{“default:coal_lump”, 40},
{“default:stick”, 99},
{“default:torch”, 90},
{“candles:candle”, 5},
{“pigiron:iron_ingot”, 12},
{“default:steel_ingot”, 8},
{“default:copper_ingot”, 16},
{“default:tin_ingot”, 16},
{“default:bronze_ingot”, 14},
{“moreores:silver_ingot”, 6},
{“default:gold_ingot”, 2},
{“default:mese_post_light”, 2},
{“df_trees:goblin_cap_wood_mese_light”, 2},
{“moreblocks:glow_glass”, 1},
{“death_compass:inactive”, 2},
{“bees:grafting_tool”},
{“bees:bottle_honey”, 1},
{“bees:wax”, 10},
{“farming:seed_barley”, 10},
{“farming:seed_cotton”, 10},
{“farming:seed_mint”, 10},
{“farming:seed_oat”, 10},
{“farming:seed_rice”, 10},
{“farming:seed_rye”, 10},
{“farming:seed_wheat”, 10},
{“farming:string”, 6},
{“fire:flint_and_steel”},
{“bweapons_utility_pack:torch_bow”},
{“bweapons_bows_pack:arrow”, 50},
{“bweapons_bows_pack:bolt”, 50},
{“bweapons_bows_pack:crossbow”},
{“bweapons_bows_pack:wooden_bow”},
{“default:axe_bronze”},
{“default:axe_steel”},
{“default:pick_bronze”},
{“default:pick_steel”},
{“default:shovel_bronze”},
{“default:shovel_steel”},
{“default:sword_bronze”},
{“default:sword_steel”},
{“farming:hoe_bronze”},
{“farming:hoe_steel”},
{“moreores:axe_silver”},
{“moreores:hoe_silver”},
{“moreores:pick_silver”},
{“moreores:shovel_silver”},
{“moreores:sword_silver”},
{“3d_armor:boots_bronze”},
{“3d_armor:boots_steel”},
{“3d_armor:chestplate_bronze”},
{“3d_armor:chestplate_steel”},
{“3d_armor:helmet_bronze”},
{“3d_armor:helmet_steel”},
{“3d_armor:leggings_bronze”},
{“3d_armor:leggings_steel”},
{“mobs:horseshoe_bronze”},
{“mobs:horseshoe_steel”},
{“mobs:lasso”},
{“mobs:shears”},
{“shields:shield_bronze”},
{“shields:shield_steel”},
{“realcompass:0”},
{“ropes:wood1rope_block”, 2},
{“tnt:gunpowder”, 10},
{“vessels:glass_bottle”, 3},
{“vessels:glass_fragments”, 20},
{“thirsty:gold_canteen”},
{“thirsty:silver_canteen”},
}

[gd2shoe]

Anything I submit is going to need to get through the dev team.  lol

Here are my thoughts:  Why would a player even bother with Geomoria?  Why wander the corridors dodging arrows and fending off zombies?  Why not just keep digging?  The loot needs to be somewhat better than what the player could make on their own at this point, but not so good as to be game-breaking.  I’m still new enough to Minetest that I only have a vague idea what this might entail.  Not mese, but maybe the rare find of something made with mese shards?  Maybe an item or two that the player ought to have made, but might not have known about?

I have lootchests mostly working now.  I think loading up the loot table is the biggest remaining hurdle… before I start making pull requests.

[gd2shoe]

Found This: https://forum.minetest.net/viewtopic.php?p=262399#p262399

Short version, this was not considered a bug, and was never going to be fixed.  It was always the plan for someone else to replace chests with a loot container (like lootchest mod).  I’m guessing Mesecraft just hasn’t gotten around to integrating the two mods (alpha release, etc).

I say that it still is a bug, if anyone ever forks and expands this project.  If any future “plans” involve nodes with constructors, those constructors need to be called.  If Mesecraft intends to keep Geomoria, I’m guessing the mod will eventually be customized.  (The fountains really don’t work with dynamic liquid…)

Trying to work out now how to get lootchests to fill Geomoria.  I suspect it’s going to be straightforward.  The hard part is going to be: Filled with what?  (game balance is a can of worms)

[gd2shoe]

Breakthrough.  I have a partial fix.  It’s ugly as sin.  It needs to be formatted and subjected to code review.

Fundamentally, I’m using __index and __newindex to intercept all access to the data table except when the vm is directly involved.  (I’m letting it have the raw, underlying table for performance and for predictable behavior.)  Any node getting set that has a constructor gets thrown into a queue.  Constructors are called after the changes are committed to the map.  This should broadly fix all constructor issues, should any other nodes require it.

The problem that remains: The chests are no longer buggy… but they are still empty.  I’m guessing that there’s some sort of lootchest mod registration that needs to take place?  Maybe this is an area that just hasn’t been worked on at all?

Apparently the door thing is a different, unrelated issue.  plans.lua uses ‘doors:door_steel_a’ all the time, when half the time it should be using ‘doors:door_steel_b’.  Fixing that is going to be… bothersome.  It should be fixed, but I’m not sure how without accidentally getting ‘a’ and ‘b’ mixed up half the time.  (How did this happen in the first place?)

[gd2shoe]

Relatively minor, possibly related issue:

Double doors aren’t paired properly.  You know how if you put down two doors, and you put the left door down first, the right door automatically puts its hinge on the right, away from it’s partner?  Yeah.  Geomoria doesn’t do that.  One of the doors always has a hinge in the middle.

This one isn’t a big deal in terms of gameplay, but it comes across to the player as sloppy.  I’m guessing it’s the same issue.  The door constructor isn’t getting called, and the doors are just defaulting to one hinge orientation.

(I’ve placed several dozen doors now, looking at different combinations.  It looks like the door, when placed, blindly looks to the node on its left, sees if it’s a door, and orients its hinge accordingly.)

[gd2shoe]

Suspicions partially confirmed…

I started a new game in vanilla minetest with geomoria and moreblocks copied from Mesecraft.  The chests here are bugged (no inventory slots, just grey area).

debug.txt
2023-09-05 16:48:45: WARNING[Main]: GUIInventoryList::draw(): The inventory location “nodemeta:-1038,-171,-534” doesn’t exist

[gd2shoe]

Where I’m at so far…

I think the problem is the Geomoria mod, as included in Mesecraft.  I’m not 100% positive, but I think it’s creating chests using a voxel manipulator without calling the chest constructor.  This leaves the node without associated inventory meta data.  I have no idea what code is supposed to fill the chest with loot, but I suspect that it chokes on the missing inventory meta.  Perhaps that code (if I can find it) could also use a patch (might be the simpler fix, actually).

(I’m not playing on a “potato”, but not that far off.  If I’m wrong about the cause of the bug, it could be some race condition brought about by limited RAM or the speed of my aging processor.)

Notes:

“The purpose of [VoxelManip] is for fast, low-level, bulk access to reading and writing Map content. As such, setting map nodes through VoxelManip will lack many of the higher level features and concepts you may be used to with other methods of setting nodes. For example, nodes will not have their construction and destruction callbacks run, and no rollback information is logged.”
From the intro at — https://minetest.gitlab.io/minetest/lua-voxel-manipulator/

• init.lua:33 – defines local treasure_chest = ‘default:chest’
• plans.lua defines geomoria_mod.plans which specifies where “treasure” might be located
• mapgen.lua:63 creates local vm, emin, emax = minetest.get_mapgen_object(“voxelmanip”)
• mapgen.lua:71 creates local area = VoxelArea:new({MinEdge = emin, MaxEdge = emax})
• mapgen.lua:128 calls geomorph, which reads and implements the plans.  It passes area as a parameter, along with a table named data.
  local write, wetness = geomoria_mod.geomorph(minp, maxp, data, p2data, area, node, heightmap)
• geomorph.lua:221 Decides randomly whether to create treasure, based on the value in the plan
• geomorph.lua:225 Takes a detour back to init.lua for geomoria_mod.treasure_chest_hook(…) — this should be a no-op, but might get froggy if another mod uses this hook.  I don’t think so.  A search doesn’t show any other references to it in the mesecraft folder.
• geomorph.lua:228 records an area:index in the table named data (created in mapgen.lua) pointing to the content id of treasure_chest (aka default:chest; see mapgen.lua:29-38 for “node”)
• mapgen.lua:188 writes changes from data to the vm– vm:set_data(data)

I’m speculating that stepping through the data table after mapgen.lua:188 looking for chests and calling  the constructor might solve this.  minetest.registered_nodes[“default:chest”].on_construct(pos)

On second thought, the call to geomorph could carry another table with locations of nodes that need their constructors called.  That might provide solutions to other node types besides chests if further bugs are found, and would be a lot more efficient than iterating through the entirety of the data table looking for the odd chest here or there.

Continuing my exploration…

[Author]

Posts