sure can. I've been thinking about ways to display what I'm talking about (both for the "voting" process and straight up for the wiki).

As to the grouping ... I'm not 100% because I haven't tried it, but from what I gleaned looking at the xml's, base and rom specific, it should be possible to create new groups. Certainly 100% doable to reassign tables to different groups and 10000% doable to at least rename some tables. So that "MAP Test 1: Mid VE Max Voltage" becomes "MAP Test 1: Mid VE Max Voltage (JDM MAP)". And all other JDM MAP specific tables; though really they aren't specific to that mod, they are the tables we only usually care about when swapping in a JDM MAP.

The real people we need to talk to about these changes are the likes of MrFred since we'd want him to modifiy his instructions to jive with the XML, though most people won't need that part of the instructions anyway if they can just download the entire XML.

I think the real benefit here is it should make it much easier for people when they ahve to reinstall, upgrade, change roms, etc etc ... basically anything where we've all dreaded it because it meant completly remaking our ecuflash definitions. I simply see no reason not to have a complete set of definition files that is as up-to date as we can make it.

Which brings up the final point ... I'm only going to really be able to work 94170015 / evo7base. Getting buy-in from the other ROMs is going to be implortant too.

 

I think fostytou and I can sign on for working on Evo 9 and 0015

I completly agree with making it easier to switch to a new rom....every time a new tephra patch comes out it is a pain to switch all my maps over, JDM MAP blah blah.

With 1 XML, 1 Base file, and 1 evoscan file, we will only need to change change a few paramaters in each map to provide new functionality.

I think we should re-structure the downloads so that the XML, Base, and EvoScan file is one zip, and each map is its own download.

 

yeah that is what I was thinking ... put it all together as a package.

 

Well I just edited evo7base to put the High Octane Fuel Table in category BLAHBLAHBLAH and sure enough ecuflash created that group and put the HOFT in there.

So ... if we are so inclined, we can consider regrouping certain "mod" tables based on the mod rather than the function. This might not fly, but we'll see. I'll keep playing and post an example.

 

Guys - I just want to say THANK YOU. As a relative new 'tuner' with my car, 2006 Evo IX, and learning and doing most things on my own and reading and re-reading everything each of YOU have been involved in...I just want to say thanks!

This Wiki is awesome.

I like to think that I had already learned a lot before it...and have JUST learned some things that I MISSED in my numerous searches and reading sessions. I love the idea of a 'standard' setup for ecuflash xml's. It would make helping people that much easier.

So much of the 'issue' with learning what to do is learning what NOT to do. Early on I purchased a 'mail in tune' and one of the first things I LEARNED NOT to do was not max out the boostlimit tables ...that mail in tune had maxed them out...and my car had no safety catch in it. I've since taken over the boost curves by using the cars BCS system and it's thanks to YOU guys...

I'm haulin butt with my car...and have very minimal knock (1 or 2 counts in low rpms - still working on them). I've learned that tuning the car myself is a constant on-going process.

I just wanted to say that your work on all this is VERY much appreciated.

Thank you!

 

Ok so here are my thoughts on how to break things out for user level:

4 (Beginner) - fuel, timing, most limits, etc ... Any of the standard things beginning tuners tweak that do NOT require modified hardware (injectors, MAP, BCS, etc)

3 (Intermediate) - anything else that someone might tweak but still has nothing to do with modified hardware.

2 (Advanced) - anything that is associated with modified hardware

1 (Developer) - EVerything else to include all the definitions associated with patched ROMs.

 

So you guys know how you usually have to restart ecuflash when changing user level to get things to show up ... I think I found and fixed the reason. A lot of defs had no level assigned. Now that I've added it to all defs in the base file, AND removed them from the rom specific xml (they were jerking up the choices I made in the base), changing the User Lever in the options automatically changes what you see in real time.

EDIT 1: aaaannnnd now I get how all the definition files work. I've moved the bulk of the MUT table definition where it belongs, the base file, and then only define the address in the ROM specific xml.

EDIT 2: Ok I've attached a new set of evo7base.xml and 94170015 def files. These include all the details for:

- The "normal" definitions
- JDM MAP
- Direct Boost Control
- Tephra v5.10

What else are people adding to the def files?
I'm reading a lot about new tables being discovered / some of the old ones being redefined but frankly I'm not keeping up on it. Anyway have a clue?

I went through both definitions completely and stripped out all unneeded syntax. Mostly that meant removing all the details in 94170015 that are duplicates of what is, or that I moved to, the base file. It makes for a MUCH cleaner and easier to understand set of files.

The main point is that the base file should contain ALL the scaling definitions and ALL of the table definitions. I'm not sure why we've been adding scaling defs and table defs to the rom specific files when modding stuff but it really uglies up the def files.

The only thing that needs to be in the ROM specific file are the address definitions. The only reason to define anything else (scale, elements, etc) is if it deviates from the base. The only thing I found that varies is the address. So I removed everything but those and everything works.

I also added some comments to the base to make it easier to follow. Mostly for this discussion but I think it could help folks just the same.

And finally I mucked with the user levels using the logic I posted above. The easy way to see what is contained in each level is to make sure you have unchecked "Show Tables Beyond User Level" and then choose the level and see what tables pop up/go away.

So, I also downloaded a tephra rom and opened it up with my def files and everything looked good. I'm hoping you guys have the time to check things out and make sure I didn't miss anything as well as give me feed back on what I did that was just stupid

 

bump for my edits

 

supposedly Mrfred has started a similar effort with the '9 files ... I PM'ed him in the hope of joining forces. When I get home I'll also incorporate all of the lean spool tables, in to their own lean spool group of course.

 

Just got in this morning, I got some work to do here at, well....work(boring)....but then I'll take a look at what you have done.

 

np ... I'm at well .. work too, and can only really msg. No ecuflash at work. From what I'm reading I really think all the "boost enhancement" tables need to be removed. They aren't right. Also, I'd really like to hear your thoughts on tables that don't require mods and aren't really advanced topics, but which no one really messes with anyway and can be relegated to the developer level, or at least the advanced level. My reasoning being I've always hated all the clutter of tables I never use. Sure *I* can change my file but I was loath to do it because it would be non-standard and that makes things a hassle when upgrading.

 

This is why I think you should concentrate on fixing the problems on the base files for *stock* ECUs, and making everything else a diff (this can be done through branches on SVN, letting people check out what mods, if any, they want).

anything else is just going to be too "non-standard" as you put it.

 

Are you talking about some of the scailing or compensation tables that no one really knows how to tune....lol
Yea I think we can put those in the developer level along with the knock filter tables and other tables that 99.9% of users will never touch.

 

your changes seeem pretty consistant with how the 0015 roms were done, like you described, using mrfreds evo9base changes.

Collabarting with him is a good idea.

 

Glad we could help, and thanks for talking the time to let us all know how helpfull it was.