Orientation Bug for tracks, droppers, etc..

Discussion in 'WorldEdit' started by Jill Kitten, Oct 12, 2017 at 1:03 AM.

  1. Jill Kitten

    Jill Kitten New Member

    succinct version:

    1> Is there no other place to look up or make a bug report for WorldEdit?

    2> copy-paste-save-load-move commands do not preserve orientation/direction information for tracks w/>2 connections, dispensers, and droppers [they end up pointing the wrong way when pasted or moved].

    3> Is it already known why this happens, and if so why?

    More detail:

    In WorldEdit when using copy-paste [w/ or w/o rotate] and move commands, many block items do not have the same orientation/direction as when they were copied. I noticed this with tracks [w/more than 2 sides connected to other tracks], dispensers, and droppers. I am new to WorldEdit so I am not certain what other items might be affected. This kills almost all of my red-stone automation where I effectively have to rebuild most of it. I was mostly creating schematics which uses copy-paste, but I noticed this also when using the 'move' command.

    I tried poking around for where to look up bug reports [or where to make one if not found] but did not find much other than this forum. And a search for just the word 'orientation' only turned up about 15 or so results that did not seem to mention this issue, so here I am trying to find out where I find or make a bug report about this, and maybe even get some answers as to why this happens.

    P.S. I also noticed that a single track w/no other connections just goes to the default orientation regardless of the original copied/saved orientation.

    P.S.S. I did notice mention of pictures and item frames, but not tracks, dispensers, and droppers,.. Is it maybe related to that issue, or is this a separate thing?
    Last edited: Oct 12, 2017 at 1:10 AM
  2. wizjany

    wizjany Administrator Developer

  3. Jill Kitten

    Jill Kitten New Member

    Where did I look, first the wiki at http://wiki.sk89q.com/wiki/WorldEdit turned up nothing useful for 'bug report', then a general web search for "worldedit bug report" turned up references mostly to bukkit, forge, and YouTube, in which I mostly found people trying to GIVE a bug report. And since this seemed to be the main forum for WorldEdit [which I found from the wiki] I searched here also for the specific word 'orientation' to see if anybody was discussing the issue. I notice your images are from enginehub and dev.bukkit but they don't actually say 'bug report' they say 'issue tracker' which means they would not be found in a search for 'bug report'. I would suggest that if you had a description sentence like 'To find or file a bug report visit the issue tracker at'... Then searches for 'bug report' in reference to WorldEdit would then show up.

    Seeing as how VERY popular WorldEdit is, have you tried gaining a dialog with MC programmers to see about solving some of these shortcomings? [Great mod by the way, the best!]

    The other thing that occurs to me is aren't this and other issues not a big deal with McEdit? I have not used it [MCEdit], but how do they seem to bypass these issues? Is it just that they do not interact with the MC game program? Then I wonder if they have access to that info in the savegame data, is there no way to access that same data? Although I am sure it would be a slow kludge, it may be a way to temporarily work around the issue until you can lobby the MC programmers to make a few things available in the data sets. Anyway, just an idea, thanks for the info.


    [[did someone delete my followup post pointing at where to do a bug report? Why would anyone bother doing that?]]
    Last edited: Oct 13, 2017 at 12:51 PM
  4. wizjany

    wizjany Administrator Developer

    Last edited: Oct 12, 2017 at 12:07 PM
  5. PseudoKnight

    PseudoKnight Well-Known Member

    Huh, I checked 4 different search engines (with and without search history) and they all had the tracker in the top 4 entries. Perhaps your search history is polluted on your favorite search engine.

    I cannot recreate the hopper/dropper issue on 1.12.2, so that's probably fixed. I'm guessing you're on an older version?
    The rail bug still remains, though, even in //fast mode.
  6. Jill Kitten

    Jill Kitten New Member

    It shouldn't be THAT old, I just got it like last month: Minecraft 1.12.1 with Forge 8.0.99.99 [w/Liteloader], WorldEdit 6.1.8 snapshot cd4729 [with CUI].
    Hoppers are fine, they are always fine, but droppers have the issue.
    A schematic of a timer where it has 2 droppers that are supposed to face each other and have a single item amongst them [rs latch] but when pasted at least one faces the wrong way and the item in it will fly out:
    https://www.dropbox.com/s/fd9wneug1hj15hp/TimerLongAccurate2x3x4.schematic?dl=0
    And this happens not just when I paste or rotate and paste, but just selecting it in world and using //move.
    So is it possible that this issue has been fixed in that minor [1.12.1 to 1.12.2] revision?
    Or maybe I have a bad copy of WorldEdit, or ?

    P.S. I was avoiding updating MC for every single tiny change as that becomes a super pain to do ALL the time, I would normally wait for a larger revision, but it also occurs to me that I may also not have the right version of mod loader or mod since I am total noob [like a month] to this MC moding setup, I was doing MC on XB360 and the last pc version I think I played was before 1.1 w/out mods.
    Last edited: Oct 13, 2017 at 12:45 PM
  7. PseudoKnight

    PseudoKnight Well-Known Member

    Excuse me, I meant droppers and dispensers. They were what I tested. I believe furnaces also had this issue a while back, but that got fixed earlier.

    I'll test your specific configuration, but I did test droppers facing into walls. It might be a specific orientation too.
  8. Jill Kitten

    Jill Kitten New Member

    Actually I was initially wondering if I have the proper versions of Forge and WorldEdit... because if I don't then that may be the issue and I have to deal with that since, if it is so, updating to MC1.12.2 might do nothing. Beyond that, if they are all fine and I update to MC1.12.2 and it is still an issue then I might have to take a deeper look at the internal configuration which I really don't want to have to mess with especially since I am new to this in particular. [of coarse this is assuming the issue is actually fixed, so I guess it is a good idea you test as you said you intend to do]
  9. PseudoKnight

    PseudoKnight Well-Known Member

    Well, it doesn't happen on a Spigot 1.12.2 server, so there's that. Not going to test Forge. I'll take your word for it there.
  10. Jill Kitten

    Jill Kitten New Member

    Isn't 'Spigot' a multiplayer server running bukkit and NOT a single player game? [at least that was my understanding] That makes it quite different in a few ways. At least I know it is not an issue someplace, so it could be a single player issue, a Forge issue, or a version issue. Thank you for your effort that is actually useful intel that helps narrow things down.

    Just a simple last bit PseudoKnight, are you running WorldEditCUI [selection highlighting for WE] and what version of WorldEdit are you running?
    Last edited: Oct 14, 2017 at 8:39 AM
  11. PseudoKnight

    PseudoKnight Well-Known Member

    Yes, I use WE CUI and I run the latest build of WE.
  12. Jill Kitten

    Jill Kitten New Member

    Ok, so I have updated MC to 1.12.2 and Forge along with it and the problems still persist. I also verified that I am using the current stable version of WorldEdit.

    Updating all that did nothing, so I am guessing this is still a bug at least for Forge in Single Player as of [email protected]:59.

    I hope this can be solved [or at least a workaround made] soon as I had such high hopes for this. while I can fill/erase large areas and do that generic stuff, using this with working redstone contraptions turns into a nightmarish pain to hunt down and find every little disoriented item in a system, especially when you paste it and it starts on its own going haywire spewing items out everywhere destroying its own functionality. I guess until then I will be using this to empty out under water tunnels and other generic stuff and forgo a large number of the //schematic files I planned to make of my redstone contraptions. Again it is a wonderful mod, still very useful, but I am saddened by this [hopefully] temporary limitation.
  13. Jill Kitten

    Jill Kitten New Member

    wizjany, since my setup demonstrates the issue, it may be helpful in reproducing the issue which may help in finding a solution, is there any data or files I can provide to the devs that might help with the bug hunt for these, like logs or a zipped copy of my minecraft folder or whatever?
  14. PseudoKnight

    PseudoKnight Well-Known Member

    I thought we covered this already. The issue appears to be a server one, not a WorldEdit one, as demonstrated by it working as expected on Spigot. I am not very familiar with Forge code so I'm not sure if there's a way to avoid the block update, but if it's not working in //fast mode, it's unlikely. (the rail update is unavoidable in //fast mode on Spigot, for example)
  15. Jill Kitten

    Jill Kitten New Member

    Oh yes I tried fast mode, not only does the problem persist, things just get worse where some things don't update, what a pain that was. Maybe you can explain to me who the server is when in Single Player, what makes Spigot w/bukkit work where it won't on a single computer with Forge. Does that not mean that the issue is in the API with Forge? Or has something special been done on specifically the Spigot server to solve the problem, what is the difference between the standard version of minecraft and the spigot version of minecraft? If they are the same version then is not the issue Forge? And in any case are you telling me there is no desire to find a work around for this issue on Forge because the programmers of WE only use Spigot? If that is the case then why did they even make a page on Forge for WE? Are you telling me NO ONE is working on the issue? That there is no hope of it ever working on forge?

    I get it is a 'server' issue, I guess what I don't get is your response, I don't understand the point of why it was given. Is it just to iterate that no attempt will be made to find a workaround? I am an old programmer, I have been at it for over 3 decades since the old apple][+ was new, and while most of my work has been in assembly with different processors and hardware, I am not a minecraft mod maker, but I do understand the premise that it is NOT exactly the fault of the code for WE. However I do understand that when working with API's [especially the windows API] that you continually have to make workarounds for a failed API interface and/or functionality. Am I being told that those who maintain WE have no intent of even trying to find a workaround for the issue? Is that why you responded? I understand it is not necessarily the fault of WorldEdit, I definitely understand that all to well from personal experience with API's for windows [3.1 to win9x to win7, etc.], Linux, and apple [at least the old days of apple], where workarounds are most of what you are doing, dealing with the shortcomings of an operating system's interface. Many workarounds are a kludge and can cause major slow downs, but at least it functions, because if it doesn't function then there is no point of its existence. Any good programmer should understand that. What I don't understand is your response... is it to make sure blame is not on WE [fault is irrelevant], is it to iterate a lack of desire to find a workaround with Forge, or what?

    Please help me understand your response. I professed my acceptance that it is not working for Forge and offered any help [if it was desired] in supplying data, etc. to help find a workaround, and you replied with "I thought we covered this already. The issue appears to be a server one, not a WorldEdit one...". Yeah, we did cover that already, so are you telling me that because I am using Forge my help isn't wanted? I just don't get your response. What was the point of it?
    Last edited: Oct 15, 2017 at 11:45 AM
  16. wizjany

    wizjany Administrator Developer

    No because we literally can't do anything.

    and no the programmers of worldedit don't just use spigot. we don't use anything.

    if you're such a programmer, fix it yourself. worldedit is open source and so is forge.
  17. PseudoKnight

    PseudoKnight Well-Known Member

    Just to be clear, I'm not a WorldEdit plugin developer. I do work on other plugins and run a Spigot server. I was curious about this issue before I realized it was Forge singleplayer, but I was doing my best to follow through.

    No, in the server implementation. I believe it's a vanilla issue, though.

    I investigated this with some spare time I had yesterday and it appears the Spigot developers patched a workaround into the server that solves this and other related issues.

    It looks like a vanilla issue. To verify you can use a /setblock command to see (maybe I'm wrong). Forge simply doesn't "fix" it like Spigot does.

    It's an upstream issue. I'm fairly certain there's no way of fixing this without modding the server or directly accessing obfuscated methods, which is bad practice for a mod that wants to maintain compatibility. So, it's not impossible (almost anything is possible if you want to make the sacrifices necessary to accomplish them), but it'd be bad for WE to workaround this... if I understand it correctly.

    Someone might have been or are working on it. That's for Forge development. This problem affects ALL plugins/mods like WorldEdit. It's not a WE issue.
  18. Jill Kitten

    Jill Kitten New Member

    Ok, I find that useful, I guess I still don't fully understand the purpose of your previous post, but this recent post does clarify that they actually modified MC server side code to patch the issue which explains exactly why the difference exists, thank you for that info.

    It makes me curious if they found a solution on their end, how willing they might be to share what that was? It could be quite handy and maybe insightful. Maybe even a clue as to a temporary workaround, even if it is an external [to java] client side library or executable. Of coarse that is where I tend to go as that is what I am used to having to do for a temporary workaround. I get your premise of "bad practice" [coders speak] it doesn't mean you are not sometimes forced into doing it. Being an assembly programmer maybe I seem a bit hard core about solutions, but if it SOLVES the problem then that workaround can be a model to the MC coders to make that change, and it has also proven to be a useful lobby tool for me in the past.

    Ha ha, funny, as I pointed out I worked with mostly API in assembly, I have worked with C++, Vb, Pascal, Fortran, COBOL, and many other languages [mostly due to the need to deal with the different calling conventions], but since I retired from that I never heavily got into the new languages like java or Python [which I have noticed many silly things about them], but I doubt I am familiar enough with the details of java or the MC modding API to be of direct use there. I would love to be of help, but it would be like starting over from the beginning to understand not just every detail of java, but also every detail of the MC modding conventions and interface. If you want some hot, trim anti-bloat super fast assembly code then I might be able to help, but java being a compile on demand effectively scripted language with ambiguous interface conventions and type conversions, I am guessing I would be a real pain in your butt considering your flippant, coarse, and impatient nature. My only point to you is while I am not an MC modder, I do understand many basic premises in programming including that you are always trying to find a solution, but it seems by your stance you are content to point the finger at someone else saying "it isn't me" and conclude that there is no solution, in essence trying to place irrelevant blame while just giving up.
    I don't even know if you tried to bring these shortcomings to the attention of the MC or Forge programmers, have you even filed a report to them about it? I would hope so, if not then why not. Programming isn't just writing code, many times you have to deal with coders of some API, and try to lobby them to make a fix. And until they do your job as a programmer is usually trying to create a work around for the mean time, but you don't just give up.

    Now if there is something I can actually help with, I would love to, I might be old but I am willing to help to the extent of my capabilities. Do you actually want me poking around your code pointing out things and asking millions of questions? I might be able to help with the lobbying process as I have done that before [more than I cared to], so if you were just being flippant then I would think you have an entirely different problem altogether, otherwise if you believe there is actually something I can help with, then lets talk about what that might be.
    Last edited: Oct 16, 2017 at 12:27 AM
  19. PseudoKnight

    PseudoKnight Well-Known Member

    The modding community have limitations in order to play nicely with each other. Doing things wrongly sometimes makes more problems and more work for everyone else, including yourself. It's more fruitful in the long term to be collaborative.

    I'm not sure it's appropriate to compare it to the Windows API. But I think it would be like rewriting part of Windows to make your application work exactly how you want it to (which, if multiple applications tried to do, would break Windows). Or you'd have to re-implement that part of Windows by accessing code you're not supposed to (which could easily break the next Windows patch). Now it could be possible to keep up with the patches (multi-version support can get messy), but that's a lot of extra work for someone who is a volunteer, when it could be fixed by the upstream programmers.
    Last edited: Oct 16, 2017 at 2:13 AM
  20. Jill Kitten

    Jill Kitten New Member

    I notice with /setblock you have to explicitly specify the block state, an example might be the dropper as specified here:
    https://minecraft.gamepedia.com/Block_states#Dropper
    in order to make it point the correct direction.
    Of coarse you have to know the initial state of the source to know what it is supposed to be in the first place, but WE having access to the data [as evidenced by its use of /schematic] one would think it should already have that [unless THAT is the real source of the issue].

    I notice the /clone command appropriately copies all the blocks state data, while it is clearly more cumbersome to use, it effectively does the same thing as //move. If //move was made into nothing more than a front end for /clone [where /move just calls /clone and then /set 0 the source] one would think it would be a decent workaround for //move [which of coarse still leaves /paste].
    The big difference between //move and /clone is move takes a number and an axial direction while clone takes coordinates, which means /move has to translate its selection points to the first 2 coordinates and translate its axial direction and magnitude relative to the start position to generate the appropriate final coordinate.

    I think i will check out /setblock and its support for block state a bit more to see where that goes...
    Last edited: Oct 16, 2017 at 3:35 AM
  21. Jill Kitten

    Jill Kitten New Member

    Oh yeah, don't I know it! Effectively you ARE rewriting windows API functions! Although you are not replacing them, you are just providing function calls that another programmer can call INSTEAD of the direct API call to fix an issue. A major part of my work was creating libraries that simplify and fix many shortcomings of the windows API, poking around at core windows API and making functions that allow other programmers to have a fix to get around common basic problems in windows. I usually stay away from 'int' calls [processor interrupts] if I can avoid it, but there have been those times I was forced to go there. And yes maintenance can be a cumbersome part of it, but that's why you spend so much time filling out bug reports and constantly lobbying API designers to fix an issue. I swear I spent more time doing that crap than actual coding, I definitely do NOT miss that part of it. But if you are waiting for upstream programmers to fix it for you 90+% of the time you will die of old age first, and of coarse they won't fix it if you don't lobby them to do so. The best experiences I had was when I made a fix, gave them access to it and they actually implemented it. Most of the time ego gets in the way and they don't like you pointing out their shortcomings but once in a while they wise up and realize someone solved their problem for them and then adopt it.

    Of coarse collaborative volunteering is definitely different than when you do it for a living where it is much more crucial to fix issues, and I get that it is just a game, but I just feel that throwing your arms in the air and giving up doesn't solve anything.
    Last edited: Oct 16, 2017 at 3:11 AM
  22. PseudoKnight

    PseudoKnight Well-Known Member

    I think you misunderstood what I was saying there. You're describing what Forge and Bukkit do, and I was talking about from a plugin/mod author's perspective.

    You're assuming that's not already happening. When I run into a Spigot issue I submit a ticket to that team with any details I can provide. Most of the time the issue is fixed rather quickly. The only times it hasn't was when the bug was really complex or something else needed to be done first before it could be fixed. There will be the occasional design disagreement (i don't envy those choices). Also there's the cases they also point upstream and the issue can be brought to the Mojang tracker. While I haven't interacted with the Forge team, I do see solutions cross pollinate between Craftbukkit/Spigot/Paper, Sponge, and Forge.

    You're interpreting this as giving up, but if you'll excuse a weak analogy, you're asking for a screwdriver in a bakery. I'm pointing to the hardware store next door. That's what they do.
  23. PseudoKnight

    PseudoKnight Well-Known Member

    I wish I hadn't continued this conversation. Because it's Forge I've had to make some assumptions based on things others have said, similar issues, and some skimming of code. It might be possible to workaround this issue within the API, but figuring that out is a pain because I'm not setup right now to solve Forge issues. Anyway, this is what WorldEdit is calling, if anyone wants to trace this.

    https://github.com/sk89q/WorldEdit/...om/sk89q/worldedit/forge/ForgeWorld.java#L172
  24. Jill Kitten

    Jill Kitten New Member

    I understood, I was just lamenting about Win API programming and agreeing w/what you were saying about the differences of that with collaborative volunteering.

    I love to hear that the open source collaborative process has such good support and how they tend to resolves issues. My experience has been mostly opposite of that because these guys [e.g. MS and their ilk] get burned out with their dead lines and thousands of issues and a hovering boss, they just want to push on to the next thing and they tend to try and ignore as much as they can, to get any attention to anything you have to persist until they actually investigate it, and typically if they cannot instantly reproduce the issue [which doesn't always work especially with intermittent problems] they push it all the way to the back or ignore it altogether and brush it off. I really wish the big programming houses would adopt a more collaborative stance with the wider programming community, but that won't happen since they would not open source their proprietary code and they really see outside programmers as competition as opposed to collaborators.

    Thanks for the link, I'll have a look.
  25. wizjany

    wizjany Administrator Developer

    i've skipped most of the conversation, but yea it's fixed in spigot because when it was originally reported to me (mar 2015 by the look of my irc logs) someone brought it up to the paper, they (paper team) patched it, and the fix eventually moved upstream to spigot proper.
  26. Jill Kitten

    Jill Kitten New Member

    Cool, I'm glad they took it right up, very handy. You wouldn't happen to have a link to the specific bug report on Forge would you [I am curious to see what they have done with it]?