RomRaider

I'd agree with this.

Too bad no one has organized the effort.

Why are you trying to cause a schism in the way we share files? Why do you want to be "separated"? Why are you trying to implement more proprietary data formats?


Who, or how many, people are going to store that many of THEIR files on YOUR server in YOUR proprietary format, and why? I think I could store hundreds of thousands on my laptop that I tune with. It'd be absurd for any individual to count on a website to get to their own files. This doesn't make the least bit of sense.

The point is applying the same tune to different ROM revisions. Some people don't want to upgrade* to the latest revision for their ECU. Braden, say, could go make a tune for one of the early 02 WRXs, which has bigger fuel and timing maps than later revisions, someone could download it and use it on any 2.0l WRX that we deem compatible. Other than that, adding notes are the only advantages of what I've proposed to the simple hex diff.

The purpose for putting them on the server would be for easier sharing and review by other users. You go mod your car, get a base tune, post your log and people suggest changes, you make them and so on. If you don't like it, don't use it.

* I'll use the term upgrade expecting an argument, but that's not the point of this thread, so guys, please don't bother.


It seems as though you are implying there are already "some" proprietary data formats.

If this is really important-

We already know where all the tables are, and where all the data is, and how to read it.

If you're keen on just saving space, why not just:
1) create md5 or sha1 sums of each table in each stock rom
2) when someone uploads a rom, determine what XML rom def applies and calculate the signatures of each table in their image
3) save just the unique tables in some nice, dense format


Problem solved.

<edit> 4) When someone tries to download a rom, something on the server has to know to spew forth a stock rom with the spiffy unique tables.

I guess that it essentially is a binary diff, now that I think about it more.
</edit>

The real question though is: What's cheaper? Disk space or coding time & cpu cycles?

It was just an idea from previous experience making software. I was pointing out the fact that malicious code could be introduced with my previous code control/diff type DB idea. I am not advocating an RomRaider proprietary format. RomRaider is open source.



For sharing on the net and following the progress of a tune. I like to share all of my good basemaps is all. Of course, full copies would be on my laptop as well. That doesn't mean Joe Blow in Alaska has access to my basemaps. If we had such a feature, experienced tuners such as yourself could more easily share their knowledge by posting all of their base maps while taking up little storage space.



-Gabe

FWIW, Bill is probably correct, ramtune is what we really need, not a better way to share maps.

i have to agree with merchgod here - can we just forget about this non-essential stuff and concentrate on the really important things like ramtune?

I can't count the number of times i've been siting on the dyno wishing i could make a live timing or fuel adjustment, while i've never asked myself "wow i wish i could export a diff of my tune to xml"...

I'm not saying it doesn't have some value, just not right now...

How do you propose we get back on track?

in the meantime, if people want some internet storage space:

here's the ftp site information:

user
ftpupload@ken-gilbert.com

password
(model number of the one-step colder, copper, NGK spark plug commonly used on the ej205, all lower case)

address
ftp.ken-gilbert.com

there's currently 1681.34 Megabytes available, which is enough for a couple of roms, and my transfer limit is 70GB/month, of which i've used about half in the last 24 days.

First would be getting a roll call from the java developers who interested in coding for it and seeing how much time they would have to work on it. I've proposed a simpler version of Ramtune in the real-time tuning thread that would be easier to integrate into RomRaider. I'll update the 'RamTune' development outline if anyone is interested. Since Kascade has released a test version of the logger that does block read/writes of ram, really the only thing left to do is work on the user interface in RomRaider for RamTune barring any major issues, like the overhaul, that need to be done first.

Sorry, didn't mean to come across like such a dick in my earlier posts. I just don't see the current file sizes as a problem at all, nor do I see the advantages (not convinced of any of them) outweighing putting up another barrier between different Openecu projects.

If you are worried about bombing a portion of the ECU that has important code, like boot up or whatever, by someone posting a bum ROM, Enguinity can still check any given ROM to see if any undefined areas have been modified. If we will be flashing directly within Enguinity in the future, this means a difference file really doesn't offer any safety advantage over sharing the whole flash image.

Flashing or not an Enguinity XML required diff file could never offer this advantage over using an agnostic diff XML definition (like I suggested earlier). You have to build the full file in Enguinity anyway before it is flashed, thus Enguinity can check for any items in the file outside its defs. You don't need to tie it to Enguinity defs. You can still do comments as well.

It's already unfortunate that the normal XML defs were never standardized. There are three formats now for the three editors. While none are difficult to recognize. This makes it harder on end users in general. I think doing this yet again is just a pain for users.

I think you guys are right, and any benefits of doing this would be pretty small. Plus, there doesn't seem to be much interest in it, and really, the biggest users are ones that wouldn't really need it at all.

The lack of a standard definition is pretty disappointing. I tried to work with Colby and epifan when I first wrote the original XML parser. If you look at the current definitions, they have a whole lot in common with Colby's. Unfortunately, he just isn't available enough to have the type of communication we'd have needed to pull it off.

Interesting idea, but if this were a vote, I'd have to agree with this assessment. I think the maps and such are already highly portable and though there may be value in this, I think the value of realtime tuning is much greater to the end user.

How to get back on track? Let's keep as much of the project steady as we can and focus on RamTune. I'll go into details about what I think that will take from a software design perspective when I get home today if people are interested.

J

We need someone to define a road map, ASAP. I'm personally getting a tad frustrated as I feel any bandwidth I pour into RomRaider has a relatively high chance of either repeating undocumented work, fulfulling an unwanted feature or blocking something more important I'm not aware of. I don't have the time to mess around

I also don't have the time to coordinate this. Someone needs to step up and take ownership or RomRaider is going to stagnate.

I understand and share a very small part of your frustration.

Back in January, qoncept unilaterally decreed the next RomRaider function upgrade would be an overhaul of its GUI: 0.5.0 GUI overhaul. Never mind that most complaints from actual users about the existing GUI stemmed from a lack of understanding how it worked, due to its poor documentation.

Regardless, Tgui jumped in and did most of the heavy lifting for the new GUI's development. And on April 1, he checked in everything he'd developed for the GUI overhaul up to then, with the hope that the overhaul would soon be completed, given the head start he'd imparted (http://www.romraider.com/forum/viewtopic.php?p=15252#15252). Six minutes later, qoncept responded that he's too pre-occupied with working on his car to do any work on RomRaider in the near future.

Finally, this week in this thread, we learn that qconcept, seemingly sitting out in left field munching on lotus blossoms, has been thinking big thoughts about RomRaider. But completion of the 0.5.0 GUI has apparently not moved an inch closer to the door than it was on April 1.

Meanwhile, Merchgod has already prototyped the ROM changes necessary to implement:
- realtime tuning (RAMtune)
- per-gear boost control
- two-stage rev limit launch control

Merchgod says that none of these extremely substantive improvements to RomRaider functionality can move forward until the GUI overhaul is completed.

jfitzpatrick from Innovative Motorsports contributed a bunch of stuff, too, just like Tgui. As far as I can tell, his work has been completely ignored, as well.

It looks like the RomRaider train is headed for a wreck at the end of the line.

It probably could. My concern was the huge memory leak but that was figured out by someone (crazymikie?). I don't know enough about the Java development to say whether or not the overhaul has to come first or not, but from how it was described it sounded like it would be good idea considering what might happen if RomRaider locked up in the middle of a ram write while RT tuning on a dyno. That is, stability is important.

I don't blame anyone, especially not Jared, for any lack of progress. We all do this for free in our spare time.