RomRaider

I still definately want to be doing work, and I'd like to lead in some capacity. Just isn't working out, and I'm very likely to just keep getting more busy.

I also don't really think a forum is a bad way to communicate. In my experience, mailing lists are just a huge annoyance. That was supposed to be more or less the point of the dev forum.

A big thing to look in to is what to do with the current release. I've got all of this code for a new release but I'm unable to finish it. Should we throw it out? Divide up tasks among developers so we can get it finished?

What code is this? If its JTable related it wont integrate well with my tuning entity implementation as I rely on some pretty special entities.

EDIT: Nix the above really. Whom ever is to manage all this should take tabs on whatever people have done and know what to delegate.

I don't want to oversee all this. Jared, you sound busy like me. What about the OP?

Drees?

I'd say divide it up Jared. There are several java developers who have volunteered to help out.

If you moved away from coding anything, period, and just moved to managing the project, could you handle that (short code reviews mainly and giving the thumbs up on releases)?

-Gabe

Can you not just use RomRaiderJTable instead of JTable wherever you're using it? It's a subclass of JTable and has all of the original functionality.

I created a new XML definition handler for the new format, new ECU metadata structure and was working on redoing the GUI for individual tables, which is kind of where I left off. There is a whole lot of work in the RomRaider.newmaps package.

Well, thats the thing.. I could handle doing some coding, but its managing the project that takes up the time. I hate to say it. But it honestly is probably best for the project and for me.

I can work with whoever would like to do this to help sort out what I've already done and what I was going to do.

I certainly wouldn't mind chance to lead if no one objects. I have already personally committed to at least a couple of hours an evening to this project. My goals are the same as what I described in the first post. Accomplishing them will require a very gradual approach so here's what I have in mind to achieve the first goal, Finishing v1.5:

I. Everyone PMs me on: What they have finished & What they have partially finished and how much time it will take. I get the feeling the sticky thread "To Do List" is a little outdated. We'll update that with this information and the information in the next step...
II. I'll assess what we have and decide the best 1.5 feature set based on time estimates
III. I'll assemble a timeline and we can all see where things are
IV. I can pitch in and help wherever appropriate. I have a thorough C++/Java, serial programming (RFID I/O and Satellite), and architecture background which can probably be put to use anywhere except for the ECU intricacies itself.

From reading some of the other threads, the most realistic feature list for v1.5 includes:
1) EcuFlash integration
2) RamTune (I heard this was finished)
3) External Logger Modules

I'm not so sure about #3 as I haven't heard too much on this front. Logging integration with wideband devices would be nice, but I think #1 and #2 are more crucial to RomRaider's continued immediate success.

Tgui's UI is something that can be integrated into any release just as easily as v1.5, and since he feels that he won't have the time he wants to dedicate to it, I think that the feature is a good candidate for deferral.

So please, all active developers, please PM me with your status information so I can coordinate.

Thanks,
J

No, not really. I use some higher level more generic data objects since I have to worry about supporting different tuning entities.

I'm not a java developer but I think for v0.5, the overhaul should be the key focus. According to the post by Jared (sticky at the top of this forum), the list below was what was planned for 0.5b. The updates to the parser are key as loading maps is relatively slow right now (and gets slower as we add tables). There is also a substantial memory leak (I can only open about 6-7 roms before I have to shut RomRaider down). In addition, Jared was talking about adding multiple units support with global adjustability (e.g. metric/imperial).

While RamTune rom code is working for 16bit ecus, that is the easy part. Adding RamTune functionality to RomRaider is going to be a major undertaking.

0.5.0b
- Overhaul ECU definition parser with SAX (95%)
--- Add <switchgroup>
--- Add hidden and default attributes to switches
--- Update schema
--- Add hidden tables (5%)
-- Add default values for switches (5%)
- Convert tables to JTable
--- Improve table copy/paste method for spreadsheet apps
- Add hex view for scaling types for immobilizer codes (5%)
- Add character data type (5%)
- <category> tag, supporting nested categories (5%)
- Remove image from 3d graph background
- Switch icons show state
- Add signed integer storage type
- Improve non-Windows shell integration
- Overhaul table loading population
- Make 2D tables vertical instead of horizontal
- Save changes on close prompt
- Add regional number format support
- Autoupdate for ECU definitions

Dear RomRaider Team,

I wanted to address some concerns some of the developers are having with my quick-1.5-release strategy and I want to be clear that I'm not turning away any functionality _whatsoever_. It all looks great from what I've seen in source control and I'm not asking anyone to sacrifice any of it.

If RamTune is ready, the TuningEntity UI is a month or more away, and the current UI can be RamTune-enhanced concurrently with the TuningEntity UI development, then I think we should have at least two releases. The first one has RamTune with the current UI made RamTune-aware and the second one whenever the TuningEntity UI is ready.

I'll need some time to determine how long it will take to make these enhancements, but after looking at some of the code we have in place last night, I think this is workable. It is this reason that I think I can patch the current UI quicker than I can help with a new TuningEntity implementation right now. This statement is especially true if we consider the current UI throw-away code due to the impending TuningEntity design. It won't be as usable, visually pleasing, or functional as a full TuningEntity implementation, but it will allow a timely release with RamTune. Before I start any development, I'll draw up a personal todo list and run it by Tgui to make sure that what I'm doing isn't harder than implementing a TuningEntity UI.



Once RamTune is tested end to end and v1.5 is ready, I'll be able to go around to the boards to "publish" our results and start an awareness-campaign. I know it sounds cheesy, but support in the future depends on our user-base that we build - both by creating a product that truly has inherent value and by telling people about it.

On a personal note, people may wonder why I care about RomRaider the way I do. The reason is fairly simple. I believe that innovation in this area of the market is stagnant. I don't see stock-ECU-modification commercial entities stepping up to the challenge of delivering new features like MAP-Based Fueling or Per-Gear Boost Control. And for what reason? Why? There are literally tens of thousands of Subaru and Mitsubishi car enthusiasts with a significant "do-it-yourself" segment that don't want to go to the extra expense and risk of an aftermarket ECU. Some of us just want to be able to switch injectors or inspect how safely our car is running. I believe the #1 reason for innovation in this market are open source projects like these motivating everyone else. Without naming names, you could almost draw a direct correlation between the timing of some of the market leaders' features and RomRaider's features. What an appropriate name: "RomRaider".

John
Dallas, Texas

I disagree. I think the overhaul should come first. Otherwise you are going to be doing double the work. RomRaider is already well known among Subaru enthusiasts. It isn't like we need to rush development to get name recognition. Certainly, RamTune will bring in a whole lot of new users, but wouldn't it better if the foundation of RomRaider was more solid and the major, glaring issues were resolved first?

I agree with merchgod on this one. Doing double the work to get something out faster is just not logical. Especially when it’s to raise awareness of a project that is not going down the tubes, it’s live and well. If a greater focus can be put on the release of an overhaul that release will on its own bring in new users and allow for new features to be added quicker. Also if you want to bring it new users you need to advertise, even if it’s the current version. Otherwise jradams38 it seems like you have a true passion for getting organized and getting moving with the project, I wish I had the time and the programming experience so I could bring the same help to the table. Also once school is over in mid may I wouldn't mind giving a hand with the marketing and tech writing that is if things over at DSMotorsport don't pick up too much. PM me and let me know what’s going on with those two things.

Eric Mattessich
Eric@xvracing.com

Point taken Merchgod and ejsportcom. Though I think that a full UI implementation is a lot of effort and and the RamTune-aware modification to the current UI isn't, I get the sense that a lot of the developers on the team feel the same way. Part of being on a team is cooperation, so I won't push this farther.

So I think I'm of most help for now to help with the TuningEntity UI overhaul and continue on with the original deployment schedule. Can't blame a guy for tryin' . I'll coordinate with Tgui on this.

J

I would agree if we were doing something similar to Cobb with RT tuning, but we have chosen to go beyond that for the HC16. Instead of a static set of 9 tables, the RT table selection will be dynamic and the user will be able to choose any assortment of RT tables from a collection of 20 tables for live tuning, within the limits of our ram "hole" which can vary by rom. This adds a layer of complexity to RomRaider. Check out the RamTune development plan especially RomRaider functionality and you will understand what I mean:
http://www.romraider.com/forum/viewtopic.php?t=1136

My judgement may stem from my lack of experience with the app so please be patient with me and help me to understand. I just don't see too many UI changes necessary. When a RamTune-enabled ECU image is loaded, it just has additional maps as far as the UI is concerned. These maps might have an extra button that upon clicking, saves their information directly to ECU RAM.

But, like I said, I would rather take advantage of a team effort than try to force any kind of opinion on anyone. If someone wants to elaborate on why the current UI would resist RamTune-awareness changes, let's take the discussion to the UI overhaul thread.

I'm in the middle of understanding the TuningEntity UI and I'm gathering questions for Tgui. If there are any documents or threads that might help with this, please feel free to send my way. I hope to get at least get some test-map UI up and running by the end of the weekend. Maybe I'm being naive and optimistic, but we'll see

Gracias,
J

It is much more than that, however. Please read the plan at the link provided. Again, if it was the Cobb setup, then it would be as easy as what you are talking about. It is not, however. I'm not a software developer and it sounds like you really know what you are talking about, so if I am way off base, please let me know.

Also, since we will be writing to ram real-time, we have to make sure that RomRaider is rock solid. You do not want RomRaider locking up due to a memory leak when it is in the process of writing to a car's ram while the motor is running and at high loads on a dyno. It has to be very reliable.