1
0
mirror of https://gitlab.com/OpenMW/openmw.git synced 2025-01-25 15:35:23 +00:00
OpenMW/apps/openmw/mwdialogue/dialoguemanagerimp.cpp

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

762 lines
26 KiB
C++
Raw Normal View History

#include "dialoguemanagerimp.hpp"
2010-08-06 18:01:34 +02:00
2010-08-08 15:09:44 +02:00
#include <algorithm>
#include <list>
#include <optional>
#include <sstream>
2018-08-14 23:05:43 +04:00
#include <components/debug/debuglog.hpp>
2010-08-08 15:09:44 +02:00
#include <components/esm3/dialoguestate.hpp>
#include <components/esm3/esmwriter.hpp>
#include <components/esm3/loaddial.hpp>
#include <components/esm3/loadfact.hpp>
#include <components/esm3/loadinfo.hpp>
2012-11-10 14:31:58 +01:00
#include <components/compiler/errorhandler.hpp>
#include <components/compiler/exception.hpp>
#include <components/compiler/locals.hpp>
#include <components/compiler/output.hpp>
#include <components/compiler/scanner.hpp>
#include <components/compiler/scriptparser.hpp>
#include <components/interpreter/defines.hpp>
2012-11-10 14:31:58 +01:00
#include <components/interpreter/interpreter.hpp>
#include <components/settings/settings.hpp>
#include "../mwbase/environment.hpp"
2013-01-19 16:20:22 -08:00
#include "../mwbase/journal.hpp"
2012-11-10 00:29:36 +01:00
#include "../mwbase/mechanicsmanager.hpp"
#include "../mwbase/scriptmanager.hpp"
#include "../mwbase/soundmanager.hpp"
#include "../mwbase/windowmanager.hpp"
#include "../mwbase/world.hpp"
2010-08-06 18:01:34 +02:00
#include "../mwworld/class.hpp"
#include "../mwworld/containerstore.hpp"
2012-10-01 19:17:04 +04:00
#include "../mwworld/esmstore.hpp"
2010-08-06 18:01:34 +02:00
2012-02-17 20:20:23 +01:00
#include "../mwscript/compilercontext.hpp"
#include "../mwscript/extensions.hpp"
2012-02-17 20:20:23 +01:00
#include "../mwscript/interpretercontext.hpp"
2015-08-21 21:12:39 +12:00
#include "../mwmechanics/actorutil.hpp"
#include "../mwmechanics/creaturestats.hpp"
#include "../mwmechanics/npcstats.hpp"
#include "filter.hpp"
#include "hypertextparser.hpp"
2012-09-23 00:36:20 +02:00
namespace MWDialogue
{
DialogueManager::DialogueManager(
const Compiler::Extensions& extensions, Translation::Storage& translationDataStorage)
: mTranslationDataStorage(translationDataStorage)
, mCompilerContext(MWScript::CompilerContext::Type_Dialogue)
, mErrorHandler()
2013-05-15 17:54:18 +02:00
, mTalkedTo(false)
, mOriginalDisposition(0)
, mCurrentDisposition(0)
, mPermanentDispositionChange(0)
2012-02-17 20:20:23 +01:00
{
mChoice = -1;
mIsInChoice = false;
mGoodbye = false;
mCompilerContext.setExtensions(&extensions);
2012-02-17 20:20:23 +01:00
}
2010-08-06 18:01:34 +02:00
2013-05-15 17:54:18 +02:00
void DialogueManager::clear()
{
mKnownTopics.clear();
mTalkedTo = false;
mOriginalDisposition = 0;
mCurrentDisposition = 0;
2013-05-15 17:54:18 +02:00
mPermanentDispositionChange = 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
void DialogueManager::addTopic(const ESM::RefId& topic)
2012-02-10 16:09:43 +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
mKnownTopics.insert(topic);
2012-02-10 16:09:43 +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
std::vector<ESM::RefId> DialogueManager::parseTopicIdsFromText(const std::string& text)
2012-02-15 13:23:59 +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
std::vector<ESM::RefId> topicIdList;
std::vector<HyperTextParser::Token> hypertext = HyperTextParser::parseHyperText(text);
for (std::vector<HyperTextParser::Token>::iterator tok = hypertext.begin(); tok != hypertext.end(); ++tok)
2012-02-15 13:23:59 +01:00
{
2014-10-20 01:10:08 +02:00
std::string topicId = Misc::StringUtils::lowerCase(tok->mText);
if (tok->isExplicitLink())
2012-02-15 13:23:59 +01:00
{
// calculation of standard form for all hyperlinks
2014-10-20 01:10:08 +02:00
size_t asterisk_count = HyperTextParser::removePseudoAsterisks(topicId);
for (; asterisk_count > 0; --asterisk_count)
2014-10-20 01:10:08 +02:00
topicId.append("*");
2014-10-20 01:10:08 +02:00
topicId = mTranslationDataStorage.topicStandardForm(topicId);
2012-02-15 13:23:59 +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
topicIdList.push_back(ESM::RefId::stringRefId(topicId));
}
return topicIdList;
}
void DialogueManager::addTopicsFromText(const std::string& text)
{
updateActorKnownTopics();
for (const auto& topicId : parseTopicIdsFromText(text))
{
if (mActorKnownTopics.count(topicId))
mKnownTopics.insert(topicId);
}
2012-02-15 13:23:59 +01:00
}
void DialogueManager::updateOriginalDisposition()
{
if (mActor.getClass().isNpc())
{
const auto& stats = mActor.getClass().getNpcStats(mActor);
// Disposition changed by script; discard our preconceived notions
if (stats.getBaseDisposition() != mCurrentDisposition)
{
mCurrentDisposition = stats.getBaseDisposition();
mOriginalDisposition = mCurrentDisposition;
}
}
}
bool DialogueManager::startDialogue(const MWWorld::Ptr& actor, ResponseCallback* callback)
2010-08-06 18:01:34 +02:00
{
updateGlobals();
// Dialogue with dead actor (e.g. through script) should not be allowed.
if (actor.getClass().getCreatureStats(actor).isDead())
return false;
mLastTopic = ESM::RefId();
// Note that we intentionally don't reset mPermanentDispositionChange
2013-03-31 13:13:46 +02:00
2012-03-18 15:26:18 +01:00
mChoice = -1;
mIsInChoice = false;
mGoodbye = false;
mChoices.clear();
2012-02-17 20:20:23 +01:00
mActor = actor;
2012-11-16 12:47:09 +01:00
MWMechanics::CreatureStats& creatureStats = actor.getClass().getCreatureStats(actor);
mTalkedTo = creatureStats.hasTalkedToPlayer();
2012-02-17 20:20:23 +01:00
mActorKnownTopics.clear();
2012-03-19 19:21:08 +01:00
// greeting
const MWWorld::Store<ESM::Dialogue>& dialogs
= MWBase::Environment::get().getWorld()->getStore().get<ESM::Dialogue>();
Filter filter(actor, mChoice, mTalkedTo);
for (MWWorld::Store<ESM::Dialogue>::iterator it = dialogs.begin(); it != dialogs.end(); ++it)
{
if (it->mType == ESM::Dialogue::Greeting)
{
// Search a response (we do not accept a fallback to "Info refusal" here)
if (const ESM::DialInfo* info = filter.search(*it, false))
2012-02-10 22:54:17 +01:00
{
creatureStats.talkedToPlayer();
if (!info->mSound.empty())
2012-02-10 22:54:17 +01:00
{
// TODO play sound
2012-02-10 22:54:17 +01:00
}
MWScript::InterpreterContext interpreterContext(&mActor.getRefData().getLocals(), mActor);
callback->addResponse("", Interpreter::fixDefinesDialog(info->mResponse, interpreterContext));
executeScript(info->mResultScript, mActor);
mLastTopic = it->mId;
addTopicsFromText(info->mResponse);
return true;
2012-02-10 22:54:17 +01:00
}
}
}
return false;
2012-02-10 22:01:31 +01:00
}
std::optional<Interpreter::Program> DialogueManager::compile(const std::string& cmd, const MWWorld::Ptr& actor)
{
bool success = true;
std::optional<Interpreter::Program> program;
2012-11-16 12:47:09 +01:00
2012-02-17 20:20:23 +01:00
try
2012-02-10 22:01:31 +01:00
{
mErrorHandler.reset();
2012-02-17 20:20:23 +01:00
mErrorHandler.setContext("[dialogue script]");
2012-03-05 16:56:14 +01:00
std::istringstream input(cmd + "\n");
2012-02-17 20:20:23 +01:00
Compiler::Scanner scanner(mErrorHandler, input, mCompilerContext.getExtensions());
2012-02-17 20:20:23 +01:00
2012-03-05 16:56:14 +01:00
Compiler::Locals locals;
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::RefId& actorScript = actor.getClass().getScript(actor);
2012-03-05 16:56:14 +01:00
if (!actorScript.empty())
{
// grab local variables from actor's script, if available.
locals = MWBase::Environment::get().getScriptManager()->getLocals(actorScript);
2012-03-05 16:56:14 +01:00
}
Compiler::ScriptParser parser(mErrorHandler, mCompilerContext, locals, false);
2012-02-17 20:20:23 +01:00
scanner.scan(parser);
2012-11-16 12:47:09 +01:00
if (!mErrorHandler.isGood())
success = false;
if (success)
program = parser.getProgram();
2012-02-17 20:20:23 +01:00
}
catch (const Compiler::SourceException& /* error */)
2012-02-17 20:20:23 +01:00
{
// error has already been reported via error handler
success = false;
2012-02-10 22:01:31 +01:00
}
2012-02-17 20:20:23 +01:00
catch (const std::exception& error)
{
2018-08-14 23:05:43 +04:00
Log(Debug::Error) << std::string("Dialogue error: An exception has been thrown: ") + error.what();
success = false;
}
if (!success)
{
Log(Debug::Error) << "Error: compiling failed (dialogue script): \n" << cmd << "\n";
2012-02-17 20:20:23 +01:00
}
return program;
2012-02-17 20:20:23 +01:00
}
void DialogueManager::executeScript(const std::string& script, const MWWorld::Ptr& actor)
2012-02-17 20:20:23 +01:00
{
if (const std::optional<Interpreter::Program> program = compile(script, actor))
2012-02-17 20:20:23 +01:00
{
try
{
MWScript::InterpreterContext interpreterContext(&actor.getRefData().getLocals(), actor);
2012-02-17 20:20:23 +01:00
Interpreter::Interpreter interpreter;
MWScript::installOpcodes(interpreter);
interpreter.run(*program, interpreterContext);
2012-02-17 20:20:23 +01:00
}
catch (const std::exception& error)
{
2018-08-14 23:05:43 +04:00
Log(Debug::Error) << std::string("Dialogue error: An exception has been thrown: ") + error.what();
2012-02-17 20:20:23 +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 DialogueManager::inJournal(const ESM::RefId& topicId, const ESM::RefId& infoId) const
{
const MWDialogue::Topic* topicHistory = nullptr;
MWBase::Journal* journal = MWBase::Environment::get().getJournal();
for (auto it = journal->topicBegin(); it != journal->topicEnd(); ++it)
{
if (it->first == topicId)
{
topicHistory = &it->second;
break;
}
}
if (!topicHistory)
return false;
for (const auto& topic : *topicHistory)
{
if (topic.mInfoId == infoId)
return true;
}
return false;
}
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 DialogueManager::executeTopic(const ESM::RefId& topic, ResponseCallback* callback)
2012-12-08 14:24:15 +01:00
{
Filter filter(mActor, mChoice, mTalkedTo);
2022-09-22 21:26:05 +03:00
2012-12-08 14:24:15 +01:00
const MWWorld::Store<ESM::Dialogue>& dialogues
= MWBase::Environment::get().getWorld()->getStore().get<ESM::Dialogue>();
2012-12-08 14:24:15 +01:00
const ESM::Dialogue& dialogue = *dialogues.find(topic);
const ESM::DialInfo* info = filter.search(dialogue, true);
2012-12-08 14:24:15 +01:00
if (info)
2012-12-08 14:24:15 +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
ESM::RefId title;
2012-12-08 14:24:15 +01:00
if (dialogue.mType == ESM::Dialogue::Persuasion)
{
// Determine GMST from dialogue topic. GMSTs are:
// sAdmireSuccess, sAdmireFail, sIntimidateSuccess, sIntimidateFail,
// sTauntSuccess, sTauntFail, sBribeSuccess, sBribeFail
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
std::string modifiedTopic = "s" + topic.getRefIdString();
2012-12-08 14:24:15 +01:00
modifiedTopic.erase(std::remove(modifiedTopic.begin(), modifiedTopic.end(), ' '), modifiedTopic.end());
const MWWorld::Store<ESM::GameSetting>& gmsts
= MWBase::Environment::get().getWorld()->getStore().get<ESM::GameSetting>();
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
title = ESM::RefId::stringRefId(gmsts.find(modifiedTopic)->mValue.getString());
2012-12-08 14:24:15 +01:00
}
else
2013-05-04 14:15:47 +02:00
title = topic;
2012-12-08 14:24:15 +01:00
MWScript::InterpreterContext interpreterContext(&mActor.getRefData().getLocals(), mActor);
callback->addResponse(
title.getRefIdString(), Interpreter::fixDefinesDialog(info->mResponse, interpreterContext));
if (dialogue.mType == ESM::Dialogue::Topic)
{
// Make sure the returned DialInfo is from the Dialogue we supplied. If could also be from the Info
// refusal group, in which case it should not be added to the journal.
for (ESM::Dialogue::InfoContainer::const_iterator iter = dialogue.mInfo.begin();
iter != dialogue.mInfo.end(); ++iter)
{
if (iter->mId == info->mId)
{
MWBase::Environment::get().getJournal()->addTopic(topic, info->mId, mActor);
break;
}
}
}
2012-12-08 14:24:15 +01:00
mLastTopic = topic;
executeScript(info->mResultScript, mActor);
2012-12-08 14:24:15 +01:00
addTopicsFromText(info->mResponse);
2012-12-08 14:24:15 +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
const ESM::Dialogue* DialogueManager::searchDialogue(const ESM::RefId& id)
{
return MWBase::Environment::get().getWorld()->getStore().get<ESM::Dialogue>().search(id);
}
void DialogueManager::updateGlobals()
{
MWBase::Environment::get().getWorld()->updateDialogueGlobals();
}
void DialogueManager::updateActorKnownTopics()
{
updateGlobals();
mActorKnownTopics.clear();
const auto& dialogs = MWBase::Environment::get().getWorld()->getStore().get<ESM::Dialogue>();
2017-09-25 21:47:35 +02:00
Filter filter(mActor, -1, mTalkedTo);
for (const auto& dialog : dialogs)
{
if (dialog.mType == ESM::Dialogue::Topic)
{
const auto* answer = filter.search(dialog, true);
const auto& topicId = dialog.mId;
if (answer != nullptr)
{
int topicFlags = 0;
if (!inJournal(topicId, answer->mId))
{
// Does this dialogue contains some actor-specific answer?
if (answer->mActor == mActor.getCellRef().getRefId())
topicFlags |= MWBase::DialogueManager::TopicType::Specific;
}
else
topicFlags |= MWBase::DialogueManager::TopicType::Exhausted;
mActorKnownTopics.insert(std::make_pair(dialog.mId, ActorKnownTopicInfo{ topicFlags, answer }));
}
}
}
// If response to a topic leads to a new topic, the original topic is not exhausted.
for (auto& [dialogId, topicInfo] : mActorKnownTopics)
{
// If the topic is not marked as exhausted, we don't need to do anything about it.
// If the topic will not be shown to the player, the flag actually does not matter.
if (!(topicInfo.mFlags & MWBase::DialogueManager::TopicType::Exhausted) || !mKnownTopics.count(dialogId))
continue;
for (const auto& topicId : parseTopicIdsFromText(topicInfo.mInfo->mResponse))
{
if (mActorKnownTopics.count(topicId) && !mKnownTopics.count(topicId))
{
topicInfo.mFlags &= ~MWBase::DialogueManager::TopicType::Exhausted;
break;
}
}
}
}
std::list<std::string> DialogueManager::getAvailableTopics()
{
updateActorKnownTopics();
std::list<std::string> keywordList;
for (const auto& [topic, topicInfo] : mActorKnownTopics)
{
// does the player know the topic?
if (mKnownTopics.count(topic))
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
keywordList.push_back(topic.getRefIdString());
}
// sort again, because the previous sort was case-sensitive
2014-06-14 20:25:44 +02:00
keywordList.sort(Misc::StringUtils::ciLess);
return keywordList;
}
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
int DialogueManager::getTopicFlag(const ESM::RefId& topicId) const
{
auto known = mActorKnownTopics.find(topicId);
if (known != mActorKnownTopics.end())
return known->second.mFlags;
return 0;
}
void DialogueManager::keywordSelected(const std::string& keyword, ResponseCallback* callback)
{
if (!mIsInChoice)
{
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* dialogue = searchDialogue(ESM::RefId::stringRefId(keyword));
if (dialogue && dialogue->mType == ESM::Dialogue::Topic)
{
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
executeTopic(ESM::RefId::stringRefId(keyword), callback);
}
}
}
2013-03-31 13:13:46 +02:00
bool DialogueManager::isInChoice() const
{
return mIsInChoice;
}
void DialogueManager::goodbyeSelected()
{
// Apply disposition change to NPC's base disposition if we **think** we need to change something
if ((mPermanentDispositionChange || mOriginalDisposition != mCurrentDisposition) && mActor.getClass().isNpc())
2012-11-10 00:38:45 +01:00
{
updateOriginalDisposition();
MWMechanics::NpcStats& npcStats = mActor.getClass().getNpcStats(mActor);
// Clamp permanent disposition change so that final disposition doesn't go below 0 (could happen with
// intimidate)
npcStats.setBaseDisposition(0);
int zero = MWBase::Environment::get().getMechanicsManager()->getDerivedDisposition(mActor, false);
2021-11-06 07:30:28 +03:00
int disposition = std::clamp(mOriginalDisposition + mPermanentDispositionChange, -zero, 100 - zero);
npcStats.setBaseDisposition(disposition);
2012-11-10 00:38:45 +01:00
}
2012-11-10 00:29:36 +01:00
mPermanentDispositionChange = 0;
mOriginalDisposition = 0;
mCurrentDisposition = 0;
}
void DialogueManager::questionAnswered(int answer, ResponseCallback* callback)
{
2013-05-04 14:15:47 +02:00
mChoice = answer;
2013-04-19 17:57:22 +02:00
const ESM::Dialogue* dialogue = searchDialogue(mLastTopic);
if (dialogue)
{
2013-05-04 14:15:47 +02:00
Filter filter(mActor, mChoice, mTalkedTo);
if (dialogue->mType == ESM::Dialogue::Topic || dialogue->mType == ESM::Dialogue::Greeting)
{
if (const ESM::DialInfo* info = filter.search(*dialogue, true))
2013-03-31 13:13:46 +02:00
{
2013-05-04 14:15:47 +02:00
std::string text = info->mResponse;
addTopicsFromText(text);
2013-05-04 14:15:47 +02:00
mChoice = -1;
mIsInChoice = false;
mChoices.clear();
2013-05-04 14:15:47 +02:00
MWScript::InterpreterContext interpreterContext(&mActor.getRefData().getLocals(), mActor);
callback->addResponse("", Interpreter::fixDefinesDialog(text, interpreterContext));
if (dialogue->mType == ESM::Dialogue::Topic)
{
// Make sure the returned DialInfo is from the Dialogue we supplied. If could also be from the
// Info refusal group, in which case it should not be added to the journal
for (ESM::Dialogue::InfoContainer::const_iterator iter = dialogue->mInfo.begin();
iter != dialogue->mInfo.end(); ++iter)
{
if (iter->mId == info->mId)
{
MWBase::Environment::get().getJournal()->addTopic(mLastTopic, info->mId, mActor);
break;
}
}
}
executeScript(info->mResultScript, mActor);
}
else
{
mChoice = -1;
mIsInChoice = false;
mChoices.clear();
}
}
}
updateActorKnownTopics();
2012-02-17 20:20:23 +01:00
}
void DialogueManager::addChoice(std::string_view text, int choice)
{
2018-06-08 19:18:53 +03:00
mIsInChoice = true;
2022-05-22 09:29:03 +02:00
mChoices.emplace_back(text, choice);
}
2012-04-04 22:13:57 +02:00
2022-10-17 09:43:20 +02:00
const std::vector<std::pair<std::string, int>>& DialogueManager::getChoices() const
{
return mChoices;
}
2022-10-17 09:43:20 +02:00
bool DialogueManager::isGoodbye() const
{
return mGoodbye;
}
void DialogueManager::goodbye()
{
2018-06-08 19:18:53 +03:00
mIsInChoice = false;
mGoodbye = true;
}
2012-11-10 00:29:36 +01:00
void DialogueManager::persuade(int type, ResponseCallback* callback)
2012-11-10 00:29:36 +01:00
{
bool success;
int temp, perm;
2012-11-10 00:29:36 +01:00
MWBase::Environment::get().getMechanicsManager()->getPersuasionDispositionChange(
2016-03-18 00:39:19 +01:00
mActor, MWBase::MechanicsManager::PersuasionType(type), success, temp, perm);
updateOriginalDisposition();
if (temp > 0 && perm > 0 && mOriginalDisposition + perm + mPermanentDispositionChange < 0)
perm = -(mOriginalDisposition + mPermanentDispositionChange);
mCurrentDisposition += temp;
mActor.getClass().getNpcStats(mActor).setBaseDisposition(mCurrentDisposition);
2012-11-10 00:29:36 +01:00
mPermanentDispositionChange += perm;
2015-08-21 21:12:39 +12:00
MWWorld::Ptr player = MWMechanics::getPlayer();
player.getClass().skillUsageSucceeded(player, ESM::Skill::Speechcraft, success ? 0 : 1);
if (success)
{
int gold = 0;
if (type == MWBase::MechanicsManager::PT_Bribe10)
gold = 10;
else if (type == MWBase::MechanicsManager::PT_Bribe100)
gold = 100;
else if (type == MWBase::MechanicsManager::PT_Bribe1000)
gold = 1000;
if (gold)
{
player.getClass().getContainerStore(player).remove(MWWorld::ContainerStore::sGoldId, gold);
mActor.getClass().getContainerStore(mActor).add(MWWorld::ContainerStore::sGoldId, gold);
}
}
2012-12-08 14:24:15 +01:00
2012-11-10 00:29:36 +01:00
std::string text;
if (type == MWBase::MechanicsManager::PT_Admire)
2012-12-08 14:24:15 +01:00
text = "Admire";
2012-11-10 00:29:36 +01:00
else if (type == MWBase::MechanicsManager::PT_Taunt)
2012-12-08 14:24:15 +01:00
text = "Taunt";
2012-11-10 00:29:36 +01:00
else if (type == MWBase::MechanicsManager::PT_Intimidate)
2012-12-08 14:24:15 +01:00
text = "Intimidate";
2012-12-06 18:30:19 +01:00
else
{
2012-12-08 14:24:15 +01:00
text = "Bribe";
2012-12-07 11:36:38 +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
executeTopic(ESM::RefId::stringRefId(text + (success ? " Success" : " Fail")), callback);
2012-11-10 00:29:36 +01:00
}
void DialogueManager::applyBarterDispositionChange(int delta)
2012-11-10 00:38:45 +01:00
{
if (mActor.getClass().isNpc())
{
updateOriginalDisposition();
mCurrentDisposition += delta;
mActor.getClass().getNpcStats(mActor).setBaseDisposition(mCurrentDisposition);
if (Settings::Manager::getBool("barter disposition change is permanent", "Game"))
mPermanentDispositionChange += delta;
}
2012-11-10 00:38:45 +01:00
}
bool DialogueManager::checkServiceRefused(ResponseCallback* callback, ServiceType service)
2013-03-16 20:32:21 +01:00
{
Filter filter(mActor, service, mTalkedTo);
2013-03-16 20:32:21 +01:00
const MWWorld::Store<ESM::Dialogue>& dialogues
= MWBase::Environment::get().getWorld()->getStore().get<ESM::Dialogue>();
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& dialogue = *dialogues.find(ESM::RefId::stringRefId("Service Refusal"));
2013-03-16 20:32:21 +01:00
std::vector<const ESM::DialInfo*> infos = filter.list(dialogue, false, false, true);
if (!infos.empty())
{
const ESM::DialInfo* info = infos[0];
addTopicsFromText(info->mResponse);
2013-03-16 20:32:21 +01:00
const MWWorld::Store<ESM::GameSetting>& gmsts
= MWBase::Environment::get().getWorld()->getStore().get<ESM::GameSetting>();
MWScript::InterpreterContext interpreterContext(&mActor.getRefData().getLocals(), mActor);
2013-05-04 14:15:47 +02:00
2018-08-29 18:38:12 +03:00
callback->addResponse(gmsts.find("sServiceRefusal")->mValue.getString(),
Interpreter::fixDefinesDialog(info->mResponse, interpreterContext));
2013-03-16 20:32:21 +01:00
executeScript(info->mResultScript, mActor);
2013-03-16 20:32:21 +01:00
return true;
}
return false;
}
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 DialogueManager::say(const MWWorld::Ptr& actor, const ESM::RefId& topic)
{
MWBase::SoundManager* sndMgr = MWBase::Environment::get().getSoundManager();
if (sndMgr->sayActive(actor))
{
// Actor is already saying something.
return;
}
if (actor.getClass().isNpc() && MWBase::Environment::get().getWorld()->isSwimming(actor))
{
// NPCs don't talk while submerged
return;
}
if (actor.getClass().getCreatureStats(actor).getKnockedDown())
{
// Unconscious actors can not speak
return;
}
const MWWorld::ESMStore& store = MWBase::Environment::get().getWorld()->getStore();
const ESM::Dialogue* dial = store.get<ESM::Dialogue>().find(topic);
const MWMechanics::CreatureStats& creatureStats = actor.getClass().getCreatureStats(actor);
Filter filter(actor, 0, creatureStats.hasTalkedToPlayer());
const ESM::DialInfo* info = filter.search(*dial, false);
2018-10-09 10:21:12 +04:00
if (info != nullptr)
{
MWBase::WindowManager* winMgr = MWBase::Environment::get().getWindowManager();
if (winMgr->getSubtitlesEnabled())
winMgr->messageBox(info->mResponse);
if (!info->mSound.empty())
sndMgr->say(actor, info->mSound);
if (!info->mResultScript.empty())
executeScript(info->mResultScript, actor);
}
}
int DialogueManager::countSavedGameRecords() const
{
return 1; // known topics
}
void DialogueManager::write(ESM::ESMWriter& writer, Loading::Listener& progress) const
{
ESM::DialogueState state;
state.mKnownTopics.reserve(mKnownTopics.size());
std::copy(mKnownTopics.begin(), mKnownTopics.end(), std::back_inserter(state.mKnownTopics));
state.mChangedFactionReaction = mChangedFactionReaction;
writer.startRecord(ESM::REC_DIAS);
state.save(writer);
writer.endRecord(ESM::REC_DIAS);
}
2015-01-22 19:04:59 +01:00
void DialogueManager::readRecord(ESM::ESMReader& reader, uint32_t type)
{
if (type == ESM::REC_DIAS)
{
const MWWorld::ESMStore& store = MWBase::Environment::get().getWorld()->getStore();
ESM::DialogueState state;
state.load(reader);
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
for (std::vector<ESM::RefId>::const_iterator iter(state.mKnownTopics.begin());
iter != state.mKnownTopics.end(); ++iter)
if (store.get<ESM::Dialogue>().search(*iter))
mKnownTopics.insert(*iter);
mChangedFactionReaction = state.mChangedFactionReaction;
}
}
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 DialogueManager::modFactionReaction(const ESM::RefId& faction1, const ESM::RefId& faction2, int diff)
{
// Make sure the factions exist
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
MWBase::Environment::get().getWorld()->getStore().get<ESM::Faction>().find(faction1);
MWBase::Environment::get().getWorld()->getStore().get<ESM::Faction>().find(faction2);
int newValue = getFactionReaction(faction1, faction2) + diff;
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
auto& map = mChangedFactionReaction[faction1];
map[faction2] = newValue;
}
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 DialogueManager::setFactionReaction(const ESM::RefId& faction1, const ESM::RefId& faction2, int absolute)
{
// Make sure the factions exist
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
MWBase::Environment::get().getWorld()->getStore().get<ESM::Faction>().find(faction1);
MWBase::Environment::get().getWorld()->getStore().get<ESM::Faction>().find(faction2);
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
auto& map = mChangedFactionReaction[faction1];
map[faction2] = absolute;
}
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
int DialogueManager::getFactionReaction(const ESM::RefId& faction1, const ESM::RefId& faction2) 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
ModFactionReactionMap::const_iterator map = mChangedFactionReaction.find(faction1);
if (map != mChangedFactionReaction.end() && map->second.find(faction2) != map->second.end())
return map->second.at(faction2);
const ESM::Faction* faction
= MWBase::Environment::get().getWorld()->getStore().get<ESM::Faction>().find(faction1);
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
auto it = faction->mReactions.begin();
for (; it != faction->mReactions.end(); ++it)
{
if (it->first == faction2)
return it->second;
}
return 0;
}
void DialogueManager::clearInfoActor(const MWWorld::Ptr& actor) const
{
if (actor == mActor && !mLastTopic.empty())
{
MWBase::Environment::get().getJournal()->removeLastAddedTopicResponse(
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
mLastTopic, actor.getClass().getName(actor));
}
}
2010-08-06 18:01:34 +02:00
}