For those running this fueling strategy, have you modified the X (load) axis?  I have a few cars that I did edit this on, scaled it to where the last column was 191 as opposed to 140.  Some of these vehicles exhibit wavy power once into full boost and higher rpms.  The requested AFR stays solid but there is a faint, but noticeable fluctuation in power that you can feel in the seat.  This isnt picked up in logs of timing, boost, throttle or really anything else that I can see.  It is obviously detectable when acceleration Gs are calculated.  When I edit the axis to stock values this issue goes away.  On cars with the edit that dont hit over 191 load this doesnt happen, so it leads me to believe on cars that do it travels to the next cell.

Onto my actual question, do we have this map wrong?  The map is 6x6, yet it seems the axis data being used is larger when you look at it by itself.  I referenced PRJs autogenerated xdf and this axis is listed as SRL12ESUB, which may be wrong but is irrelevant to this question.  That axis is shown as significantly larger.

If you expand the map by 2 columns and make it 6x8 it seems to make sense.  I have attached some more shots to show what the maps that have issues look like when the axis is expanded to show what we normally dont see.

Can someone with more knowledge shed some light on this?

So you are saying, when you disassemble, it only calls for 6 cells in reference to kflamkrl?  Any ideas on why there are tangible numbers before and after the section we use?  Is this axis used by another map that uses the rest of it?  If so that could explain the strange behavior when it is edited.

Sorry but now I am even more confused, because kflamkr and kflamkrl have different values in that axis, so they arent shared from where i am sitting.  The addresses I have are different, yet the same in every XDF I can find and discussion on this subject.  I am using a widely used XDF from Nyet.

These are what I have for the axis addresses:
KFLAMKR - 0x18292

KFLAMKRL - 0x100F6

If I am reading what you are saying right, and believing you (I always do, fwiw) then everyone has their knock based fueling set up wrong.

The more I look at it, its wrong.  Would also explain why when I edit that axis the fueling still works as expected (since im not even actually editing the associated one) but I get other ghost in the machine type behavior from whatever that axis i am editing does do.  I doubt many people felt the need to change it so they likely never felt it.

If you were wrong, dont feel bad, every reference until now has been the same.  I found the addresses long ago when we all first started down this path in a post from tony.  For all i know I shared that and it became standard.

0x100F6 is part of SRL12ESUB which begins at 0x100F2 and is used in KFFWLW and KFWLHO.

I defined these in the M-box myself using the R-box, I already had the right addresses

Actually...

the ddillenger map pack i have is wrong, the one you posted here last year    Every single definition I can find has this error, all the way back to before the functions discovery.  There is only one mention until now of the correct address and that is by tony in an xdf thread.  Its the post I was thinking of, but I had referenced it at the time for the conversion factors only, over looking the addresses.

some notes about how this happened... 

when we all stumbled upon this stuff in early 2012, berttos was the first to ever post a definition with it, titled 8D0907551M-valentinesDay.xdf and this one is is what started it, not sure where he got the address but I have a .kp file that is also off and i believe its one of the oldest ones we have kicked around, I think most of us have referenced these M and G box ols files for stuff. Additionally, phila posted a screen grab of his maps here http://nefariousmotorsports.com/forum/index.php?topic=141.msg15920#msg15920 that somehow had the bad info, at the same time, possibly from that VD xdf.  This screen grab is what many of us used in the process of defining our maps and spot checking data that should be displayed, so it never got questioned.

How ironic is it that I randomly had this annoy me enough to dig into and discovered what was up exactly two years later because the same guy had the right info.  Only realizing this cause berttos labled his xdf that way.  Regardless, this axis change fixed the issue.  I dont even understand what that axis change was doing, it was so slight it was hard to even detect.

Thanks for the help Phila!  Makes me wonder what else we have wrong.

Back when I used TP, I just modded the xdf everyone was using. Once I made the transition into OLS I started doing my own defining. Now, I won't even use someone elses, I would just be constantly questioning if everything was correct.