Region Selection Improvements about minetest-worldedit HOT 14 CLOSED

What's a region node? A node inside the region? WorldEdit position 1/2?

What's an "active" region node? What does it mean for one to be "active"?

I am a little unclear as to what you are suggesting.

from minetest-worldedit.

Sorry about confusing the terminology. I was referring to the WorldEdit
positions 1/2 as the "region nodes". An active one is the one that would be
acted on by the various commands I proposed. (Another apporach would be to
always treat #1 as the active position that commands would act on, and just
make it simple to switch the positions of #1 and #2). Does that help?

On Tue, Feb 25, 2014 at 1:40 PM, Anthony [email protected] wrote:

What's a region node? A node inside the region? WorldEdit position 1/2?

What's an "active" region node? What does it mean for one to be "active"?

I am a little unclear as to what you are suggesting.

Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-36042132
.

from minetest-worldedit.

Ah, that makes more sense. What's the nearest horizontal direction from the camera?

This is an interesting idea. Instead of all these commands though, what about something like //movemarker 1 ? 20, like the //move and //copy commands? This way, the player simply looks in the direction they want the marker to move in and it will move in that direction.

from minetest-worldedit.

Need to stop writing issues in haste! :)

What's the nearest horizontal direction from the camera?

What I meant was forward should be in the x or z direction, which ever is closest to the direction the player is facing (I personally don't think it makes sense to include y direction in this logic because I think it help to have up/down to always be in a consistent direction, but I can see why you might want to do it this way).

//movemarker 1 ? 20

what does 1 ? 20 mean? (marker number + optional number of nodes?)

This way, the player simply looks in the direction they want the marker to move in and it will move in that direction.

I would prefer to have a little more control. In particular, I think having the ability to move markers in all three dimensions without moving the camera is key.

So how about

• //movemarkerabs n dx dy dz move marker n (=1 or 2 or B (both)) in the absolute direction dx dy dz (this one probably isn't necessary but just for completion) |
• //movemarker n dx dy dz move marker n in steps dx dy dz relative to the player orientation (in my orientation scheme: dx = step dx units away from the x or z direction that is closest to the player orientation, dy = units up (+) or down (-), dz = units right (+) or left (-) relative to player orientation) |
• //switchmarkers swaps the 1 and 2 markers - (would make it easier to bind keys if you can bind arrow keys to marker 1 and then just swap them)

from minetest-worldedit.

The ? is the axis name that means, "the axis and sign of the direction the player is facing". For example, if I type //c ? 20 into the chat prompt, it will copy my current region 20 nodes forward from the axis I'm looking at.

What are the advantages of moving the markers without moving the camera? It seems to me that moving the camera is a split-second operation that is more intuitive than figuring out which axis to use manually.

All of the existing commands supporting ? (player relative axis) work only in one axis at a time. This is in order to simplify the mental model, to make commands easy to remember and mentally construct - rather than having to figure out which offset goes to which parameter, we simply type in the axis we want and how much to offset it by. I am in favor of keeping this consistent with the others, but feel free to convince me otherwise.

from minetest-worldedit.

What are the advantages of moving the markers without moving the camera?
It seems to me that moving the
camera is a split-second operation that is more intuitive than figuring
out which axis to use manually.
[...] but feel free to convince me otherwise.

My logic is predicated on being able to implement keyboard shortcuts as
aliases for commands (I'm working on a patch to the MT engine). With
keyboard shortcuts, then it will mean fewer mouse moves and key presses to
move a marker into the desired place. e.g. I would set the arrow keys +
pgup and pgdn to control a marker position in 3 dimensions. I think it
should be reasonably intuitive because the key setup would basically be 3rd
person control of the marker. (I would also like to have shift and control
modifiers for those keys: shift = move marker 2 instead of 1, ctrl = move
both markers.)

In addition to copy/move, perhaps a more standard cut/copy/paste operation
might also be useful in combination with what I'm proposing?

On Wed, Feb 26, 2014 at 2:32 PM, Anthony [email protected] wrote:

The ? is the axis name that means, "the axis and sign of the direction
the player is facing". For example, if I type //c ? 20 into the chat
prompt, it will copy my current region 20 nodes forward from the axis I'm
looking at.

What are the advantages of moving the markers without moving the camera?
It seems to me that moving the camera is a split-second operation that is
more intuitive than figuring out which axis to use manually.

All of the existing commands supporting ? (player relative axis) work
only in one axis at a time. This is in order to simplify the mental model,
to make commands easy to remember and mentally construct - rather than
having to figure out which offset goes to which parameter, we simply type
in the axis we want and how much to offset it by. I am in favor of keeping
this consistent with the others, but feel free to convince me otherwise.

Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-36166457
.

from minetest-worldedit.

For keyboard shortcuts, I think your suggestion is quite reasonable - when the keyboard patch is merged, it will probably be implemented as a separate component, like the WorldEdit GUI. The keyboard shortcuts should not affect the other interfaces, like the chat interface.

from minetest-worldedit.

At least at first I was hoping to implement the keyboard shortcuts as a
client side feature in which they would just be aliases for commands.
Sending arbitrary key presses through the server has potential to create
lag issues (though that could be mitigated by queuing up key presses I
guess). The command interface already deals with all of the server issues,
I think, so it seemed to me like a nice thing to leverage. The only thing
bad about this approach is that it doesn't let mods set keyboard shortcuts

• but maybe I can come up with an API that let's a mod tell the clients to
  set up a bunch of key press aliases (the client would have to deal with any
  clashes). How does this sound to you?
  On Feb 26, 2014 4:08 PM, "Anthony" [email protected] wrote:

For keyboard shortcuts, I think your suggestion is quite reasonable - when
the keyboard patch is merged, it will probably be implemented as a separate
component, like the WorldEdit GUI. The keyboard shortcuts should not affect
the other interfaces, like the chat interface.

Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-36176821
.

from minetest-worldedit.

Actually, the commands are executed on the server as well - any lag issues from sending keypresses to the server are also present in binding keys to commands, since commands must be sent to the server to be run.

In short, this would not remove the latency issue.

You may be thinking of some of the builtin commands in Minetest like /set fov 70, which do execute on the client side and therefore have no latency. However, all commands registered by Lua mods are run on the server side and unfortunately, there is no way around this - at least until there is a client side modding API, which seems highly unlikely at this point.

from minetest-worldedit.

I am not worried about the latency of sending commands to the server and
getting a response back -- I'm more worried about the ability to spam the
server with a million keypress and impose lag on everyone. I was working
off the assumption that the command framework already deals with this by
not allowing too many commands to be queued.

Probably getting off the topic of the original issue at this point, but to
me there are four main benefits of doing keypresses as command aliases:

1. Simple addition to the client, minimal additional server side code
   (other than an API to let mods recommend keypress aliases to clients)
2. User can set up key shortcuts for arbitrary commands (maybe this feature
   could be abused, but not like people can't hack their client and create
   havoc anyway)
3. Would work with any mod that has commands, no changes required
4. Doing it any other way would involve a bunch of duplication of the
   command handling code anyway.

On Wed, Feb 26, 2014 at 5:15 PM, Anthony [email protected] wrote:

Actually, the commands are executed on the server as well - any lag issues
from sending keypresses to the server are also present in binding keys to
commands, since commands must be sent to the server to be run.

In short, this would not remove the latency issue.

You may be thinking of some of the builtin commands in Minetest like /set
fov 70, which do execute on the client side and therefore have no
latency. However, all commands registered by Lua mods are run on the server
side and unfortunately, there is no way around this - at least until there
is a client side modding API, which seems highly unlikely at this point.

Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-36184452
.

from minetest-worldedit.

This is also not the case unfortunately - the command framework is also susceptible to spamming, but in practice this doesn't show up because it's hard to spam commands. In any case, it is very simple to rate limit by using a debouncing function.

I do like the idea of keypresses as command aliases, and as you said, it is easier to implement as well. However, the WorldEdit chat interface should remain that - a chat interface, not a keypress interface.

I think the best solution is to register specific commands just for keypress use in the keypress interface, like //_movemarker x y z, and then have "human-friendly" versions in the chat interface, like //p move1 x 14. This way, we get the best of both worlds. Thoughts?

from minetest-worldedit.

I think the best solution is to register specific commands just for
keypress use in the keypress interface,
like //_movemarker x y z, and then have "human-friendly" versions in the
chat interface, like//p move1 x 14. This way, we get the best of both
worlds. Thoughts?

Sounds like we have a plan. Now time for me to shut up and code.

On Wed, Feb 26, 2014 at 5:42 PM, Anthony [email protected] wrote:

This is also not the case unfortunately - the command framework is also
susceptible to spamming, but in practice this doesn't show up because it's
hard to spam commands. In any case, it is very simple to rate limit by
using a debouncing function.

I do like the idea of keypresses as command aliases, and as you said, it
is easier to implement as well. However, the WorldEdit chat interface
should remain that - a chat interface, not a keypress interface.

I think the best solution is to register specific commands just for
keypress use in the keypress interface, like //_movemarker x y z, and
then have "human-friendly" versions in the chat interface, like //p move1
x 14. This way, we get the best of both worlds. Thoughts?

Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-36187188
.

from minetest-worldedit.

Post here when the patch is in! Work can start on the worldedit_keys module as soon as the API is somewhat finalized.

from minetest-worldedit.

something like this was added with #118

from minetest-worldedit.