FOSS gamedev and creative worlds

First of all: Yes, I understand why 32766/32768 is a "special" or "round" number. I also understand why it's not 65536 (unknown nodes).

Now, as far as my question... I'm currently working with some people on a mod that has a bunch of nodes. Several of the nodes it adds can also have markings placed on top which become part of the node. All of those, including ones with markings, can be cut with the moreblocks circular saw, which offers 45 shapes per node. This currently adds up to 20836 nodes in total, not leaving much for other mods.

So...

• How much of a pain in the a** would it be to increase the limit?
• If it's not so bad, are there plans to possibly do so?
• If it would be a pain to do, why?

cheapie wrote:How much of a pain in the a** would it be to increase the limit?

1:Ahem!Even if you are angry to tell things like that, childs are watching :\
2:32768 that already great!Ya don't think?
3:it might be planned but for now try to have less nodes... You've got a lot of them!
[around 730 nodes that can be cut!]

As far as i can remember it used to be lower, that number was chosen as being 'more than enough' even for VanessaE's mods and subgames. I think it's enough and already overkill, see it as a friendly suggestion you're overdoing things.

IMO this excessive amount of nodes wouldn't be required if there was a possibility to swap node textures. Many mods have to register new nodes because of 3 differently colored pixels in a texture...

webdesigner97 wrote:IMO this excessive amount of nodes wouldn't be required if there was a possibility to swap node textures. Many mods have to register new nodes because of 3 differently colored pixels in a texture...

I've tried suggesting this to the engine devs before, but even though this would make this only need ~90 nodes for the mentioned part instead of ~20000, nobody seems interested.

Wow, any server that registers so many nodes is gonna use a LOT of memory...

In a perfect world, there would be a way to dynamically render nodes, Registering entities may help you cut down on the number of nodes. 20000 nodes purely for decoration purposes is way too many.

This signs mod uses entities to display text:
https://github.com/PilzAdam/signs

Perhaps a similar technique could be used for the sawed blocks, with appropriate changes to the moreblocks code. I'm not sure what sort of limit Minetest imposes on the number of registered entities.

I just checked my world with dreambuilder and some other mods, and it has 17544 nodes. Most of it comes from stairsplus.

Using entities to simulate nodes would probably be too much... not to mention that they may disappear / pop-up spontaneously, since entities are only loaded when really needed.

Maybe a new param2type could be added to store the index of the mesh/texture to use from an array in the nodedef. That way a node can provide a list of mesh/texture combinations it can have as part of the same node and the client will know which one to use based on param2.

The problem with this is that it wouldn't allow the use of param2 as facedir or wallmounted at the same time, and you still have a limit in how big that array can be.

But with that many nodes for a single mod, you might have to see if you are doing things wrong... are you properly taking advantage of facedir? maybe some of your nodes are symmetrical. What about the new connected-nodebox api? maybe you can take advantage of it too.

Ferk wrote:Using entities to simulate nodes would probably be too much... not to mention that they may disappear / pop-up spontaneously, since entities are only loaded when really needed.

Maybe a new param2type could be added to store the index of the mesh/texture to use from an array in the nodedef. That way a node can provide a list of mesh/texture combinations it can have as part of the same node and the client will know which one to use based on param2.

The problem with this is that it wouldn't allow the use of param2 as facedir or wallmounted at the same time, and you still have a limit in how big that array can be.

But with that many nodes for a single mod, you might have to see if you are doing things wrong... are you properly taking advantage of facedir? maybe some of your nodes are symmetrical. What about the new connected-nodebox api? maybe you can take advantage of it too.

I am not so familiar with the engine, but maybe it would be possible to add a param3 (also for random textures)?

I think it should be really ∞.
But I up vote it be higher. Through RAM might be higher and, GPU for processing all them nodes.

Changing this value would be difficult and could cause compatibility problems. In the map.sqlite, data are written node per node. Every node is encoded by 32 bits : 8 for param1 (light), 8 for param2, 15 for node ID, and I suppose the latest is used for something else (could someone confirm this?). But changing this structure would be complicated and would increase the size of the file.

Registering entities to display nodes is extremely hacky. I'm strongly against using entities for anything that could be done another way (this makes me think that I would love to see the texts on signs managed by the core instead of using entities…)

What we need is a way to store additional data in nodes, for example unused bits of param2 could be used to select the texture inside a list.

What we need is a way to store additional data in nodes, for example unused bits of param2 could be used to select the texture inside a list.

While selectable textures at runtime is a great idea, I was thinking more on the lines of a mod using the already-existing node metadata to store information about the node, have Minetest provide a Lua functions for rendering textures and polygons, and then have Minetest cache the resulting rendered thing until a render update is requested.

Ideally a task like this ought to be done client-side, but that's not trivial.

I'm sorry but I've not completely understood. Do you mean storing the nodebox data in a special field in node metadata? I've already proposed it some months ago, it seems that this topic has been forgotten.

Gael de Sailly wrote:I'm sorry but I've not completely understood. Do you mean storing the nodebox data in a special field in node metadata? I've already proposed it some months ago, it seems that this topic has been forgotten.

I'm talking about this metadata:
http://dev.minetest.net/NodeMetaRef