[advice] daily deeds polish

roippi said:
Okay, I can replicate this problem using a different compiler. Weird. I'll figure this out.
Click to expand...

The SourceForge page commits KoLmafia to run with Java 1.4 (I believe, SF is unavailable due to heavy traffic at the moment so I cannot verify). If you are using a feature that was introduced later than that then something needs to be reconsidered.
 
Well, that was a learning experience. The problem was some type casting that 1.5+ handled more elegantly than 1.4. Can't use generics (also 1.5) so I just made all the variables explicitly new Integer(). Ta-da.

Also just used an ArrayList where I was using a (very small) hashset. I have no idea which is faster in this case, but it cuts out two imports.
 
Last edited:
Cool.

I'll come up with a better solution to handle different box lengths in various Looks and/or Feels. This one kinda employs some magic numbers.
 
nyah ha! Figured out the programmatic way. setPrototypeDisplayValue() is not the most intuitively named of methods.

I also refactored somewhat. Might want to revert before trying this patch. DisabledItemsComboBox now resides in its own file over in widgets.

If this works for you, lost, I think I'm happy with the code and will submit.
 

Attachments

Yet another patch format. I had to fix it up a bit before Tortoise could figure out what to do with it. Now that I'm past that hurdle, everything looks good.
 
A glance at the patch file shows a formatting issue: in our source tree, we indent with TAB characters, not spaces.
 
So.. I for whatever reason decided to do some more work on daily deeds. I'm not sure DD deserves its own tab in preferences, but I gave it one:

ddprefs.JPG

No, that's not the default layout; you can put any of the built-in deeds wherever you want. Or remove them. Right now I save the layout to a global preference, but some might prefer a user preference.

Once I finish refactoring daily deeds I could add an interface to add your own deeds. Maybe. It's never going to be as feature-rich as StDoodle's custom deeds, that's for sure.

Anyway, feedback always appreciated. I didn't spend too much time on that tab interface (shamelessly stole much of it from another tab), so if devs think that it's against the hola spirit of "say no to adding preferences," I'll understand. I personally think this would be nice to implement, since I always groan a bit when someone asks to add something marginal (like, say, coal paperweight) to daily deeds. With this we could add as much marginal opt-in content to DD as we want.
 
I really like this. It would certainly beat having the Daily Dungeon commented out of my copy.

I do see a potential issue though. When a new item is added for Daily Deeds, most people won't know about it because it won't automatically be added to the Daily Deeds panel. Unless there's a preference for things included (including order I guess) as well as things excluded (order doesn't matter), and anything not in either list when mafia is opened gets added to the end of the included list.
 
lostcalpolydude said:
I really like this. It would certainly beat having the Daily Dungeon commented out of my copy.

I do see a potential issue though. When a new item is added for Daily Deeds, most people won't know about it because it won't automatically be added to the Daily Deeds panel. Unless there's a preference for things included (including order I guess) as well as things excluded (order doesn't matter), and anything not in either list when mafia is opened gets added to the end of the included list.
Click to expand...

Huh. That is a potential issue. It seems like it's a choice between adding a second "deactivated" preference (clunky) or making new deeds strictly opt-in (unfriendly to casual users). I'm not sure which is the better option.
 
lostcalpolydude said:
I do see a potential issue though. When a new item is added for Daily Deeds, most people won't know about it because it won't automatically be added to the Daily Deeds panel. Unless there's a preference for things included (including order I guess) as well as things excluded (order doesn't matter), and anything not in either list when mafia is opened gets added to the end of the included list.
Click to expand...

That was actually the most PITA part of writing my script; integrating user preferences with handling of newly-acquired goodies. If I were to ever re-do the script, I would have several completely separate preferences; one to track what the current default should be (ie default && applicable), one for what it's actually set to, and one for whether it's ever been user-edited. Blech.

I also recommend that if a major overhaul is done, there should be a page that lists everything the character either has or could have access to (ie things like demons become available to everyone who ascends, even if they aren't currently; things like familiars depend on, well, having said familiar).

If anyone wants to go further into details regarding my thought process on DD's I'd be happy to do so. ;)
 
Last edited:
Should be easy to set new items... just add the new setting to defaults.txt as enabled (or not, depending on what the 'standard' desire is likely to be) and it should automatically roll out. But just saying that if we're adding a bunch of new preferences, a mechanism for new-defaults already exists...
 
Theraze said:
Should be easy to set new items... just add the new setting to defaults.txt as enabled (or not, depending on what the 'standard' desire is likely to be) and it should automatically roll out. But just saying that if we're adding a bunch of new preferences, a mechanism for new-defaults already exists...
Click to expand...

Unfortunately (well, in this case at least) if a preference is set, defaults.txt will not overwrite it. Since there's just one comma-delimited preference string that contains all of the enabled deeds, simply altering defaults.txt won't do much for people who already have that pref set. Unless I'm misunderstanding what you're saying.

Refactoring is coming along.. I can specify a deed with DEEDS_TYPE "Boolean", "BooleanItem", or "Skill" without needing a special function within DailyDeedsPanel to handle it. Right now "Skill" can only take single-cast skills, but soon enough it will be able to handle finite-castable skills.
 
Ah, true. I was thinking individual preferences for the values, but if you're just using one overloaded preference for the whole tab, it's basically screwed. :)
 
Well... this can still be done as a single overloaded preference.

You change the preference to a single integer and XOR out the each individual option. To tell you how many options there are currently set you have the first value being a dummy preference which is always on. Then you check to see if the preference value was greater than A where A is the value of the dummy preference. If the preference's value is less than A you add on the new options and the new dummy value.

Was that clear?
 
You must log in or register to reply here.
Back
Top