Some recent bug fixes to Trimalyzer:
- Fix a bug that caused settings to not be initialized for new users
- Fix a bug in the selector that made entering maf analysis mode impossible
- Avoid some redundant refreshing of the analysis table
Previous versions of Trimalyzer didn’t really work with INT values very well, since I completely botched a conversion (missed a move from 100% to 0%)
The latest version (1.0b+) fixes this issue.
Users of previous versions should open the ‘advanced settings’ dialog and ‘reset to defaults’ to fully correct the issue as well…
I’m writing a new fueling analyzer, similar to the one used in EEHack.
Such an analyzer allows you to load massive amounts of log data, and generate a map of reasonable fueling corrections to be applied to a VE or MAF table.
Right now, this is commonly done on hand-made spreadsheets, which lack advanced filtering and are difficult for people not familiar with spreadsheets.
Basically, a good BLM analyzer will almost ‘auto-tune’ most regular driving ranges. EEHack users already benefit from this, and my new program will allow everyone else to do it.
Stand by as I get a beta ready, and watch this thread:
EEHack is written on top of a C++ library called QT, allowing me to develop new features rapidly, support Linux and Mac OSX, and program things in new and interesting ways. It’s also a great way for people to develop programs that aren’t accustomed to writing GUI software.
Almost by accident, I’ve found that Windows XP is not supported by versions of QT later than 5.6.
This means that if I use the newest QT library, and I do like to keep things updated, EEHack will stop working with Windows XP entirely. The new beta, for example, is built against QT 5.8, and refuses to start on Windows XP.
On one hand, Windows XP is now over 15 years old, and EEHack is a fairly modern program, so part of me doesn’t care, but I personally have an XP netbook I use for tuning, so I do feel the pain of people with old hardware. Hell, you can’t even get a decent web browser for XP anymore.
I have several options I’m considering:
If we do choose option one, all hope is not lost. Anyone can download QT with QT creator and compile EEHack themselves. This is kind of what my Linux user base is doing since I stopped releasing binaries for Linux, and it works alright.
Any opinions, please do comment.
Does this matter to you? Do you still use XP? Why?
Not many changes, mostly some fixed up tooltips, but now we dump the results of the flash log to the debug window.
When a flash write goes bad, it would be nice for me to be able to get those logs so I can help figure out what happened, but most users find the window is closed with no way to get that information back.
Also added a help button that directs you to the support forum.
Would appreciate some people testing flash write in this beta and ensuring everything shows up in the debug log…
EDIT: Now on second beta, compiled against a new version of QT
For help with EEHack, EEX, or general f-body stuff, I made a forum so it’s easier to ask questions, or just discuss the software.
I doubt it’ll become very active, but my hope is that new users can read this forum to search for answers to frequently asked questions.
This forum shares its membership database with this blog as well, so if you’ve already signed up, you’re good to go.
This should be more efficient than posting comments here if you need help (and I will now stop approving comments on blog posts asking for help, instead sending a private message reccommending re-posting on the forum …)
Apparently some of the B/D-body bins in the factory bin archive were incorrect.
Affected bins: 16207111, 16230221, 16230221, 16239511, 16243011, 16243021, 16243171, 16243931, 16243941.
These are fairly uncommon bins, but if yo’re a bin collector, you might want to check your list and download them again.
Not sure how, but the executable became corrupt for the automatic tuning service.
After a long wait, it’s fixed now. Thanks for your patience.