Project organization

[Xarxus]

So i should build a rulest with all the LUA, a mod for the base manual and a mod for the advanced one?

[damned]

Yes.

[Xarxus]

Perfect, I get it. Thank you all for your patience.

[Valarian]

Let's say we have two paper manuals: the basic manual defines the races and these have 3 stats.

The ruleset (.pak) will contain your blank character sheet layout for the 3 stats, and spaces for adding whatever other attributes, skills, and stats are required by the basic game.
Your module (.mod) for the basic manual will contain the race descriptions and what the stats are for that particular race. As with the D&D 5e module, you can create the module entry so that a player can drag and drop the race from the module to the character sheet and have the 3 stats filled in.

The expansion manual, in addition to defining new races, adds 2 more stats, bringing them to 5.

An extension (.ext) will add the additional 2 stats to the blank character sheet defined in the ruleset.
Your module (.mod) for the advanced manual will contain the modified/new race descriptions and what the stats are for that particular race.

[Xarxus]

So the advanced mod will need the extention. What happens if the extension is not loaded?

Ty 4 all

[LordEntrails]

So the advanced mod will need the extention. What happens if the extension is not loaded?

Ty 4 all

It doesn't require an extension. But, depending upon how you want things to work you may want an extension.

For example some possible approaches for you;

A) One ruleset, no extensions
In this model you would create one ruleset that has all the mechanical capabilities for the basic and advanced game. You could allow GM options to turn on/off the display of such, or you could just have all the fields there and the 'basic' users would need to know that they don't fill them in. This would probably be simplest for the users as they would not need to use or understand extensions.

B) One Ruleset, one+ Extension
Here you would have a ruleset that sets up for the 'basic' game. Character sheets, rules automation, etc would only support the basic rules of the game. Then you could have one (or more) extensions that add the advanced character sheet fields, objects types (i.e. vehicles or similar), etc. This would require for the advanced fields that the extension be loaded when the campaign starts each time (extensions default to loading what was loaded last time). If someone disabled the extension in the future, you would have to make sure the campaign would still run with just using the basic rules functionality. Depending upon your architecture, this may or may not be easy. Also, users might get confused if their wasn't a clear (out side of FG) difference between the basic and advanced rules. But if this is a commercial product, then it would allow you to force users to buy the advanced product in order to use the advanced rules extension (not saying that is a good marketing strategy, just that it is a strategy).

Either way, all of the readable text and data objects themselves go in modules.

[Xarxus]

Ty all for your information.
@LordEntrails - I think I will proceed as indicated by option A. It is more linear and I think it is easier to use when distributed or published.

[Xarxus]

After a long time (I had to work a lot and Covid created a lot of problems - by the way, welcome back to everyone) I'll resume the discussion here.

I opted for option A that LordEntrails suggested to me.

Now I find myself having to manage this situation: I have a single ruleset and two modules. In the second module things are added (e.g. skills), but also changed. Is it possible to make sure that the version of the second module is used when this modifies the one already present in the first? If so, how?

[Xarxus]

Ok, it seems is not possible

[LordEntrails]

So you have two development campaigns (A & B). Each makes a module. And in B you copy a item (#1) from A and modify it? And then you have play campaign C and load both A & B?

If so, then when you are in C, there should be two entries for the item (#1), one listed as coming from A and one listed as coming from B.

If instead, in development campaign B you only modify the item (#1) from A, when you export it will not export the modified item (since it comes from a module). And therefore in Campaign C you won't see the changes from B, you will only see the item (#1) from A.