* Adding Void magic
* Mapping BaseRangeConstant to SpellBase
* Fixing DoTs to only use the top layer enchantments
* Added limiter for switching between war and void magic
In the cache.bin, this is probably a bool. It is 1 for every instance found.
If/When we understand what this flag might have meant, we can re-add. However, given that it was always true in cache.bin, that is unlikely.
Furthermore, in GDLE, this bit was always set to 1 on write, and always masked off on read.
If an int/float had a default of '0', it was removed.
If a nullable had adefault of NULL, it was removed.
This isn't needed for EF.
This cleans up the SQL.
This also helps make sure our sql writers are generating the full INSERT query to recreate a record.
Columns id and guid have been combined into a single guid column.
This requires that every landblock instance be provided with a valid unique guid.
In the old code, you could provide an instance that would have an auto generated id (column) and a guid of 0. ACE would then see the guid is 0 and would use the following:
GuidManager.NewDynamicGuid();
In the cache.bin, every landblock instance has a unique id.
If we need to add the ability to have dynamically guid'd landblockinstances, this is an easy thing to add back.
The cache.bin, as well as the client use these data structs in WXYZ order.
However, when you actually construct a Quaternion in ACE (Which uses a System.Numerics native type), the arguments are passed in XYZW.
I prefer XYZW order, but, to keep things in lined with the client, I've univied angles to be WXYZ order in our cache.bin exporter and in ACE.
There were 3 redundant values which were basically flags indicating if it's associated vital was actually used.
However, in the cache.bin, any time a vital was present, it's associated flag was also set to 1. This is basically redundant.
We can simplify this as follows. If the Vital != 0, it gets applied. If the Vital == 0, it doesn't get applied.
I suspect they may have wanted the flag so they could leave a vital value in the db, but just have it disabled. We don't need this.
This allows us to not have to add all 8 records found in the cache.bin.
Instead, we only have to add the records that actually modify something. This new bool basically indicates if it was the first 4 or the last 4 or the fixed 8 found in the cache.bin
We were relying on the order of the recipe_componet records to remain the same, but this isn't gauranteed unless we provide a zIndex.
Instead of adding a zIndex to the Recipe_Component table, we can just put the static values in the base Recipe table.
* Rename SkillStatus to SkillAdvancementClass
SkillStatus and SkillAdvancementClass are neither the perfect names for what this value represents.
However, the client calls it SkillAdvancementClass. We call it SAC in the database. And GDLE also uses the SAC naming.
I think switching this name helps align ACE with the pdb without adding any additional confusion, meaning, this new name is equally as confusing as the previous, but at last its aligned with the pdb and gdle.
* changelog
* This moves the .sql file generation code that Ripley has been using into ACE.Database
This will help us import data from any source into ACE EF objects, and then use these SQLWriters to create a unified output.
* Weenie and LandblockInstances SQL Writers added + Enums
Some styling and comments added to the other SQL Writer classes.
Still need to do the treasure tables, as well as recipe/cook books.
Also need to confirm SQL output is well formed and accurate.
* CookBookSQLWriter and RecipeSQLWriter
Writers that still aren't implemented:
PointsOfInterest
TreasureDeath
TreasureWielded
Also, still need to test the output of these writers to make sure it's correct.
* Formatting tweaked a little bit, much closer to the final product
This creates scripts that import.
Still need to verify a couple of data mismatches.
* This moves the Int/Did property decoder to ACE.Entity.Enum.Properties
This code will likely be used to help UI content editors and database viewers.
* This fixes float output where precision was lost. Woops.
* Fat fingered a variable in the weenie SQL writer
This concludes all the testing for the SQL Writers.
They all test OK and produce the same results as the code Ripley was using to generate the .sql files.
