ExprMidpointLocations

[Absolutionism]

Problem

Currently is no quick and easy route of getting the center location from two locations.
The only current way I know to achieve this, is
set {_center} to {_loc1} ~ ((vector from {_loc1} to {_loc2}) / vector(2,2,2))

Solution

Adds ExprCenterLocations that does this.

Testing Completed

ExprCenterLocations.sk

---

Completes: none
Related: none

[ShaneBeee]

Just going to throw my 2 cents in here.
This in my opinion seems like bloat.

Skript should focus on the language and the Bukkit API itself.

Skript shouldn't be putting on focus on doing math that a Skript user could do themselves.
This feels more like something meant for an addon.

Again, I repeat, just my opinion.

[sovdeeth]

I'm kind of ambivalent on this, since it seems like a really easy thing to do with existing tools. It's a bit clunky since you have to get a vector or do math on x/y/z, though, so i see the appeal of a simpler manner. I don't mind it either way.

That said, I'm strongly against calling it the center point. I think that muddles the waters between the existing center expression (and could cause syntax conflicts as is currently written). I would stick entirely to the term midpoint for this.

I'd like to comment that the pr template does ask you to argue why the given problem needs solving, and I think just the fact that no QOL expression exists is not reason enough. I'd like to see some arguments as to why it needs to be added and why it's better than whatever you can currently do.

This is also missing any documentation of testing completed.

[Absolutionism]

So you want only [the] midpoint (between|of) %location% and %location% + from ... to ...

[sovdeeth]

So you want only [the] midpoint (between|of) %location% and %location% + from ... to ...

well midpoint from x to y doesn't make much sense, but the between/of seems fine, yes
(also fyi you can divide the vector by 2 directly, instead of using a vector of 2s)

[sovdeeth]

I'm not sure this is the best way to approach this. Consider midpoint between {_vec} and vector(1,2,3). Wouldn't {_vec} be able to return a location?

[sovdeeth]

checks need to be done regardless, the parse check is not air-tight