The only way to replace Vanilla Engine (IMHO)

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
TamrielCitizen
Posts: 19
Joined: 04 Dec 2018, 06:25

The only way to replace Vanilla Engine (IMHO)

Post by TamrielCitizen » 04 Dec 2018, 19:19

Hello, everyone!
First off, I apologise for the long post, but I was following the project for a long time now, and the number of things I would like to say has finally become so large that I decided to register, which is something I almost never do anywhere.

I want to start by saying a huge thank you to everyone working on OpenMW, and to everyone who has worked on it in the past. What you have done, and continue to do, is phenomenal. I appreciate the amount of effort involved and respect you for spending so much time on something you make available to everyone for free.
Just like probably all of you, I dream about a time when OpenMW will make the old Vanilla Engine completely redundant, bringing with it all the benefits of a modern engine and making possible things that previously weren't. :D However, currently some things diminish my optimism, and that's why I want to clear up any possible misunderstanding on my part, while also presenting my view on what should be achieved before OpenMW could bring that future about.
I'd also like to emphasise that the last thing I want is to offend or antagonise anyone, but it's possible that I may sometimes miscommunicate and someone could think that I'm just trolling or, you know, breaking Wheaton's Law, and thus entirely dismiss me. :( While I do my best to avoid it, it may be difficult when discussing something I deeply care about, especially considering that I am extremely introverted and not a native English speaker. :oops:

My basic idea is quite simple: OpenMW will only be able to replace Vanilla Engine when there won't be any reason anymore to choose the latter. Otherwise, people who consider that reason crucially important for them, won't be switching to OpenMW, which thus will remain an alternative, not a replacement. Considering some inevitable incompatibilities, this leads to the fragmentation of the community, which I assume everyone wants to avoid, especially since Morrowind is such an old game already. Of course, right now OpenMW hasn't even reached 1.0 yet, so I am talking here about the eventual time when the decisions made by the OpenMW team won't be based on the commitment to focus on reaching that goal first anymore. To make myself clear, I am not so much concerned about when something will be done, as about whether it will be done at all.
As it stands right now, there are several such reasons, some of which may already be in the past by the time 1.0 comes:
  1. Any engine inevitably has bugs and unintended/undocumented behaviour, but with a game as old as Morrowind, virtually all of that in the Vanilla Engine is already discovered and documented with bugs mostly fixed by "engine hacks" such as MCP and MGE XE. Meanwhile, lots of bugs are yet to be fixed in OpenMW, and more bugs and unintended/undocumented behaviour are yet to be discovered.
  2. OpenMW doesn't always provide an option to behave exactly the same as Vanilla Engine in situations when some people may prefer Vanilla Engine behaviour.
  3. In contrast to the previous reason, some people may prefer other behaviour, which is offered by "engine hacks" in the form of an option, but such an option is not present in OpenMW.
  4. There are a lot of great mods that either don't work as intended in some situations using OpenMW, or aren't even compatible with it.
  5. For a lot of people, there may not be much point to switch to OpenMW from Vanilla Engine+MCP+MGE XE+MWSE 2+Mods, even if all the above reasons are in the past. Their experience just wouldn't improve enough to rationalise the switch.
№1 is something that, obviously, can never be fully in the past with an engine that is continuing its development. But there should come a point when the engine is tested enough that the probability of encountering an unexpected behaviour or an unfixed bug became too insignificant to matter if all the other reasons are in the past, and №1 would thus be ignored (of course, developers should still work on discovering and fixing such things). However, its continued existence makes №5 even more important. If some people's experience wouldn't improve with a switch to OpenMW, the existence of №1 may well become a decisive factor for them to stick with Vanilla Engine. So, №5 should be in the past to make people eventually ignore №1. :) By the way, if it's unclear what I mean by "unintended/undocumented (unexpected) behaviour", I can elaborate.

№2 and №3 are obviously closely connected. As I understand, leaving №2 in the past is one of the main goals for OpenMW 1.0, which I am very happy about. However, there are several cases where opinions are divided about whether Vanilla behaviour should be implemented or not, some people arguing in favour of "more sane" (in their opinion) behaviour, which in some cases is how OpenMW behaves currently. Sometimes behaviour that was introduced by MCP or other "engine hacks" to Vanilla Engine is the preferred one for many people (and, again, in some cases this is how OpenMW currently behaves). Examples are Issue #1751 and Issue #4135. I will make a comment in the recent forum thread about #1751, too, as I'd like to discuss it in more detail, but I hope the decision was made, or will be made soon, to restore Vanilla Engine behaviour.
I believe that OpenMW 1.0 (as it's presumably one of the goals), and any subsequent version of OpenMW, has to provide the player with the ability to configure it such that it behaves exactly as Vanilla Engine in every situation (unless it's literally impossible), even if some people consider such behaviour "less sane" than alternatives. Obviously, I am not speaking about reproducing bugs or technical limitations (such as game crashes or plugin number limit), but if people exist who argue in favour of some Vanilla Engine behaviour, there should be an option to have such behaviour in OpenMW.

But what about №3, then? Well, it is my belief that one of reasons why people love MCP and MGE XE so much, and why they are used by virtually everyone nowadays (well, unless they use OpenMW, that is) is the fact that every feature/fix they provide is optional and/or configurable (with MWSE 2 allowing even further customization). Speaking for myself, there are lots of features/fixes in them that I love, and there are also features/fixes currently present in OpenMW that I love as well. Other people, however, may dislike some of them just as much as I dislike current OpenMW behaviour described in Issue #1751. Everyone has different preferences.
The obvious and simultaneously the best way to address such disagreements is to provide the player with an option to enable/disable each feature/fix, both those unique to OpenMW and those first introduced in MCP or MGE XE. I believe that every feature/fix from MCP and MGE XE should be eventually introduced to OpenMW in the form of an option.
Quite honestly, I don't understand why if someone suggests to add an option for some feature/fix, the lead developers appear to be very reluctant to agree, even when someone is ready to implement it. I even got the impression that the policy is to avoid adding more options unless absolutely necessary. This doesn't make sense to me, especially coming from the team that emphasises that their project is a Free Open Source Software, and goes to great lengths to ensure that everything involved is 100% FOSS (sometimes to the point that from a bystander perspective it may look comically exaggerated and unreasonable), which I think reflects a deep belief that I respect even though I myself don't care that much about such things.
But doesn't providing the players with more options mean providing them with more freedom to choose what they like? I hope that I've just misunderstood the developers' intentions. Maybe the "anti-options" policy is just pre-1.0? If so, I hope that post-1.0 policy will change to "pro-options".

Leaving №4 in the past is, I believe, a topic that nothing I can say on is something the developers haven't already considered. I'd just like to point out that leaving №1, №2 and №3 in the past should also result in mostly leaving №4 in the past, although probably not completely. Also, making MWSE mods compatible with OpenMW is crucial. By "compatible" I mean that mods that work with MWSE should also work in OpenMW, and they should behave the same way in OpenMW as they do in Vanilla Engine+MWSE. Again, I am speaking about how it should be eventually, in the distant bright future, about what the goal should be. :D

That leaves №5 to discuss. The point I am trying to make here is that if some people don't think that their experience would noticeably improve with a switch to OpenMW, they won't go through all the trouble of making and configuring an OpenMW installation (whether it does take a lot of effort or not), even if №2, №3 and №4 are already in the past. The fact that, as I've noted, №1 won't ever completely go away, will even further decrease the likelihood that they switch. Which, by the way, means they may also continue making mods for the Vanilla Engine, leading to the possibility (this is unlikely, thankfully) that №3 and/or №4 might make a "comeback", again influencing other people's decisions...
Of course, there are already some things possible with OpenMW that aren't (at least yet) possible even with a "hacked" Vanilla Engine, and OpenMW hasn't even reached 1.0 yet, while some are already planned for post-1.0. Well, let's go over them (tell me if I missed something important):
  • OpenMW is cross-platform. While it's a great thing, the majority of people who play Morrowind still use Windows, and it doesn't affect them.
  • OpenMW is open source. Again, a great thing, but for people who don't plan on working with the engine code, it doesn't mean much, unless it's a matter of "ideology"/belief, which is, obviously, less frequent among Windows users than, say, Linux users. :)
  • OpenMW/OpenMW-CS allows creating and playing games other than Morrowind for free (we are speaking about the future here, of course). Amazing, but in the context of OpenMW replacing Vanilla Engine to play Morrowind it is irrelevant.
  • Multiplayer (we are still in the future). This is actually a feature that could convince some of the people who were otherwise unconvinced. However, I'd argue that a lot of people don't care about multiplayer, and this is likely even more true among those who play Morrowind than among those who play games in general.
  • OpenMW offers features/fixes/modding capabilities not present in the Vanilla Engine, some of which may prove to be impossible to achieve even with "hacks" of the Vanilla Engine. This, I believe, will convince most people, assuming, of course, that №2, №3 and №4 are already in the past and №1 is weakened enough that it could already be ignored. However, some people may actually be quite content with what they can already do using "hacked" Vanilla Engine without any need for what OpenMW allows on top of that (and these people would be less likely to ignore the existence of №1). Fortunately, these people probably won't cause №3 and/or №4 to make a "comeback", at least, but it is still a fragmentation of an already shrinking community.
    Of course, nothing will convince everyone, but there is something that I think may convince virtually everyone.
  • Performance increase (sadly, the future again). Virtually everyone who still plays Morrowind nowadays, plays with mods, some of which have a significant impact on performance, including MGE XE features such as Distant Land. Poor Vanilla Engine optimization leads to poor performance even on current-gen high-end gaming systems. Who wouldn't want a performance increase that comes with the switch to OpenMW, if №2, №3 and №4 are already in the past and №1 is weakened enough that it could already be ignored?
Right now, OpenMW offers only marginally better performance than the Vanilla Engine at most, while still missing or only half-implementing some of the performance-killing features that it would have to implement fully to leave №1, №2, №3 and №4 in the past. I am mostly referencing Distant Land here, as I consider it a very important feature and there was a recent forum thread about it, but, obviously, it isn't the only such feature.
Concerns were also voiced that OpenMW isn't well optimised for multiple cores, which is understandable, especially considering that even modern games are often not very good at it (which is why generally Intel CPUs are considered best for gaming, while AMD CPUs with more cores/threads are considered better for other, better optimised tasks). I was surprised, however, that the person who brought this topic to attention was denounced as a troll on the basis of misusing/misunderstanding some terminology. Maybe it was because of something that person had said before, though.

But what's that? Vulkan Scene Graph, that is supposedly easy to switch to from Open Scene Graph that OpenMW currently uses? Of course, I have no idea whether it is really relatively easy to do that or not, but as far as I know Vulkan API offers a very major performance boost when compared to OpenGL. And guess what else? Correct me if I am wrong, but it significantly improves the usage of multiple cores, as well as reducing CPU bottlenecks by utilizing GPU more instead - and OpenMW is definitely facing a CPU bottleneck on modern gaming systems in most cases.
I think that the performance increase such a change could bring makes it absolutely worth the effort involved, especially if it results in getting rid of №5 for good. Of course, Vulkan Scene Graph is still in the early stage of development, and probably not ready yet for OpenMW to switch to it, but we are talking about the future here, right? ;)

I do hope that the developers will somehow find the time to read through this insane amount of text. After all, I think I've managed to make some good points, even if it literally took me an entire day to write all of this. :oops:
Thank you!

User avatar
AnyOldName3
Posts: 1192
Joined: 26 Nov 2015, 03:25

Re: The only way to replace Vanilla Engine (IMHO)

Post by AnyOldName3 » 04 Dec 2018, 20:36

I was surprised, however, that the person who brought this topic to attention was denounced as a troll on the basis of misusing/misunderstanding some terminology.
Pretty much every point that guy raised was either nonsensical or untrue. Examples include him claiming we're not really 64-bit (without providing any evidence or even explaining what he meant by 'really' 64-bit) and that we only use one core.
AnyOldName3, Master of Shadows

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

Re: The only way to replace Vanilla Engine (IMHO)

Post by psi29a » 04 Dec 2018, 20:57

You are called a troll when you report a developer for flaming and trolling when they are honestly trying to help. There is something obviously wrong with you if you do that. All the developers that decided to interact with you are patient but after being aggressive and dismissive to developers replies, then developers consider it a waste of time to deal with you.

As posted else where: don't be a dick. If you disagree with this, then please leave us alone. We'd rather spend out time working on OpenMW than dealing with people who can't be civil.

We do this for us and if people enjoy it, great!

What OpenMW and won't be, read this:
https://openmw.org/faq/

We will _NOT_ be replicating bugs from the original. Any mods that rely on bugs won't be supported. They will need to be re-written. No exceptions.

If people want to keep playing/modding Morrowind.exe w/ hacks, don't let us stop you!

There are some things we will not be doing and that is keeping the Vanilla Morrowind experience, that is what you have Morrowind.exe for. This conflicts with our longer term goal of supporting additional games.

If you want to help, then go to our issue tracker and lend a hand.
https://gitlab.com/OpenMW/openmw/issues

We have a ton of work and wasting our time isn't helping. :)

User avatar
raevol
Posts: 2802
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: The only way to replace Vanilla Engine (IMHO)

Post by raevol » 04 Dec 2018, 21:10

The TLDR for this is that he wants the option to disable all non-vanilla features, and he's saying vulkan support would give us multi-core support.

TamrielCitizen
Posts: 19
Joined: 04 Dec 2018, 06:25

Re: The only way to replace Vanilla Engine (IMHO)

Post by TamrielCitizen » 04 Dec 2018, 22:02

AnyOldName3 wrote:
04 Dec 2018, 20:36
I was surprised, however, that the person who brought this topic to attention was denounced as a troll on the basis of misusing/misunderstanding some terminology.
Pretty much every point that guy raised was either nonsensical or untrue. Examples include him claiming we're not really 64-bit (without providing any evidence or even explaining what he meant by 'really' 64-bit) and that we only use one core.
Well, I often met people who apparently think that "64-bit" is synonymous to "able to use multiple cores" in the context of software performance. To be perfectly honest, I am not sure that I myself understand all the details relevant to multi-threading and terminology surrounding it. Obviously, OpenMW does use multiple cores, but it also appears to not be very optimised for it. I think that's essentially what he wanted to say, considering the videos he posted links to (I assume he made those videos himself?), and, anyway, what he wanted to say and how he chose to formulate it is not really relevant to the point I am making in my post. What is relevant though, is the CPU bottleneck and room for improvement in terms of multi-core usage that, if I am interpreting those videos correctly, he demonstrated. Of course, I may be completely misunderstanding either those graphs or something else, if so, I'll be grateful for any clarification.

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

Re: The only way to replace Vanilla Engine (IMHO)

Post by psi29a » 04 Dec 2018, 22:33

TamrielCitizen wrote:
04 Dec 2018, 22:02
Well, I often met people who apparently think that "64-bit" is synonymous to "able to use multiple cores" in the context of software performance. To be perfectly honest, I am not sure that I myself understand all the details relevant to multi-threading and terminology surrounding it. Obviously, OpenMW does use multiple cores, but it also appears to not be very optimised for it. I think that's essentially what he wanted to say, considering the videos he posted links to (I assume he made those videos himself?), and, anyway, what he wanted to say and how he chose to formulate it is not really relevant to the point I am making in my post. What is relevant though, is the CPU bottleneck and room for improvement in terms of multi-core usage that, if I am interpreting those videos correctly, he demonstrated. Of course, I may be completely misunderstanding either those graphs or something else, if so, I'll be grateful for any clarification.
It doesn't really matter what anyone has to say when they are behaving badly. Toxic people are a waste of everyone's time.

To your points:
If we spent our time optimizing instead of developing features and fixing bugs, it would take EVEN longer to get to 1.0
Premature optimization is the devil.
Will it get better with time, yes.
Is OpenMW not as fully optimized as it could be, absolutely, but everyone already knows that.
So what was their bloody point?!

Is OpenMW multi-threaded, yes. Is it optimized, no. Will it be, yes. Does OpenMW make use of more than one core, absolutely and you're insane to think otherwise. Just look the code, it's right there in the damn code. Look at it! We're not hiding anything, we're not lying. The guy is literally insane.

It's open-source, it will always be improved. It is just a question of time and ability to work on it.

People who complain, are misinformed and start rights with developers while also not offering to help just waste everyone's time. Those people don't belong here.

TamrielCitizen
Posts: 19
Joined: 04 Dec 2018, 06:25

Re: The only way to replace Vanilla Engine (IMHO)

Post by TamrielCitizen » 04 Dec 2018, 22:43

psi29a wrote:
04 Dec 2018, 20:57
You are called a troll when you report a developer for flaming and trolling when they are honestly trying to help. There is something obviously wrong with you if you do that. All the developers that decided to interact with you are patient but after being aggressive and dismissive to developers replies, then developers consider it a waste of time to deal with you.

As posted else where: don't be a dick. If you disagree with this, then please leave us alone. We'd rather spend out time working on OpenMW than dealing with people who can't be civil.

We do this for us and if people enjoy it, great!
I hope you don't actually mean me when you say "you", but rather in a general sense, as I have actually spent ~13 hours today making sure that everything in my post is as perfect as I can possibly make it and that I do not accidentally offend anyone. As I said, I am not a native English speaker, and I am also extremely introverted on top of that, meaning that I rarely communicate with anyone at all. Just in case I did somehow manage to say something stupid, I apologise. :(
If you are talking about the person who posted links to videos in the other thread, well, as I said, I am not really aware of everything that happened there, I just read that thread recently, watched those videos, and thought that those videos demonstrated quite well some issues with OpenMW's current optimisation. I may have been wrong though. That's why I was interested in reading that thread further, to see if there was maybe some flaw with the method used to show CPU bottleneck in that video, and whether that person is correct in saying that OpenMW is poorly optimised for multiple cores currently. I was thus disappointed with how the thread ended, and while I thought that the person in question was a bit too easily offended, I didn't think he was trolling or intentionally offending anyone, just misusing/misunderstanding some terminology. I am not that experienced with recognising trolling though.
Of course, I realise that optimisation, as well as everything else, is still work-in-progress, but if everything was finished there wouldn't be any point for me to discuss it. And I do hope that my mention of that person, whether or not he was breaking Wheaton's Law, is not the only thing that you noticed in the post I spent so much time working on, in the hope that it may help at least a little bit to bring about a future when OpenMW replaces the Vanilla Engine. Maybe I am just too idealistic (people told me so). :cry:

TamrielCitizen
Posts: 19
Joined: 04 Dec 2018, 06:25

Re: The only way to replace Vanilla Engine (IMHO)

Post by TamrielCitizen » 04 Dec 2018, 23:13

psi29a wrote:
04 Dec 2018, 22:33
TamrielCitizen wrote:
04 Dec 2018, 22:02
Well, I often met people who apparently think that "64-bit" is synonymous to "able to use multiple cores" in the context of software performance. To be perfectly honest, I am not sure that I myself understand all the details relevant to multi-threading and terminology surrounding it. Obviously, OpenMW does use multiple cores, but it also appears to not be very optimised for it. I think that's essentially what he wanted to say, considering the videos he posted links to (I assume he made those videos himself?), and, anyway, what he wanted to say and how he chose to formulate it is not really relevant to the point I am making in my post. What is relevant though, is the CPU bottleneck and room for improvement in terms of multi-core usage that, if I am interpreting those videos correctly, he demonstrated. Of course, I may be completely misunderstanding either those graphs or something else, if so, I'll be grateful for any clarification.
It doesn't really matter what anyone has to say when they are behaving badly. Toxic people are a waste of everyone's time.

To your points:
If we spent our time optimizing instead of developing features and fixing bugs, it would take EVEN longer to get to 1.0
Premature optimization is the devil.
Will it get better with time, yes.
Is OpenMW not as fully optimized as it could be, absolutely, but everyone already knows that.
So what was their bloody point?!

Is OpenMW multi-threaded, yes. Is it optimized, no. Will it be, yes. Does OpenMW make use of more than one core, absolutely and you're insane to think otherwise. Just look the code, it's right there in the damn code. Look at it! We're not hiding anything, we're not lying. The guy is literally insane.

It's open-source, it will always be improved. It is just a question of time and ability to work on it.

People who complain, are misinformed and start rights with developers while also not offering to help just waste everyone's time. Those people don't belong here.
Well, I do mention several times that I am speaking about the eventual bright future of OpenMW. I even specifically said that it doesn't really matter to me when something will be done, just whether you guys are planning to do it at all. I absolutely do not wish for optimisation efforts to delay 1.0. I mentioned Vulkan Scene Graph, and the fact that it's still in the early stage of development, so not ready for OpenMW to switch to yet even if the developers decide to do that eventually, which I hope they/you will. Unless you actually find even better way to increase optimisation, which would be great. I just suggested it based on what I know about the Vulkan API.

Of course, I understand that it's all complicated, and Vulkan API is supposed to be quite difficult to use, but I thought (am I wrong here?) that the most difficult part is done by the Vulkan Scene Graph project, and I read somewhere on this forum that the Vulkan Scene Graph project lead said it will be relatively easy to switch to from Open Scene Graph, which makes sense if he leads both projects. Admittedly, I assumed that such a switch would immediately improve OpenMW performance (of course, there would still be some problems/bugs introduced by the switch, but that's why it's relatively easy, not just easy), but I was basing that on my understanding (am I wrong?) that VSG would handle the most complicated parts, with all the projects using it benefiting from its better optimisation. Kind of how the OpenMW performance increased when you switched from Ogre3D, which I assume was more difficult than switching from OSG to VSG.

Also, I am slow to formulate my thoughts, so when I am answering a post, I may not see something someone posted after that, or any edits to previous posts. I apologise for any confusion this might cause.

TamrielCitizen
Posts: 19
Joined: 04 Dec 2018, 06:25

Re: The only way to replace Vanilla Engine (IMHO)

Post by TamrielCitizen » 04 Dec 2018, 23:54

psi29a wrote:
04 Dec 2018, 20:57

What OpenMW and won't be, read this:
https://openmw.org/faq/

We will _NOT_ be replicating bugs from the original. Any mods that rely on bugs won't be supported. They will need to be re-written. No exceptions.

If people want to keep playing/modding Morrowind.exe w/ hacks, don't let us stop you!

There are some things we will not be doing and that is keeping the Vanilla Morrowind experience, that is what you have Morrowind.exe for. This conflicts with our longer term goal of supporting additional games.

If you want to help, then go to our issue tracker and lend a hand.
https://gitlab.com/OpenMW/openmw/issues

We have a ton of work and wasting our time isn't helping. :)
I've read the FAQ, as a matter of fact I was following the project for about a year.

I am also not speaking of the Vanilla Engine bugs, I mentioned that, too. I am talking about things like game mechanics mostly, for example, Issue #1751. Basically, those cases when there are people arguing in favour of the Vanilla Engine behaviour. I don't think anyone ever argues in favour of game crashes, for example. I can also understand your decision to not support mods that rely on bugs, but what exactly do you consider a "bug" in this context? Do you count a mod relying on Abilities having unique gameplay mechanics (just like Curses, Powers and Deceases all have unique gameplay mechanics) among mods relying on bugs? I made a post explaining my view on this further in the recent forum thread about #1751.

I just assumed that OpenMW team cares about Morrowind and its community, just as I do. In one of the recent forum threads, if I remember right, a member of the team mentioned how the OpenMW team wants to prevent the fragmentation of the community, which is really what my post is all about. Maybe it wasn't a member of the team though, just a frequent forum user. I don't understand how my suggestions could prevent OpenMW from supporting additional games, or affect OpenMW badly in any other way, really. Other than maybe reduce "code cleanness", but shouldn't the end user experience be more important in programming?

Also, don't you guys often mention in your news posts that if someone wants to contribute, they may do this not only by writing actual code, but also by providing feedback and suggestions on the forum? That's what I did.

User avatar
Ravenwing
Posts: 279
Joined: 02 Jan 2016, 02:51

Re: The only way to replace Vanilla Engine (IMHO)

Post by Ravenwing » 05 Dec 2018, 00:08

Not a dev, but I believe I am accurately representing them in the following.

The answer to the “vanilla+MCP+MGE XE+MWSE+mods” features question is almost universally: we either support or plan to support all features provided by those tools, but the implementation will probably not be identical as we are not bound by the same restrictions. This is also universally dependent on time and interest by existing and future developers. Some mods may not be compatible, but our responsibility remains to maintain compatibility with all mods that do not require 3rd party tools or engine bugs. If you believe a mod should be compatible under these conditions but isn’t, please file a bug report. Very popular mods that require MWSE may require a rewrite eventually, but it is hard to say at this stage and we try to do everything in our power to reduce the likelihood and resulting headache as possible.

As to options, we all love options. In general we will try to provide as many as possible. The main reason we might not is to prevent the code base from become unmanageable. More options sometimes increases the likelihood of bugs.

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests