epifan wrote:Enginuity defs mistakes directly converted to ecuEdit XML. Sorry, I can't on-fly correct your mistakes
I'm not saying the Enginuity defs are bug-free, they are still in beta testing, but I would hardly classify it as having "many mistakes". Xmlwrite's definitions aren't bug-free either (check out injectory latency for 32bit ecus which the Enginuity defs have correct).
epifan wrote:So, you are not refuse that you are using xmlwrite defs for create "enginuity defs" Ok, this is noble act
CEL fixes are only primitive involve of users CEL table is simple accessible for most users with some experience
Some of ecuEdit users request CEL support for enginuity converter and I made it.
Xmlwrite helps as reference, no doubt, but we are not just copying over its definitions. If we did, you wouldn't see any support for revisions other than that which is included in Xmlwrite, but we have added revisions requested by users that xmlwrite does not support, especially for 32bit roms. Xmlwrite is most likely a dead commodity for the public, because of the source of its defs and the fact that it was primarily released to give the openecu project a head start and not become an evolving resource. This is the same open source project that enabled you to develop your software and for which now you feel you can bash and spread misinformation about. Without this project, your software would be dead in the water, so I suggest that you be more respectful of it, even if users post something negative about Ecuedit.
epifan wrote:About maps that xmlwrite doesn't have: this is only advertising - this maps are not useful or they are not accurate (now).
Not useful? Tables for the 32bit ecus like advance multiplier (initial), timing compensation (intake temp), timing compensation (coolant temp), closed loop delays and the previously mentioned inj. latency, among others aren't useful? CEL fixes on 16bit roms might be easy for the average user to do with the hex editor, but the 32bit roms aren't very intuitive for the average user. Again, what is not accurate? Specifics? There should be many examples by the way you bash the definitions. If they are so inaccurate, then you would do you user base a service by not including a converter for them.
epifan wrote:P.S. Please stop fling mud! I don't understand why are you attack me? You have incredible accurate XML defs created by your own, powerful unique FREEWARE software - so rule the world!!! I cannot be your competitor
Umm, I didn't say anything until you decided to bash Enginuity. If Ecuedit and the great error-free definitions that you created entirely from scratch for paying customers were so great then you wouldn't feel the need to lash out at the other FREE open source projects as well as spread false information (such as Ecuflash charging money in the future) with nothing to back up your claims. You don't see Cobb going around bashing Ecutek about their software, do you? My suggestion to you is to let your software stand on its own merits. If you must point out a flaw in one of the open source projects, then do it in a sane, logical manner with evidence to back up your claims. Otherwise, it just reflects poorly on your company and YOU as well. Cheers.