Ruleset Automation

[damned]

Or maybe the other way around - indicating that automation *will* be applied?

Perfectly acceptable in my opinion.

[celestian]

Late to this thread (sorry - that's what I get for being asleep when everyone(?) else is awake)

Serious questions to Moon and my fellow Devs: there seems to be two constraints on "automation" - either complexity of (parse) data, leading to longer load times, etc, or complexity of data-structure, leading to larger "databases" (if you're generous with calling a flat-file a database) and thus longer load times, etc.

From a CompSci POV, the solutions to each of these problems (when constrained by "reasonable" commercial limits) is to reduce the size of your flat-file-DB, hence a lot of operations moving away from an XML-based flat-file to something like JSON or YAML; or moving the flat-file to a true DB-System (like MariaDB/MySQL, etc).

OK, so, what are the downs-de of each of these approaches? Well, XML-to-JSON (or YAML) converters are relatively easy to write, so doing the conversions moving forward is (relativitly) not too difficult, and during the transition it wouldn't be too hard for FGU (with its larger memory store) to be able to read both formats. Trouble is, it still means you have to load *ALL* of the data into memory.

Moving from XML to JSON wouldn't be a bad idea but XML is also how the UI is laid out. Trying to edit JSON for UI/controls would be a nightmare... and that's saying a lot (I don't like XML either). HTML templating for UI control would be a viable option (much more common).

I'd be curious to see how XML to JSON would improve things. My understanding of the resources/speed issue is tied to XML "nodes". Each one is a LUA object and because of that it requires more resources. JPG has suggested they could be un-tethered but it would require a major re-write of code which... isn't on the table.

[esmdev]

I like the automation A. It looks like a great solution and it's easy to see.

[Neovirtus]

Agreed, I think that makes a lot of sense. Let people know what is fully automated, and they will know to double check everything else.

[deer_buster]

Late to this thread (sorry - that's what I get for being asleep when everyone(?) else is awake)

Serious questions to Moon and my fellow Devs: there seems to be two constraints on "automation" - either complexity of (parse) data, leading to longer load times, etc, or complexity of data-structure, leading to larger "databases" (if you're generous with calling a flat-file a database) and thus longer load times, etc.

From a CompSci POV, the solutions to each of these problems (when constrained by "reasonable" commercial limits) is to reduce the size of your flat-file-DB, hence a lot of operations moving away from an XML-based flat-file to something like JSON or YAML; or moving the flat-file to a true DB-System (like MariaDB/MySQL, etc).

OK, so, what are the downs-de of each of these approaches? Well, XML-to-JSON (or YAML) converters are relatively easy to write, so doing the conversions moving forward is (relativitly) not too difficult, and during the transition it wouldn't be too hard for FGU (with its larger memory store) to be able to read both formats. Trouble is, it still means you have to load *ALL* of the data into memory.

The other approach (using a "proper" DB) means more complexity in set-up (you need to include the DB-Engine), but arguments about "more tech-support calls", while once valid a few years ago, have generally disappeared with the modern iteration of "in-app" or "on-CD" versions of modern DB-Engines. The benefit of using a proper DB is that, while the base memory load is slightkly higher, you're not loading all of the data at once, hence the system should run faster overall. The downside, of course, is that its a lot more work to get an XML-DB translater (although it can and has been done). And again, during transition FGU could use both methods.

In fact, if its done correctly, gently, and with careful planning, the end users would never know the difference - only the FG Coders and the Community Devs.

So, a (potentially) radical set of ideas; what do SW and my fellow Devs think - discuss.

Cheers

Well, as long as we are speaking hypotheticals here, as someone with a software engineering background, I'd love for there to be a "proper" DB. Hell for that matter, I would love to get rid of LUA altogether and have a "proper" way to extend FG, but I realize that LUA is the common game scripting method currently. XML is outdated and unwieldy, and templates would be my preferred replacement.

[LordEntrails]

I too like the A-Automated idea. Though I would like the A to be more unique/identifiable. Maybe a circle A or a script font A.

[Bidmaron]

A gear icon would be perfect