Experimental APIs for FGU

[Weltenbrand]

Thank you.

There is no way to "block" GMs from changing to what they want using the image control panel. This is by design, and you should not subvert the GM from changing to what they want for their own games.

I disagree with this statement. I/we subvert GMs from changing a lot, by not suppling a option to change XYZ in a ruleset. I dont see why ditance calculations should be different.
If the map does not return half gridcells as 0.5m, the melee distance calculations wont work for my ruleset. And people often dont read manuals/wikis, therefore I would like to make it clear, that this setting should not be changed.
Adding a tooltip would also be fine, but it seems to me that this controls are part auf the FGU Programm and nor of the CoreRPG ruleset.

[SilentRuin]

Thank you.



I disagree with this statement. I/we subvert GMs from changing a lot, by not suppling a option to change XYZ in a ruleset. I dont see why ditance calculations should be different.
If the map does not return half gridcells as 0.5m, the melee distance calculations wont work for my ruleset. And people often dont read manuals/wikis, therefore I would like to make it clear, that this setting should not be changed.
Adding a tooltip would also be fine, but it seems to me that this controls are part auf the FGU Programm and nor of the CoreRPG ruleset.

You missed the point, its not that you "can't code it to happen" its that they do not want to code it to happen as that is one of the great features in FGU map tools, GM's can do what they want to make the data behave as they want. They are not going to give some 3rd party control over denying that control.

[Weltenbrand]

I understand it is a want. It is ok if SW don't want to change it.

You missed my point - "GM's can do what they want to make the data behave as they want." - no they can't. They can change the data as far as the current ruleset allows them (or maniuplate the db.xml).
They cant roll a skill check in DnD with a d2. Why ? the ruleset does not allow this, because it isnt "correct" in this ruleset.

It is fine to not provide this functionality to ruleset devs, but please dont use freedom for GMs as an argument for this.

[SilentRuin]

I understand it is a want. It is ok if SW don't want to change it.

You missed my point - "GM's can do what they want to make the data behave as they want." - no they can't. They can change the data as far as the current ruleset allows them (or maniuplate the db.xml).
They cant roll a skill check in DnD with a d2. Why ? the ruleset does not allow this, because it isnt "correct" in this ruleset.

It is fine to not provide this functionality to ruleset devs, but please dont use freedom for GMs as an argument for this.

They can with generic map tools. Which are not ruleset based. At least in the context of this conversation about distances and map definitions. If you're changing the topic to other specific ruleset data - then sure - what you can do is limited to ruleset (to some degree as there is still generic data that must be respected) because that is their data and their tools to control it.

[Weltenbrand]

I will move this to PM. I don't think the discussion is too philosophical to belong here.

At topic: I am doing the distance calculation with getPosition and getGridSize now without the getDistance functions. This appraoch should be not affected by "raw distance" ?
There is no "need" to anything. I made my point and dont find the counter argument to be convincing.

[LordEntrails]

I would be annoyed, and perhaps not even use a ruleset, if the ruleset did not allow me to use maps/images in a unit of measure that makes sense to me. Some folks want meters, some want feet. To refuse to allow people to change this when the built in capability is already there is... unfortunate. But that's just from a GM/User perspective w/o specific knowledge of your ruleset.

[SilentRuin]

Not sure why I allowed my counter argument to go offline but I'll share it here so that what he found unconvincing is at least public...

First this is only my opinion as I'm not a SW dev, low level ENGINE code data sets and controls are given access to rulesets (CoreRPG, 5E, etc.) on a need to use basis. Because it can really screw things up if non SW employees have access to manipulate whatever they want. So they limit what they expose and what you can do with that data/control. Anything in the ruleset code they provide is fair game for you to change. But not the ENGINE level code because people outside of their direct control messing with that level of the code can seriously make their overall product look bad. So they only have the DEV document expose certain API functionality. This whole thread is about a few new API's they are going to expose. They, as a rule, are cautious in exposing any of that stuff to outside devs (ruleset/extension).

And for sure when they expose controls (map tool check mark for raw distances check mark) that control that same data. Some things in the FGU product are not subject to "ruleset" control. Low level map functionality and behavior being one of them. That is ENGINE code. Smiteworks keeps control of ENGINE operational code and does not provide API's for them except in limited cases for use by rulesets. There are plenty of examples of this, but for sure this whole thread is about them opening up access to the ENGINE data operations with an API. It will be limited.

Will they change that at some point? Only if it does not risk any future changes or control of those changes they have planned for the future. Hence, a gate on what they will expose in the API to the ENGINE code/data.

[Weltenbrand]

Ok back to public if this is desired.

@SilentRuin
First this is not the part I find unconvincing, this is the last part you send me and I haven't responded yet.
Again I understand it is not exposed at the moment. You don't have to repeat how it is at the moment. This doesn't change anything on the argument if it is a good or bad idea.
I made the point that I think it would be good to be able to hide the control. The response was not "subvert GM" as the reason to not do this. Which I think is not a valid argument, like I stated.
I also stated "not wanting to do it" is accetable. This would habe been a way better answer in my opinion.

From your PM "you do not want to accept that they will not expose it for you. That is your point."
I written one piece of opinion to SW in a sub forum which is build to give feedback. Afterwards I disagreed with you answer and didn't say anything further regarding SW, just to you answer.
I seemed to have missunderstood your answer. I thought you have a reason why you think it should be like this. Now I get the feeling your answer is more "it is like it is". Which is ok, but not really helpful.
I think it is fair game to give feedback in a feedback subforum as client which generates more clients in his free time.

And a boolean flag to hide a control surely does not create a massiv esecurity flaw in the engine code.


@LordEntrails I dont want to disallow changing the units or grid cell size. I want to disable uncheck "raw distance". The ruleset needs to be half grid cells to be calculated as half cells and not rounded to full cells.

[LordEntrails]

Got it

[Weltenbrand]

I think I overlooked this bit:

imagecontrol.setDistanceDiagMult("*");

I can call this before every distance calculation, to get the desired behaviour? (And set it back to the value from imagecontrol.getDistanceDiagMult if I want do be nice.)
(with the side effect that the shown and the used distance are different)
But this wont work with the Token Package ?