Marked Improvements, ?fixes

Feedback on past, current, and future development.
User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Marked Improvements, ?fixes

Post by Zini » 11 Mar 2013, 15:17

We're going to anyway, once we start having mods that want to scale objects beyond the 0.5...2.0 limit. Then we'll be in the messy world of conflicts as some mods want to scale objects as they see fit, and others rely on veritably broken behavior.
That is unavoidable anyway. After 1.0 we will move away from hardcoded behaviour in many areas and make things more customisable. When used this customisability will inevitably violate some assumptions made by the authors of some mods. That does not mean we should break those mods by default, even when the new customisability is not used.

The rescaling misfeature is not a special case and I see no reason to give it a special treatment, especially since the workaround is so easy and simple (took me about 10 minutes to implement the re-scaling, will take about another 10 minutes to implement the GMST switch).

As I have written before I don't really expect this to be used with Morrowind.esm. However that is up to the modding community. For TCs on the other hand re-scaling switched off should be the default.
And if we absolutely need a save-load detector, with valid use-cases presented, then it would be better to do it properly. A signal or a global variable that's set for the first frame after load.
With this I agree. We should consider adding such a feature at some point.

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

Re: Marked Improvements, ?fixes

Post by Chris » 12 Mar 2013, 02:04

Zini wrote:That is unavoidable anyway.
I don't see how. If we don't replicate the broken behavior, mods can't use it. We can't have conflicts if we don't provide different behaviors for different mods to fight over.
After 1.0 we will move away from hardcoded behaviour in many areas and make things more customisable. When used this customisability will inevitably violate some assumptions made by the authors of some mods. That does not mean we should break those mods by default, even when the new customisability is not used.
And we're going to have enough new features that can break mods them in the future, so I don't see a reason to make more unnecessary problems for ourselves.

If we don't force rescaling then some mods will, at most, lose a misfeature of being able to detect a game load. Since the game does allow large and small scales during play, the mods themselves will function and work, just while believing the player never quits/reloads as the scale will never get reset/clamped by the process. If the mod allows the player to continue playing after making the save, it's impossible for this to be a problem. If we do force it, however, then we create a compatibility issue as some mods will try to force the rescaling off (breaking mods that need it on), and others will force it on (breaking mods that need it off).
As I have written before I don't really expect this to be used with Morrowind.esm.
I don't see why not. If someone wants to make really large or really small scaled objects, it's completely up to them. Mods or TCs, I'd expect anything we provide to be used by either.

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Marked Improvements, ?fixes

Post by Zini » 12 Mar 2013, 07:18

don't see how. If we don't replicate the broken behavior, mods can't use it. We can't have conflicts if we don't provide different behaviors for different mods to fight over.
With this statement I meant compatibility problems in general, resulting from OpenMW being more flexible than MW.
And we're going to have enough new features that can break mods them in the future, so I don't see a reason to make more unnecessary problems for ourselves.
Consistency? We are replicating the behaviour of MW, unless there is a very strong contrary indicator.
I don't see why not. If someone wants to make really large or really small scaled objects, it's completely up to them. Mods or TCs, I'd expect anything we provide to be used by either.
You can have large and small scaled objects in MW. It just takes a tiny bit of scripting.

But yes, it is completely up to the content developers which features they use. And it is also up them to consider the resulting compatibility problems.


The less difference we have in the behaviour between OpenMW and MW, the better, especially if it costs us nothing. This is a tiny feature, that took a tiny amount of work and will only add a tiny amount to the possible compatibility challenge for future content developers while at the same time avoids us having to explain to users and developers of some older mods, why their stuff does not work on OpenMW. Looks like an obvious decision to me.

ezzetabi
Posts: 407
Joined: 03 Feb 2012, 16:52

Re: Marked Improvements, ?fixes

Post by ezzetabi » 12 Mar 2013, 09:50

To make everyone happy you might want to add a new subrecord, for example "SANE".
If the subrecord is present the object has a OpenMW behavior, if it does not the object has a Morrowind, possibly insane, behavior.

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

Re: Marked Improvements, ?fixes

Post by Chris » 12 Mar 2013, 11:24

Zini wrote:Consistency? We are replicating the behaviour of MW, unless there is a very strong contrary indicator.
The game allows objects to be scaled outside of the 0.5-2.0 range and it runs fine with it. On load, however, the scale gets clamped, so the object gets the incorrect scale when loaded. This is clearly a bug in the vanilla engine (either it should never allow it to go outside that range, or it should handle the scale beyond that range correctly). AFAIK we're not replicating bugs unnecessarily, and indeed, one of our stated goals is to avoid recreating bugs the vanilla engine suffers from whenever possible. I've yet to hear a valid reason why this bug needs to be replicated, particularly with the issues* and security holes** it introduces.

* Issues:
1) Objects that want to be outside the 0.5...2.0 scale now have to have a constantly-running script, which does nothing but check the object's scale every frame on the off-chance the user reloaded a save, to work around the bug. Either that or set a GMST, which just puts us right where we should've been in the first place (and hope nothing else tries to set the GMST back).
2) It makes modding the object (via another mod) difficult since the scale is set via an active script rather than a record that can be edited. Depending on the script and the author's wishes, this can make it impossible to supply an edited script whose only difference is the scale value.
3) Makes it harder for content creators since the object's Scale field may not accurately reflect the actual scale of the object in game.
4) Makes it harder to batch, since objects that get modified at run-time are are more difficult to batch properly.

** Security hole:
1) Allows scripts to detect a state they have no business knowing. This in turns allows them to screw around with the player's saves, doing things that may not be immediately obvious and cause problems that can be attributed to the engine.

And for all that, I can't name anything useful it enables.
You can have large and small scaled objects in MW. It just takes a tiny bit of scripting.
Scripting objects in MW isn't the best thing in the world, given how each object can only have one script attached to it. If something is already scripted, it causes more unnecessary work for the modder.
But yes, it is completely up to the content developers which features they use. And it is also up them to consider the resulting compatibility problems.
So the fewer compatibility problems we create, the better.
The less difference we have in the behaviour between OpenMW and MW, the better, especially if it costs us nothing.
Except it does cost us. The relevant engine code may be small, but the potential issues aren't. The added work content developers may have to do, the possible issues they have to watch for, the possible bug reports we have to handle, the extra resource strain on the engine... there's more to it than a simple flag in the loading function.

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Marked Improvements, ?fixes

Post by Zini » 12 Mar 2013, 11:53

To make everyone happy you might want to add a new subrecord, for example "SANE".
If the subrecord is present the object has a OpenMW behavior, if it does not the object has a Morrowind, possibly insane, behavior.
That would be another option. A lot more costly though. Maybe too costly, considering that this is only a very minor issue to begin with.

@Chris: I guess we have to agree to disagree once more, because I disagree with pretty much every single statement in your last posting.

User avatar
Markelius
Posts: 58
Joined: 19 Mar 2013, 09:13

Re: Marked Improvements, ?fixes

Post by Markelius » 02 Jul 2013, 06:27

abot wrote:This and other exploits of engine quirks (e.g. removeitem inventory encumbrance bug, used to give gold weight...) have been used by popular mods.

In short, I think you should aim to compatibility with engine quirks when they have been used by mods, else it will be only half-compatible.
While it might break mods, it would probably be a better idea to implement features that allow those mods to be recreated without weird loopholes and quirks, it would solve two problems at once.
Known as starwarsgal by the Morrowind Modding community.
modding tumblr | bethsoft forum profile

BlueFootedBooby
Posts: 34
Joined: 15 Sep 2013, 16:00
Location: ...here?

Re: Marked Improvements, ?fixes

Post by BlueFootedBooby » 15 Sep 2013, 16:10

Tarius wrote: I wouldnt ask these types of questions. This is a game where you have a mud crab merchant.
The people at Bethesda have always been unique snowflakes. They made a game with a world the size of Britain where the tutorial breaks halfway through; then a game with one of the most fascinating settings since Planescape: Torment where depending on your machine specs you can fall through the floor if you quicksave while falling; then a game where everyone shouts about mudcrabs 24/7 and horses have textured, normal mapped anuses. They're amazing world builders, so-so writers, comically inconsistent programmers, and always, above all else, quirky as all hell.

Honestly, I find stuff like the fatigue bar to be part of the charm.

User avatar
TorbenC
Posts: 146
Joined: 26 Aug 2012, 23:13

Re: Marked Improvements, ?fixes

Post by TorbenC » 15 Sep 2013, 22:50

BlueFootedBooby wrote:
Tarius wrote: I wouldnt ask these types of questions. This is a game where you have a mud crab merchant.
The people at Bethesda have always been unique snowflakes. They made a game with a world the size of Britain where the tutorial breaks halfway through; then a game with one of the most fascinating settings since Planescape: Torment where depending on your machine specs you can fall through the floor if you quicksave while falling; then a game where everyone shouts about mudcrabs 24/7 and horses have textured, normal mapped anuses. They're amazing world builders, so-so writers, comically inconsistent programmers, and always, above all else, quirky as all hell.

Honestly, I find stuff like the fatigue bar to be part of the charm.
Sheer brilliance in that post.

Tarius
Posts: 574
Joined: 24 Oct 2011, 19:29

Re: Marked Improvements, ?fixes

Post by Tarius » 17 Sep 2013, 18:44

Nice name. That post reminds me of another game series: Quest for Glory.
I am a bigger fan of tons of control rather than taking the "user-friendly" approach.
-Okulo

Post Reply