FGU: Developer question, Controls

[celestian]

I asked some questions about FGU and they did make it on FG Friday but I don't think I was clear on the details.

Specifically:


Will FGU use actual controls with "standard" expected results for interface parts like listboxes, radiobuttons, comboboxes, cascading menus, miller type columns, tabs, forms,etc?

What I mean is, the current API doesn't allow us to actually use standard controls (that I know Unity has) like combobox, checkboxes, trees and cascading menus. What we do now is just manipulate windows in a tricky way to make it act like those controls. Sometimes that doesn't work out so well ;(

Will we actually get access to those types of controls and their expected behaviors?

For me, this seems like one of the biggest bits of the API that could improve the UI immensely. So, I'm hoping we will get access to those controls through the API. I'm really wanting to use some dynamic cascading options in FGU at some point ;)

[Moon Wizard]

No, the standard Unity controls were not able to be used for implementing the interface. They do not work well for the customizable tabletop approach used in FG with all the hooks and customizations we allow.

Regards,
JPG

[celestian]

No, the standard Unity controls were not able to be used for implementing the interface. They do not work well for the customizable tabletop approach used in FG with all the hooks and customizations we allow.

Regards,
JPG

That's very unfortunate. I would have thought that adding new options similar to how we currently have stringcontrol or scrollercontrol but for combobox/etc would have been a simple "wrapper" feature added in. I obviously don't have a background with FG's API backend functionality so can't say much but ... very sad to hear this.

[Tabulazero]

You mean that FGU will not support basic controls such as buttons, checkboxes, radiobuttons or comboboxes ?

That is sad.

[Oberoten]

You mean that FGU will not support basic controls such as buttons, checkboxes, radiobuttons or comboboxes ?

That is sad.

It most likely will as it is stated to be backwards compatible. All this means (from how I understand it) is that it won't be using Unity's standards for it.

- Obe

[Tabulazero]

It most likely will as it is stated to be backwards compatible. All this means (from how I understand it) is that it won't be using Unity's standards for it.

- Obe

That is indeed one way to interpret Moon Wizard's comment I had not thought about.

[celestian]

That is indeed one way to interpret Moon Wizard's comment I had not thought about.

They are going to continue to use the simulated controls. These are just windows with the various options. I was hoping for more standardize controls. The combobox for example as it exists today in FG has very strange behaviors.

[Moon Wizard]

There is no comboboxcontrol built into the FG client. The current implementation is an advanced template that uses a window list and a bunch of string fields to simulate a combo box.

We really want to add in additional control types at some point; but we had to limit the scope of the first release to get stuff out the door. Plus, backward compatibility of 10 years of code on a new platform is much more work then anyone thought, especially when adding in new image features.

Regards,
JPG

[Minty23185Fresh]

I apologize up front if it seems as though I am being obtuse, but this discussion seems to imply that not only is content (e.g. purchased modules) going to be compatible with FGU so is community authored extensibility?

Restated: the extensions I have written will also be compatible with FGU? This seems, to say the least, improbable, if not downright impossible.

[Trenloe]

Restated: the extensions I have written will also be compatible with FGU? This seems, to say the least, improbable, if not downright impossible.
In FGU you won’t have direct access to the Unity libraries, just like in FGC you don’t have direct access to the C# libraries.

The BIG thing with FGU is that it’s backwards compatible with as much existing FGC DLC, extensions, etc.. It still uses LUA for coding and XML for GUI specification - just like FGC. Hence why all of the Unity controls etc. aren’t available within FGU. Moving the FGC LUA/XML engine to FGU is one of the main reasons that it has taken so long, but is a major piece of functionality to allow code/DLC/campaigns from the last 10+ years of FGC to run in FGU.

[Moon Wizard]

Much of the API will work as it does in FGC, but there are quite a few changes to the API coming, especially around image controls.

If extensions do not modify image-related code or APIs, then they should mostly be okay. Anything that uses image APIs will need to be rewritten. There also might be some things we have to work through with custom dice handlers as well, due to the more advanced custom dice expressions.

We tried as much as possible to preserve backward compatibility without limiting our ability to add new features. The CoreRPG code will already be adjusted to handle the image API changes.

Please treat this information as development discussion, and things can change during continued development.

Regards,
JPG

[Darce]

Any thoughts about developement for particle effects? Seems like one of few things that Roll20 has that FGC does not in the VTT comparison charts.

[LordEntrails]

Any thoughts about developement for particle effects? Seems like one of few things that Roll20 has that FGC does not in the VTT comparison charts.
Check out the weather effects video on the KS page. https://youtu.be/M48W68MMQtc