* Use composite RefId to remove INFO record of deleted DIAL record. OrderedInfo
stores original RefId while InfoCollection stores composite one.
* Do not erase deleted topic from InfoOrderByTopic map. To keep all deleted
record ids for InfoCollection::sort call to make sure reorderRowsImp is called
with correct number of indices.
Topic info records need to have specific order defined via mNext and mPrev
fields (next and previous records). When loading multiple files a record may be
inserted into middle of the topic but neighborhood records may not be aware of
it. Having the order it's possible to move the records within one topic.
Sort the record once after loading all content files but preserve the order for
all other operations. Use std::map to group info ids by topic to make sure the
topics order is stable. Keep order within a topic for info ids on loading new
records. Use this order later for sorting the records.
There was additional logic to create topic infos index by topic id to make
getTopicInfos and removeDialogueInfos functions faster. In practice it makes
loading slower.
Move infos index by topic to CSMWorld::Data and use only on loading.
Fixed some types
removed useless header
applied clang format
fixed compile tests
fixed clang tidy, and closer to logic before this MR
Removed hardcoded refids
unless there is a returned value we don't use static RefIds
can use == between RefId and hardcoded string
Fix clang format
Fixed a few instances where std::string was used, when only const std::string& was needed
removed unused variable
Slowly moving through the open-cs errors
Good progress in openCS
Very good progress on openCS
Getting closer with openCS
OpenCS compiles and runs! Didn't have time to test it all though
ix openMW
everything compiles on windows??
Fix gcc
Fix Clang
- The order of info records with the same topic are maintained in Collection::mRecords
- The index lookup data structure are not ordered. The topic string is hashed. The infos for the topic are simply placed in a vector.
- The index values for appending or inserting a record takes prev/next values (if exist)
- FIXME: prev/next values are not adjusted for adding or removing records
- FIXME: undo after reordering does not reset the modified flag
(copied the changes from commit SHA-1: 06f9922822)
