Compass and long range tool not working properly if at all...

Discussion in 'WorldEdit' started by Jill Kitten, Sep 22, 2017.

  1. Jill Kitten

    Jill Kitten New Member

    Left click is not working for compass or long range tool, to be more clear, it works for close range only when I can normally highlight a block [as in vanilla MC] and then it works, but not otherwise outside of that very close distance.
    I just got started last week [2017-09-??] with official MC for PC [was on XB360], added the forge mod so I could use WorldEdit and did the common standard install for this arrangement. Everything seems to work well, but this one thing just doesn't seem to work. I tried pointing at a 'far' block just barely out of range of the vanilla MC highlight selection and these tools don't work as well as the /jumpto command not working for 'far' blocks in the same exact way [FYI: I set the /lrbuild tool to a blaze rod].
    Also the right click function only works for about 20 [or so] blocks away, which is not very far, in vids I see others using it MUCH farther than that [some 50, some much more], so it could also be said it is not working correctly either.

    Not sure if anyone has encountered this, I poked around using search to see if anyone has, but no results, is this a unique issue? Anyway, some help would be handy especially since I am new to WorldEdit and MC for PC, thanks.
    Last edited: Sep 22, 2017
  2. wizjany

    wizjany Administrator Developer

    it's an issue with forge. there's no way for us to detect when you use those things on the platform unfortunately, and we haven't implemented a workaround.
  3. Jill Kitten

    Jill Kitten New Member

    Do we know WHY it works in this weird way? And since this is an issue why did I not find anyone posting about it? [How is anything going to be resolved if nobody talks about it]
    Does it not seem odd that for left click it works when MC notices the block, but otherwise not,... and for right click the max range is shortened by half [almost like there is a data type difference with an incorrect translation of value]. It is not that it 'never' works, it is that it works incorrectly, a partial functionality. Why would this be different for Forge than for bukkit or others, in what possible way would the base platform affect the integral interface for the 'class' communication with the MC API? If it did then one would think there should be a huge plethora of issues across the board since it would be reasonable to think that all interfaces would be affected in some way. While I am not familiar with the class structure or code of WorldEdit it seems that this is a particular detail that specifically affects WorldEdit and all its commands that are to work at far distances which is a considerable set of the functionality, clearly this should not be ignored.
    While I am an experienced programmer, I am not expecting you to bring me totally up to speed with it all, but if a resolution will ever be found it first has to be determined as to WHY it happens. So I ask do we know WHY it works in this weird 'partial' way? [and has the problem been reproduced by WorldEdit coders so they can track what is going on with this?]
  4. wizjany

    wizjany Administrator Developer

    yea, the client doesn't send a packet to the server when you left click without targeting a block.
    that's the entire extent of it.
    if you use a dev build of worldedit on the client and server (or just client for singleplayer), worldedit will actually explicitly send the packet now. forgot someone added that recently.
  5. Jill Kitten

    Jill Kitten New Member

    I see, by the way thank you for that quick informative detail. Ok, so I am finding this issue on client single player, so is this to say that I am experiencing the partial workaround which is to bypass the common data path because the common path for this functionality is not provided in Forge? If this is so then it seems the data being sent is being corrupted/badly translated, or is incorrectly gathered in the first place. I say this because it would seem to me that from the WorldEdit end of things the basic information of the player position, orientation, obviously the world data itself, and the messages of player action [like left/right clicks] should all be available which is the info needed to correctly detect the condition, so the only thing left would be WHAT is being gathered or sent. So from my understanding, am I correct in saying that I am experiencing the temporary workaround on the client for single player? And am I to then assume they are still working on this issue, and have reproduced these particular partial functionality? [and if not is there anything I could do to help provide what is needed, like logs or implement some test code or ?]

    [by the way, I measured the active range of right click with the compass function and it was 21 blocks including both the start and end positions which would be 0 to 20 in relative position, clearly more than MC highlighting distance of 0 to 4]
    Last edited: Sep 23, 2017
  6. wizjany

    wizjany Administrator Developer

    can you please be more succinct i don't feel like reading so much
  7. Jill Kitten

    Jill Kitten New Member

    There will be a lot of missing context, but I will try.

    I see, thanks for a quick informative detail.

    I am on client single player, does this mean I am experiencing the partial fix, or did you mean the DEV client single player IS fixed?

    If the latter [dev is fixed], does this mean the fix is already coming, or...

    If the former are they still working on this issue and have reproduced the particular partial functionality, and if not reproduced is there anything I could do to help provide what is needed, like logs or implement some test code or ? [especially since this is a lot of missing functionality, and should be affecting more but isn't {also meaning they should have what is needed}]

    BTW: measured range of right click with compass was 21 blocks including start and end [= 0 to 20], clearly more than Vanilla MC highlighting selection distance [= 0 to 4].
    Last edited: Sep 23, 2017
  8. wizjany

    wizjany Administrator Developer

    the dev builds have a workaround of the minecraft "issue" (i.e. it doesn't send packets). it should have full functionality, so it's not a "partial" fix, however it doesn't actually fix the root of the issue, just works around it so the user should have to worry about it.

    right click (//thru) is different from left click (//jumpto). i was only talking about left clicking. afaik there aren't any issues with right clicking (the thru command intentionally has limited range of wall thickness though? not sure what you're asking)
  9. Jill Kitten

    Jill Kitten New Member

    So the coming update is fixed for left click w/a kludge, sounds like need to lobby Forge [or MC, or ?] to provide what is needed to avoid the kludge later.

    To be clear, /jumpto as a chat command works, it is the /jumpto function of the compass that only works 4 blocks away.

    For /thru function of the compass wall thickness =1, range = 20, otherwise it warns "Nothing to pass through" while others on instruction vids have range 50+, that is also an issue [even if not part of the other issue], and funny enough [as I just tried it] the /thru chat command doesn't seem to be working at all warning "No free spot ahead of you found." despite the fact that the same compass function works under the same exact conditions [within 20 blocks].

    [note I have not tried wall thickness > 1, didn't see the point]
    Last edited: Sep 23, 2017