Mod compatibility drive

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
Post Reply
User avatar
NatalieN
Posts: 43
Joined: 30 Nov 2015, 21:32

Mod compatibility drive

Post by NatalieN » 28 Sep 2016, 02:08

The biggest issue I've seen when talking to people about adopting OpenMW is mod compatibility. I see comments like this one all the time. "OpenMW is great, but you can't play it with mods." I think that view is probably what's holding us back the most from closing out issue 1000.

To address that, and especially before a 1.0 release, I think it would be great if some of us volunteered our time and our familiarity with the OpenMW engine to help mod creators troubleshoot compatibility with OpenMW. I've already done it with The Lamp and Julan Ashlander Companion. It's been my experience that most of the problems can be taken care of by running the OpenMW-CS verifiier and fixing the issues it highlights. There could be other issues, like when mod makers use meshes with one-way collisions (#806) which is where our familiarity with the engine differences could help mod makers come up with work-arounds. When I was doing the Julan mod, I came across several undocumented bugs, which I was able to open tickets for. Many subsequently got fixed. Nothing helps identify issues like looking at actual use cases that are broken.

I think this would be a great way for us to boost the appeal of OpenMW, and an excellent way for those without advanced technical skills to contribute to the development of the engine. I've already done two, and I'm looking to do a third. Is anyone else interested in reaching out to mod creators and troubleshooting compatibility?
Please consider donating to Scrawl's Patreon and Ace's Nightly to help support OpenMW's development.

User avatar
Pherim
Posts: 139
Joined: 27 Aug 2014, 15:37

Re: Mod compatibility drive

Post by Pherim » 28 Sep 2016, 08:44

The thing is, in my opinion, collision working only in one way is not a bug. Just like the rendering engine only displays one side of a polygon unless there is a NiStencilProperty present, it works with the normals of the mesh to use only one side for collision. And unless it is done intentionally, there should be no situation in normal gameplay where one gets on the wrong side of collision objects. I find it strange that OpenMW changes that. Sure, there are mods which have wrongly oriented collision meshes, leaving the player stuck inside objects (like for example the trees in an earlier version of Vurt's Ashlands Overhaul), but it should be up to the mod creators to make sure collision on their meshes works correctly (and it is often as easy to fix as simply clicking "face normals" in NifSkope). In other places people are very strict about what from the vanilla game is a but and what isn't, so I am surprised that this is considered to be one. Other engines have this as well (for example Unity3D, though I admit later Bethesda Games don't), so I don't see any real reason to change it.

edit: wait, there was another post just a moment ago, wasn't there? :?:

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

Re: Mod compatibility drive

Post by Chris » 28 Sep 2016, 20:28

Pherim wrote:The thing is, in my opinion, collision working only in one way is not a bug. Just like the rendering engine only displays one side of a polygon unless there is a NiStencilProperty present, it works with the normals of the mesh to use only one side for collision. And unless it is done intentionally, there should be no situation in normal gameplay where one gets on the wrong side of collision objects. I find it strange that OpenMW changes that.
Mainly because Bullet doesn't normally differentiate between sides of a surface. I don't remember what the code was like, or is like now, but I don't recall any special handling for detecting collisions given which side of the surface is hit, so it would have to be explicitly coded in. Also, while I'm not saying this should or shouldn't be changed, assuming you can walk through one side of an object can be error prone. Imagine this scenario (ASCII art, yay):

Code: Select all

                 |     __
                 |    /  \
  <-wall-normal- | <- |  |  Player
                 |    \__/ 
Now imagine someone wants to mod the wall mesh piece and add a bit of detail to it:

Code: Select all

               |\|     __
               |      /  \
               |/| <- |  |  Player
                 |    \__/ 
This will suddenly cause the player to get stuck on the new outcropping, since it has surfaces facing backwards which now face the player. It's also unlikely that any non-specialized mesh will be perfectly flat, and can cause erratic behavior while the player is in the wall (can they still back out? can they step side to side?). Not to mention, the graphical anomalies caused by surfaces clipping into the near plane. It's just an all-around better idea to use scripting to place a wall behind the player when they walk passed a certain trigger.

User avatar
Pherim
Posts: 139
Joined: 27 Aug 2014, 15:37

Re: Mod compatibility drive

Post by Pherim » 28 Sep 2016, 23:07

Chris wrote:Mainly because Bullet doesn't normally differentiate between sides of a surface. I don't remember what the code was like, or is like now, but I don't recall any special handling for detecting collisions given which side of the surface is hit, so it would have to be explicitly coded in. Also, while I'm not saying this should or shouldn't be changed, assuming you can walk through one side of an object can be error prone. Imagine this scenario (ASCII art, yay):
I see... so restoring vanilla behavior would require the change, not the other way round. Fair enough. I agree that using walls like this is a non-standard use of meshes and for the vanilla game it doesn't matter if collision is single- or double-sided. Anyway, the scenario you describe is very specific and can easily be avoided by using a collision mesh that prevents the player from getting stuck. Of course, if a vanilla mesh is used and it is replaced by a different mesh there might still be errors. Although I must say, mesh replacers for wall pieces are extremely uncommon (not counting fixes for vanilla meshes), so it is highly unlikely to happen.

User avatar
NatalieN
Posts: 43
Joined: 30 Nov 2015, 21:32

Re: Mod compatibility drive

Post by NatalieN » 29 Sep 2016, 00:13

#806 has it's own thread. Maybe a mod can move the OT posts?

Topic at hand: Is anyone else willing to help mod creators troubleshoot their mods? I think we could get a bit more PR if we had a enough people interested to justify a news post or posts on other sites.
Please consider donating to Scrawl's Patreon and Ace's Nightly to help support OpenMW's development.

User avatar
psi29a
Posts: 3889
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Mod compatibility drive

Post by psi29a » 29 Sep 2016, 08:30

Or tell them to come here and ask their questions.
Will my mods work with OpenMW: Chances are likely yes, try it out.

My mod doesn't work with OpenMW: Check it first with OpenMW-CS and do a verify, fix any outstanding problems it finds. It might even fix unnoticed bugs in your mod in Vanilla Morrowind.

Still doesn't work, help!: Come on the forums and start a new thread about your mod and someone will review it.
For me, this is a simple FAQ. If people have issues, stop complaining and do something. We are more than willing to help, just ask!

User avatar
Shnatsel
Posts: 62
Joined: 31 Oct 2014, 01:06
Location: Moscow
Contact:

Re: Mod compatibility drive

Post by Shnatsel » 29 Sep 2016, 23:29

Sounds good to me. Perhaps a news announcement on the frontpage is in order? Is OpenCS verifier sufficiently feature-complete and tested for such production use?

Post Reply

Who is online

Users browsing this forum: vk1970 and 3 guests