30.11.2009, 08:04:19
Disclaimer: In all instances, "you" is a general, plural "you" in this post, not a personal "you" directed at WoRmINaToR. This message applies to all NPatch users.
As it has been stated numerous times before, we do not offer NPatch support.
VK's abrasive nature, his utter lack of quality assurance, random decisions to stop coding, and the general bugginess of his code have all been known for a very long time.
In other words: Anyone who decided to go with NPatch had it coming.
You can't say "fuck quality", abandon ship, go with the mad scientist of EXE hackers for a year, totally mess up your rules and mod with NPatch-induced madness, and then realize "oh shit...the RenProj dudes were right - this sucks!" and then expect us to be waiting here investing time and energy to fix your problems for you.
If NPatch was built reasonably, I might have done it. The way it is, I refuse to wade through the documentation to try to understand wth he was thinking. That is, if there is any documentation at all. Would surprise me.
And, to be perfectly honest, even if I wanted to support NPatch, I couldn't - since VK has no problem randomly renaming flags and changing functionality just because, I would have to constantly track what exactly currently works how in NPatch and adapt the converter. No way.
Sorry, but if you decided to go with VK's madness despite us constantly and continuously pointing out how badly NPatch is developed and how unreliable VK is, then you're on your own. Choosing NPatch despite its problems was your decision, not ours, and there's no reason we should have to support his bullshit just because people chose not to listen and go with him anyway.
That being said, I did not plan on recompiling the converter every time a new Ares is released. I plan on implementing a text-based file format that describes which changes to perform, so that we only have to release new translation files should something change, not an entirely new converter.
So if you're up for it, once it's developed, you can just go and edit the translation file to work on NPatch flags instead. But that will not be officially supported. If you want to, you can even start an NPatch->Ares thread on your own and debate with other users how to migrate. I won't sticky it, I won't provide support, but I won't kill the thread, either.
It's not like we're telling NPatch users they can't use Ares. We're happy if NPatch users switch.
We just feel that, if, after reiterating over and over and over again that we advise against NPatch usage, people still chose to go with that rather than RP or Ares, the consequences of that decision are their problems to deal with, not ours.
In addition, as pointed out further up, the converter will be coded in standards-compliant C++, under an open source license, using an open source widget library - so even if pure translation file editing doesn't help, nothing's stopping anyone from making the necessary changes for it to support NPatch.
Bottom line: NPatch support can be added to the converter, but I won't be the one doing it.
As it has been stated numerous times before, we do not offer NPatch support.
VK's abrasive nature, his utter lack of quality assurance, random decisions to stop coding, and the general bugginess of his code have all been known for a very long time.
In other words: Anyone who decided to go with NPatch had it coming.
You can't say "fuck quality", abandon ship, go with the mad scientist of EXE hackers for a year, totally mess up your rules and mod with NPatch-induced madness, and then realize "oh shit...the RenProj dudes were right - this sucks!" and then expect us to be waiting here investing time and energy to fix your problems for you.
If NPatch was built reasonably, I might have done it. The way it is, I refuse to wade through the documentation to try to understand wth he was thinking. That is, if there is any documentation at all. Would surprise me.
And, to be perfectly honest, even if I wanted to support NPatch, I couldn't - since VK has no problem randomly renaming flags and changing functionality just because, I would have to constantly track what exactly currently works how in NPatch and adapt the converter. No way.
Sorry, but if you decided to go with VK's madness despite us constantly and continuously pointing out how badly NPatch is developed and how unreliable VK is, then you're on your own. Choosing NPatch despite its problems was your decision, not ours, and there's no reason we should have to support his bullshit just because people chose not to listen and go with him anyway.
That being said, I did not plan on recompiling the converter every time a new Ares is released. I plan on implementing a text-based file format that describes which changes to perform, so that we only have to release new translation files should something change, not an entirely new converter.
So if you're up for it, once it's developed, you can just go and edit the translation file to work on NPatch flags instead. But that will not be officially supported. If you want to, you can even start an NPatch->Ares thread on your own and debate with other users how to migrate. I won't sticky it, I won't provide support, but I won't kill the thread, either.
It's not like we're telling NPatch users they can't use Ares. We're happy if NPatch users switch.
We just feel that, if, after reiterating over and over and over again that we advise against NPatch usage, people still chose to go with that rather than RP or Ares, the consequences of that decision are their problems to deal with, not ours.
In addition, as pointed out further up, the converter will be coded in standards-compliant C++, under an open source license, using an open source widget library - so even if pure translation file editing doesn't help, nothing's stopping anyone from making the necessary changes for it to support NPatch.
Bottom line: NPatch support can be added to the converter, but I won't be the one doing it.
Forum Rules
(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!
(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.