Creating a ruleset: finaly getting my feet wet

[JML]

So I first attempted to create a ruleset for a french RPG in december but didn't get enough time to go further than documentation reading and creating the first almost empty files, which at the time didn't produce much of a working character sheet.

I'm getting back to it and am tackling the first problems, discovering the ropes and quirks of FG framework and API.

Here's the thread where I intend to ask for help and/or enlightenment. I'll try to find answers by myself first, but please, be patient ;)

[Trenloe]

First thing - it’s not cleear if you’re starting from scratch or building on top of CoreRPG? It is strongly recommended that you build a layered ruleset on top of CoreRPG - you’ll inherit lots of base functionality and will be able to take advantage of future new functionality. All the recent commercial rulesets, and many community ones, are developed this way.

[JML]

Ok, so here's my first question…

After wrestling a bit with the XML code, I managed to display the first traits on 3 different lines as I intended, but was surprised to see them vertically aligning when I thought they shouldn't because of different width specified.

Here's the result:
22777

When Race width is set to 150, Taille and Main directrice to 50 each!

It looks like automated alignment took place, which is often a good thing, but does someone know what the rules are? I'd better know them if I want to stay in control of my design.

[JML]

First thing - it’s not cleear if you’re starting from scratch or building on top of CoreRPG? It is strongly recommended that you build a layered ruleset on top of CoreRPG - you’ll inherit lots of base functionality and will be able to take advantage of future new functionality. All the recent commercial rulesets, and many community ones, are developed this way.

I'm building on top of CoreRPG as recommended, which I understand perfectly and agree with. Thanks for your quick response.

[dulux-oz]

I'm building on top of CoreRPG as recommended, which I understand perfectly and agree with. Thanks for your quick response.

Hi JML,

What Trenloe has said is spot-on, 100% correct. Something for you to consider, in addition to what Trenloe has said, is to build your new Ruleset on top of the DORCore instead of the CoreRPG.

What is the DORCore?

The DORCore is a ruleset that itself is built on top of the CoreRPG and includes all of DOE Extension already built-in, plus a Universal Dice Roller and some other, minor (but nifty) tools. You get all of the benefits of the CoreRPG plus an expanded Dice-Rolling Engine plus automatic access to arguable the most popular Extensions ever written for Fantasy Grounds - all in one package.

So take a look at the DORCore (here (https://www.fantasygrounds.com/forums/showthread.php?42221-DORCore-An-Advanced-Beta-Release-Of-A-New-Ruleset)) and consider it for the basis of your new Ruleset - and good luck, its a big job you've set yourself on but a very, very rewarding one. :)

Cheers

[Trenloe]

Ok, so here's my first question…

After wrestling a bit with the XML code, I managed to display the first traits on 3 different lines as I intended, but was surprised to see them vertically aligning when I thought they shouldn't because of different width specified.

Here's the result:
22777

When Race width is set to 150, Taille and Main directrice to 50 each!

It looks like automated alignment took place, which is often a good thing, but does someone know what the rules are? I'd better know them if I want to stay in control of my design.
This will more than likely be due to anchoring on a control and inheriting sizing information from that control. Some info here: https://www.fantasygrounds.com/wiki/index.php/Developer_Guide_-_Rulesets_-_Interface#Anchoring

Without seeing your XML we really can't see why this is happening. Please include examples of your code in future so we can help further. :)

[JML]

Anchoring must be the reason behind it as you point out. I took a look at the documentation regarding anchoring but didn't see anything regarding size inheritance. May be I missed it.

Anyway here's the code I used:


<sheetdata>
<frame_char name="cadreDescription">
<bounds>15,0,-29,135</bounds>
</frame_char>
<string_labeled name="race">
<anchored to="cadreDescription" position="insidetopleft" offset="15,10" width="150" height="20" />
<labelres>char_label_race</labelres>
</string_labeled>
<string_labeled name="genre">
<anchored to="race" position="right" offset="5,0" width="50" />
<labelres>char_label_genre</labelres>
</string_labeled>
<string_labeled name="age">
<anchored to="genre" position="right" offset="5,0" width="50" />
<labelres>char_label_age</labelres>
</string_labeled>
<string_labeled name="taille">
<anchored to="race" position="below" offset="0,15" width="50" height="20" />
<labelres>char_label_taille</labelres>
</string_labeled>
<string_labeled name="poids">
<anchored to="taille" position="right" offset="5,0" width="50" />
<labelres>char_label_poids</labelres>
</string_labeled>
<string_labeled name="beaute">
<anchored to="poids" position="right" offset="5,0" width="50" />
<labelres>char_label_beaute</labelres>
</string_labeled>
<string_labeled name="main_directrice">
<anchored to="taille" position="below" offset="0,15" width="50" height="20" />
<labelres>char_label_main_directrice</labelres>
</string_labeled>
<string_labeled name="heure_naissance">
<anchored to="main_directrice" position="right" offset="5,0" width="150" />
<labelres>char_label_heure_naissance</labelres>
</string_labeled>
<string_labeled name="haut_revant">
<anchored to="heure_naissance" position="right" offset="5,0" width="50" />
<labelres>char_label_haut_revant</labelres>
</string_labeled>
</sheetdata>


It's very raw as I'm only testing how things work for now. I hope it'll get much prettier sometime ;)

By the way, I also was surprised to have to explicitly give height on each new line to display the horizontal underlines. Otherwise they don't appear. I obviously have much to learn…

[JML]

@Dulux-Oz
I gave a try to your great extensions already and will get back to you with suggestions someday, but I'm still wondering if I'll ask permission to make this an official ruleset and am wary about copyright future concerns if I'm lucky enough to be granted the aforementioned permission.

Thanks for the suggestion anyway. I already thought about it and will keep it in mind.

[damned]

Anchoring to different things like insideleft or right etc have different values that are inherited and that are required.
It can be confusing!

[JML]

Now that I know where to look at and what kind of surprises may be encountered I'll try to note them. Is there a place to reference them ?

Thanks for your quick answers guys.

[damned]

some snippets from Moon Wizard in a recent conversation on discord...

position="left" (or right) will bind both top and bottom anchors.

If you only want to bind one anchor, use "lefthigh" or "leftlow"

https://cdn.discordapp.com/attachments/389093811021807616/423329143296622592/600px-Anchors.png

left/right bind three anchors, and topleft/bottomleft bind two anchors.
You'll notice that "left" has three arrows.
in that graphic.

[Varsuuk]

OMG, I get it now, I just wrote a 2 point, 2paragraph description of what I would think happen with a position=right asking what you meant by binding top and bottom and what those squares meant and.... then I had an epiphany and the diagram makes total sense now. Wow, I knew it would be obvious once I saw it.

So, if I got it right, a simple short assertion should verifying this: if you bind to right, your left edge is set by right edge of TO and because your top position and your bottom position are bound your height is set as well. If instead it were righthigh, only your top and left sides are set. so setting height means your control extends below the TO control if the height exceeds height of TO control. If was right low, the same values would mean your control extends higher than the TO control.

Correct?

Wow, if I am right, it was so obscure before now to me.

[JML]

Totally agree with Varsuuk. Thanks a thousand times Damned. I saw the pic in the documentation, but didn't get that the arrows had this meaning. I'm going to test that…

[Varsuuk]

Also, since there are both child-route and attribute-route ways of specifying <anchored> data, is there one that is better for FG to deal with?

I would go the attribute way due to being more concise (irony,, huh?) way of seeing all the data. But I’ll pick technical over human reasons if there are good ones.

[Trenloe]

Also, since there are both child-route and attribute-route ways of specifying <anchored> data, is there one that is better for FG to deal with?

I would go the attribute way due to being more concise (irony,, huh?) way of seeing all the data. But I’ll pick technical over human reasons if there are good ones.
If you're doing dynamic resizing (e.g. if you want to allow the width or height of a window to be adjustable) then, assuming your GUI design allows for such things, it is easier if you go with locations and sizes based off anchoring on other controls. They you usually just have to change the size/position of one control and the others follow - if the GUI design allow for it.

[Varsuuk]

Yup, so far haven't used any "absolute" numbers. All but one have been the single position= version using the chart. The one where I didn't do that was because I wanted it to anchor between 2 different controls on left/right.
So, what I meant to say is if there was any downside to using
<anchored position="bottomright" offset="10,5" ... />

vs the one with child elements:
<anchored>
<position>bottomright</position>
<offset>10,5</offset>
</anchored>

PS - pardon any syntax/content errors above - tossed the example out of my head.

[Bidmaron]

One potential issue I know about is if you use attributes vice children, you cannot get to them through scripting using the array syntax for accessing control specifications. If there are api calls, those should work but be advised that without fastinit FG does a depth-first build and controls are not built where api calls will reliably work until children are first constructed. This is why you cannot get control sizes in onInit calls of controls unless you use the array structure, and that won’t have what you need if you use attributes.
The plus size to attributes is that the arrays take up less storage. Sure makes modders’ lives harder though.

[Trenloe]

Accessing control sizes etc. in array structure is only accurate if your controls cannot be resized. Having static windows is definitely easier, but very often you'll soon find that you (or people who use your code) want to resize a window - make it bigger or smaller, and controls need to adjust as part of this. Relative anchoring helps a lot here.

[Varsuuk]

Relative anchoring so far is not on the table for consideration - I’ve so far assumed it to be the only way to go (considering vast differences in screen real estate) - granted I speak from inexperience, but everything I am doing at the moment is based on anchoring vs direct placement.

My question was about pros and cons of the WAY i >described< said anchoring. When someone offers me multiple ways of doing something in code I always fall back to two considerations:

1. Which is more efficient (sub grouped by considerations of speed and or size)
2. Which is clearer to read/understand (ease of typing, etc never comes into play for me)

Depending on the speed (and to lesser extent, memory) delta I usually go with clarity except where the delta is sufficient impetus and the context is materially impacted by the performance gain.

Otherwise, “write once, read a bleeploadtimes more over the years” comes to mind as my driving rationale for code that reads as clearly as I can make it because I have a poor memory to begin with.

[Trenloe]

Relative anchoring so far is not on the table for consideration...
I would strongly suggest using relative anchoring if there is any possibility of the window being resized. It is especially useful for column headings and rows in a windowlist, where the overall window might have the width resized.

And using shorthand notation anchoring will help a lot if you need to make tiny tweeks to control placement. If you use hard coded dimensions you'll probably have to change most control placements if you need to shift control positions slightly.

[Varsuuk]

I’m sorry Trenloe, I really suck at written communication. I’m sorry for wasting your time by being so bad at this and than you for your patience.

Short: I am and have always been using the below/ aboveright etc position based system and so far no x,y,w,h style placement.

I also chose he attributes version of assigning the above values ca child tags because it was briefed and easier to get full sense of it without mentally parsing xml tags. I just wanted to know if there were any CONS to using attributes cvs child tags since both were described on the wiki as valid.

Again, I’m sorry T.


Relative anchoring so far is not on the table for consideration[Edit: BECAUSE I *ALREADY* CHOSE RELATIVE ANCHORING] - I’ve so far assumed it [Edit: it=RELATIVE ANCHORING] to be the only way to go (considering vast differences in screen real estate) - granted I speak from inexperience, but everything I am doing at the moment is based on anchoring vs direct placement.

My question was about pros and cons of the WAY i >described< said anchoring. When someone offers me multiple ways of doing something...

[Bidmaron]

Accessing control sizes etc. in array structure is only accurate if your controls cannot be resized. Having static windows is definitely easier, but very often you'll soon find that you (or people who use your code) want to resize a window - make it bigger or smaller, and controls need to adjust as part of this. Relative anchoring helps a lot here.

Hey, Trenloe, a question here: are you saying the array is only produced at initialization and not updated? I am using that technique in my dragline, and it seems to be working fine, but I use the getSize calls once I have initialized, so I never knew the arrays weren't getting updated as I resized the control because I only looked there at initialization. Useful to know if that is true though.

[Trenloe]

but I use the getSize calls once I have initialized.
Now I'm confused - how are you getting the size of the controls? Through getSize (https://www.fantasygrounds.com/refdoc/windowcontrol.xcp#getSize)API calls or through traversing the XML definitions? I was referring to your comment of traversing the original XML definition through the array structure.

If you use the getSize (https://www.fantasygrounds.com/refdoc/windowcontrol.xcp#getSize) API call you will get the current size at that point.

[Bidmaron]

Sorry, Trenloe when I get home I will post my code. It works so I am doing something right.