Check In's, News

Check In: Jul 10 2018 (The fancy settings classes I made suck, time to re-write them)

As it turns out, the fancy code that I wrote from ODIF and IM2 that allowed me to add settings to the program with a single line of code and allowed the framework to auto generate setting pages and files, well, it sucks…

I have a plan to get back on track, but it involves re-writing the entire settings section, aswell as adopting it into the application everywhere that settings are read from or written to by the app itself. The problem comes from a combination of how Json treats data and how the settings are defined. The current method worked great when settings were only true/false or a numeric value, the program was able to easily tell the difference between the two, but now there are complex settings like device mapping, lightbar animations, axis tuning, all of which would try to store all the data they needed inside one loosely typed and dynamic variable. This worked for saving the settings as is very good at doing that, but then when it came time to read those settings back into the app from text it started to involve too much special and ultimately flimsy methods.

The solution will be a completely new approach instead of special setting hierarchical classes, the data will be used by the application in regular strongly typed classes. Json can already handle this data in read and write perfectly fine with no modifications needed, the trick will be the other reason I made the settings structure the way I did before, and that is to develop UI middle layers that automatically intemperate the settings hierarchy and show UI pages for them for the user to interact with. I think this can be done with some class property iteration and some added attributes but it is still going to take a lot of work to implement.

Thanks for the continued support and I will keep you guys informed!

1 Comment

  1. Turns out this may be much easier than expected. I already had all the parts in place as IM 1.7 had a “Controller Monitor” window at one time to help view the raw properties and classes created by controllers (which I really need to add back because it is super helpful and awesome looking) and I out of curiosity I passed a profile object to it which has the old native setting types and the darn thing actually populated! Tweeks needed to get the setting names into attributes instead of just properties, but I see a lot of benefits to this unexpected issue and have no doubt this will lead to cool new stuff!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Designed by DSD Consulting Services