Improve weapon templates

[LazyDope]

I know that v1 is not being particularly worked on anymore, however I made these changes for our personal group to use until v2 is released, so I thought I'd share them with the original project.

I found using the scale factor instead of a constant added to distance works a bit better for some of the larger sizes, and it also allows me to fix the cone shape so that it better matches at larger sizes. Cone size up to 7 now has an accurate size when the template is placed on the centre of the tile.

[LazyDope]

It seems like this might also be applicable to v2, though a rewrite of the template system might also be in the works

[BoltsJ]

I think this is based on a misunderstanding of the templates. The handle of cone templates should be placed on the token emitting the cone. The targeting code is programmed to ignore the user, so they won't be caught up in the targeting even if their space gets highlighted.

[LazyDope]

Even if that's the case, which doesn't make a ton of sense to me since it makes placing the templates more complicated, the size of the cones still grow at the wrong rate, since the mechanical size of the cone is based on side length, whereas the foundry size of the cone is based on the midline length. This means that larger templates are bigger than they should be.

I've found that using these values for the templates give them much more consistent sizes that correlates closer with the patterns in the rule book, for more than just cones.

[LazyDope]

Things like the cone on the right from the core rulebook would not be possible if placing the cone handle exclusively from inside the token, which leads me to believe the intention is that patterns originate from the edge of the token like range, rather than from inside it.

[LazyDope]

I encourage you to try these out and see for yourself how they feel. I originally made these changes because I found the existing templates to be a bit lacking for my Plasma Thrower wielding mech, where the cones never quite came out the right size, missing tiles here and there, or just simply not being size 7 by any stretch of the definition.

[LazyDope]

I also suggest using curved cones, rather than the straight ones, this also seems more in line with what the core rulebook has going on

[Eranziel]

Things like the cone on the right from the core rulebook would not be possible if placing the cone handle exclusively from inside the token, which leads me to believe the intention is that patterns originate from the edge of the token like range, rather than from inside it.

Both of those examples from the rulebook are easily doable using the current templates implementation.

I don't know what you mean about range starting from the edge of the token. Range is measured starting from one of the token's spaces, so that a space adjacent to the token is range 1.

Personally I find it much more intuitive to aim the templates when the handle is placed on the originating token. You can place the handle there and then just spin the mouse wheel to see what your potential options are, as opposed to having to change both the origin and rotation.

I'll try the changes out and see how they feel, but I'm inclined to keep the current angle and size. I agree that the round cones work better for hex grids, but these templates obey the world's cone shape setting so that is a choice left to the user.

[BoltsJ]

The decision for the template handle was made because it makes rotation during placement easier and is consistent with how burst and line templates are treated. The trade off for ease of use and consistency was deemed worth the inclusion of 2 extra spaces on the Cone 7 templates. This has been the behavior for the templates for a long time and changing it could lead to a lot of confusion.
Also, I have fixed the underlying issue completely in #725 , though that is on v12.

[LazyDope]

That's fair, though it puts them at odd angles instead of what seems to be the intended multiples of 15 degrees.

I encountered the most issues when using the cone 7 template, since with the current scale factor, a cone with a midline length of 7.1 actually has a side length of about 8.2 tiles, meaning a lot of tiles along the edge were getting targeted that wouldn't normally.

I also noticed some strange behaviour when the aiming the current template along the direction of one of the vertices of the hex, since the angle is less than 60, there would be a lot of ambiguous tiles, meaning the targeted area would be smaller than expected on one of these snap locations, which doesn't seem like ideal behaviour.

[BoltsJ]

I've considered making a tweak to the rotational snapping to lock cones to cardinal and ordinal directions and thus limit to the example orientations from the book, but I found out last night that people are using the free rotation to target with the "skewed" shapes. I may end up reducing the snap step to accommodate that use case.

[LazyDope]

Yeah I saw some of your work Bolts on the discord the other day and it seems like that has far outdone the work I've done here. I just made this tweak to make it work better for us at the time and thought I'd share, but the work you've been doing definitely seems like a more fleshed out solution.