Hi!

I just recently added support for GriefPrevention to use WECUI visuals when making WE selections. The one issue I'm having is WECUI only supports a single selection at a time which is perfectly fine for what this CUI is designed for. I was just wondering if it would be feasible to add an Event I can use to pass multiple selections. Essentially, I want to be able to show multiple claims using WECUI visuals in the area when a player shift-clicks with a stick in GriefPrevention. Let me know if this is feasible, if not then I'll try to think of something else.

Thanks!

Hey blood.

Yes that's certainly possible. The simplest way I can think to do it is to add a new message types with + prepended or something like that which adds selections rather than clearing the current one. This would allow compatibility with worldedit when being used at the same time. It would then just be necessary to add an extra message to clear all selections. I assume you're just pumping messages into the relevant channel to make this work?

At the moment a cuboid selection would be:

s|cuboid
p|0|99|123|456|789
p|1|34|567|964|321

but of course the next s|cuboid would clear the selection. I would propose doing something like

+s|cuboid
+p|0|99|123|456|789
+p|1|34|567|964|321
+s|cuboid
+p|0|12|55|754|33
+p|1|44|16|900|50

to add multiple selections and then

+s|clear

to clear them all later on?

Would that work for you? Could also add some colouring or other info to differentiate the regions. Eg.

+s|cuboid
+c|FF0000
+p|0|99|123|456|789
+p|1|34|567|964|321
+s|cuboid
+c|00FF00
+p|0|12|55|754|33
+p|1|44|16|900|50

Obviously with some client-side options to enable server-specified colours per region.

Thoughts?

You know, I wonder if we should/could actually provide some kind of identifier to each selection, that way you could also remove individual selections. I never thought about it before, but it might be interesting if you could see other players selections in worldedit itself.

Indeed, in fact it actually makes sense to use IDs since then you can arbitrarily reposition regions later on without having to resend them all if one changes.

Yeah all of that is possible, I mean just sketch out what things you want and I'll look to getting them implemented. We can bump the WECUI protocol version to 4 to support the required changes.

UUIDs or anything distinctly unique would be my preference too. I was going to suggest a <pluginid>:<number> be used (eg. griefprevention:0) to avoid overlaps in ids but UUIDs works just as well.

Would still need a command to clear a specified selection as well.

I actually made a mod which does exactly what we're talking about a few years ago, called VoxelVisualiser. It had a server-side API which multiple plugins could use to send region visualisations to the client, putting something like this into WECUI is perfectly logical though so I'm happy to fold it in.

OK here is essentially what I would like to have for GriefPrevention

• s| would support an additional UUID for identifying a selection. So example of this would be
  s|cuboid|11137e44-b7cf-4e9c-bc6a-508cc912a657
s|clear would support a UUID param for clearing specific selections. If no UUID is passed then it would simply clear all selections as it does now. An example with UUID would be
  s|clear|11137e44-b7cf-4e9c-bc6a-508cc912a657

• c| type would be added for color and support the following params
  c|grid|edge|point1|point2

• As for controlling amount of grid lines, not really sure what would be a good way to go about handling it. Perhaps a new type g| that takes a param for how much spacing(stepping) should occur between lines. So a few examples
  g|0 would have no lines in between the edges
  g|1 would skip a line after every line
  g|2 would skip 2 lines
  and so forth
  Note: I'm only familiar with the cuboid grid, not sure how this would work with other types of selections.

• An additional feature to set block corners(fake) would be nice as well but I can easily handle this on my end for the time being. This is just to spice up the visual so its easier to see the corners. I do see WECUI already has a corner for each point but it wouldn't be a bad idea to be able to alter the visual block for each corner. I always thought this feature in GP was quite nice.

I think this would be a good starting point and we could expand these ideas further. Let me know what you think.

Thanks!

Being able to identify selections would be very useful for GriefPrevention as I would be able to allow a player to toggle on/off one or more claim visuals easily instead of having to resend all the selections again. I think using UUID's as the identifier would work good but no idea if that is what you want. GP claims already use UUID's, so I would simply pass the claim UUID as the selection identifier. So perhaps something like the following

+s|cuboid|11137e44-b7cf-4e9c-bc6a-508cc912a657
+c|FF0000
+p|0|99|123|456|789
+p|1|34|567|964|321
+s|cuboid|22237e44-b7cf-4e9c-bc6a-508cc912a657
+c|00FF00
+p|0|12|55|754|33
+p|1|44|16|900|50

Now of course, the UUID could be replaced with a simple int but I've always preferred UUID as an identifier.

The c| support would be great as I would definitely need to be able to distinguish claim types by color. Could the c| take color codes for grid/edge/points? so I would simply pass more colors where needed such as

+c|00FF00|FF0000

Another feature that would be useful is ability to space out the rendered lines. So if I wanted to visualize an area with only edge lines and no grid or space out each line in the grid.

Okay so the current state of play is as follows:

• Protocol version is now 4. You can detect the correct WECUI is available by checking this value
• All multi-region commands are prefixed with + to separate them from the normal selection commands, this provides backwards compatibility with WorldEdit since WE can continue to work alongside other consumers sending messages to WECUI
• +s|cuboid|<guid> will create a new cuboid region
• +col|#123456|#123456|#123456|#123456 will set colours for the region elements (8-digit RGBA values supported too, eg use #FFFFFF55 for a partially-transparent white)
• +grid|<spacing> can be used to set spacing, any valid double can be specifed, values less than 0.5 will cause the grid to be turned off
• +s|clear will clear all regions (except the WorldEdit selection of course)
• +s|clear|<guid> will clear a specific region
• +p|0|~|~|~|~|~ will set the specified node to follow the user's eye position (use +p|1|~|~|~|~|~ for the second point)

Video demonstrating all of the above:

I have also set up my Jenkins to build the branch so artefacts are available here (1.12)

I was able to test everything last night and it all seems to be working as expected!

Thanks for the support. I'll let you know if I find something else I need .

Once you're super-duper sure, I'll make a release. I'll sit on it for a bit in case you find anything else you need though!

No problem, I'll get a bunch more users to test just to confirm everything is stable. I'll let you know when that happens.

Looks cool, I'll probably play around with some WorldEdit related stuff using this, when I get the chance anyways.

Yeah, being able to view other user's selections would be a really cool feature 😄

@Mumfrey So after further testing I've come across another issue.

http://i.imgur.com/GBv35vR.png

As you can see in above screenshot, the grid seems to look odd the further out it renders.

Also, I'm wondering if you can provide a feature where grids are not seen through blocks. So with the above img, the grid below the player would not be rendered. This would allow for a more "immersive" experience while inside a claim and visualizing the outer grid. Perhaps I could enable this feature by sending another param? I'm imagining it would be similar to how world borders are rendered.

That's fixed by a2a5e93.

Also, I'm wondering if you can provide a feature where grids are not seen through blocks. So with the above img, the grid below the player would not be rendered. This would allow for a more "immersive" experience while inside a claim and visualizing the outer grid. Perhaps I could enable this feature by sending another param? I'm imagining it would be similar to how world borders are rendered.

Yeah that's possible, Could add a param to the grid message to determine the draw type.

@Mumfrey Thanks! If you could add a draw type to grid, that would be great! Unless you think this would be better to be selected in liteloader settings for WECUI? A player may not want to see anything rendered through blocks so they could select it if this was the case. Similar to the "Always on top" setting. However having both options wouldn't hurt either =)

Thanks again.

EDIT: And before I forget, could you make a 1.10.2 build for latest commit?
Thanks

Sending +grid|<spacing>|cull now culls gridlines which are behind terrain (client-side "always on top" mode still overrides however)

I have also merged the changes onto the backport branch so Jenkins should build it.

OK here is another issue

http://i.imgur.com/4ddetVf.png

Odd rendering of grid when in a distance.

Here is another image when I move closer

http://i.imgur.com/qGCnvbO.png

I just realized I derped and updated my liteloader jar and not WECUI =). I'll do a proper testing now.

Update: Works perfectly as described! Amazing! Thanks again, this will be a huge help for GP.

Is it possible this is a weird interaction with a mod, can you replicate this in a vanilla client setting?

The grid stops rendering at a set distance from the player so that only a total number of grid lines are ever rendered, if you're seeing undrawn grid lines then it's culling because it believes the camera is in a different location than it actually is.

Is there any pattern to when this happens? Are certain modded blocks in range, are you in spectator mode perhaps?

Actually I can see you're not in spectator mod because you're holding an item, so I guess that's not it. I'll investigate but it's pretty weird. I wonder if it's a strange interaction between the grid spacing code and the culling logic.

I've been testing with just SF and no mods. It seems it tries to render the box at all times. I don't recall seeing a grid without all 4 sides attempting to render. Is there a way to disable this to see if it is causing the issue? So essentially I only see based on my distance just like anything else in game.

Ok I see what the problem is.

Basically the existing code culls at 128 blocks away, this is because with a 1-spaced grid, by the time it gets 128 metres away the lines are so close together it's basically solid anyway. The issue is that with wider spaced grid lines (which of course weren't possible before), 128 metres is actually close enough that you can see the grid lines stop. Basically all i need to do is multiply the cull distance by the spacing to ensure that it it always draws right up to the visible limit.

To be clear. It always renders the sides of the cube, but with selections thousands of blocks across, rendering all the gridlines would use up so much memory and take so long that it would crash most computers. So what I do is say you're standing at x=64 and z=0, on the x plane it's gonna render grid lines from -64 to 192 and on z from -128 to 128.

This is a simple fix which wasn't easy to spot because I hadn't realised it was the spacing which was causing the apparent glitch.

Issue seems to be resolved

http://i.imgur.com/9f77MBu.png

http://i.imgur.com/johQy6A.png

Thanks for the quick fix =)

So I think everything is now working well enough to push into a proper release. I plan on pushing my GP update tonight so it will be great to have this rolled out as well for all versions (1.10/1.11/1.12)

Thanks again for all the help

Roger that.