Board Thread:The Last Sovereign Discussion/@comment-25881556-20171217124902/@comment-31763506-20180218222714

Thanks all for the good wishes and advice. Note that even if I temporarily focus my efforts to more productive channels, I'll definitely still be hanging around here and anxiously anticipating every TLS update.

I'll note that it's interesting how quickly Fulminato has gone from advocating for CSV in all things to be willing to learn Access.

That said, here's all the work to date in a zip with two files. It's very much "as is". It won't do you much good unless you have Access 2010 or later right now. I'm fairly sure LibreOffice Base can't interpret Access files in the same way that LibreOffice can handle Word or Excel documents. There are ways of getting a working copy of Access without paying for one, but that would be unethical and I would never condone that.

http://s000.tinyupload.com/index.php?file_id=57333261085600379418

The RPG Maker script is basically done, but if you want to understand how it works or how to extend it, you need to search through RPG Maker's in program help documentation. Search the terms "RPG Enemy" or "RPG Skill" to get a foothold.

Most of the heavy lifting is done by queries and subreports right now. Each file output by the DataDump script corresponds to an Access table, and there's no way to quickly import new data from a fresh dump. You have to delete the contents of the tables (which is potentially easy by making a macro that executes a series of delete queries), and then import the pipe delimited text files into the now empty Access tables (this is also scriptable, but less easily, which is why it hasn't been done).

The query features used to parse the data are also applied inconsistently. When RPG Maker objects have a collection of Features or Effects, these features or effects have a combination of a Code and a Data_id that governs how they are interpreted. So for EnemyFeatures, a Code of 13 indicates that it is a State Rate that is being specified, and that you should look up the Data_id in the list of States, of which State_id 2 corresponds to Poison. When I made a subreport for each of the four classes of "interesting" enemy features, I used an index table called "EnemyFeatureCodeDataIDIndex" (SQL programmers are not known for creativity) to lookup how they ought to be interpreted. Since this would need to be updated if a new Code-Data_id combination was introduced, I made a query to find such new combinations, and to build said table in the first place. ("MissingEnemyFeatureCodes")

By the time I was doing Skill Effects, I realized that this was a silly approach, and instead fed the Code, Data_id and value fields into a custom inline function coded in Access VBA. ("DisplaySkillEffectInfo" in the module "InlineFunctions"). This is probably the better approach, but requires a bit more code to handle all possible Code/Data_id combinations for Skill effects. You'd have to make a test skill with test effects and run the data dump to see how each possible UI option that SL hasn't used yet is translated to a Code and Data_id. Same with the other similar tables.

Right now, the child tables are displayed in the output report using Access Sub_Reports, but that might not be the best approach. I've used access to output HTML source for gigantic lists of technical data before, but Wikia source is a different animal. (This is definitely not how you are supposed to use Access to make web pages.) It doesn't seem like you can make one Access report field correspond to one line of Wikia source. Scripting the output with Access VBA might be more effective, but less maintainable.

Oh, and dropitems use a SQL Union query to unify items, weapons ans armors, which is an odd animal in Access but also the easiest way to do it.

The process of creating an admin form that will display the RPG Maker data like RPG maker is comparatively simple, but tedious, so I have not even started.

Knowing how to build Access queries and the SQL that underlies them might be necessary to understanding what I've done here. (Of course, understanding SQL is an absurdly useful and desirable job skill.) I included one example of how you can use a query to answer a question, "DuplicateEnemyFeatures". It is a list of enemies with multiple versions of the same feature. (ATM, they are all state rate - poison.)

I think that's enough to start with if anyone really wants to do so, but I'm happy to answer questions if it comes up.