FOSS gamedev and creative worlds

This will be merged upstream in the near future (days or weeks): http://c55.me/minetest/wiki/doku.php?id=changes:itemdef

It will break some of the mods and you might want to make an upgraded version of your mod beforehand so that it will be available when people need it.

:D thank you for fixing the hand and glass! that was my pet peeve :P

You mean all registers in the mods will need to be changed to the new format? If so, I'll start adapting mine tomorrow :)

I should note that I don't have time to do anything of the sort, and add_tool will probably need updating. Anyone is free to do so, or wait for me to get around to it in a month or so.

Hey, here's something that i would like to see and i'm sure that many other people would:
A keyboard shortcut when collecting itens you've made in your inventory. EX:
| = 99 stick

| |
| = 99 ladders
| |

This would give me 99 ladders right? But the problem is, that you have to click twice to get one ladder. So, if i'm right, 99x2 = 198. This are 198 clicks for 99 ladders (when not lagged). Now, think with me, i need to use 5x99 sticks to get 99 ladders. Considering that you need 25 wood to get 99 sticks, you need 125 woods to get all the sticks. 125x2 = 250. This give me a total of 448 clicks for 99 ladders (again, when not lagged). Please consider doing a keyboard shortcut to get all the makeable itens you're doing. If this would possible, to make 99 ladders i would need only 5 clicks to make the sticks (99 sticks per block ) and 1 click to make 99 ladders!
What i mean to a keyboard shortcut, is like pressing shift then click. Think about it ;D

P.S I know that this is not the ladder recipe, for ladder would be even more clicks. Is just an example.

rahonejm wrote:Hey, here's something that i would like to see and i'm sure that many other people would:

Please don't post this in the mods forum, it should go in the General Discussion. Especially not in this topic.

MarkTraceur wrote:

rahonejm wrote:Hey, here's something that i would like to see and i'm sure that many other people would:

Please don't post this in the mods forum, it should go in the General Discussion. Especially not in this topic.

Well, sorry about that, but this topic doesn't addresses only changes on modding so i tought that would be appropriate.

I've noticed that furnace_burntime is deprecated and I should use new craft syntax. Formerly I used this parameter to check material flammability in my fire mod. How can I check it now?

neko259 wrote:I've noticed that furnace_burntime is deprecated and I should use new craft syntax. Formerly I used this parameter to check material flammability in my fire mod. How can I check it now?

Shortcomings

It's currently not possible to retrieve the result of a crafting operation from Lua. ...

Fuel soon be craft, seems no way(((

You can now use all fields allowed in item definitions.

Maybe I can use material.flammability for nodes from now?

neko259 wrote:

You can now use all fields allowed in item definitions.

Maybe I can use material.flammability for nodes from now?

Most people use the "minetest.digprop_woodlike()" like functions that are defined in "data/builtin.lua" and none of those set "material.flammability" even in this patch.

I noticed that in the new defualt/init.lua file has the old style in node dug_item file. Is this still right?:

@MarkTraceur
I might do it on the weekend if noone else did it by then.

@neko259
I don't know. Maybe once the furnace is completely redone in Lua, the cooking and fuel business will be moved again, possibly with registration functions implemented in Lua. Maybe a field material.flammability could indeed be added instead of fuel recipes, although that would mean if a mod wants to add flammability to an item defined by a different mod, it would have to redefine the whole item, but anyway doing so is not as useful as adding cooking recipes to existing items. I don't really have time to think about this stuff now :/

@randomproof
Thanks, didn't spot that. The documentation at the top is outdated in that respect too. It works because the old format is still supported (for compatibility with old maps), but it should be changed.

Will we somewhen be able to create our "crafting tables"? (like minecraft or "chemistry table", for example)? I think, for implementing this in current script api it needs at least callbacks like on_put_item/on_take_item (that could return true if everything OK or false if player can't take/put this => locked chests functionlity. This callbacks should work for every inventory in our chest/node - for example, some inventories can be "read only", some - fully accessible) and inventory preview support (currently we cannot determine from player's craftresult if it is preview or not).

I love the new documentation :)

Very useful since I couldn't find descriptions for a lot of parameters before.

Great work and keep it up!

This is going upstream today in some hours from now.

Check out the latest API changes in the wiki (there have been some since the first post in this thread).

Needs to be changed to

Otherwise it doesn't work.

@neko259
Indeed, thanks. Fixed.

How can I check node flammability now? furnace_burntime is deprecated, and material.flammability is inaccessible.

@nekoi259

This might take a while, sorry! First of all, flammability of nodes in the world should be unrelated to how long they burn in the furnace (e.g. mese burns very well in the furnace, but you might not want it to catch fire in the world so easily, that might be devastating). celeron55 and I have been talking about building nodes out of material components, one of those components would be "flammable". These components are basically nothing different than custom fields in node definitions, but with a (hopefully) well understood way how they interact with other nodes and material components and items. For example, digging duration and tool wear would be decided by the tool based on the material components that a node has. Obviously nothing of this is near any kind of implementation yet. If you want, you can read the discussion on IRC about this stuff.

For now the best way is probably to check material.cuttability and material.weight. Of course this is far from ideal.

For now the best way is probably to check material.cuttability and material.weight. Of course this is far from ideal.

How does weight show if the node is flammable?

Hmm. Using cuttability works. I wish API to be much more descriptive and have comments for every parameter :)

I meant using weight to determine how long a node burns, and cuttability to determine how easily fire spreads to it.

Weight doesn't show if the node flammable or not (like stone for example). For now I use cuttability, but I'll try to change it and make more realistic.

kahrl,
since your update the inventory images of node-like items that don't have their inventory_image explicitly set to minetest.inventory_cube(...) or something else are not shown on my system that doesn't support render-to-target.

Slightly further investigation has shown that the "if(rtt == NULL)" block isn't reached for these items (generate_image probably isn't even called).

Thanks --jn

Hmm. How were they shown before (or are with inventorycube) if render-to-target isn't supported?

EDIT: Oh, I see, it just rendered the texture of one side. I guess something similar should be done at itemdef.cpp:420.

Maybe updateTexturesAndMeshes could call generate_image with the right options / texture name. (just speculating)

EDIT: btw, you can simulate rtt inavailability by changing line 423 of mesh.cpp.

This works (after the call to generateTextureFromMesh)

I noticed that chests with stuff in them disappear in the client if they are dug. They stay in the server but not in the client.

@randomproof: I have a fix (or workaround) here.