* Set all Shard non-zero defaults to zero
There appears to be a bug in EF where, if the models value is not nullab,e and is 0, and the SQL columns default is not 0, the EF.SaveChanges() command will INSERT the record but omit the columns that are 0 value.
The DB will then add default values for the omitted columns.
The entire record is then returned as a result, and EF uses this to update the model, now setting those fields that were 0 to the new non-zero default.
This is the cause for the Jive Turkey emote delay issues.
The next step will be to create an update script that will set existing shard objects to their weenie defaults. The following tables will need to be investigated:
biota_properties_create_list
biota_properties_emote
biota_properties_emote_action
* biota_properties_spell_book probability
* Add alwaysshowwelcome to default config dict
* Update SQL tools for 8.0
* Rebase SQL scripts
* Update scaffolding
* Fix TargetType Enum
* Correct TargetType again...
* Use 16PY PR db for confirmation of SQL rebase testing
* Undo enum shift in code
* Shard PopulatedCollectionFlags
This greatly improves GetBiota performance.
It does so by recording the biotas populated collections on save, and then on Get, only pulling those known populated collections back from the database.
* Note added about GetBiota improvements
* Shard Parallel loops added for GetPlayerBiotas
This improves performance signifcantly.
Previously, a full mule too 8s to load.
Now, it's uder 500ms.
This removes Character as the parent of a Biota, and instead, makes them side by side objects that are owned by Player.
Session no longer owns Character.
Session maintains a list of the Characters for the account.
Session holds a reference to the current Player being used.
Player holds a reference to Biota and Character objects.
What I said in discord:
We have the Player object (our god class).
To put a player in the world, it requires a biota. It doesn't require a character or session.
To manipulate the player, we need a session (but not a character).
To give the player a user interface, we need a character.
The character holds all the user progress of the particular biota it's associated with.
So, a session holds a link to the current player the session is managing.
Player holds a link to the biota and character that represent the player.
The biota represents the player from the worlds pov.
The character represents the player from the users pov.
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.
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.
* Rebase Shard and World DBs
* ReScaffold Shard DB
* ReScaffold World DB
* Update SQL Bases
* ReScaffold Shard DB
* ReScaffold World DB
* Update DB to v0.0.16 PR
* Update changelog
* Update changelog.md
* World DB Rekeyed
* Rebase World DB
* Rebase Shard DB
* Update PK in EmoteAction
* Shard DB Rekeyed. This change creates lots of exceptions currently.
* Revert to Shard/World DB Rebase
* Restore Id to each table
* Restore Id to Shard tables
* Update World DB pr location
* Missed this ObjectId > Id change
* Rename Tables
* Updating Changlog and Readme. This PR fixes#782 and fixes#783
* Updating Changelog again to note that you must drop and re-create Shard and World DB due to changes
* Update EmoteCategory, EmoteType and SpellType enums
* Add CombatStyle enum
* Rebase SQL scripts
* Change uint to int in SQL
* Adjust SpellType
* Changed all PropertyInt properties from uint to int
* Some CombatStance work + StyleCop clean up
* Update README
* Updated ACE-World requirement and appveyor
* Add and use LandblockObjectInstance
* Uncomment weenieHeaderFlags2
* Rebase SQL scripts
* Update changelog
* Adjust linespacing in changelog
* Add generators back to the landblocks.
* Update appveyor script
* test database install
* Renamed functions to be more inline with their use
* STOP... Rebase time!
* WIP appveyor
* appveyor WIP 2
* appveyor WIP 3
* appveyor WIP 4
* appveyor WIP 5
* appveyor WIP 6
* appveyor WIP 7
* appveyor WIP 8
* Fixes for Appveyor
* Cleaning up StyleCop warning
* More AppVeyor fun
* Another Appveyor test
* Updated GuidManager
* Deleted previous generator test data due to issues with appveyor?
* Stylecop error
* Changed GuidType to fix IsCreature. why is this a thing?
* Extend generators to spawn linked generators
* Fix appveyor and guid
* Renamed generatorId to generatorWeenieClassId
* Renamed sql script for appveyor
* Fix for appveyor for real - dumb me :-P
* Change ItemType to Type
* Generator Instances
* Updated changelog
* Added ACE-World db version requirement
* Updated sql script
* Fixes for Null exceptions
* More Generator Properties
* Changed how generators are classified
* Updated changelog
* Fixed merge error
* Updated SQL script to reflect new generator properties
* Typo in changelog
* Requested Changes plus some ID output adjustments
* Rebased and synced SQL scripts.
* Updated AppVeyor script
* Added turning on the Event Scheduler to ShardBase
* Changed NOT PRESERVE to PRESERVE on event
