Fantasy Grounds Unity engine

[lostsanityreturned]

For the record I am not asking for the features I mentioned, they are just features I appreciate :P

As for altitude. To be honest just the ability to track it without auto distance calculations would be enough. But again, that is something that can be implemented by us on the extension end without too much hassle.

[Three of Swords]

Token Altitude
One of the challenges that I mentioned in the stream with incorporating altitude is that you essentially have to either:
a) ignore creature height (i.e. treat all creatures as flat when measuring distances).
b) create a cube around creatures based on size (i.e. Large creatures are 2x2x2, regardless of whether it makes sense for the creature (i.e. horse, basilisk, etc.))
c) add data fields to every creature to denote the grid "height" of the creature (none of which is defined in the 5E game system as an example).

As for distance measurements, there is actually a mention in one of the 5E rulebooks stating that the distance is the counted just like range (i.e. 1 cube diagonally in any direction is still 1 cube distance). So, greater of vertical, horizontal or altitude is used as range for calculations. The calculation itself will be straightforward.

Option A is the only real option. Altitude should only represent how high the creature is off the ground. Nothing else. A halfling or the Tarrasque with an altitude of 10' are both 10' off the ground. If the height of a creature matters, the players can temporarily add 30' to the Tarrasque's altitude (or whatever they want for the height of the beast) for more accurate measurements.

[Ram Tyr]

Token Altitude
One of the challenges that I mentioned in the stream with incorporating altitude is that you essentially have to either:
a) ignore creature height (i.e. treat all creatures as flat when measuring distances).
b) create a cube around creatures based on size (i.e. Large creatures are 2x2x2, regardless of whether it makes sense for the creature (i.e. horse, basilisk, etc.))
c) add data fields to every creature to denote the grid "height" of the creature (none of which is defined in the 5E game system as an example).

Option A is the only real option. Altitude should only represent how high the creature is off the ground. Nothing else. A halfling or the Tarrasque with an altitude of 10' are both 10' off the ground. If the height of a creature matters, the players can temporarily add 30' to the Tarrasque's altitude (or whatever they want for the height of the beast) for more accurate measurements.

I would describe the situation as...
Option a is a special case of option b. (Where the third dimension is ignored, leaving all creatures flat.)
Option b is a special case of option c. (Where the cube around each creature is specified for the creature instead of just being based on size.)

So, a system that can accommodate option c can be utilized for option b or for option a.

So, a plan to build out option c can result in the use of option a in a system that does not define height in combat... such as 5e. A plan to build out option c can result in the use of option b in a system that defines height for all creatures by some attribute (like size). Obviously, building out option c also means when someone develops a system that uses the third dimension, FGU is ready. I could imagine this might be something even more important for things like vehicular combat... where the size difference between, for example, space ships might be significantly greater than the longest dimension of the smaller ship.

Now, obviously, none of this is an argument that therefore building option C is easiest. It is a question of planning for flexibility that may prove useful.

[Whaley]

Token Altitude
Currently, we have no plans to incorporate altitude into FGU scope for the first version. I've been making a pretty firm stand on scope creep when it comes to FGU, because we want to actually get it out the door at some point.

I did mention that it may be something we look at later. Remember that adding support for any one ruleset requires making sure that all the CoreRPG-derived ones work, so it's a slightly larger task than incorporating into a single ruleset.

One of the challenges that I mentioned in the stream with incorporating altitude is that you essentially have to either:
a) ignore creature height (i.e. treat all creatures as flat when measuring distances).
b) create a cube around creatures based on size (i.e. Large creatures are 2x2x2, regardless of whether it makes sense for the creature (i.e. horse, basilisk, etc.))
c) add data fields to every creature to denote the grid "height" of the creature (none of which is defined in the 5E game system as an example).

As for distance measurements, there is actually a mention in one of the 5E rulebooks stating that the distance is the counted just like range (i.e. 1 cube diagonally in any direction is still 1 cube distance). So, greater of vertical, horizontal or altitude is used as range for calculations. The calculation itself will be straightforward.

Adding support for automatic range penalty application is a different feature request, and it's unique to every game system (unlike altitude).

FGU vs. New Features
We are constantly weighing the addition of new features with moving the platform forward. That's one of the reasons why we decided to put out the word to hire more people once the KS campaign successfully funded. Of course, you have to assume as a business that new hires usually take 3+ months to bring up to speed enough to make an overall positive improvement (due to learning, time to train, additional overhead, etc.)

When a KS funds, that is just the beginning of the process; since we now have to deliver the software within a reasonable time frame. We made a decision last year that I personally needed to switch over from spending over half my time on ruleset enhancements and fixes, and focus almost entirely on FGU in order to make a push to get it out. Unfortunately, that means that some of the progress on ruleset improvements takes a back seat until FGU is out.

Cheers,
JPG

I appreciate the feedback, I was mainly asking for a future endeavor to add and not a prior to launch. I am more than happy with it being a community extension or module that we update ourselves. I think I am going to start learning how to do them myself. I honestly can't wait to get my hands on Unity and start to be able to use it! As for everybody else that replied, I appreciate the discussion we have had about the new features and desired features we want in the future.

[njohn858]

With the LoS tags on the walls and such, can a player move their token past that into the wall space? Or is there a 'tokens are not allowed to be placed here' aspect to it?

[pindercarl]

With the LoS tags on the walls and such, can a player move their token past that into the wall space? Or is there a 'tokens are not allowed to be placed here' aspect to it?

When line-of-sight is enabled, the players are prevented from moving their tokens outside the actively visible area. The visible area is calculated from the walls, ergo, walls can prevent player movement. The GM has no such restrictions.

[njohn858]

When line-of-sight is enabled, the players are prevented from moving their tokens outside the actively visible area. The visible area is calculated from the walls, ergo, walls can prevent player movement. The GM has no such restrictions.

That's awesome! I'm so looking forward to the Beta and being able to start working with it!

[Gix]

Our goal is to support the current ruleset model as much as possible to minimize disruption. This means that XML/Lua will continue to be the languages to use.

As we work through the Unity port, we may identify things we need to change to support the new platform; but our goal is to provide full support or backward compatibility when possible.

Cheers,
JPG

I realize you all have made the decision for backward compatibility, but could you comment on the possibility/likelyhood that in the future you might support JavaScript scripting and JSON data? (I believe Unity had support for JS at some point, even though they removed it as a development language)

[lochost]

I realize you all have made the decision for backward compatibility, but could you comment on the possibility/likelyhood that in the future you might support JavaScript scripting and JSON data? (I believe Unity had support for JS at some point, even though they removed it as a development language)

Imo, as Unity's programming language is C# it'll be way easier and efficient to use it instead of implementing another language's interpreter.

[Andraax]

Imo, as Unity's programming language is C# it'll be way easier and efficient to use it instead of implementing another language's interpreter.

The problem is that C# is a compiled language, and I don't think that SW is going to distribute and support a compiler. What's needed is an interpreted language. If we're adding new interpreters, I suggest Perl and / or Python.