Hi,Quote:
Originally Posted by BushViper
Yep, I agree the details are out of date, and most do exist in the pages of this thread. I've got some fixes to make to some of my other extensions and will get around to updating the forge/DMsGuild listing for all my extensions as soon as I get time.
For the default suffix the usage 1 square is 5 feet is assumed, I dont think you need to do anything with the suffix unless you want to have 'km/miles' level spell tokens !! The system already includes a suffix 'm' for meters at '1.5' for a grid set as meters. This is used to convert from grid squares to the graphic representation of the token that is always calculated in 5 feet units of resolution. Normally a spell token will be '70 pixels per 5 feet' and this is normally 1 square in 5e. The value comes from the number of 'meters in 5 feet' ( 1.524, rounded to 1.5 for ease. )
Collision percentage reduces the size of the radius of the shape by that amount. So a 30 foot circle will be reduced to a 30*Percentage foot collision circle. This can be used to make the grid selection for target smaller than the spell token, so you do not get selection on squares that get a tiny fraction of the circle ( or token shape ) just going over the corner of a square and hence selecting that token. Normally by about 95% size of collision a 30 foot circle would select what most people playing on a grid would consider the correct selection of a person stood on the 45 degree axis of the center. ( This typically been the point on a circle that just goes over the corner of that square by a tiny amount. ) The system is design to allow the flexibility of been 'perfect' selection to allow reduced collision to get closer to what players would expect as a grid.
The other graphics options are to do with a software render that convers and scan the spell shapes into 'pixels' that represent grid squares. You can configure this to also have a 2x2 subpixel selection per square. ( Mainly for games that allow snapped by not in square positions, ie player token center on the cross junction of a sqaure. ) Again this then matches what pixels the square token is in, and if any overlap then the token is selected. Most people do not use this method, and just reduce the collision size, which results in the same basic outcome. It was mainly a debug system designed to allow GM to see what squares are 'hit' for the token at a given collision and position. So they can tune a spell token to cope with a reasonable grid selection for a spell token that is centered on the center/line edge/corner of a square and grid output of what squares would have been selected.
But I expect most GM just use the basic templated xml files listed at the top, as this might cause the odd edge case extra/missing selection depending on how that GM runs the game.
Our group is reasonable flexible and tend to just fix any slight miss selected or 'on the edge of a spell token' cases with a quick confirm with the current GM at the time, so we just use the basic imported xml at full collision between the shapes.
Because of this I've not updated much of these details on the forge, because the average user does not want to see pages of advanced descriptions and think its going to be a massive pain to configure... when in fact most people I'd guess just import the xml template and just play. ( Which is how its basically designed to work... )
The system is already configured for all rulesets that run the 5 units (feet) to one square default, it has a '*5' factor for 4e as this defaults to 1 unit per square, and has a default suffix for the users that want to use 1 unit as meter per square. I dont think people put spell tokens down on travel maps that are in km/miles level or 100 feet per square type things. ( Tokens would be so small on these you would never be able to select them, which is why FG defaults player token to one square... implying you are now a 100x100 foot character which you obviously are not.. )
Hope this help,
pete
