Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000322TunixJimStim Pluginpublic2011-10-18 15:582011-10-24 22:02
Assigned ToFred 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24 
Summary0000322: Make JimStim Support More Generic
DescriptionDifferent JimStim's come preconfigured with different patterns and most users don't have a serial card to update them, thus MTX as-is can only ever be correct for some of them, not all. Additionally, for those users that do have that facility, the list is just in the way. I end up clicking through all the items searching for what I want by watching the LEDs on the JimStim, not cool.

What I propose is field for wheel selection with 0-63 value range and text "Wheel pattern number" next to it. Then it'd be useful always. The current situation is misleading and usually wrong and can only lead to version chasing.
Attached Files

- Relationships

-  Notes
dandruczyk (viewer)
2011-10-18 22:09

Not possible to do as megatunix has ZERO WAY to determine automatically if the user changed the wheel patterns as Jean didn't put in a way to change the revision/signature information when updating the patterns, or to query the patterns directly, such that megatunix could decode them and react accordingly.

Not fixing as this feature request could affect only one-two developers at most and they would be savvy enough to alter the MegaTunic datamap for the tab to suite their special purpose setups.
User avatar (0000409)
Fred (administrator)
2011-10-18 22:14

You missed the point. Developers certainly can fix, but normal users will be affected too because new jimstims are sent with different pattern files to old jimstims... anyone that ends up with something different from the mtx defaults, which, btw, are different from the currently supplied defaults for jimstim, is fucked. Make it a number and keep everyone happy :-)
dandruczyk (viewer)
2011-10-18 22:31

The problem with JEAN then, if he is loading different patterns with the same signature/revision that is an API VIOLATION of his own creation and he needs to fix it by using UNIQUE revisions if the api is different (i.e. different patterns).

I suggest he add a call to download all the patterns as well,
dandruczyk (viewer)
2011-10-18 22:33

If the signature/revision call returned UNIQUE info per jimstim release, then mtx interrogation profiles can be updated to accomodate that and tabs tweaked as needed with no internal code changes needed. If he has different API jimstims returnign the same version info, then I cannot help there, as the fault lies with him.
User avatar (0000414)
Fred (administrator)
2011-10-19 06:44

Hmmm, I'm not sure that I agree with that. The patterns are analogous to tunes really. The code remains the same and the interface/API remains the same, just the "PW" and "Timing" change :-) In any case, right now it's painful.

Would you accept a patch to expand the list to the full 64 or 63 options with the number prefixing each one, and "Spare" on the ones that aren't in your particular device? I just want access to all slots and in a predictable way. Though I have to say, the list is already obscenely long, and when you open it to change, it doesn't start off on the one you last had, so you have to search for it again if you want the next one, etc. 64 items will make it VERY long :-)

There are one or more bugs in either JimStim 2.0.3, Jean's win loader app, or the MTX JimStim plugin, but without display of which number it's sending to the device, it's hard to know what the deal is. I suspect the JimStim or the exe, but JimStim support in MTX is kinda new so... :-)
dandruczyk (viewer)
2011-10-23 14:03

Different contents in the device or a different number of choices is an API CHANGE and to be handled properly needs to be detectable, right now, jean's API doee NOT allow this so there is NO WAY for MTX/the user to know for 100% certainty if the jimstim is stock or tainted.

A patch to select the wheel by a number would be fine, however if the user makes a choice that doesn't match the combobox the result is undefined and may try to revert to a "known" (choosable) value, which may negate your effots.

Basically the jimstim API is broken and until jean releases the sources to the world so we can see if it can be improved, the situation is likely to stay as is.
User avatar (0000451)
Fred (administrator)
2011-10-24 10:57

Although I still disagree that it's an API change, and still maintain that it's simply the same as changing your VE curve, could you please just do two things which I know won't take you more than half an hour, and which you know will take me two hours (which I don't have):

1) Add missing entries to the list ("01 EDIS/Dizzy" to "63 Spare" format) and make the list ordered by number.
2) Put a text field that allows simple entry of a number from 0 - 63, with a warning next to it that the names in the list probably do not match their devices default contents.

That way you can continue to maintain that all JimStims have a standard set of patterns, which they certainly do NOT, even off of the show room floor, and I can start getting some real use out of my real world JimStim that never matched your list in the first place...

The API doesn't specify the names, thus putting the names in the GUI is broken in the first place. The GUI shouldn't attempt to look pretty and guess at what the user has. It should just do what it knows is right and let the user look up that page with the listings and/or read their text file, etc.
dandruczyk (viewer)
2011-10-24 14:53

the API specifies the memory layout, by changing the memory layout (different wheel patterns) thus changes the API, but sine the tuning software has no way to DETERMINE things are different that is a major problem.

pushed preceding the wheel pattern names with their numerical match however EDIS/Dist is index 00, not 01 as per [^] [^]
dandruczyk (viewer)
2011-10-24 21:59

Added ability to select pattern by number.
User avatar (0000479)
Fred (administrator)
2011-10-24 22:02

Great, thank you very much! :-)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker