[mod] Rhotator Screwdriver [1.2] [rhotator]

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

[mod] Rhotator Screwdriver [1.2] [rhotator]

by entuland » Tue Jun 19, 2018 23:12

Rhotator Screwdriver - a different twist at screwdriving

Repo:
https://github.com/entuland/rhotator

Download links:

Version 1.0, embedded matrix.lua library:
https://github.com/entuland/rhotator/archive/1.0.zip

Version 1.1, depending on separated [matrix] mod, same as 1.0 otherwise:
https://github.com/entuland/rhotator/archive/1.1.zip

Version 1.2, same as 1.1, added rotation memory and fixed the implicit dependency on [matrix]
https://github.com/entuland/rhotator/archive/1.2.zip

Dependencies: none for 1.0, [matrix] for 1.1 and 1.2
Code License: MIT
Media License: CC0

The README.md there has a few screenshots and the description of how it works, here is just the overview so you can understand what it is all about:

The default screwdriver included in minetest_game, as well as any other screwdriver mod I have found, operate differently depending on the node's direction and rotation. This means that any given click on a node may produce different results which you cannot predict at a glance.

The Rhotator Screwdriver uses a different approach: the direction and orientation of the node make absolutely no difference.

These are the factors that affect the results of a click:

  • the face you point at
  • where on that face you point
  • what button you click
  • whether or not you hold down the sneak key

You will always be able to predict exactly the effect of the Rhotator Screwdriver.

Four consecutive clicks of the same button on the same position will always bring the node back to its original direction / orientation.


The Rhotator Screwdriver performs the same checks as the built-in minetest_game screwdriver.

For some reason some protection mods fail to prevent both screwdrivers from rotating the nodes, so make sure you test everything yourself to avoid surprises.

Image
Last edited by entuland on Sat Jun 23, 2018 13:33, edited 6 times in total.
 

User avatar
texmex
Member
 
Posts: 1066
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: texmex
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by entuland » Wed Jun 20, 2018 17:38

texmex wrote:Super decent! Finally a sane way of rotating nodes.


Glad you like it :)

I must say that the first version of the first post was "this is my attempt at a saner screwdriver" but then I thought it was a bit offensive for the current implementations and I cut that part :P
 

User avatar
Linuxdirk
Member
 
Posts: 1672
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by Linuxdirk » Wed Jun 20, 2018 17:42

entuland wrote:I must say that the first version of the first post was "this is my attempt at a saner screwdriver" but then I thought it was a bit offensive for the current implementations and I cut that part :P

Well, the built-in screwdriver is everything but sane. Will totally try this.

Edit: Do you really need a 3rd party 1115 sloc library?
 

User avatar
Stix
Member
 
Posts: 1304
Joined: Fri Aug 04, 2017 14:19
Location: USA
IRC: nil
In-game: Stix [+alts]

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by Stix » Wed Jun 20, 2018 17:49

Finally! I've been waiting an eternity for a saner approach to the currently "broken" screwdriver, and this is the answer! I suggest you make a pull-request to replace the default screwdriver with your version, its really that good +1.
Hey, what can i say? I'm the bad guy.
Next release of your favorite game? "Bugfixes" --Wuzzy
[OLD]The new Minetest-offtopic can be found here: https://minetestoftopic.createaforum.com/index.php
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by entuland » Wed Jun 20, 2018 17:54

Linuxdirk wrote:
entuland wrote:I must say that the first version of the first post was "this is my attempt at a saner screwdriver" but then I thought it was a bit offensive for the current implementations and I cut that part :P

Well, the built-in screwdriver is everything but sane. Will totally try this.

Edit: Do you really need a 3rd party 1115 sloc library?

Unfortunately I do, cause I need the matrix operations to properly rotate the nodes.

I will make such external library as a separated mod so that I can require it from both of my mods that use it (wesh and rhotator).

Extracting only the needed functions and only include them could be a way as well, but it would be just useless added work. A few KB more for a dedicated mod will not be a big deal.

Hope you'll like the Rhotator Screwdriver regardless of the carried burden :P
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by entuland » Wed Jun 20, 2018 17:57

Stix wrote:Finally! I've been waiting an eternity for a saner approach to the currently "broken" screwdriver, and this is the answer! I suggest you make a pull-request to replace the default screwdriver with your version, its really that good +1.

I'm glad you like it :)

Well, the ideal thing would be integrating properly _all_ of those matrix functions in the game, not just the Rhotator Screwdriver. There are lots of mods out there that fall short on proper arbitrary rotation manipulation, relying on limited tables covering only the Y-up rotations or the alike in the worst cases.

We'll see, for the moment I'm happy if this helps people out there.
 

User avatar
Linuxdirk
Member
 
Posts: 1672
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by Linuxdirk » Wed Jun 20, 2018 18:21

entuland wrote:Hope you'll like the Rhotator Screwdriver regardless of the carried burden :P

I’m not a fan of external libs. So while it’s great to see some activity around the utterly broken default screwdriver I probably won’t use it. But the idea is really nice! Big thumbs up for that.
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by entuland » Wed Jun 20, 2018 18:55

Linuxdirk wrote:
entuland wrote:Hope you'll like the Rhotator Screwdriver regardless of the carried burden :P

I’m not a fan of external libs. So while it’s great to see some activity around the utterly broken default screwdriver I probably won’t use it. But the idea is really nice! Big thumbs up for that.


I'm glad you like the idea :)

I'm not really sure what is the problem there with the library I'm using... please, anybody, don't take my words in the wrong way, I'm just trying to understand.

Minetest only provides a few spatial helpers to deal with vectors, lacks any proper matrix facilities which probably is the cause for other mods failing to properly handle arbitrary rotations.

The library I'm using is licensed with the very license that comes with Lua itself, which in turn is just the MIT license I use for my mods.

Here is the original library: https://github.com/davidm/lua-matrix

Here is the fork I made to have it as a standalone mod (just a thin wrapper): https://github.com/entuland/lua-matrix

The first post has been updated with a link to release 1.1, depending on the above thin wrapper.

I'll be more than happy to know what would be the best option to implement all of this, even though my personal opinion would be to include _all_ of that lib into Minetest itself, adding even more helper functions to facilitate the use of such matrix operations, which can be daunting for people not used to them.
 

User avatar
Linuxdirk
Member
 
Posts: 1672
Joined: Wed Sep 17, 2014 11:21
Location: Germany
In-game: Linuxdirk

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by Linuxdirk » Wed Jun 20, 2018 20:01

entuland wrote:Minetest only provides a few spatial helpers to deal with vectors, lacks any proper matrix facilities which probably is the cause for other mods failing to properly handle arbitrary rotations.

This isn’t enough for vectors? What’s missing? Maybe create a feature request issue. And maybe check this handy thing here.

You can get the position of the node in relation to the player, and the current rotation of the node from the node’s meta data, and the face the player is pointing and as well as the exact position the player is pointing to on the face. I never looked into this, but what else is needed to sanely rotate a node?
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.0] [rhotator]

by entuland » Wed Jun 20, 2018 21:12

Linuxdirk wrote:
entuland wrote:Minetest only provides a few spatial helpers to deal with vectors, lacks any proper matrix facilities which probably is the cause for other mods failing to properly handle arbitrary rotations.

This isn’t enough for vectors? What’s missing? Maybe create a feature request issue. And maybe check this handy thing here.

You can get the position of the node in relation to the player, and the current rotation of the node from the node’s meta data, and the face the player is pointing and as well as the exact position the player is pointing to on the face. I never looked into this, but what else is needed to sanely rotate a node?


Oh well, technically no, you don't really need matrices to perform arbitrary rotations.

You don't need them just like you don't need multiplications to perform additions where all values are equal, but multiplications are faster to type and they express clearly what they're doing.

In Minetest rotations are expressed as a single number, ranging 0 to 23, where the total of 24 values is actually the combination of 6 semiaxes and 4 rotations around each of those semiaxes.

This is the current approach at dealing with the facedir values (extracted from the built-in screwdriver just because it's the one at hand, other mods do just the same):

Code: Select all
local facedir_tbl = {
   [screwdriver.ROTATE_FACE] = {
      [0] = 1, [1] = 2, [2] = 3, [3] = 0,
      [4] = 5, [5] = 6, [6] = 7, [7] = 4,
      [8] = 9, [9] = 10, [10] = 11, [11] = 8,
      [12] = 13, [13] = 14, [14] = 15, [15] = 12,
      [16] = 17, [17] = 18, [18] = 19, [19] = 16,
      [20] = 21, [21] = 22, [22] = 23, [23] = 20,
   },
   [screwdriver.ROTATE_AXIS] = {
      [0] = 4, [1] = 4, [2] = 4, [3] = 4,
      [4] = 8, [5] = 8, [6] = 8, [7] = 8,
      [8] = 12, [9] = 12, [10] = 12, [11] = 12,
      [12] = 16, [13] = 16, [14] = 16, [15] = 16,
      [16] = 20, [17] = 20, [18] = 20, [19] = 20,
      [20] = 0, [21] = 0, [22] = 0, [23] = 0,
   },
}


The above works, in the sense that it does what it is meant to do: map a facedir value to another facedir value according to a specific transformation (two transformations actually above, one for each table).

In the case of my mods (both [wesh] and [rhotator]) I _could_ use the same approach, and it would work. The only problem is that since I need all combinations, I should implement a table mapping all combinations of the 24 values against eachother (for a total of 576 pairs).

Using matrices instead I only need to write down 10 starting matrices (6 for the semiaxes, 4 for the rotations around the positive Y axis) and then I can combine them together without worring what is the actual orientation of the nodes, or of the face I'm pointing at (for the [rhotator] mod) or the capture / rebuild orientation of my canvases (for the [wesh] mod).

For example, the line that does the magic in [rhotator] is this:
Code: Select all
local stop = transform * rotation * transform:invert() * start


In the above all elements are matrices, not simple numbers. I take the "start" matrix, I bring the pointed face on the positive Y axis by multiplying for the inverse of the "transform" matrix, then I multiply for the "rotation" matrix to apply the actual desired rotation and finally I multiply for the regular "transform" matrix to bring that face back to where it was, correctly rotated around its axis - matrix multiplications are not commutative and they get applied right to left, so the order of factors there is meaningful.

I don't need to know what face I'm actually pointing at, or what rotation I need to apply or what orientation the node is, matrices make all of it "transparent" to the code, I just need to map the 24 facedir values to 24 matrices (and I don't even need to hardcode those 24 matrices, cause I can generate them combining the 6 "semiaxis" matrices and the 4 "rotation around Y" matrices).

Edit 1: of course I am using the handy thing...
https://github.com/entuland/rhotator/bl ... t.lua#L131
...that's what is making [rhotator] aware of the position of the crosshair relative to the face and to compute the closest edge used in "push" mode, but it's just one piece of the puzzle.

Edit 2: in particular, this is one of the functions one could eventually consider using to deal with such arbitrary transformations:

https://github.com/minetest/minetest/bl ... ua#L40-L91

The problem with working with vectors is though that they only convey the main direction the node is pointing to, not its rotation around that direction. That's why out of the 24 possible combinations of 6 directions and 4 rotations, that function only produces 8 values out of 24 (accounting for the Y value of the given vector) and 4 values out of 24 in case the Y value of the vector is to be ignored according to the caller of the function (the "is6d" flag).

Proper abritrary rotations in 3D require either a matrix, or an XYZ vector plus an angle (called axis-angle representation), or a quaternion (a vector with 4 values, none of which is X, Y or Z, it's simply another way to represent the datum about "direction + rotation").

(in the case of the dir_to_facedir() function it's easy to see how it's just an approximation at handling arbitrary directions / rotations for the simple fact that it operates only on a vector, it doesn't ask for an angle around that vector at all)

Quaternions and matrices can both be combined ignoring their "internals" (sort of, I'm simplifying) whereas axis-angle representations require far more juggling. Matrices in particular are the most powerful among them all because they can represent and combine spatial information far beyond the simple direction and rotation (scaling, skewing, mirroring and whatnot).

If I wanted to add some "mirror" flags to my [wesh] mod interface I could traverse the nested table and juggle the values (say, transforming 1 to 16 into 16 to 1) but using matrices I could simply apply a mirror+translate to the coords and be done with it.
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.1] [rhotator]

by entuland » Fri Jun 22, 2018 16:14

Added rotation memory feature (only available in master branch for now, not in the tagged releases):
https://github.com/entuland/rhotator

Rotation memory only applies to "facedir" and "colorfacedir" nodes.

It can be toggled on and off with a chat command, its state gets saved and restored between play sessions.

When the rotation memory is enabled, all supported nodes will be placed with the same rotation as the last node you rotated with the [rhotator] screwdriver.

The above means that you can place a stair, rotate it as you better prefer and continue placing as many as you want without worrying about aiming at the correct spot or from a specific direction, they will all get placed as the one you rotated manually.

This last rotation will not survive a world reload, though. You'll need to rotate a node again for the rotation memory to start working again (for instance if you left a staircase branch incomplete and you want to pick over where you left after a world reload).

I will most probably store that information as well to have it persist across world reloads.

I look forward for any feature request if you feel like providing any - for instance, I could create another tool to copy / apply the rotation from and to already placed nodes: say, you have a large wall with some oriented pattern and you want to rotate them all without dismantling / rebuilding it: you could use such new tool to right-click and apply the last used rotation, or use the left-click to copy the rotation from an existing node)
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland
 

User avatar
texmex
Member
 
Posts: 1066
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: texmex
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by entuland » Sat Jun 23, 2018 17:53

texmex wrote:The mod name "matrix" is taken >:) https://github.com/diggers-mt/minetest- ... r/mod.conf

Oh well, considering how the official content repository uses well defined rules for naming rights precedence, I think I'll keep the name, having been the first to ever post about a mod with such a name in the official forums:

search.php?keywords=matrix&terms=all&author=&sc=1&sf=titleonly&sr=topics&sk=t&sd=d&st=0&ch=300&t=0&submit=Search

If an official word will come down that I shall rename my mod I will comply.

Edit: actually, in the perspective that sooner or later matrix facilities make it to Minetest itself, it would be a good thing that I "locked" the name for the "right thing", so to say, so that when time will come we'll have "matrix" available along with "vector", and "my" [matrix] mod will have no problem in going forgotten.
 

User avatar
texmex
Member
 
Posts: 1066
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: texmex
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by entuland » Sat Jun 23, 2018 18:43

texmex wrote:That's a problem… https://content.minetest.net/packages/texmex/matrix/

Perhaps matrixorg or matrix_bridge would suit better.


Yep, probably that would match the subject better.

I'm editing this post to get rid of my bad reaction to my even worse reading of your message, TexMex. My apologies whether or not you read it.
 

User avatar
texmex
Member
 
Posts: 1066
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: texmex

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by texmex » Sat Jun 23, 2018 19:35

No worries entuland, we’ll settle on something. I’m thinking matrix_chat, but I need to update my opening_hours mod as well first.
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by entuland » Sat Jun 23, 2018 19:55

texmex wrote:No worries entuland, we’ll settle on something. I’m thinking matrix_chat, but I need to update my opening_hours mod as well first.


:)

Wish you good work, sorry for adding to it with this unwanted naming clash.
 

User avatar
texmex
Member
 
Posts: 1066
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: texmex

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by texmex » Sun Jun 24, 2018 08:15

On top of our naming crash, our original libraries also also clashes in name:

https://github.com/davidm/lua-matrix : Matrices and vectors of are real, complex, and symbolic elements, implemented as Lua tables.
https://github.com/aperezdc/lua-matrix : Matrix Client-Server API for Lua and LuaJIT

So I'm really wondering how these two libraries should be able to exist in the same MT world… xD

For now though, I'm just changing to matrix_chat. I'm thinking for the sake of clarity and in order to follow a de facto Minetest library type mod naming convention you can, if you feel like it, name yours libmatrix. But that's up to you of course. I'm performing my changes right now regardless.
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by entuland » Sun Jun 24, 2018 10:02

texmex wrote:On top of our naming crash, our original libraries also also clashes in name:

https://github.com/davidm/lua-matrix : Matrices and vectors of are real, complex, and symbolic elements, implemented as Lua tables.
https://github.com/aperezdc/lua-matrix : Matrix Client-Server API for Lua and LuaJIT

So I'm really wondering how these two libraries should be able to exist in the same MT world… xD

For now though, I'm just changing to matrix_chat. I'm thinking for the sake of clarity and in order to follow a de facto Minetest library type mod naming convention you can, if you feel like it, name yours libmatrix. But that's up to you of course. I'm performing my changes right now regardless.


Yep, the "chat related" library incurred in the same problem by using the "matrix" name after four years or so that the same name was used by the "math related" library.

I'll keep the name [matrix] and the usage of the "matrix" variable name in the global space on behalf of Minetest in the perspective that some day we'll have them built in the game along with "vector":
https://dev.minetest.net/Vector_helpers

I wonder if a better approach there could have been to force all mods to never declare anything on the global scope and instead have them "return"ing the main table of their mod for accessing them afterwards in a fashion like this:

Code: Select all
-- code from mod B wanting to use mod A

local modB = {}

local modA = minetest.mods.modA

-- add methods to modB using facilities from modA

return modB


oh well. I guess we're too late for a global approach like that, and I'm not even sure something like this could be sanely enforced, or if it could be enforced at all.
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland
 

User avatar
texmex
Member
 
Posts: 1066
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: texmex

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by texmex » Sun Jun 24, 2018 11:14

Sounds good entuland. I’ll see what I can do to mitigate conflicts caused by lua-matrix (the chatty one)
 

User avatar
12Me21
Member
 
Posts: 873
Joined: Tue Mar 05, 2013 00:36
Location: (Ignore all of my posts before 2018)
GitHub: 12Me21

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by 12Me21 » Sun Sep 30, 2018 01:04

When you call on_rotate, you're supposed to pass the new param2 value, not the current one.
 

entuland
Member
 
Posts: 111
Joined: Wed May 09, 2018 15:47
GitHub: entuland
IRC: entuland
In-game: entuland

Re: [mod] Rhotator Screwdriver [1.2] [rhotator]

by entuland » Sat Nov 03, 2018 15:45

12Me21 wrote:When you call on_rotate, you're supposed to pass the new param2 value, not the current one.

Hello there 12Me21, it's been a long time since I last touched the code of my mods, and I honestly can't remember what the problem was with that on_rotate callback or whether there is a problem at all there right now - do I need to fix anything with my code?
 


Return to Mod Releases



Who is online

Users browsing this forum: No registered users and 5 guests