Emulating vanilla to get some issues closed

Everything about development and the OpenMW source code.
Post Reply
Allofich
Posts: 104
Joined: 28 May 2016, 12:50

Emulating vanilla to get some issues closed

Post by Allofich » 10 Dec 2016, 08:32

After discussion in viewtopic.php?f=2&t=3979, I decided to make this topic.

I might be wrong, but I feel like there are some issues on the bug tracker being held up because of uncertainty about how to proceed on them. Lately, MiroslavR has been doing lots of great work, getting us some very accurate-to-original behaviors. It seems like a good idea to me for all development to basically go in that direction, especially until 1.0, with configuration options for alternate behaviors. I don't think we should recreate bugs, and unfortunately, there might be a number of cases where it's arguable whether the vanilla behavior is a bug or mistake in design that we shouldn't recreate, but one thing at a time I guess.

To be more specific, here are some of the bug tracker issues I'm thinking about. These are all just my opinion. Basically for these I think we should implement the vanilla behavior and have the alternate behavior as a configuration option. As long as it's all implemented discretely, I don't think that more configuration options would be a big problem for code maintenance and testing, would it? As for the default options, other than outright bug fixes I think "all vanilla" might be the safest. Then people would know what was different in their game from vanilla as they changed options.

https://bugs.openmw.org/issues/3254
To me, the issue of AI accidentally hitting each other is probably the biggest gameplay problem still in OpenMW. It's kind of a fun feature being able to have them hit each other, but it happens so much right now. To get to 1.0, I think we should copy vanilla for now, with AI hitting unintended targets maybe still available as a configuration option. The downside is that there may not be as much incentive to improve the AI to avoid hitting each other if we do that, but there doesn't seem to be any work going on in that direction anyway...

https://bugs.openmw.org/issues/3586
I think we should leave this as is for now, like vanilla, and change this to a feature request.

https://bugs.openmw.org/issues/3257
I think we should have OpenMW ignore the environment map on the equipped cuirass by default, since otherwise a fixed model will be necessary. Maybe allow it to show as a configuration option.

https://bugs.openmw.org/issues/2623
I think we should recreate the vanilla spellcasting behavior, because users should have the option of playing with the original spellcasting AI, which the original game and mods for the original game will have been designed for. The AI spell selection in the original game seems to follow a fairly non-variable decision tree, which I don't think it would be that hard to recreate. I think we should keep the OpenMW spell selection available as an option.

https://bugs.openmw.org/issues/2455
I think we should have the reduction of armor condition as a configuration choice.

https://bugs.openmw.org/issues/1751
https://bugs.openmw.org/issues/1816
I think we should re-implement the vanilla behavior, and again perhaps offer these as configuration options. There is talk about game balancing in the comments there, but seems to me like game balancing should be left to modding, not changes by OpenMW.

There are also issues where I think the vanilla behavior is too buggy and should not be copied, but we should probably still include a recreation of the vanilla behavior as a compatibility option.

https://bugs.openmw.org/issues/3109
I think the position command should work as it is described in the TES Construction Set help file. This is also apparently how Bethesda quest makers thought it worked, since it's how they wrote the scripts. One official quest will position an NPC correctly if we fix this.

https://bugs.openmw.org/issues/3006
Parsing "else if" wrongly just seems like a little too much. But again, how about we include vanilla behavior as a compatibility option?

I'm sure I've probably got some mistaken assumptions in here somewhere, and maybe adding all these configuration options is more problematic than I'm thinking, but I think if we can get these issues done we'll be a good bit closer to 1.0.

User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Emulating vanilla to get some issues closed

Post by scrawl » 10 Dec 2016, 10:04

Completely agreed with your notes. I also agree that options should be added whenever appropriate; even for things that most people feel are outright bugs, I've heard of 'purists' out there that like to experience the game with its original bugs/exploits. The issue right now is that I am not sure where niche gameplay options would go. settings.cfg is already quite bloated and was originally just meant for things like graphics and sound options. I believe Zini's plan was to add options to the content files which won't be possible to do properly until we extend the format post-1.0. As an intermediate solution we could have a new settings file.

User avatar
psi29a
Posts: 4720
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Emulating vanilla to get some issues closed

Post by psi29a » 10 Dec 2016, 10:33

Perhaps yet another file specific for modifying gameplay, a gameplay.cfg (or something). You have OpenMW (fixed problems) and Morrowind (Purist) modes.

Allofich
Posts: 104
Joined: 28 May 2016, 12:50

Re: Emulating vanilla to get some issues closed

Post by Allofich » 10 Dec 2016, 11:26

Glad you agree. Regarding the current file being bloated, I only see four settings under [Game] in the default settings file, including a couple fairly niche ones. For the time being we could just put them there, right? The already existing ones will need to be moved to any new file that we start using anyway.

Chris
Posts: 1566
Joined: 04 Sep 2011, 08:33

Re: Emulating vanilla to get some issues closed

Post by Chris » 10 Dec 2016, 12:52

Allofich wrote:https://bugs.openmw.org/issues/3254
To me, the issue of AI accidentally hitting each other is probably the biggest gameplay problem still in OpenMW. It's kind of a fun feature being able to have them hit each other, but it happens so much right now. To get to 1.0, I think we should copy vanilla for now, with AI hitting unintended targets maybe still available as a configuration option. The downside is that there may not be as much incentive to improve the AI to avoid hitting each other if we do that, but there doesn't seem to be any work going on in that direction anyway...
The way hit-detection works (in both vanilla and OpenMW) is pretty crude. It essentially just does a cone collision test in the direction of the attack, where OpenMW picks the closest viable contact point, but vanilla probably does a bit more work to determine what to hit. In reality, a person will have much greater control over what they hit than the collision test allows for, so having some way to prioritize enemy targets isn't a bad idea at all.

I once had the idea to have the test check for the closest enemy, friendly, and neutral target points separately, and weigh the decision based on the hit distance along with their friendliness status (where neutral targets would be things like statics, corpses, etc; things which vanilla Morrowind doesn't consider for hit targets, but we may want to eventually). So a friendly actor would have to be notably closer than an enemy to be considered for hitting if they're both within the collision shape. I don't know how vanilla prioritizes hitting enemies over friendlies, but this doesn't seem like a bad idea to me.
https://bugs.openmw.org/issues/3257
I think we should have OpenMW ignore the environment map on the equipped cuirass by default, since otherwise a fixed model will be necessary. Maybe allow it to show as a configuration option.
Perhaps just ignore the environment map for equipped items for NIF models, while other model formats would honor it. Having a toggleable option seems like a mess waiting to happen, where some mods want or expect the option to be disabled, while other mods want or expect the option to be enabled.
https://bugs.openmw.org/issues/2455
I think we should have the reduction of armor condition as a configuration choice.
Or perhaps a creature flag, "Damages Armor" (ignored when the creature is a Biped with a weapon, as it will always damage it in that case).
https://bugs.openmw.org/issues/1751
https://bugs.openmw.org/issues/1816
I think we should re-implement the vanilla behavior, and again perhaps offer these as configuration options. There is talk about game balancing in the comments there, but seems to me like game balancing should be left to modding, not changes by OpenMW.
I think the problem is that it's more difficult for mods to handle working with dynamic values and getting certain systems (training, level up) to read the base values instead. How exactly would a mod fix the drain-and-train glitch, for example? The way Morrowind works with fortified/drained/damaged stats is a mess, to the point where it lends to buggy behavior (for example, not being able to restore damaged attributes that are also fortified), so trying to fully replicate it is just asking for more problems, as well as more work to re-fix them with options in the future. I think having something clean and understandable that roughly follows the apparent intent is more important, from both a code maintainability and future moddability standpoint, than to replicate vanilla 100% on that front.

User avatar
MiroslavR
Posts: 156
Joined: 12 Feb 2014, 17:45

Re: Emulating vanilla to get some issues closed

Post by MiroslavR » 10 Dec 2016, 16:11

Regarding vanilla AI combat decision making, here's the part I uncovered when I was researching fleeing:
https://gist.github.com/MiroslavR/097bf ... 9258fabf25

AFAIK, getFleeRating(), getMagicCombatRating() and getWeaponCombatRating() are all complete, but shouldFlee() (or prepareNextAction()) is unfinished and still requires a significant amount of researching work. Potion selection looks like a huge mess; it will probably be rough to convert it into a neat rating system. As for enchanted items, I have no clue if the original AI makes use of them.

I may look into this further some time in the future, but I make no promises.

Allofich
Posts: 104
Joined: 28 May 2016, 12:50

Re: Emulating vanilla to get some issues closed

Post by Allofich » 10 Dec 2016, 16:20

As for enchanted items, I have no clue if the original AI makes use of them.
Just from observation from playing the game, they do, but it seems like they will only ever use the item once.

Allofich
Posts: 104
Joined: 28 May 2016, 12:50

Re: Emulating vanilla to get some issues closed

Post by Allofich » 11 Dec 2016, 06:28

I don't know how vanilla prioritizes hitting enemies over friendlies, but this doesn't seem like a bad idea to me.
Are you talking about when the player attacks? As far as I know, AI in vanilla can't accidentally hit anything besides its intended target, except when using spells that affect an area.
Having a toggleable option seems like a mess waiting to happen, where some mods want or expect the option to be disabled, while other mods want or expect the option to be enabled.
Maybe so. There probably aren't any Morrowind-specific models out there yet using the environmental maps for equipped items, so we could just disable it, and revisit it if there turns out to be demand for it. Or maybe allow toggling with a warning that it causes the ebony cuirass (and possibly some equipment in mods?) to look wrong.
Or perhaps a creature flag, "Damages Armor"
Do you mean like one that could be turned on and off by creature in the editor? I don't think we're adding anything to the file data right now.
I think the problem is that it's more difficult for mods to handle working with dynamic values and getting certain systems (training, level up) to read the base values instead.
I agree that fixes that are hard or impossible to do through mods should be supplied through OpenMW. I think we should, design-wise, copy the vanilla way, though, just fixing things that reasonably look like bugs. (scrawl suggested some purists want the bugs, too. Maybe we could ideally even provide that, but if you really want the 100% original experience, play the original :P ) I didn't know about the "not being able to restore damaged attributes that are also fortified" issue, but my first impression, without having looked into it, is that we should not replicate that. On the other hand, the bug tracker issue I linked to should, I think, be made to work like vanilla with the current behavior available through a toggle, since there are people saying they like the current behavior.

CMAugust
Posts: 198
Joined: 10 Jan 2016, 00:13

Re: Emulating vanilla to get some issues closed

Post by CMAugust » 11 Dec 2016, 11:49

There are two points of apparent developer intent regarding birthsigns that OpenMW currently does not follow:

1) Gameplay - as far as the player was concerned, attribute bonuses from a sign were as ingrained as a racial attribute bonus, and were factored into any checks and calculations accordingly;

2) User Interface - numbers highlighted in the Stats Menu were intended to inform the player about temporary changes to the base value. As gameplay and the name itself suggests, birthsigns are an immutable part of the character's makeup from the time the player finalizes character creation. From a design point of view, it's unhelpful to highlight a change the player can't do anything about, and affects menu readability.

Although it may result in some headaches, I believe these design features should be honored in OpenMW. Hopefully an elegant, as-yet-undiscovered solution to its implementation will present itself.

Chris
Posts: 1566
Joined: 04 Sep 2011, 08:33

Re: Emulating vanilla to get some issues closed

Post by Chris » 11 Dec 2016, 13:23

Allofich wrote:Are you talking about when the player attacks? As far as I know, AI in vanilla can't accidentally hit anything besides its intended target, except when using spells that affect an area.
In general, I mean. It's probably not a bad idea to treat player attacks and AI attacks as similarly as possible, to reduce unnecessary special-cases. In the case of AI, it could be that because enemies don't move terribly often, when the AI makes the determination to attack a target that it knows it will hit at the time, it's extremely unlikely to then miss when the attack comes down.
Or perhaps a creature flag, "Damages Armor"
Do you mean like one that could be turned on and off by creature in the editor? I don't think we're adding anything to the file data right now.
Right. But my thinking is that this isn't anything any mod relies on, it doesn't seem to be a terribly in-demand feature, and having a global 'all creatures damage armor' config option seems a bit too all-or-nothing. A creature flag you'd set in the editor makes the most sense, even if people have to wait a bit longer for it.

To clarify, I mean implementing vanilla behavior of creatures not damaging armor, and then wait for a new editor feature to allow individual creature types to damage armor. (Although, IIRC, some tests regarding the item description feature seemed to indicate the vanilla engine ignores unrecognized fields, so there may not be a compatibility problem to add it to the creature struct as an optional field).

Post Reply