Capostrophic wrote:Distant land was in form of distant terrain in Ogre version.
Ah, I see. Good to know.
Allofich wrote:
CODE: SELECT ALL
- Fixed NPCs not favoring ranged weapons
"[...] when the player is far away"
I took a quick look at the code for that fix, and unless I'm mistaken it does not specifically make NPCs favor ranged weapons when the player is far away, it just gave a general boost to the likelihood of ranged weapons being chosen by the AI in any situation.
I know this issue but, to me, it sounded a bit strange (as if the ranged weapons needed to be favoured naturally).
How about "Fixed NPCs not favoring ranged weapons over comparable melee ones in combat"?
How about "Fixed NPCs not favoring ranged weapons over comparable melee ones in combat"?
Yeah, I suppose that's fine. I think it's mostly a fix in that it made an NPC who was expected to use thrown weapons because they did so in the original game also do so in OpenMW, so another option might be "Fixed NPCs not using ranged weapons as often as in the original game" or "as in vanilla Morrowind."
In file included from /build/openmw-0.39.0/components/files/configurationmanager.cpp:1:0:
/build/openmw-0.39.0/components/files/configurationmanager.hpp:56:22: error: 'unordered_map' in namespace 'std' does not name a template type
typedef std::unordered_map<std::string, path_type_f> TokensMappingContainer;
^~~~~~~~~~~~~
/build/openmw-0.39.0/components/files/configurationmanager.hpp:71:9: error: 'TokensMappingContainer' does not name a type
TokensMappingContainer mTokensMapping;
^~~~~~~~~~~~~~~~~~~~~~
/build/openmw-0.39.0/components/files/configurationmanager.cpp: In member function 'void Files::ConfigurationManager::setupTokensMapping()':
/build/openmw-0.39.0/components/files/configurationmanager.cpp:48:5: error: 'mTokensMapping' was not declared in this scope
mTokensMapping.insert(std::make_pair(mwToken, &FixedPath<>::getInstallPath));
^~~~~~~~~~~~~~
/build/openmw-0.39.0/components/files/configurationmanager.cpp: In member function 'void Files::ConfigurationManager::processPaths(Files::PathContainer&, bool)':
/build/openmw-0.39.0/components/files/configurationmanager.cpp:90:17: error: 'TokensMappingContainer' has not been declared
TokensMappingContainer::iterator tokenIt = mTokensMapping.find(path.substr(0, pos + 1));
^~~~~~~~~~~~~~~~~~~~~~
/build/openmw-0.39.0/components/files/configurationmanager.cpp:91:21: error: 'tokenIt' was not declared in this scope
if (tokenIt != mTokensMapping.end())
^~~~~~~
/build/openmw-0.39.0/components/files/configurationmanager.cpp:91:32: error: 'mTokensMapping' was not declared in this scope
if (tokenIt != mTokensMapping.end())
^~~~~~~~~~~~~~
components/CMakeFiles/components.dir/build.make:3457: recipe for target 'components/CMakeFiles/components.dir/files/configurationmanager.cpp.o' failed
make[3]: *** [components/CMakeFiles/components.dir/files/configurationmanager.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/build/openmw-0.39.0/build'
CMakeFiles/Makefile2:307: recipe for target 'components/CMakeFiles/components.dir/all' failed
make[2]: *** [components/CMakeFiles/components.dir/all] Error 2
make[2]: Leaving directory '/build/openmw-0.39.0/build'
Makefile:127: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/build/openmw-0.39.0/build'
Considering that whatever Debian does, Ubuntu will follow so this probably should be addressed.
Update: From what I've read, we're still using -std=c++98 while -std=c++11 (GCC >= 4.7.x) or -std=c++0x (GCC <= 4.6.X) si where std::unordered_map was introduced. I haven't tested this yet. https://stackoverflow.com/questions/157 ... ame-a-type
- Fixed crash when loading an ESP file with a '#' character in the filename
It wasn't just esp files, but in fact any variable in openmw.cfg including a '#' would be truncated from that point on loading, so, for example, when told to load "modwitha#hash.esp", it would try and load a file called "modwitha", which inevitably wouldn't exist. The exact same issue would occur with an esm or an openmwaddon. If you tried to add "C:/Games/OpenMWMods/#graphics/lysol's-textures/" as a mod directory, it would instead add "C:/Games/OpenMWMods/", which wouldn't cause a crash (as it's still a valid directory), but would obviously leave you without normal and parallax mapping.
It's a little more subtle than the original bug report suggested.
Thanks for this, this is a problem for 0.38 and 0.39 releases on Debian. 0.39 has yet to be released. I'm glad this won't be a problem in 0.40 but I'll keep my eye on it.
Updated original post.
Update: Just tried with 0.40 using debian's experimental and everything works as expected with Boost 1.61 and -std=c++98 Sorry for the alarm.
Out of currorisity, what is holding us back from C++11 adoption?
The final version of the editor video has been uploaded.
-----------------------------------------------
>>> https://youtu.be/izlm2CAnCpY <<<
-----------------------------------------------
Important changes:
- added version overlays for every scene (curse that poll!)
- re-recorded the voice track and added some noise reduction
@Atahualpa, thank you so much for all the corrections! I've cherrypicked through them, as some of them were more an issue of subjectivity, rather than mistakes. I understand the language can be a bit awkward because I am trying to force the entries into a certain format, and I understand we have different philosophies on punctuation sometimes, but I do really appreciate every one of your fixes- thank you!
psi29a wrote:Out of curiosity, what is holding us back from C++11 adoption?
I'm curious about that too. I think I previously read somewhere that we don't want to force developers to use specific compilers, but c++11 is becoming more mainstream.