Hi, Hello. New Here. Advice of Repos Please

Hi all,

I'm currently um, learning and developing a lot of architecture from the ground up in order to learn how to create .mods and .exts. I have a really good base going and I'm very close to building. I would like to post what I've discovered and documented here because it's mostly a large streamline of everything you phenomenal people have found, or put together for other with bugs. I essentially did this with my fg directory, some orc mods, and this forum/site. But it's almost 100% entirely complete. 1. I would love your input in case anything is incorrect or assumed poorly. But also.. I want to put this on github for the general public. I just want to ensure that is okay to do in this instance, as I'm not really sure how licenses and things work.

This is one particular example that has dramatically increased my understanding. I've attributed anything from forums to direct authors, guides, videos as well. I don't want to claim ownership of anything other than the particular project I am doing for myself as a gm. I just hope to help this be available for others, if it's appropriate. There is a very large amount of evidence I would include in the repo, again, all attributed, but these are examples I wanted to show.

I'm a very anxious person and I worry about what others think and I just want to help.

Thoughts?

Welcome to FG. What exactly is it you want to include in your repo?

Essentially the internal structure of how FG communicates with .mods, .exts, .lua. Give a real comprehensive understanding so there's a lot less guess work and running around. I know that things can be dragged and dropped to be generated. that's not what I'm trying to accomplish. I personally can't work or create with things I don't understand. I think that will help. I'm again not 100% ready. but I don't know if creating (I'm not a software engineer. RF military systems are wildly different) that form of signal flow would be frowned upon, something FG might not want public. I would love to continue to update this post as I move forward. But I don't want to step on toes or get a cease and desist. if that all makes sense.

I didn't see anything in there that SmiteWorks would be concerned about being public. It's all already public, just not in that format. Reverse engineering the executable, and posting that would be something that I'm sure they would not like (and would be against the EULA). You can always reach out to Support if you want an official answer.

I'm still trudging a long I think I have a full architecture model. If this seems incorrect please let me know. on that note. I need some sleep. I found a lot of the older reference models and compared continually, the consistency in the static but expansive design is honestly impressive. the foundation that it's become is really kind of an art form. I'm only sad I just found out about this world.

windowinstance is itself a container that contains one or more controls: https://fantasygroundsunity.atlassia...windowinstance Controls are the main way that the FG GUI interacts with the user.

More information here: https://fantasygroundsunity.atlassia...Panels+Widgets

I would really like it if this sort of information were available!

I also like to understand how systems work from a top level before diving down into the nitty gritty and these sorts of overviews make a lot of sense to me. Most of the FG technical documentation I've read is more of the "take this example, hack it about" which is great but only once I've got my head around the fundamental way the thing works.

Cheers, Hywel

thank you. I'll dig deeper into this. after the last bit, I took a bit of break so my head would stop going brrrrr.

I'll keep this thread as updated as I can and look forward to corrections/advice from the comm!

I've been looking for a bit. I'm trying to keep information validated. I am working through dependencies at the moment and I haven't found the direct answer immediately (likely search criteria).

Do extensions compete for priority? I assume there has to be some form of execution order between like types even if just alphanumeric=00-01, but I'm unsure who determines that, and if the extension can provide any sort of action to elevate or order priority? And also, with the nature of multiple manager interpretation, is there or has there been an instance where priority of extension order was necessary.


2nd thought: some extensions I've found have essentially seemed to instruct a rewrite of the PF2 ruleset after initializing the actual PF2 ruleset, and almost seem to try to derive the PF2 ruleset authority directly, which seems odd, because from what I can tell is not necessary. Is there a particular reason for this? I don't believe it stems from an addition of homebrew to PF2, because that can be done without rewriting PF2. But I didn't make them. so I can't speak on it. but it seems to be a theme I've encountered quite a few times.

I want to reiterate, code is not my specialty and I am learning through this. I also understand there are different tools, methods, and arch to get the desired output, but that's why I would like insight if possible.



I also see that there are multiple delivery methods I want to confirm that extensions that generally fall underneath a standard specific ruleset are meant to operate with multiple rulesets, likely? or is there another reason?

edit: I'm sorry. my last question is worded poorly. extensions that generally load and initialize underneath the standard specific rulesets, like PF2 are meant to operate with more than just one ruleset, like 3.5 and PF2, or what have you.

So extensions, and rulesets, can have a "loadorder" defined. a value from 1 to 100, higher order loads last. But it is not required that a loadorder be defined. I don't know if its predeictable what happens with two extensions with a conflicting loadorder or if none is defined (maybe it defaults to 0?)

The later an extension is loader, the more authority it has, i.e. the last read instance of a function overwrites what was defined before. unless a MERGE=join is defined for that file, windowclass or function.
Rulesets can also define a parent, which in itself can have a parent. So most rulesets are children of CoreRPG. So CoreRPG loads first, then D&D5E (or such). I think PF1E is actually a child of 3.5, so its Core>3.5>PF1.

Often extensions completely overwrite core or parent ruleset functions and files that they don't need to. It's because most of us are not coders either, and we hack. SmiteWorks over the last year or so has made Core and the supported rulesets much easier to modify in part, without us having to overwrite everything to achieve what we want. But again, most of us are hacks, not coders :)

Quote:

---

Originally Posted by LordEntrails

The later an extension is loader, the more authority it has, i.e. the last read instance of a function overwrites what was defined before. unless a MERGE=join is defined for that file, windowclass or function.

---

This reframes what I thought I understood. I didn't think the later the function was the more authority it derived. I thought the nature was inverse and that each following function had to align strictly with the previous. so this is good information to have.. I think my interpretation of signal flow may have been fundamentally wrong then.

Thank you. And from what I've seen, hack is far from the correct term. I also have a tendency to do exactly what I described above and over clarify to the point of exhaustion, so this was a good pull back.

So just to make sure it's clear, it goes something like this:

CoreRPG - Loads First
Defines Function A
Defines Function B
Defines Windowclass 1
Defines Windowclass 2
... etc

Child ruleset loads second
Overwrites Function A
Defines Function C
Alters Windowclass 1 via Merge=Join
Defines Windowclass 2
Defines Windowclass 3
... etc

Extension loads third
Defines Function D
Overwrites Windowclass 3

This results in the final code that FG executes as:
Function A from child ruleset
Function B from CoreRPG
Function C from child ruleset
Function D from extension
Windowclass 1 as altered by child ruleset
Windowclass 2 from child ruleset
Windowclass 3 from extension

Thank you very much. this is appreciated :)

Core can't alter Rulesets, or EXTs
Rulesets can't alter EXTs.

Having said that, some APIs are not open for Core, Rulesets, or EXTs to alter. Those are considered in the "client" .exe.