Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Area synchronization with WorldEdit selection #76

Open
DaniDipp opened this issue Aug 19, 2023 · 4 comments
Open

[Feature Request] Area synchronization with WorldEdit selection #76

DaniDipp opened this issue Aug 19, 2023 · 4 comments
Labels
priority: low this issue only has minor effects - adressing it is not immediately required status: scheduled the resolution of this issue is scheduled for the next release type: enhancement this issue requests additions or enhancements to the codebase

Comments

@DaniDipp
Copy link

DaniDipp commented Aug 19, 2023

It would be great if the mod could listen to WorldEdit's CUI events and update the area selection based on the current WE selection. This would make it easier to make precise adjustments, and allow the (optional) use of the WE selection tool, which many people are already familiar with.

Related: WorldEditCUI mod

@gliscowo
Copy link
Owner

I am genuinely somewhat confused where the real value with this originates. While I can appreciate that it's potentially redundant to manage two separate selection boxes, I don't see why you would want them to match up either. Both of these tools serve fundamentally different purposes and in my experience you update your WorldEdit selection much more frequently than the Isometric one as you make edits and then only select the final result for rendering once or twice.

I'd appreciate some concrete examples of when this is useful (and how often this would occur), because it's not impossible there are usage patterns where this genuinely makes sense that I'm not aware of

Cheers

@DaniDipp
Copy link
Author

DaniDipp commented Aug 19, 2023

Thank you for the reply, it made me realize that I didn't fully think this through, originally.
Since I have WorldEditCUI installed on my setup, I already have a selection box in my world for that, and if the two were synchronized, they would just overlap, reducing screen clutter and making it easier (for me, who is very familiar with worldedit selections) to adjust the bounding box.

What I did not consider is that people without WorldEditCUI would just see the isometric-renders selection bouncing around with their WE actions, which is obviously not intended, especially if they already framed the area that they want to render already and are making just a few last adjustments with WE.

My updated suggestion to consolidate these thoughts is that rather than synchronizing the two fundamentally different areas, there could be a subcommand like /isorender area worldedit which would be similar to /isorender area x1 y1 z1 x2 y2 z2, but ask WorldEdit (if available) for the current bounding box instead. This would give users the flexibility of the WorldEdit selection if they want it, while also leaving the two area selections separate for their specific purposes. I also imagine that it would be easier to implement ^^

@gliscowo gliscowo added type: enhancement this issue requests additions or enhancements to the codebase priority: low this issue only has minor effects - adressing it is not immediately required status: scheduled the resolution of this issue is scheduled for the next release labels Aug 19, 2023
@gliscowo
Copy link
Owner

I do agree that having the option to copy the selection from WorldEdit when appropriate could be useful, I'll look into implementing it once I get the time

Cheers

@jokil123
Copy link

jokil123 commented Feb 4, 2024

The real value of this proposal is the non cuboid selections in WorldEdit. When trying to render parts of a larger structure, the cuboid selection often lacks the fine grain control the poly selection offers for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: low this issue only has minor effects - adressing it is not immediately required status: scheduled the resolution of this issue is scheduled for the next release type: enhancement this issue requests additions or enhancements to the codebase
Projects
None yet
Development

No branches or pull requests

3 participants