1
0
mirror of https://gitlab.com/OpenMW/openmw.git synced 2025-01-28 14:53:58 +00:00

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

526 lines
15 KiB
C++
Raw Normal View History

2012-10-24 12:17:49 +04:00
#ifndef OPENMW_MWWORLD_STORE_H
#define OPENMW_MWWORLD_STORE_H
#include <map>
#include <memory>
2021-07-26 18:30:06 +02:00
#include <set>
2012-10-24 12:17:49 +04:00
#include <string>
#include <unordered_map>
2012-10-24 12:17:49 +04:00
#include <vector>
#include <components/esm/refid.hpp>
#include <components/esm3/loadcell.hpp>
#include <components/esm3/loaddial.hpp>
#include <components/esm3/loadglob.hpp>
#include <components/esm3/loadgmst.hpp>
#include <components/esm3/loadland.hpp>
#include <components/esm3/loadpgrd.hpp>
#include <components/misc/rng.hpp>
#include <components/misc/strings/algorithm.hpp>
2013-12-07 13:17:28 +01:00
#include "../mwdialogue/keywordsearch.hpp"
2015-07-09 19:22:04 +02:00
namespace ESM
{
struct Attribute;
struct LandTexture;
struct MagicEffect;
struct Skill;
struct WeaponType;
class ESMReader;
class ESMWriter;
2015-07-09 19:22:04 +02:00
}
2015-07-09 19:22:04 +02:00
namespace Loading
{
class Listener;
}
2012-11-03 20:20:16 +04:00
2012-10-24 12:17:49 +04:00
namespace MWWorld
{
struct RecordId
{
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
ESM::RefId mId;
bool mIsDeleted;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
RecordId(const ESM::RefId& id = {}, bool isDeleted = false);
};
class StoreBase
{
}; // Empty interface to be parent of all store types
class DynamicStore : public StoreBase
2012-10-24 12:17:49 +04:00
{
public:
virtual ~DynamicStore() {}
2012-10-24 12:17:49 +04:00
virtual void setUp() {}
2015-12-11 15:55:45 +01:00
/// List identifiers of records contained in this Store (case-smashed). No-op for Stores that don't use string
/// IDs.
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
virtual void listIdentifier(std::vector<ESM::RefId>& list) const {}
2012-10-24 12:17:49 +04:00
virtual size_t getSize() const = 0;
2013-12-07 13:17:28 +01:00
virtual int getDynamicSize() const { return 0; }
virtual RecordId load(ESM::ESMReader& esm) = 0;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
virtual bool eraseStatic(const ESM::RefId& id) { return false; }
2013-05-15 17:54:18 +02:00
virtual void clearDynamic() {}
2013-12-07 13:17:28 +01:00
2015-03-14 06:07:12 +11:00
virtual void write(ESM::ESMWriter& writer, Loading::Listener& progress) const {}
2013-12-07 13:17:28 +01:00
virtual RecordId read(ESM::ESMReader& reader, bool overrideOnly = false) { return RecordId(); }
2013-12-07 13:17:28 +01:00
///< Read into dynamic storage
2012-10-24 12:17:49 +04:00
};
2015-07-09 19:22:04 +02:00
template <class T>
class IndexedStore : public StoreBase
2015-07-09 19:22:04 +02:00
{
protected:
typedef typename std::map<int, T> Static;
Static mStatic;
public:
typedef typename std::map<int, T>::const_iterator iterator;
IndexedStore();
iterator begin() const;
iterator end() const;
void load(ESM::ESMReader& esm);
int getSize() const;
void setUp();
const T* search(int index) const;
// calls `search` and throws an exception if not found
2015-07-09 19:22:04 +02:00
const T* find(int index) const;
};
template <class T, class Container = std::vector<T*>>
2012-10-24 12:17:49 +04:00
class SharedIterator
{
typedef typename Container::const_iterator Iter;
2012-10-24 12:17:49 +04:00
Iter mIter;
public:
SharedIterator() {}
SharedIterator(const SharedIterator& orig)
: mIter(orig.mIter)
{
}
SharedIterator(const Iter& iter)
: mIter(iter)
{
}
SharedIterator& operator=(const SharedIterator&) = default;
2012-10-24 12:17:49 +04:00
SharedIterator& operator++()
{
++mIter;
return *this;
}
SharedIterator operator++(int)
{
SharedIterator iter = *this;
2013-07-31 18:46:32 +02:00
++mIter;
2012-10-24 12:17:49 +04:00
return iter;
}
SharedIterator& operator+=(int advance)
{
mIter += advance;
return *this;
}
2012-10-24 12:17:49 +04:00
SharedIterator& operator--()
{
--mIter;
return *this;
}
SharedIterator operator--(int)
{
SharedIterator iter = *this;
2013-07-31 18:46:32 +02:00
--mIter;
2012-10-24 12:17:49 +04:00
return iter;
}
bool operator==(const SharedIterator& x) const { return mIter == x.mIter; }
2012-10-24 12:17:49 +04:00
bool operator!=(const SharedIterator& x) const { return !(*this == x); }
2012-10-24 12:17:49 +04:00
const T& operator*() const { return **mIter; }
const T* operator->() const { return &(**mIter); }
};
2012-11-06 15:26:55 +04:00
class ESMStore;
2012-10-24 12:17:49 +04:00
template <class T>
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
class TypedDynamicStore : public DynamicStore
2012-10-24 12:17:49 +04:00
{
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
typedef std::unordered_map<ESM::RefId, T> Static;
Static mStatic;
/// @par mShared usually preserves the record order as it came from the content files (this
/// is relevant for the spell autocalc code and selection order
/// for heads/hairs in the character creation)
std::vector<T*> mShared;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
typedef std::unordered_map<ESM::RefId, T> Dynamic;
Dynamic mDynamic;
2012-10-24 12:17:49 +04:00
2012-11-06 15:26:55 +04:00
friend class ESMStore;
2012-10-24 12:17:49 +04:00
public:
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
TypedDynamicStore();
TypedDynamicStore(const TypedDynamicStore<T>& orig);
2012-10-24 12:17:49 +04:00
typedef SharedIterator<T> iterator;
2013-05-15 17:54:18 +02:00
// setUp needs to be called again after
void clearDynamic() override;
void setUp() override;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const T* search(const ESM::RefId& id) const;
const T* searchStatic(const ESM::RefId& id) const;
2012-10-24 12:17:49 +04:00
/**
* Does the record with this ID come from the dynamic store?
*/
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
bool isDynamic(const ESM::RefId& id) const;
2018-10-09 10:21:12 +04:00
/** Returns a random record that starts with the named ID, or nullptr if not found. */
const T* searchRandom(const std::string_view prefix, Misc::Rng::Generator& prng) const;
2013-08-11 00:35:19 -07:00
// calls `search` and throws an exception if not found
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const T* find(const ESM::RefId& id) const;
2012-10-24 12:17:49 +04:00
2015-07-09 19:22:04 +02:00
iterator begin() const;
iterator end() const;
size_t getSize() const override;
int getDynamicSize() const override;
/// @note The record identifiers are listed in the order that the records were defined by the content files.
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
void listIdentifier(std::vector<ESM::RefId>& list) const override;
T* insert(const T& item, bool overrideOnly = false);
2015-07-09 19:22:04 +02:00
T* insertStatic(const T& item);
2013-12-07 13:17:28 +01:00
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
bool eraseStatic(const ESM::RefId& id) override;
bool erase(const ESM::RefId& id);
2015-07-09 19:22:04 +02:00
bool erase(const T& item);
2013-12-07 13:17:28 +01:00
RecordId load(ESM::ESMReader& esm) override;
void write(ESM::ESMWriter& writer, Loading::Listener& progress) const override;
RecordId read(ESM::ESMReader& reader, bool overrideOnly = false) override;
};
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
template <class T>
class Store : public TypedDynamicStore<T>
{
};
template <>
class Store<ESM::LandTexture> : public DynamicStore
2012-10-24 12:17:49 +04:00
{
// For multiple ESM/ESP files we need one list per file.
typedef std::vector<ESM::LandTexture> LandTextureList;
std::vector<LandTextureList> mStatic;
2012-10-24 12:17:49 +04:00
public:
2015-07-09 19:22:04 +02:00
Store();
2012-10-24 12:17:49 +04:00
typedef std::vector<ESM::LandTexture>::const_iterator iterator;
// Must be threadsafe! Called from terrain background loading threads.
// Not a big deal here, since ESM::LandTexture can never be modified or inserted/erased
2015-07-09 19:22:04 +02:00
const ESM::LandTexture* search(size_t index, size_t plugin) const;
const ESM::LandTexture* find(size_t index, size_t plugin) const;
void resize(std::size_t num);
size_t getSize() const override;
2015-07-09 19:22:04 +02:00
size_t getSize(size_t plugin) const;
2012-10-24 12:17:49 +04:00
RecordId load(ESM::ESMReader& esm) override;
2012-10-24 12:17:49 +04:00
2015-07-09 19:22:04 +02:00
iterator begin(size_t plugin) const;
iterator end(size_t plugin) const;
2012-10-24 12:17:49 +04:00
};
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
template <>
class Store<ESM::GameSetting> : public TypedDynamicStore<ESM::GameSetting>
{
public:
const ESM::GameSetting* search(const ESM::RefId& id) const;
const ESM::GameSetting* find(const std::string_view id) const;
const ESM::GameSetting* search(const std::string_view id) const;
};
2012-10-24 12:17:49 +04:00
template <>
class Store<ESM::Land> : public DynamicStore
2012-10-24 12:17:49 +04:00
{
struct SpatialComparator
{
using is_transparent = void;
2021-07-26 18:30:06 +02:00
bool operator()(const ESM::Land& x, const ESM::Land& y) const
{
return std::tie(x.mX, x.mY) < std::tie(y.mX, y.mY);
}
2021-07-26 18:30:06 +02:00
bool operator()(const ESM::Land& x, const std::pair<int, int>& y) const
{
return std::tie(x.mX, x.mY) < std::tie(y.first, y.second);
}
2021-07-26 18:30:06 +02:00
bool operator()(const std::pair<int, int>& x, const ESM::Land& y) const
{
return std::tie(x.first, x.second) < std::tie(y.mX, y.mY);
}
};
2021-07-26 18:30:06 +02:00
using Statics = std::set<ESM::Land, SpatialComparator>;
Statics mStatic;
2012-10-24 12:17:49 +04:00
public:
2021-07-26 18:30:06 +02:00
typedef typename Statics::iterator iterator;
2012-10-24 12:17:49 +04:00
2015-07-09 19:22:04 +02:00
virtual ~Store();
2012-12-10 00:59:39 +01:00
size_t getSize() const override;
2015-07-09 19:22:04 +02:00
iterator begin() const;
iterator end() const;
2012-10-24 12:17:49 +04:00
// Must be threadsafe! Called from terrain background loading threads.
// Not a big deal here, since ESM::Land can never be modified or inserted/erased
2017-02-13 01:29:22 +01:00
const ESM::Land* search(int x, int y) const;
const ESM::Land* find(int x, int y) const;
2012-10-24 12:17:49 +04:00
RecordId load(ESM::ESMReader& esm) override;
void setUp() override;
2022-09-22 21:26:05 +03:00
private:
bool mBuilt = false;
2012-10-24 12:17:49 +04:00
};
template <>
class Store<ESM::Cell> : public DynamicStore
2012-10-24 12:17:49 +04:00
{
struct DynamicExtCmp
{
bool operator()(const std::pair<int, int>& left, const std::pair<int, int>& right) const
{
if (left.first == right.first && left.second == right.second)
return false;
if (left.first == right.first)
return left.second > right.second;
2015-03-02 23:29:33 +01:00
// Exterior cells are listed in descending, row-major order,
// this is a workaround for an ambiguous chargen_plank reference in the vanilla game.
// there is one at -22,16 and one at -2,-9, the latter should be used.
return left.first > right.first;
}
};
2023-01-19 17:31:45 +01:00
typedef std::unordered_map<std::string, ESM::Cell, Misc::StringUtils::CiHash> DynamicInt;
typedef std::map<std::pair<int, int>, ESM::Cell, DynamicExtCmp> DynamicExt;
DynamicInt mInt;
DynamicExt mExt;
2012-10-26 18:52:44 +04:00
2012-11-05 12:11:53 +04:00
std::vector<ESM::Cell*> mSharedInt;
std::vector<ESM::Cell*> mSharedExt;
DynamicInt mDynamicInt;
DynamicExt mDynamicExt;
2015-07-09 19:22:04 +02:00
const ESM::Cell* search(const ESM::Cell& cell) const;
void handleMovedCellRefs(ESM::ESMReader& esm, ESM::Cell* cell);
2012-10-24 12:17:49 +04:00
public:
2012-11-05 12:11:53 +04:00
typedef SharedIterator<ESM::Cell> iterator;
2023-01-19 17:31:45 +01:00
const ESM::Cell* search(std::string_view id) const;
2015-07-09 19:22:04 +02:00
const ESM::Cell* search(int x, int y) const;
const ESM::Cell* searchStatic(int x, int y) const;
2015-07-09 19:22:04 +02:00
const ESM::Cell* searchOrCreate(int x, int y);
2012-10-24 12:17:49 +04:00
2023-01-19 17:31:45 +01:00
const ESM::Cell* find(std::string_view id) const;
2015-07-09 19:22:04 +02:00
const ESM::Cell* find(int x, int y) const;
2012-10-26 18:52:44 +04:00
void clearDynamic() override;
void setUp() override;
RecordId load(ESM::ESMReader& esm) override;
2015-07-09 19:22:04 +02:00
iterator intBegin() const;
iterator intEnd() const;
iterator extBegin() const;
iterator extEnd() const;
2012-10-26 18:52:44 +04:00
// Return the northernmost cell in the easternmost column.
2023-01-19 17:31:45 +01:00
const ESM::Cell* searchExtByName(std::string_view id) const;
2012-10-26 18:52:44 +04:00
// Return the northernmost cell in the easternmost column.
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::Cell* searchExtByRegion(const ESM::RefId& id) const;
2012-10-26 18:52:44 +04:00
size_t getSize() const override;
2019-11-24 17:40:19 +04:00
size_t getExtSize() const;
size_t getIntSize() const;
2012-11-05 12:11:53 +04:00
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
void listIdentifier(std::vector<ESM::RefId>& list) const override;
2012-11-05 12:11:53 +04:00
2015-07-09 19:22:04 +02:00
ESM::Cell* insert(const ESM::Cell& cell);
2012-11-05 12:11:53 +04:00
2015-07-09 19:22:04 +02:00
bool erase(const ESM::Cell& cell);
2023-01-19 17:31:45 +01:00
bool erase(std::string_view id);
2012-11-05 12:11:53 +04:00
2015-07-09 19:22:04 +02:00
bool erase(int x, int y);
2012-10-24 12:17:49 +04:00
};
template <>
class Store<ESM::Pathgrid> : public DynamicStore
2012-10-24 12:17:49 +04:00
{
2012-10-26 20:46:30 +04:00
private:
typedef std::unordered_map<ESM::RefId, ESM::Pathgrid> Interior;
typedef std::map<std::pair<int, int>, ESM::Pathgrid> Exterior;
Interior mInt;
Exterior mExt;
Store<ESM::Cell>* mCells;
2012-10-26 20:46:30 +04:00
public:
Store();
2012-10-26 20:46:30 +04:00
2015-07-09 19:22:04 +02:00
void setCells(Store<ESM::Cell>& cells);
RecordId load(ESM::ESMReader& esm) override;
size_t getSize() const override;
void setUp() override;
2015-07-09 19:22:04 +02:00
const ESM::Pathgrid* search(int x, int y) const;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::Pathgrid* search(const ESM::RefId& name) const;
2015-07-09 19:22:04 +02:00
const ESM::Pathgrid* find(int x, int y) const;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::Pathgrid* find(const ESM::RefId& name) const;
2015-07-09 19:22:04 +02:00
const ESM::Pathgrid* search(const ESM::Cell& cell) const;
const ESM::Pathgrid* find(const ESM::Cell& cell) const;
2012-10-24 12:17:49 +04:00
};
template <>
class Store<ESM::Skill> : public IndexedStore<ESM::Skill>
{
public:
2015-07-09 19:22:04 +02:00
Store();
};
template <>
class Store<ESM::MagicEffect> : public IndexedStore<ESM::MagicEffect>
{
public:
2015-07-09 19:22:04 +02:00
Store();
};
template <>
class Store<ESM::Attribute> : public IndexedStore<ESM::Attribute>
{
std::vector<ESM::Attribute> mStatic;
public:
typedef std::vector<ESM::Attribute>::const_iterator iterator;
2015-07-09 19:22:04 +02:00
Store();
2015-07-09 19:22:04 +02:00
const ESM::Attribute* search(size_t index) const;
// calls `search` and throws an exception if not found
2015-07-09 19:22:04 +02:00
const ESM::Attribute* find(size_t index) const;
2015-07-09 19:22:04 +02:00
void setUp();
2015-07-09 19:22:04 +02:00
size_t getSize() const;
iterator begin() const;
iterator end() const;
};
template <>
class Store<ESM::WeaponType> : public DynamicStore
{
std::map<int, ESM::WeaponType> mStatic;
public:
typedef std::map<int, ESM::WeaponType>::const_iterator iterator;
Store();
const ESM::WeaponType* search(const int id) const;
// calls `search` and throws an exception if not found
const ESM::WeaponType* find(const int id) const;
RecordId load(ESM::ESMReader& esm) override { return RecordId({}, false); }
ESM::WeaponType* insert(const ESM::WeaponType& weaponType);
void setUp() override;
size_t getSize() const override;
iterator begin() const;
iterator end() const;
};
template <>
class Store<ESM::Dialogue> : public DynamicStore
{
typedef std::unordered_map<ESM::RefId, ESM::Dialogue> Static;
Static mStatic;
/// @par mShared usually preserves the record order as it came from the content files (this
/// is relevant for the spell autocalc code and selection order
/// for heads/hairs in the character creation)
/// @warning ESM::Dialogue Store currently implements a sorted order for unknown reasons.
std::vector<ESM::Dialogue*> mShared;
mutable bool mKeywordSearchModFlag;
mutable MWDialogue::KeywordSearch<std::string, int /*unused*/> mKeywordSearch;
public:
Store();
typedef SharedIterator<ESM::Dialogue> iterator;
void setUp() override;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
const ESM::Dialogue* search(const ESM::RefId& id) const;
const ESM::Dialogue* find(const ESM::RefId& id) const;
iterator begin() const;
iterator end() const;
size_t getSize() const override;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
bool eraseStatic(const ESM::RefId& id) override;
RecordId load(ESM::ESMReader& esm) override;
Initial commit: In ESM structures, replace the string members that are RefIds to other records, to a new strong type The strong type is actually just a string underneath, but this will help in the future to have a distinction so it's easier to search and replace when we use an integer ID Slowly going through all the changes to make, still hundreds of errors a lot of functions/structures use std::string or stringview to designate an ID. So it takes time Continues slowly replacing ids. There are technically more and more compilation errors I have good hope that there is a point where the amount of errors will dramatically go down as all the main functions use the ESM::RefId type Continue moving forward, changes to the stores slowly moving along Starting to see the fruit of those changes. still many many error, but more and more Irun into a situation where a function is sandwiched between two functions that use the RefId type. More replacements. Things are starting to get easier I can see more and more often the issue is that the function is awaiting a RefId, but is given a string there is less need to go down functions and to fix a long list of them. Still moving forward, and for the first time error count is going down! Good pace, not sure about topics though, mId and mName are actually the same thing and are used interchangeably Cells are back to using string for the name, haven't fixed everything yet. Many other changes Under the bar of 400 compilation errors. more good progress <100 compile errors! More progress Game settings store can use string for find, it was a bit absurd how every use of it required to create refId from string some more progress on other fronts Mostly game settings clean one error opened a lot of other errors. Down to 18, but more will prbably appear only link errors left?? Fixed link errors OpenMW compiles, and launches, with some issues, but still!
2022-09-25 13:17:09 +02:00
void listIdentifier(std::vector<ESM::RefId>& list) const override;
const MWDialogue::KeywordSearch<std::string, int>& getDialogIdKeywordSearch() const;
};
ESM::FixedString<6> getRecNameString(ESM::RecNameInts recName);
2012-10-24 12:17:49 +04:00
} // end namespace
#endif