new $EE tuning thing!

[kur4o]

I test it on 5.6 and it compliles without error.
However the base source code you used was some old beta test version that is not good.

Here is an upload of the latest tested source with all mode 4 working and some initial changes to patch.
I am sorry to tell you but you will have to transfer all the changes to this source code.

The keyboard shortcuts is very good idea. I did give it a test and it is awesome. It will be great to other m4 controls and expand it to other functions of the program, like call mode4 window with a button or call datalog window.

Steveo I am thinking to split the patch on main patch and some add-on enhancements which will be user configurable. The main patch will contain only logging enhancement and sd/maf switching. The add-ons will add extra mode4 controls. That way when you are finished with tuning you can load the basic version and save PCM cpu power with unnecessary jumps.

The patch side is implemented by global enable switch and is hard to manupilate. The easiest way will be to add a check box on the flash window that will be visible in the bin_file.cpp. I hope you can help with the linking or give some hints how can it be done.

[spfautsch]

Here is an upload of the latest tested source with all mode 4 working and some initial changes to patch.
I am sorry to tell you but you will have to transfer all the changes to this source code.

No problem, I'll try to get it done and post back later today / tonight.

[steveo]

Steveo I am thinking to split the patch on main patch and some add-on enhancements which will be user configurable. The main patch will contain only logging enhancement and sd/maf switching. The add-ons will add extra mode4 controls. That way when you are finished with tuning you can load the basic version and save PCM cpu power with unnecessary jumps.

The patch side is implemented by global enable switch and is hard to manupilate. The easiest way will be to add a check box on the flash window that will be visible in the bin_file.cpp. I hope you can help with the linking or give some hints how can it be done.

you could do user configurable custom patches for sure. adding more checkboxes to enable patches wouldn't be too hard.

you do have to think about something, though.. right now eehack has a patch version scheme so it knows exactly what functionality is present when you connect, and it can modify the ui accordingly, hide/disable controls, whatever. i did it like this so you could plug it into any car and it would behave properly, whether it was patched, factory, or even patched with older versions.

if you did individual switchable patches, you could either:

- extend that version scheme, maybe assign a second byte or two somewhere so you have enable switches for each additional patch you do, something that is 0x00 in the factory bin, and at least that would make it backwards compatible with bins patched from older eehack versions

- forget it and leave the ui inconsistent with controls that may or may not work depending on which patches the user chooses to install, which would confuse everyone

- store the last patch state and use that as your 'detection', which would be very easy to do and work just great as long as you are only tuning one vehicle and only flashing with eehack

i hope you pick the first one, things are pretty seamless right now, which took a lot of thought to achieve

just what kind of enhancements are you working on anyway?

[kur4o]

I`ve been thinking about a secret check byte for each addon so ui can be updated accordingly.
The main patch will be v4 and the addon add a sub patch version with different check byte. That way it will be backwards compatible and there won`t be any non functional options.
The addon patches will be strictly mode4 control enhancements.

I have done already Individual cylinder corrections, delta VE change and end of injection control.
Also MAF/SD switching from mode 4.

I am still having trouble with the check box linking with the bin_file.cpp.

[spfautsch]

Sorry didn't get these done sooner, hope I didn't hold up your work.

Found some info on the issue I was seeing with QtPrintSupport missing, so added a second qt version check in qcustomplot.h - appears to be a bug in the toolchain.

#if QT_VERSION < QT_VERSION_CHECK(5, 0, 0) || QT_VERSION > QT_VERSION_CHECK(5, 7, 0)
#  include <qnumeric.h>                    // workaround for bug in qt 5.8 and newer
#  include <QPrinter>                      // https://bugreports.qt.io/browse/QTBUG-56321

[steveo]

qt is the most bloated library package ever conceived, it literally does everything. i'm not surprised that the printer library links to something else crazy. i swear i added version checking support to eehack when it kept relying on the network library and it was easier to just use the stupid library for something than diagnose it.

[spfautsch]

qt is the most bloated library package ever conceived,

Your comment leads me to believe you've evidently never worked with anything in the .NET realm.

I can forgive a great many shortcomings when I can download a linux distro for the cost of bandwidth, install it onto a 10 year old piece of hardware from a flash drive and in a couple hours be compiling software as fantastic as eehack for zero spend and zero seconds of my life wasted on license / DRM subversion.

i swear i added version checking support to eehack when it kept relying on the network library and it was easier to just use the stupid library for something than diagnose it.

That (the update checking routine) sounds like something that (sh/c)ould be removed - lest it matches some ridiculous winblows antivirus heuristic.

[steveo]

if making a simple http request and comparing the result to an integer is a virus flag then you have really lazy heuristics

[steveo]

I`ve been thinking about a secret check byte for each addon so ui can be updated accordingly.
The main patch will be v4 and the addon add a sub patch version with different check byte. That way it will be backwards compatible and there won`t be any non functional options.
The addon patches will be strictly mode4 control enhancements.

I have done already Individual cylinder corrections, delta VE change and end of injection control.
Also MAF/SD switching from mode 4.

I am still having trouble with the check box linking with the bin_file.cpp.

in flash_launcher.cpp you'll see i actually use variables in the datastream control structure to control flashing behavior. the checkbox toggles a switch in datastream_control.

then in flash_routine.cpp it calls bin.apply_patches() if the switch is true, such as: control->enable_patches.get() == true (see about line 117)

you could add some more stuff to datastream.h under datastream_control, perhaps a safe_switch custom_patch_a and apply it like that, having the flash routine call more functions from bin_file

[steveo]

i should clarify that the datastream_control structure is an intermediary control interface between the UI and the datastream, which actually operates in a separate thread. this is definitely a bizarre way to do it.

the design of eehack is such that very few callbacks or signals are made from the ui to the datastream thread