Alternative approach to unknown nodes. #1

New Issue

kabou · 2022-03-12T17:52:38+01:00

kabou commented

2022-03-12 17:52:38 +01:00

In https://git.minetest.land/MineClone2/mcl_devtest/src/branch/master/unknower/init.lua a random node is registered that has a 64999 in 65000 chance to become an unknown node upon the next game restart.

Instead, why not set a single designated unknown node name, and after registration set its definitions table to nil like so:

minetest.register_node("devtest:unknown", { defs })
minetest.registered_nodes("devtest:unknown") = nil

With this approach:

the "unknown" node is always known by a specific name;
it becomes available immediately, without needing a restart;
there is no uncertainty about the 1 in 65000 chance.

In https://git.minetest.land/MineClone2/mcl_devtest/src/branch/master/unknower/init.lua a random node is registered that has a 64999 in 65000 chance to become an unknown node upon the next game restart. Instead, why not set a single designated unknown node name, and after registration set its definitions table to `nil` like so: ``` minetest.register_node("devtest:unknown", { defs }) minetest.registered_nodes("devtest:unknown") = nil ``` With this approach: * the "unknown" node is always known by a specific name; * it becomes available immediately, without needing a restart; * there is no uncertainty about the 1 in 65000 chance.

cora commented

2022-03-12 18:21:34 +01:00

With this approach:

the "unknown" node is always known by a specific name;

it becomes available immediately, without needing a restart;

there is no uncertainty about the 1 in 65000 chance.

How are you planning to place that node?

The purpose of this mod is to make it easier to place unknown nodes in the map. If you immediately unregister it it will not be available for placing.

Now I have thought about if it's possible to do this live i.e. set the node name, place then unregister it but that wouldn't exactly recreate the situation it's supposed to test (if it even works).

> With this approach: > * the "unknown" node is always known by a specific name; > * it becomes available immediately, without needing a restart; > * there is no uncertainty about the 1 in 65000 chance. How are you planning to place that node? The purpose of this mod is to make it easier to place unknown nodes in the map. If you immediately unregister it it will not be available for placing. Now I have thought about if it's possible to do this live i.e. set the node name, place then unregister it but that wouldn't exactly recreate the situation it's supposed to test (if it even works).

cora commented

2022-03-12 18:22:45 +01:00

Another way might be to write unknown node data to world db by means of voxelmanipulators - haven't tried that yet at all.

Another way *might* be to write unknown node data to world db by means of voxelmanipulators - haven't tried that yet at all.

cora commented

2022-03-12 18:23:44 +01:00

But again the situation this is supposed to test is preexisting unknown nodes. (i.e. cause a mod was removed or world was ported from other mcl variants) Placing them live into a loaded world might have other consequences idk.

But again the situation this is supposed to test is *preexisting* unknown nodes. (i.e. cause a mod was removed or world was ported from other mcl variants) Placing them live into a loaded world might have other consequences idk.

cora commented

2022-03-12 18:25:58 +01:00

the uncertainty can maybe be removed by seeding random with the old value lol.

cora commented

2022-03-12 18:37:32 +01:00

quicktesting it suggests instantly deregistering a just placed node leads to crash.

kabou commented

2022-03-12 18:42:42 +01:00

I had not actually tested anything before making the above suggestion.

Interesting that it crashes. How and where does it crash?

I had not actually tested anything before making the above suggestion. Interesting that it crashes. How and where does it crash?

cora commented

2022-03-12 19:36:13 +01:00

in builtin .. not in mcl didnt investigate where exactly. p sure this is expected behavior.

Actually it might be that new node defintions are illegal at runtime? idk

in builtin .. not in mcl didnt investigate where exactly. p sure this is expected behavior. Actually it might be that new node defintions are illegal at runtime? idk

cora commented

2022-03-12 19:38:42 +01:00

yeah. it's register_node. deleting a node from the node defs has no immediate effect (placed node remains)

cora commented

2022-03-12 19:42:53 +01:00

registration functions can only be called at load time:

Registration functions

Call these functions only at load time!

Environment

minetest.register_node(name, node definition)

11f3f72f1c/doc/lua_api.txt (L4744)

registration functions can only be called at load time: > Registration functions > ---------------------- > > Call these functions only at load time! > > ### Environment > > * `minetest.register_node(name, node definition)` https://github.com/minetest/minetest/blob/11f3f72f1cfe8111574ee865829c380cd7fc7c30/doc/lua_api.txt#L4744

kabou commented

2022-03-12 20:02:14 +01:00

Indeed. Perhaps my initial suggestion to directly alter the registration table was a bit too crude. But there is also minetest.unregister_item(name):

* `minetest.unregister_item(name)`
    * Unregisters the item from the engine, and deletes the entry with key
      `name` from `minetest.registered_items` and from the associated item table
      according to its nature: `minetest.registered_nodes`, etc.

Does it still crash when you use that in place of directly setting nil in the table? It could be assigned to a chat command, like with the other functions.

Indeed. Perhaps my initial suggestion to directly alter the registration table was a bit too crude. But there is also `minetest.unregister_item(name)`: ``` * `minetest.unregister_item(name)` * Unregisters the item from the engine, and deletes the entry with key `name` from `minetest.registered_items` and from the associated item table according to its nature: `minetest.registered_nodes`, etc. ``` Does it still crash when you use that in place of directly setting `nil` in the table? It could be assigned to a chat command, like with the other functions.

cora commented

2022-03-13 03:31:14 +01:00

Does it still crash when you use that in place of directly setting nil in the table? It could be assigned to a chat command, like with the other functions.

Yes. It didnt crash when i set the registration to nil (didnt have an immediate effect on the placed node either though).

It crashed when i tried to register the node (or the new node) again.

I mean I'll try the unregister thing but it wouldn't really help much i suppose if you can't register a new node right after (as i said the goal is to be able to place unknown nodes here).

I think my original solution is probably the best, definitely the simplest. Getting the unknown nodes "live" would be neat but i'm not sure that's even possible tbh.

> Does it still crash when you use that in place of directly setting `nil` in the table? It could be assigned to a chat command, like with the other functions. Yes. It didnt crash when i set the registration to nil (didnt have an immediate effect on the placed node either though). It crashed when i tried to register the node (or the new node) again. I mean I'll try the unregister thing but it wouldn't really help much i suppose if you can't register a new node right after (as i said the goal is to be able to place unknown nodes here). I think my original solution is probably the best, definitely the simplest. Getting the unknown nodes "live" would be neat but i'm not sure that's even possible tbh.

Sign in to join this conversation.

No Label

mcl5

mcla

Media missing

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: VoxeLibre/mcl_devtest#1