A question,
are we going to let the editor be able to make mods that will be compatible with the original engine, like pressing a button in the editor to change from vanilla construction set possibilities to enhanced construction set possibilities. I'm not sure whether this has been decided yet.
When I was asking around about whether some of the most active morrowind modding communities are looking forward for OpenMW and the use of it, one of the replies I got was this.
Haplo wrote:
Unfortunately this is a big concern. Not only will there be people who simply don't know of or don't use OpenMW, but there will also be people who use ProjectAedra over OpenMW (due to multiplayer and/or other reasons). Due to this uncertainty, TR modders won't be able to use the OpenMW editor unless there is a foolproof, error-free method for dumbing the new editor down to the "Morrowind CS" level (sort of like the TI-Inspire calculator that comes with a TI-84 faceplate that you can switch between when you only need TI-84 functionality).
However, as an individual modder, I personally would love to see an OpenMW CS, and I urge you guys to go above and beyond with development of it. The best way to ensure full penetration with your CS is to make it simply far and away the best choice over the vanilla CS, so that it only takes a relatively short time for the vast majority of people to make the switch.
All of this is still uncertain because there is still not a single "release" of an engine substitute, let alone a CS substitute. So we can't say for sure how popular an OpenMW CS will be until we can see how popular OpenMW itself will be.
Last edited by Zedd on 20 Feb 2013, 16:19, edited 1 time in total.
We kinda had this discussion before. I am strongly against putting any additional resources into providing an editor compatible with original MW. The main goal of this project should be to sent Morrowind.exe to oblivion (sorry for the pun, couldn't resist). If by 1.3 or 1.4 people are still considering using Morrowind.exe, then we did something wrong. Now project Aedra is a different issue and there is nothing wrong with cooperation between open source projects, but we should focus on our goals, not that of another project.
To be clear, I won't veto a vanilla compatibility mode for the editor. If someone really want to invest his time into it, then go ahead. But that person will definitely not be me, because I have zero interest in this feature and also it will be a pain in the arse to implement.
I understand, and i know it was mentioned somewhere before (which i couldn't find back), but I wanted to make sure of this before I took my answer to the outside.
Thanks for the quick reply.
The only reason why someone wouldn't use a source port is if the port is bad, in which case there is no reason for anyone to use it, they are simply ignorant, in which case they don't really care about mods either, or the port is really complicated to set up or even requires users to compile the source themselves. I found setting up Morrowind very easy, you just take the contents of one folder and dump them into another folder, so this rules out number three. Number one shuld obviously be sorted out when 1.0 gets released, which leaves us only with number two, which I don't consider to be worth the effort. If people want to play vaniall that's their choice, but I found that once you want to use even one mod there is no real difference in setup compared to OpenMW. As far as Project Aedra is concerned, who knows when that will ever come out, and even when it does, Morrowind is simply not a good game for multiplayer.
I've been using a few source ports for other games and there has never been a reason to use the original engine.
FWIW, for 1.0 we will likely not have any crucial differences in our file format compared to vanilla. The main differences will be in the header, and the fact that the scripts won't have any compiled bytecode. The header should be fairly easy to handle, but the missing script bytecode will be tricky.
I think we agreed on modifying the existing header record instead of adding a new one. I am fairly sure I can do that with optional extensions in a way that the content files saved from the OpenCS in the OpenMW 1.0 format do not differ in the header.
That leaves us with the script bytecode, which is indeed the point I was talking about. "tricky" is a very mild way to phrase it. I was thinking more of something like having a gun, a large bottle of sleep pills and a rope besides the keyboard while implementing MW bytecode support in the OpenCS. After all generating bytecode is not enough. We would also need to catch all those cases that can't be handled properly by the original VM. If someone really decides to tackle the MW bytecode, that is something I would insist on. Doesn't matter that the original CS would happily create invalid bytecode in these cases. We definitely should not let our CS degrade to the horrible performance of the original in any way.
Obviously there is still the option to convert the file manually:
1. Change the extension to .esm or .esp
2. Load it into the old CS
3. Hit compile all
4. Save
The resulting file should work flawlessly in MW, assuming no features were used that are available in OpenMW 1.0, but not in MW. Sounds annoying though.
