openmw.org

cc9cii wrote: ↑28 Aug 2017, 02:46 A quick Google leads to https://tesrenewal.com/comment/85791#comment-85791

Yes, I should of probably linked there as well. The project goals are a legal issue. Further down the track, the CS may need to have warning in place covering the issue of converting potential Bethesda licensed material. Copied below is the resolution with TR.

After a lengthy discussion with members of the Tamriel Rebuilt team, I've decided to make this project purely a Do-It-Yourself guide. I am cancelling all plans to release an ESM of converted content. This way, we can hopefully avoid becoming entangled in any legal grey areas and focus on discussing mod conversions and sharing our user-created work. To be clear, this guide has no official endorsement or support from Tamriel Rebuilt.

> The below fork is interesting. An attempt at incorporating TES4 compatibility for the CS

By the way, TES4 with OpenMW-CS is already possible, see https://www.youtube.com/watch?v=dxrCFlT_Nrg where I have lifted a well-known Cathedral and plonked it on top of the lighthouse in Seyda Neen. Haven't tried compiling OpenCS for quite a while so may need some cleanup work but shouldn't be too hard to get going again (but it is a really old version based on Ogre, unfortunately).

I have seen your beautiful work. All the work have you have done does lay a foundation, any push to OSG/master, should leverage as much as we can to minimise workload.

At this point I think the scripting-engine should be plugable, meaning that depending what 'game' you are playing you would get another 'scripting-engine'. I don't see the point in making one-size-fits-all here.

Sorry, I forgot to answer this; yes I agree - as I envision it a more general purpose loader detects whether the data assets belong to Morrowind, Oblivion or Skyrim and thus loads loads all the necessary components for the respective game (all within the same openmw.exe binary).
The other option would be to have
OpenMW Launcher
|-Openmw.exe
|-Openob.exe
|-...

I am not sure which one is better from a architectural perspective, I prefer the first one but the latter option is likely easier to manage.

Edit: It is a bit worrying that https://github.com/ponyrider0/openmw , c99cii , me (and who knows who else) are all working on different parts of TES4 without coordination.

Deltaxus wrote: ↑04 Sep 2017, 09:51 I am not sure which one is better from a architectural perspective, I prefer the first one but the latter option is likely easier to manage.

Edit: It is a bit worrying that https://github.com/ponyrider0/openmw , c99cii , me (and who knows who else) are all working on different parts of TES4 without coordination.

Post 1.0 will require de-hardcoding to change the current system. See Zini's posts in this thread, Questions about the dehardcoding process. The lack of project coordination is due to any architectural changes being after 1.0. PRs for OpenMW-CS would be the best option. c99cii is working on the fundamentals but his fork is using Ogre3D and ponyrider0 is focusing on converting TES3 files for use in TES4.

Post 1.0 will require de-hardcoding to change the current system. See Zini's posts in this thread, Questions about the dehardcoding process. The lack of project coordination is due to any architectural changes being after 1.0. PRs for OpenMW-CS would be the best option. c99cii is working on the fundamentals but his fork is using Ogre3D and ponyrider0 is focusing on converting TES3 files for use in TES4.

Well,

Sorry to shoot you down like that. But the dehardcoding is one of the tasks we can definitely not tackle before 1.0.

So I could basically stop writing Bison grammar files for each ES game as it wont be relevant until 1.0 and just hardcode everything for now.

Writing it once is prototype code, to get you to from A to B... once you understand what is going on, then you can re-write it properly.

I think at this point in 'the game', it is the rapid development of features and gaining knowledge to do it right later.

Whether or not they're useful immediately, Bison grammar files will probably be useful eventually.

My 'dream' for future scripting support (which probably goes completely against what Zini wants) is that we write .NET implementations of all the languages we want to support and include Mono as a dependency of OpenMW. This should magically give us great interoperability between languages, allowing us to load any combination at once, and instantly gives us support for all the languages that already have a .NET implementation.

As psi29a stated, the work would be building a foundation for later. For changes to the master now, improvements to OpenMW-CS would be the way to go. I don't know if it is possible but improvements to MWScript that don't break the 1.0 plan? See the thread, Delay 1.0 untill all of MWSE is implemented.

AnyOldName3 wrote: ↑04 Sep 2017, 12:28write .NET implementations of all the languages we want to support and include Mono as a dependency of OpenMW.

That's a pretty heavy dependancy, why Mono in comparison to other tools?