Board Thread:The Last Sovereign Discussion/@comment-25881556-20171217124902/@comment-29984007-20180221175224

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. your project, your rule. I still think the portability is the first and foremost trait to aim. manipulate that file with 'sed' or 'awk' is pretty easy. and learn a new language is nearly always good.

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.

I don't use MS office from the XP version, I think. there is an evaluation version of office 365, it's a good start.

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).

there is a simpler solution for sure... delete all the table for importing the new is insane, if it will be keep the old dump can be used to check the difference in the new and adding only the difference.

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. but setting up a regular expression to manage the substitution of the name over the 'feature' with the (double) code isn't feasible? your solution strikes me like a mountain of code for making a mouse info.

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. i realy don't know the wikia language, and even less of a automatic system to create that code.

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. i don't know if the rpgmaker-like is the better visual solution for the info, but this is the last problem for now.

TKnowing 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.

i don't think to devoted a huge amount of time in the near future, but i will check all the file for sure.