Please stop implementing Vanilla Bugs as Features

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
Post Reply
Acrytex
Posts: 2
Joined: 07 Mar 2022, 04:00

Please stop implementing Vanilla Bugs as Features

Post by Acrytex »

Please for the love of god fix the 0.47 update that RUINED enchanting for ranged weapons. For those who arent aware yet, not only does the new DOWNGRADE in 0.47 remove your ability to enchant ranged weapons with "cast when strike" (i.e steel crossbow, steel longbow, Daedric longbow etc) you can no longer use any enchantments you may have already made before the update. WHY WOULD YOU DO THIS?! WHOS IDEA WAS IT TO IMPLEMENT A BUG AS A FEATURE!?!? People are so attached to the broken parts of this game and want it to continue being broken because "ooooh im so edgy i play a broken game". It was already fixed. It was already working! Why did you ruin it?! you didnt even make it optional! You just said "screw the players that are finally happy to see this bug fix" and BROKE the game again. This is ridiculous. Ive never seen anybody do something so stupid :evil: :evil: :evil: :evil: :evil:
CMAugust
Posts: 285
Joined: 10 Jan 2016, 00:13

Re: Please stop implementing Vanilla Bugs as Features

Post by CMAugust »

With a few exceptions, OpenMW generally favors vanilla engine behavior as a baseline unless it's blatantly wrong. The reason for this is so that it has maximum compatibility with existing mods and player expectations. This can be frustrating at times, but the end goal has always been to dehardcode these strange gameplay mechanics for maximum flexibility. Ultimately, users will be able to enjoy an enhanced experience through mods or a purist experience out of the box. OpenMW currently is in that transition phase, where game mechanics are simultaneously being tightened up (resolving inconsistencies with vanilla) and dehardcoded (via development of the Lua scripting API). All I can say is to hang in there and watch this space, because further changes to OpenMW are coming that will open the door again to implementing your desired behavior.
darkbasic
Posts: 153
Joined: 18 Apr 2016, 15:45
Contact:

Re: Please stop implementing Vanilla Bugs as Features

Post by darkbasic »

Yeah but in the meantime a switch in the launcher wouldn't have been bad considering we had a different implementation before :)
User avatar
AnyOldName3
Posts: 2673
Joined: 26 Nov 2015, 03:25

Re: Please stop implementing Vanilla Bugs as Features

Post by AnyOldName3 »

It would, because it's a pain to maintain before and after implementations of every function whose behaviour's changed at some point where someone was unhappy with the new version. Even within Morrowind's dev team, there was disagreement about what was the intended behaviour with some mechanics, and fans are even more varied with what they consider a bug versus a feature, so it would be several hundred checkboxes and a mountain of confusing unmaintainable code if we had a setting here and in equivalent situations. It's only tenable for us to have one Morrowind-accurate implementation, and then give users the flexibility to implement their preferred behaviour as a mod once the relevant part of the engine's dehardcoded.
sonicboom12345
Posts: 18
Joined: 13 Sep 2016, 23:47

Re: Please stop implementing Vanilla Bugs as Features

Post by sonicboom12345 »

I agree with the OP. It's absurd to let devotion to design philosophy come in the way of user experience. The user experience is what matters. I know that's not a popular opinion, but I think any team collab can be vulnerable to groupthink, which causes valid criticisms to be waved away without giving them due consideration.

"The reason for this is so that it has maximum compatibility with existing mods and player expectations." This is silly. What mod is something like this going to break? A mod that allows you to enchant a ranged weapon, which could have been deprecated by the engine itself? Who would complain about that? Why change this?

"It would, because it's a pain to maintain before and after implementations of every function whose behaviour's changed at some point where someone was unhappy with the new version." Man, just make it an option in the launcher. There's an option for Toggle Sneak, isn't there? That wasn't in the original game, but it's an obvious gameplay improvement that's popular.

"All I can say is to hang in there and watch this space, because further changes to OpenMW are coming that will open the door again to implementing your desired behavior." Fine. But understand that community confidence in OpenMW's LUA implementation is not particularly high. This has come up again and again and it is repeatedly dismissed by members of the team who refuse to budge on the core issues. I fully expect that LUA will be possible with OpenMW at some point, but I have 0% confidence that it will ever attain parity with what MWSE is capable of because of all the restrictions that have been added to the API. None of this is to denigrate the work of the people who are working on LUA right now. But when you say "Just wait for LUA," people are going to have extreme reservations about it due to the design mentality, and rightfully so.
User avatar
AnyOldName3
Posts: 2673
Joined: 26 Nov 2015, 03:25

Re: Please stop implementing Vanilla Bugs as Features

Post by AnyOldName3 »

This is silly. What mod is something like this going to break?
This is where it becomes clear to the educated reader that you've never tried to recreate the engine of one of the most architecturally insane commercially successful games ever. I'd estimate around a third of mods would end up noticeably broken by things like this that seem obviously like minor changes. Lots of things loads of people have used for years look upon a house of cards green with envy at its structural stability. Anything which accurately describes how easily things can be broken will sound like hyperbole.
Man, just make it an option in the launcher.
just
just
That word's doing some serious heavy lifting there. It's not just a matter of adding a checkbox to the launcher (and even if it was, that wouldn't be feasible for the number of things people want to tweak as it's well into the hundreds, and no one likes a list of hundreds of checkboxes). In many cases, each version of the behaviour is a fairly significant amount of code which interacts with an even larger amount of code. Anyone with a modicum of software engineering experience can see that having lots of code that interacts with other bits of code and where lots of it can be swapped out for other bits of code is going to become nightmarish very quickly. It becomes impossible to test and maintain, and then once it works, you can never touch it again or you'll end up breaking it.

If it's as little work as you think, then surely you'd put your money where your mouth is and maintain your own fork that did what you wanted and sort out all the problems people reported with it.
There's an option for Toggle Sneak, isn't there?
For now. It's likely to be migrated to an officially-provided Lua mod Soon™. In fact, there's a decent chance that it's soon enough that the trademark symbol there is misleading.
Fine. But understand that community confidence in OpenMW's LUA implementation is not particularly high. This has come up again and again and it is repeatedly dismissed by members of the team who refuse to budge on the core issues.
The linked thread is actually only discussing a few features of fairly limited scope. You don't need unrestricted filesystem access, unrestricted network access, or the ability to trigger a save from a game script in order to have enchanted ranged weapons, so it's not actually relevant at all here, at least not in the way you want it to be. It is a little relevant in that it's a thread consisting of OpenMW team members (not some random modder - Wazabear's the one who implemented our new lighting system and is working on the post-processing framework) having a fairly heated debate about the scripting system, which is pretty good evidence that there isn't mass groupthink.
I fully expect that LUA will be possible with OpenMW at some point, but I have 0% confidence that it will ever attain parity with what MWSE is capable of because of all the restrictions that have been added to the API.
There are already things you can do with master-branch OpenMW that aren't possible with MWSE Lua, so it's not like we're only going to be offering a tiny subset of what modders want. The fact of the matter is that there are things you can do with MWSE that there's no justification for giving a mod the power to do, and which we can stop mods doing without actually restricting them from doing what they need to. It's not like the only way to change how the camera works is to make it so a Morrowind mod can send your credit card details to Russia, post your web browsing history to Facebook and send inappropriate emails to your boss. If we take the three examples from the linked thread, we've got filesystem access, network access and save management. The main things you'd want filesystem access for would be to persist data related to a specific save (but Lua can jut add data to the save itself), persist data between saves (the work-in-progress Lua settings API makes this possible) and share data between users (which we've got some proposals for, but nothing concrete yet. The big thing network access would be used for would be multiplayer, but we're planning on integrating TES3MP, which isn't implemented as a mod, so it doesn't need to be Lua that's handling that. It could also be used for things like Discord Rich Presence integration, which is the only concrete example we've ever been presented with of something anyone would possibly want that our current approach would block. We're aware of it and are trying to think of solutions. The last one's the ability to manage saved games, and that one's not set in stone and might still happen.
darkbasic
Posts: 153
Joined: 18 Apr 2016, 15:45
Contact:

Re: Please stop implementing Vanilla Bugs as Features

Post by darkbasic »

If someone else doesn't want to wait for the dehardcoding you can apply this patch to re-add on-strike ranged enchantments: https://github.com/darkbasic/openmw/com ... aec0355133
Post Reply