Now, bear with me here because I am not some tuning expert or anything, but I was thinking on my way into work today about this.

Ok, so we all know enginuity is apparently never release their launch control (at least not any time soon), so there has to be some way to program it into the ECU. I mean cobb can do it, right? We know enginuity can, so it's most definately possible.

Does anyone know exactly how cobb programs the ECU to set launch control? If not, can't you just find a car that has LC using an access port and pull their map from the ecu using ecuflash or a similar program?

Just trying to see if there is anything I can do to get this done. Not wanting to buy an AP or any other expensive programmers.


*this is not a stab at all to enginuity. Just trying to move the process along.

as i understand it, the things we upload are just blocks of data sets. The ones with launch control contain the memory, but also a jump instruction (in assembly) to a different block of data sets. if that condition is hit, (speed=0 for launch control), then the other dataset that has a lower rev limiter is used.

it isn't a matter of getting a map that does it that is hard, it is building the interfaces and backend that is probably slowing them down.

I already developed launch control for testing for both the 16-bit and 32-bit ECU (with FFS also for the 32-bit ECUs) before Cobb even released their version. It is not very hard to do at all if you know what you are doing (per gear wg compensation is also easy which also has been tested). I've even been running a prototype real-time tuning on my 02 wrx which allows for on-the-fly map switching and dynamic map selection. The point is, the ROM hacks are not difficult to do. Plus we wouldn't copy someone else's code even if it wasn't easy. The problem is the user interface as well as how to best implement these features for the general public. Releasing hacked ROMs for download is not very feasible when you consider the number of different models, years, and markets. For a little perspective, the latest Enginuity/Ecuflash ECU definitions support 186 different Subaru ROM revisions. Even if you only support one revision per model/year/market, that is still quite a few to try to manage/host. Then there's the issue of what you do when you update the code? Do you maintain support for the older versions (for example, the definitions)? As you can imagine it can become an exponentially greater headache as well as more confusing for users as time passes.

The best solution is to implement a patching system in Enginuity that would be able to:
1. Patch existing supported ROMs with new code
2. Upgrade older versions to newer versions (i.e. versions of the ROM hacks)
3. Return ROM to stock.
4. display/hide relevant tables (ex. LC rpm threshold) based on features and version of the current ROM.

In addition, you have to plan ahead based on real-time tuning, especially for the 16-bit ECUs which have very limited RAM/ROM that we can make use of.

Even before the Enginuity site went down, contributions to Enginuity development had declined quite a bit. The only active java developer (that I'm aware of) right before the site went down was Kascade, who created/develops Enginuity's logger. So a lot of the features planned during the height of development were never realized due to the lack of java developers. I don't know if that will be the case in the future. If it is, then ultimately I'll release LC, per gear wg comp, etc. maybe through a free standalone app (I don't work with Java) and also possibly real-time tuning down the road as well, depending on how much time I have to work on it.

Other than myself and outside of Enginuity, the only other person that is working on ROM hacks that I know of is Freon who has developed his own speed density setup for the 32-bit ECU, so that is something else to look forward to in the future for the openecu community.

Two questions:

Could features #2 and #4 be cut if the user just backs up their factory ROM before messing with launch control, speed density, or anything else? That way, the only patching that would be necessary would be from stock to whatever-modified-ROM. I guess it comes down to one question: is flashing to a stock image from an image with modified code any different from flashing to a stock image from an image with modified data (i.e. modified tables, which people are doing already).

To apply code patches to factory ROMs, would this work?
http://binpatch.sourceforge.net/doc.html
It seems optimistic to think that a simple pattern-based search-and-replace operation would do the trick, but I gotta ask. What other complexities need to be dealt with?

I'm guessing that the patches could alter the ROM's ECU ID, which should make #4 easy enough just using the existing ECU definition mechanisms (at least for tables in ROM).

Two questions:

Could features #2 and #4 be cut if the user just backs up their factory ROM before messing with launch control, speed density, or anything else? That way, the only patching that would be necessary would be from stock to whatever-modified-ROM. I guess it comes down to one question: is flashing to a stock image from an image with modified code any different from flashing to a stock image from an image with modified data (i.e. modified tables, which people are doing already).
I'm not talking about the ROM version, but the version of the feature. For example, it is likely that the features, such as LC, would be refined over time. So, this would need to be taken into account. Everytime there was a new version, the user would would have to manually transfer their tune over to the new ROM, if the hacked ROMs were simply uploaded instead of a more user-friendly patching of the ROM (with the ability to first remove the any older version). Flashing a hacked ROM is no different from any other modified ROM.

To apply code patches to factory ROMs, would this work?
http://binpatch.sourceforge.net/doc.html
It seems optimistic to think that a simple pattern-based search-and-replace operation would do the trick, but I gotta ask. What other complexities need to be dealt with?
I could write the necessary patching application. But as I mentioned, I'm not a java developer, so it would be a standalone application and not integrated into Enginuity.

I'm guessing that the patches could alter the ROM's ECU ID, which should make #4 easy enough just using the existing ECU definition mechanisms (at least for tables in ROM).
Yes, you could modify the ROM id (and change it for each new version if necessary). That is how I would do it if the other functionality is not added to Enginuity.

I'm a java developer, but have never looked at the Enginuity code. Nor do I have any detailed knowledge of the internal workings of the ECU (other than some tuning).

I'd offer up my services to build a patching system. But I think my hill may be bigger to climb than Tea Cup's hill (learning java).

Tea Cups, what are you thinking for this patching system? Are we just talking about sections of binary data and list of where it overwrite or insert it into the ECU hex images?

Thanks for clarifying. Yeah, I overlooked the issue w/ transferring the tune between ROM images. It seems like a similar approach would still work though - apply a patch for V1 of the feature, and then if V2 comes out, reverse that patch (returning the code to stock) and then apply the V2 patch.

Given the pace of Enginuity development, I'm all for the standalone approach. The usage scenario is pretty different from what Enginuity is all about. A user would only need to do this when code updates come out. Changes to the code and changes to the tune are probably pretty much independent. Unless maybe the user wants to update the LC rev limit right after applying the patch, but if the code gets patched with a standalone utility that would only take one extra download/tweak/upload cycle.

Also, if you get the ROM patches out there, maybe that would motivate someone to make the corresponding changes to Enginuity. :)

I'd offer up my services to build a patching system. But I think my hill may be bigger to climb than Tea Cup's hill (learning java).
I have no desire to learn Java. :)

If the Enginuity project continues on its current pace in the future (especially if the site is permanently down), then I'll come up with some tools to support LC,etc. and real-time tuning in visual basic (eventually at least). It might be easier that way, especially for real-time tuning since I know exactly what needs to happen. However, I am no-where near as skilled of a programmer as the Enginuity developers so it will likely not be as polished. But, hey, if it works, it works. ;)

Tea Cups, what are you thinking for this patching system? Are we just talking about sections of binary data and list of where it overwrite or insert it into the ECU hex images?
Yes, although there would need to be a master default which would return the ROM to stock for all past versions. This would be applied before a new version is applied to avoid any conflicts. The patching system is easy. The hard part is the interface and functionality to support real-time tuning.

I'll start looking through the enginuity code. If I decide I want to give the patch manager a shot, I'd need to pick you brain Tea cups. I've got about a bazillion questions already. These don't need to be answered now, but I'm just thinknig out loud... I'm assuming we'll needa system to create/edit "patches". I'm assuming we'll need a system to manage the "patches." I'm assuming we'll need a system to apply and un-apply "patches". I'm assuming some patches may work on some images and not on others. I'm assuming some patches may be incompatible with other patches. Given an unknown ecu image are we looking to have a way to determine which patches are applied to it based on something contained in the image? And so on and so on...

If the Enginuity project continues on its current pace in the future (especially if the site is permanently down),
As I have mentioned - Enginuity is Open Source - so if there are devs willing the project should never go down.

I find what is currently happening with Enginuity.org VERY disappointing. The guys in charge should take a good look at them self because this is not how open source projects are supposed to be run.

If it is website troubles, then that is nothing - I will provide hosting for free. If it is something else, then make it public so we all know what is going on - you'd be surprised at the efforts the community will go to to stand behind an open source project if it is being targeted.

Anyhoo, the longer the site is down the more I start to worry. So to ease my mind, it would be very much appreciated if one of the current Enginuity devs would forward me a link to the latest 0.4.1b source code.

So to ease my mind, it would be very much appreciated if one of the current Enginuity devs would forward me a link to the latest 0.4.1b source code.

See that folder in your Enginuity install directory named "src"...

/me waits


/me waits some more


Yup.

Thanks for pointing that out.

To think I searched google for hours looking for the latest source files and didn't even think to check the Enginuity "program Files" directory - lol.

Cheers :)

I find what is currently happening with Enginuity.org VERY disappointing. The guys in charge should take a good look at them self because this is not how open source projects are supposed to be run.

dude, not for nothing but you have absolutely no grounds to make such insinuations of incompetence.

maybe you'd be singing a different tune if you were here 5 years ago when the only reflash you could get cost you 1,000 dollars.

I'll start looking through the enginuity code. If I decide I want to give the patch manager a shot, I'd need to pick you brain Tea cups. I've got about a bazillion questions already. These don't need to be answered now, but I'm just thinknig out loud... I'm assuming we'll needa system to create/edit "patches". I'm assuming we'll need a system to manage the "patches." I'm assuming we'll need a system to apply and un-apply "patches". I'm assuming some patches may work on some images and not on others. I'm assuming some patches may be incompatible with other patches. Given an unknown ecu image are we looking to have a way to determine which patches are applied to it based on something contained in the image? And so on and so on...
The basic functionality is already there. The switch table allows for patching. It is currently used primarily for the CEL fixes. It would need to be expanded to allow for switch groups for which non-consecutive patches could be grouped together for a particular feature. And, of course, a default switch group that would return to stock all past patches. And then a simple interface to control this (with warnings the damaging effects of launch control, etc.). The patches would have to be rom specific, so they would be arranged as the current ECU defs are -> by rom id.

As I have mentioned - Enginuity is Open Source - so if there are devs willing the project should never go down.

I find what is currently happening with Enginuity.org VERY disappointing. The guys in charge should take a good look at them self because this is not how open source projects are supposed to be run.
The current issue with the site is not the fault of the guys in charge and has nothing to do with any action or lack of action that has been taken by them. As far as development of Enginuity, it is entirely up to how many developers are willing to contribute. You can't fault the developers who have taken the project as far as it has. They just don't have time to work on it anymore due to changes in their personal lives. I don't think the Enginuity site will be permanently down, but it has been awhile since I heard any more news.

dude, not for nothing but you have absolutely no grounds to make such insinuations of incompetence.
Re read my post. I did not insinuate any incompetence. In fact I am more than happy with by the ability of the Enginuity devs and the application they have created.

BUT this does not mean I am not allowed to be disappointed with what is happening atm.

I only just purchased a WRX for the first time, and after looking around found the open source Enginuity application.

Now being pro open-source and knowing how to program, perhaps I wanted to contribute so that the extra features I was seeking would be implemented!

However since there is no project website there is no information for willing devs, no details of svn/cvs, no contact details, no list of current devs, no information pertaining to the source code etc etc - and that is what I find disappointing.

Do you see what I am getting at?

In no way am i saying that the work the devs have done is unappreciated, it isn't - I'm merely interested in the future of the project now that I have happened to stumble across it.

If the devs are too busy (for personal reasons) or just "over it" then that is fine, but there needs to be an avenue for future devs and people who want to contribute to the project to keep it going.

What happens every so often with open-source projects is that when a project is idling in no-mans land (like Enginuity is atm) other keen programmers (such as myself) will take what source code is available and fork the project.

This can be a good thing sometimes (as the new forked project will have some momentum and a fresh approach) but it can also waste resources that could be pooled to make the current Enginuity application better.

Anyhoo, I justthought that needed to be said, so you understand that I am not having a go at the current devs.

Regards
L

I started looking at the source last night. It uses netbeans, their proprietary form files and swing jars. I'm an eclipse guy, so I had to get netbeans installed. I didn't see any ant build scripts, so I'm now sure how they are going about building this into an distribution although it's possible I missed it. It looks like it uses a package called RXTX for serial communications. That appears to be JNI. I started looking into getting that last night as well but I'm not sure what version the code is based on, etc.

There appears to be almost no comments nor any javadoc in the code.

In wrxsti.l's defense, without a home for the development that includes the proper packages, build scripts, tips about getting the development environment setup, and somewhere to control the distributions it does seem a bit daunting.

The site issue is not the fault of any of the devs or the creator (Jared), nor is it possible to solve the problem by moving it to a different host (a lot of people have already offered free hosting but this not solve anything). We can't discuss what the dispute is, as this would compromise what was near resolved (last time I was able to get ahold of Jared, anyway). Meaning that if the details were revealed, you can pretty much guarantee that there will be no more Enginuity site. As I have said before, this has nothing to do with intellectual property and has nothing to do with any tuning companies, such as Cobb and Ecutek, where it could be said that Enginuity might compete with them to some degree. Enginuity is not being bought out either, as far as I know.

...We can't discuss what the dispute is, as this would compromise what was near resolved (last time I was able to get ahold of Jared, anyway). Meaning that if the details were revealed, you can pretty much guarantee that there will be no more Enginuity site...

OK folks, I think it's fair to say that we're not going to be told the reasons why the site is down. Let it go.

You can still get the software at Ken Gilbert's site, you can still get ROMs at Osecuroms, you get info on tuning at openecu.org, and you have access to the people who seemed to do most of the developement on this site and the others just mentioned.

Curiosity is human nature, but really, we've all been politly asked to wait and be patient. Being a pain in Jared's ass won't accelerate the process, and evidently may make it worse. Bugging Tea cups isn't going to get an answer either, and won't bring the site back even if you do get an answer.

This particular topic (why is Enginuty.org down) is showing up in almost every thread here, and it's gotten old. If you want to bitch about something you can't fix, go somewhere else (preferably OT) and do it.

OK folks, I think it's fair to say that we're not going to be told the reasons why the site is down. Let it go.
And as I said, I think that is unacceptable for an open-source project and very dissappointing.


You can still get the software at Ken Gilbert's site, you can still get ROMs at Osecuroms, you get info on tuning at openecu.org, and you have access to the people who seemed to do most of the developement on this site and the others just mentioned.
This is fine for those that simply want to install and tune - but what about those who want information relating to development of the code?


Curiosity is human nature...

And open-source software is supposed to allows you to be curious ;)

And as I said, I think that is unacceptable for an open-source project and very dissappointing.


This is fine for those that simply want to install and tune - but what about those who want information relating to development of the code?


And open-source software is supposed to allows you to be curious ;)
He (Jared) is not doing anything unacceptable. He owes all of us nothing. Not even explainations... As shocking as it sounds, open source doesn't mean "free-ride." It is open source, the source code IS available publicly. That's it. You, me, none of us have no claim on his personal time. He hosted and ran the web site, but he was not, and is not obligated to spend his time, money, or effort in any amount he doesn't see fit.

Want info on developement, ask Tea cups. Post questions asking about developement. Guess what, open source doesn't mean ANY developer is obligated how to teach you to do what they do.

Go ahead an be curious, but demanding something you aren't due is rude. Complaining about it to no positive effect is ridiculous. You've asked, you've been told no, and it's pretty immature to keep asking.

If you feel so strongly about this, why not start your own web site? Create a forum and make it available to the public, like he did. Rather than sit around, complaining that no one is doing the hard, unglamourous part if it, step up to the plate and take that role on. I'm sure most everyone here, including myself would support you on some level with it.

Create a forum and make it available to the public, like he did. Rather than sit around, complaining that no one is doing the hard, unglamourous part if it, step up to the plate and take that role on. I'm sure most everyone here, including myself would support you on some level with it.

Yup. All that's really needed right now (IMO) is a source control server with the last-known-good revision and an administrator who is willing to grant write access to, or process submissions from, interested developers. Far as I know, this could start with the source in the installer that ride5000 is distributing. I'm guessing there won't be a flood of new commits anytime soon, so the administrative overhead should be fairly small.

NASIOC's forum will suffice until Enginuity.org is either revived or pronounced dead.

It would be great to have Enginuity's wiki again, but the information there was aimed more at users than at developers so its absence isn't blocking development.

First and foremost I need to say that this will be my last post on this and I'm sorry if I have said things that have offended the current devs, it was never my goal.

I wish you guys/gals all the best and want to thank you for your time and effort in creating Enginuity for the public. Thank you.

He (Jared) is not doing anything unacceptable. He owes all of us nothing. Not even explainations... As shocking as it sounds, open source doesn't mean "free-ride."
I never said he did and I never said it was.


It is open source, the source code IS available publicly. That's it. You, me, none of us have no claim on his personal time. He hosted and ran the web site, but he was not, and is not obligated to spend his time, money, or effort in any amount he doesn't see fit.

The GPL also stipulates that all make files and any other files relating/required to comilation of the source code ;)


Want info on developement, ask Tea cups. Post questions asking about developement. Guess what, open source doesn't mean ANY developer is obligated how to teach you to do what they do.
I never said it was. Gees mate, please re-read my posts.


Go ahead an be curious, but demanding something you aren't due is rude.

People are allowed to express their disapointment in the current affairs mate, afterall it is a forum. Please explain to me what it is you think I keep demanding so I know how I am being rude.


If you feel so strongly about this, why not start your own web site? Create a forum and make it available to the public, like he did. Rather than sit around, complaining that no one is doing the hard, unglamourous part if it, step up to the plate and take that role on. I'm sure most everyone here, including myself would support you on some level with it.
If you actually take the time to read my posts, instead of focusing on what you can flame, you would see that I mentioned this, but I did not think it was good for the current Enginuity project.

I quote myself just for you - take note of the bold text.:
"What happens every so often with open-source projects is that when a project is idling in no-mans land (like Enginuity is atm) other keen programmers (such as myself) will take what source code is available and fork the project. This can be a good thing sometimes (as the new forked project will have some momentum and a fresh approach) but it can also waste resources that could be pooled to make the current Enginuity application better."


I could set up a new project and fork enginuity (and I am contemplating this atm), but I DO NOT want to re-create the wheel when there are still some active devs working on the current enginuity project who are churning out stable releases.

Anyhoo, I've started digging through what is available and who knows - something fresh may already be in the making ;)

Enginuity's developers weren't exactly "churning out stable releases" before the forum went down. Kascade was doing some work on the logger IIRC so you might want to coordinate with him if you want to work on that stuff but the core map editing stuff wasn't changing much. Qoncept had a large refactoring in mind but wasn't making much visible progress with it. Merchgod was releasing XML updates frequently but that can evolve independently from the Java.

Stuff like ROM patching might benefit from close coordination between XML and Java, but like I said earlier I think decoupling that from Enginuity might help it move forward faster. Then integrate everything when it's stable and only if it's really worth the trouble to integrate. (I personally don't see a problem with using separate tools to modify the code vs. the data.)

Some fresh contributions might be just the thing to get the project moving forward again.

what i'm failing to see is the crux of wrxsti.l's desire to have an "enginuity" open source project flourishing.

what exactly does the current revision lack? what exactly is he looking to do? it's never been stated, and from my perspective he's making much ado about nothing in particular.

what i'm failing to see is the crux of wrxsti.l's desire to have an "enginuity" open source project flourishing.

what exactly does the current revision lack? what exactly is he looking to do? it's never been stated, and from my perspective he's making much ado about nothing in particular.He wants Launch Control. Duh. But any one of the other missing features mentioned in post # 3 above would do.

Development of Enginuity, except for some wideband logging integration, effectively ceased nearly a year ago, long before the website went away. I, too, am very disappointed with the recent pace of development. Who isn't?

And now software developers like wrxsti.l, DocDetroit and others are looking to step in and help out with the Java development. But, without help from qoncept, I doubt they'll get very far and qoncept himself disappeared in November.

The site issue is not the fault of any of the devs or the creator (Jared), nor is it possible to solve the problem by moving it to a different host (a lot of people have already offered free hosting but this not solve anything). We can't discuss what the dispute is, as this would compromise what was near resolved (last time I was able to get ahold of Jared, anyway). Meaning that if the details were revealed, you can pretty much guarantee that there will be no more Enginuity site. As I have said before, this has nothing to do with intellectual property and has nothing to do with any tuning companies, such as Cobb and Ecutek, where it could be said that Enginuity might compete with them to some degree. Enginuity is not being bought out either, as far as I know.In the thread at http://forums.nasioc.com/forums/showthread.php?t=1384505, qoncept explained that the Enginuity website outage was due to "technical problems." Given all the trademarks and domain names out there which incorporate the word Enginuity, I'd guess the technical problems, which shut down the site, prevent it from moving and require sensitive negotiations to correct, arose in the form of a cease and desist letter. Just something to think about in case anyone is considering starting a SourceForge project or something in order to get Enginuity development back on track.

;20642003']
In the thread at http://forums.nasioc.com/forums/showthread.php?t=1384505, qoncept explained that the Enginuity website outage was due to "technical problems." Given all the trademarks and domain names out there which incorporate the word Enginuity, I'd guess the technical problems, which shut down the site, prevent it from moving and require sensitive negotiations to correct, arose in the form of a cease and desist letter. Just something to think about in case anyone is considering starting a SourceForge project or something in order to get Enginuity development back on track.


It has already been said that it wasn't actually due to technical reasons, and lots of people have offered to host it. I guess the community at large would have appreciated a standup answer of 'we are having legal difficulties, please stand by' or something similar. It would certainly help any future developers that may want to hop on. Personally, I've done alot of java gui work in a past life but have avoided even looking at enginuity do the closed nature of the project. (Thankfully I don't have to look at java any more though! php/perl/and c# on the client graphical side of things)

;20642003']He wants Launch Control. Duh. But any one of the other missing features mentioned in post # 3 above would do.

:) ;)

The current issue with the site is not the fault of the guys in charge and has nothing to do with any action or lack of action that has been taken by them. As far as development of Enginuity, it is entirely up to how many developers are willing to contribute. You can't fault the developers who have taken the project as far as it has. They just don't have time to work on it anymore due to changes in their personal lives. I don't think the Enginuity site will be permanently down, but it has been awhile since I heard any more news.

Well, I'll say this is somewhat BS. Not this post in particular, just with at least how I view the entire situation.

*Please note, I have no beef with you in particular* ;)

This is a touchy note as I know I've asked a few people for the latest version of the Enginuity source and posted as much a number of times.

No one answered. Have I pissed people off? I offered to implement further features. I know this is bigger than myself... but "Come on." "Daddys not coming or anything!" A little bit of communication with those that spent hours on Enginuity would have been classy.

I had a new gui ready to go, full support for the UTEC, Tuner Pro integrated mostly, AEM wideband ready to be added and a suite of data smoothing algos that didn't need the *cough* rather experimental 3D util I added (which was to be replaced with a full OpenGL version)

In any case Enginuty is dead to me. Drama llama :(

On the flip side, after dealing with Java outside of the distributed applications and web applications world, its too *mucky* for me for the desktop arena. Its actually a pain in the ass.

I started another project in C++ a week ago that uses components made for easy compilation on Mac, Linux and Windows. I'm not sure what to do with it yet. Rom editing should be done in another week as after I completed all the ROM editing nonsense, I've found myself hacking at GUI aesthetics. Why? I wanted to learn more about how to *hack* ROMs. I suppose ECU Flash code is available technically, but I've never seen a steady easy way to get it. I also needed to get some native coding experience on my Mac.

FWIW with a couple days coding tieing the ROM parsing code to the GUI remaining. EDIT: Maybe a week ;)

Simple Tune (after a search on the web for competing product names.) ;) Yes, it compiles on Linux and Windows as well and its faster than Java. I suppose I'll release some test builds when I have a solid build system. Its simple and not feature filled though and is probably of limited interest outside of my world.

My reason for posting about this, maybe another option.... In any case its an amusing pet project at this point.

http://i189.photobucket.com/albums/z250/tgui_photos/Simple_Tune.png

Anyhoo, I've started digging through what is available and who knows - something fresh may already be in the making ;)

Maybe :)

Tgui, that's freakin awesome man, way to go!

LOL @ the about box.

You say you made a bunch of improvements to Enginuity - why not release your version?

I'm willing to help out as much as I can with this.

Lately I've been poking around various IDE's, IDA, and just reading up on any technical info on openecu and osecuroms I can find trying to get a better grasp on how everything involved works.

I'm no 'developer' , but I do have some basic code knowledge and plenty of advanced computing knowledge. I also have a metric ton of spare time to work with, and I'm a fairly quick learner.

If anyone wants to help me help you, drop me a line.

eric: good riddance to java. :) i never liked it in the first place.

ken

fwiw, if ppl need a copy of a disassembler, send me an email.

Well, I'll say this is somewhat BS. Not this post in particular, just with at least how I view the entire situation.

*Please note, I have no beef with you in particular* ;)

This is a touchy note as I know I've asked a few people for the latest version of the Enginuity source and posted as much a number of times.

Well, I don't have it otherwise I would give it to you (I have no need for it). Have you tried contacting Paul?

LOL @ the about box.

You say you made a bunch of improvements to Enginuity - why not release your version?

About box: LOL yeah, I needed a string in there of sorts to test. Trust me, the program is about as complete as it looks haha. And no, its not telemarketed sp?

Improvements: They're in the source

The refactor? In there because of me. Not used because someone wouldn't sack up and implement a "Rom Tuning Entity" interface. The ROM modifying code is too goddamned coupled to the GUI for me to decipher, so the person that wrote it was to implement. Jonin[CT], how much did I bitch about all this?

As I remember its all under the NEWGui package, so have at it :)

eric: good riddance to java. :) i never liked it in the first place.

ken

fwiw, if ppl need a copy of a disassembler, send me an email.

Hey hey hey! Java rules! For the right application. As a matter of fact, I think Enginuity would rule using a new GUI all together. QT has Java bindings now and would probably make for a killer speed upgrade to Enginuity.

But man, I'm having some fun with C/C++

Count me in as someone who could contribute - I just found enginuity a few weeks ago after I read through the 2007 sti down in compression thread. Its a shame that it seems that development on it has slowed over the last year. Regardless I think its a great program the way it sits now.

I know C/C++ and Java, I've even used that RxTx library that was mentioned iirc.

I would love to contribute if you are using C/C++. I used to work as a C programmer many many years ago. It'll give me a reason to start programming again.

It would be cool to implement some of the functions from AirBoy's interpolation spreadsheet into the tuning software / datalogger.

If hosting is a issue I can host it on a very high bandwidth well connected server at no charge. as a Tuner I want to see real time tuning so bad I can taste it as its a pain in the ass on the dyno.


LC would be nice but a feature I want is the ability top compare lots of tables and copy them quickly.

Exmaple. I've got my base stage 2 map. I want to make a stage 2 from that for say a 04. The tables I'm changing are the same but I got to copy them all by hand and it can take upwards to an hour.

6+ people willing to help, and a free host? Lets roll. :)

Another nice feature for the hacks could be a logic that switches or scales maps based on an on/off or flow sensor signal from meth/water injection. Not sure what you could use as an input though..

Ok well how about this:

Since there are more than enough WILLING developers to keep this going, then there is absolutely no reason that they keep the site going.

Whoever posted above about offering free hosting then, be a hero, do it.

You don't need the original dev's anymore, right?

The bigger loss is the forums and all the data in them. The software is easy to distrbute, as has been proven lately. It's the massed knowledge of the tuning community that's hard to do without.

The bigger loss is the forums and all the data in them. The software is easy to distrbute, as has been proven lately. It's the massed knowledge of the tuning community that's hard to do without.

I would kill to get some of those threads back :( Some awesome data there...

Has anyone asked the old forum admin for a backup, or if one exists?

If there is an issue with privacy, I'm sure it wouldn't be that hard to strip it of usernames and IP's and use member numbers or something.

I just started getting into enginuity, opensource, and refreshing myself on code, right before it went down... sucks to have just a taste of what was on there. :(

Has anyone asked the old forum admin for a backup, or if one exists?



My guess is doubtful that we will see anything ever come about from enguinity again, including the old site and forums. there probably is some $$$ exchanging hands right now.

Ok well how about this:

Since there are more than enough WILLING developers to keep this going, then there is absolutely no reason that they keep the site going.

Whoever posted above about offering free hosting then, be a hero, do it.

You don't need the original dev's anymore, right?

Before any more time is invested in "Enginuity," it is my legal/common sense opinion that it would be wise to figure out at least some idea what issue got the plug pulled on the old site. Pushing forward with "Enginuity" otherwise would be foolish and could result in another site being lost down the road.

Dan

My guess is doubtful that we will see anything ever come about from enguinity again, including the old site and forums. there probably is some $$$ exchanging hands right now.
:lol:

Like I said before, it is a dispute that needs to be resolved. The dispute is with another company (NOT Cobb or Ecutek) and it does NOT involve IP. Mentioning the details such as the company would end any chance at a resolution and you can kiss the Enginuity site goodbye for certain.

I'm not involved in the discussion with this company. I only know what Jared has told me. I haven't been able to get in contact with him lately (I've only talked with him via email in the past), but I know he was in the process of moving and staying at someone else's house who didn't have internet access and that his primary computer was in storage. He's also starting another job while trying to sell his old house. So, this might have something to do with the progress and lack of info. I don't know.

Save your breath- you've given the same information out multiple times and some people just don't seem to get it. I guess there will always be a need to create drama.

Let me try now....I heard the site was sold to a Russian company that writes applications that crack passwords using Nvidia GPUs. They decided that they wanted to start hacking ECUs now...... :lol:

:lol:

Like I said before, it is a dispute that needs to be resolved. The dispute is with another company (NOT Cobb or Ecutek) and it does NOT involve IP. Mentioning the details such as the company would end any chance at a resolution and you can kiss the Enginuity site goodbye for certain.

I'm not involved in the discussion with this company. I only know what Jared has told me. I haven't been able to get in contact with him lately (I've only talked with him via email in the past), but I know he was in the process of moving and staying at someone else's house who didn't have internet access and that his primary computer was in storage. He's also starting another job while trying to sell his old house. So, this might have something to do with the progress and lack of info. I don't know.

Save your breath- you've given the same information out multiple times and some people just don't seem to get it. I guess there will always be a need to create drama.

Let me try now....I heard the site was sold to a Russian company that writes applications that crack passwords using Nvidia GPUs. They decided that they wanted to start hacking ECUs now...... :lol:

WTF, ATI is better!

Save your breath- you've given the same information out multiple times and some people just don't seem to get it. I guess there will always be a need to create drama.
Yeah, there's not much more to say either. Ultimately, we will have to wait for Jared to respond for any further updates.

WTF, ATI is better!

I have a friend that works at ATI. I guess I should have plugged his company.

Next time I start a rumor, I'll be sure to mention them. :)


Mike

WTF, ATI is better!

I agree ;)

I agree ;)

well, maybe with the advent of the 3870 but their previous generation wasn't really anything to write home about. the 8800gt is still a really nice card for not a lot of money.

well, maybe with the advent of the 3870 but their previous generation wasn't really anything to write home about. the 8800gt is still a really nice card for not a lot of money.

I buy what supports Linux well. So all my home built machines are Nvidia powered. On board 6250 baby ;)

/End thread jack