The resizing of LTEX store to the correct number of plugins was done in the load() method, but the load method won't be called if a plugin contains LAND records but doesn't contain LTEX records. For such plugins the Store<ESM::LandTexture>::search() function would then fail an assertion.
(cherry picked from commit 4687c4baad)
# Conflicts:
# apps/openmw/mwworld/store.cpp
# apps/openmw/mwworld/store.hpp
Note, I suspect Rng::rollClosedProbability() is not needed. The only difference between it and rollProbability() is that one time in 37k (on Windows), it will give an output of 1.0.
On some versions of Linux, the value of 1.0 will occur about 1 time in 4 billion.
(cherry picked from commit 3f28634d1f)
# Conflicts:
# apps/openmw/mwclass/creature.cpp
# apps/openmw/mwclass/npc.cpp
# apps/openmw/mwgui/pickpocketitemmodel.cpp
# apps/openmw/mwgui/waitdialog.cpp
# apps/openmw/mwmechanics/combat.cpp
# apps/openmw/mwmechanics/mechanicsmanagerimp.cpp
# components/CMakeLists.txt
# libs/openengine/misc/rng.cpp
- 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
- At least with MSVC the latter is more efficient.
- There are many more, but leave them until they show up during profiling (so far only loading was profiled, and mainly cell references)
- Morrowind load over 300,000 references, so even small inefficiencies add up to longer loading times.
- std::map is used, but should try others, std::unordered_map or even std::vector
- Quoting Qt-4.8: "Note: . Setting the property to true with setSortingEnabled() immediately triggers a call to sortByColumn() with the current sort section and order."
There is no change in behaviour since we were using the C locale.
The locale-aware tolower is much slower than the locale-unaware one. At least on Linux/GCC it calls dynamic_cast's, and is overall slower by an order of magnitude.
(cherry picked from commit 27e669296e)
I'm a bit confused; `mwsound/ffmpeg_decoder.hpp/cpp` requires FFMPEG headers to compile, how did this work in the first place?
(cherry picked from commit d2a4175804)